Sublime Forum

Plugin_host crash on Win10 x64


I’m building a new Emmet package for ST3 editor. In next version, I plan to use a small QuickJS module for running JS code in Python ( instead of heavy PyV8.

So far I was able to successfully compile and run in on macOS and Win x32. But when I’m trying to use the same GCC compilation environment for x64 (MinGW-w64, gcc 8.1.0, POSIX threads, Python 3.3.5), plugin_host constantly crashes. After playing with compiler options, I think that it’s one of the standard MinGW libs cause crashes (libpthread? libgcc?): if I compile module without static links, ST simply throws default Python error with failed DLL load, but after I modify PATH env variable to point to MinGW DLLs, it’s just crashes.

My testing environment:
Sublime Text 3 v3.2.2
32 bit: Windows 7 (x32, from, MinGW 8.1.0, POSIX thread, Python 3.3.5: works fine
64 bit: Windows 10 (x64, from, MinGW 8.1.0 (also tried 4.9), POSIX thread (also tries win32 thread), Python 3.3.5: crash
macOS: 10.14 and 10.15, works fine

Is there any details about environment I should use to compile Python modules for Win10 x64?

1 Like


On Windows the Python DLL and extensions need to be compiled with MSVC 2010 if I recall correctly. I’m no expert on MinGW, but my recollection is that you can’t always mix the MSVC ABI with MinGW.



OK, thanks, will try it out and post results here



May I suggest using native Python code instead? Having to proxy something that seems like a collection of simple algorithms instead of doing the implementation in ST’s main plugin language just sounds pretty unattractive and unstable. Emmet is notorious for causing crashes, for example.



It’s hard for me to properly maintain 2 code bases: most popular editors today use JS (or provide system-wide JS bindings, like macOS) for plugins.

Although, if you share some details about crashes, I may consider to rewrite Emmet codebase to Python. The new Emmet 2 is much simpler and smaller (just abbreviation parser and expander), everything else is implemented as ad-hoc solution for every editor:

I know that there are many issues with PyV8 downloads, which is why I’m switching to QuickJS, which is much smaller and will be embedded right in ST module



OK, I give up: MSVC 2010 doesn’t support C99, which is used in Py-QuickJS. It’s not worth it, will rewrite core codebase to Python.

Thank you for your help!



The next dev cycle should be starting soon, and there are definitely going to be some new features that will be attractive to plugin authors. Unless you are planning on writing and releasing the new version in the immediate future, you may want to wait a little.



Maybe “crashes” isn’t exactly accurate and it’s mostly freezing due to problems, but in the forum it’s been a common working solution to disable Emmet.

Also this issue in some new ST build earlier this year: Emmet Users on Windows Dev Builds?

Not to mention that it overrides default key bindings that you need to opt-out. (Or maybe that changed a while ago.)



Oh, that sounds interesting :smirk: any details about upcoming changes (maybe in private)? I use most of ST api heavily in new plugin (phantoms, popups, marked regions, event listeners etc.), it will be a pity if it’s not necessary.

Anyways, I have a lot of things to do before release so I can wait



Yeah, these are exactly the reasons why I made a full plugin rewrite. Most of these things are already fixed, everything else will be configurable via web-site, including keyboard shortcuts (which are not enabled by default).



I had some success in compiling pywinpty for sublime with mingw so I believe it’s doable in some sense.




I took some time to compile quickjs for windows x64 and it worked.

The following snippet is what I used. Hope it will help you.

conda config --set allow_conda_downgrades true
conda install conda=4.6.14 . # otherwise we cannot install python 3.3
conda create -n py33 python=3.3 -c conda-forge
activate py33
conda install m2w64-toolchain
conda install libpython
# go to path to quickjs

# patch to make it python 3.3 compatible
# ie, replace `CONFIG_VERSION = ....`

python build_ext -i --compiler=mingw32
python bdist

# unzip dist/ to Sublime Text

# copy from to Sublime Text

# everyting should be working
1 Like


I’d prefer a native python implementation of Emmet.



Anyway, I didn’t mean to encourage moving Emmet to javascript. I was just curious if quickjs could be compiled on windows.



Nice, thank you! Maybe I’ll you use it for some other project.
For now, I’m in the middle of porting Emmet core to Python, I think it will be the best solution



Just asking, what are the benefits of porting the code base to python ?



No need for a JavaScript VM running within the python VM, obviously. It has been a reason for issues and crashes many times.



How does this affect performance ?