search

howl-editor / howl

The Howl Editor
http://howl.io
Other
712 stars 68 forks source link

Windows build #201

Open robert-nix opened 8 years ago

robert-nix commented 8 years ago

Changes: https://github.com/howl-editor/howl/commit/7a551fbc3b2a49da0fc5e3bf4219b2198b8863ab

Related to #100.

I was interested in doing this port for fun, so this changeset is just to show what I did. I did not attempt to run the tests, I only opened some files in the editor.

The build environment is msys2's mingw32 environment. I had to change LuaJIT's Makefile to build the .a file (change BUILDMODE in src/Makefile from mixed to static). There are a ton of gtk dlls that would need to be packaged to make a release out of it.

The biggest pain by far is the fact that LuaJIT's ffi doesn't function the same on Windows as it does on Posix systems with regards to being able to load a name without knowing the module it comes from. I solved this hackily by adding over 9000 exports to the output binary (objdump and regex). gcc doesn't like this as much as I don't like this.

robert-nix commented 8 years ago

Apparently something unrelated to the aux folder issues still hangs trying to read from \Device\Serial0. I worked around that temporarily by running dd if=/dev/zero of=/dev/ttyS0 to lock up the file, but whatever opens that file will need to be tracked down for a permanent solution.

nilnor commented 8 years ago

I realize that this is a quick and hacky start, but wow - it's fantastic to see the progress you've made in such a short time. You must have been busy :) And great to see it actually up and running! I'm not a Windows user myself, but will of course help out with anything I can, so let me know. A future Windows release would be great of course, but "just" making it build cleanly on msys2/mingw32 would be an awesome start.

refi64 commented 8 years ago

This is absolutely amazing! I had been wanting to try something like this for some time, but Windows decided it was going to stop booting...

shalabhc commented 8 years ago

I just wanted to chime in and say how awesome this is - excellent work!

robert-nix commented 8 years ago

I made some improvements: https://github.com/howl-editor/howl/compare/master...Mischanix:windows-build

The idea behind the lj_clib patch isn't appropriate for upstream LuaJIT because it changes the semantics of ffi on windows such that ffi.load will leak module handles. This doesn't matter for howl because howl never uses ffi.load, instead relying on pkg-config to load all the shared library dependencies when the program starts.

robert-nix commented 8 years ago

build instructions:

Works on Vista+

refi64 commented 8 years ago

Wait, were you able to remove the whole giant-file-of-exports thing?

You are seriously awesome for doing this. I feel like I want to hug a bear or something right now...

robert-nix commented 8 years ago

The aux problem has been fixed by 18a95ef, but for packaging an installer is still needed to create the lua files, because neither Windows' default .zip utility nor 7-zip can successfully create a folder named aux.

refi64 commented 8 years ago

Maybe we should just rename the aux directory to something else...maybe auxl or support?

nilnor commented 8 years ago

I'm open for re-arranging the code to avoid the aux name, probably by just moving the contents of aux into util instead.

@Mischanix Do you have a sense of how well things work in general with the current fixes? E.g. running processes, normal editing functionality, etc?

Re the LuaJIT patch, that's an impressive work-around :) I'm also however thinking about the possibility to actually use ffi.load from Howl. Prior to 0.4 the Scintilla dependency required the Gtk libraries to be linked in anyway, so it was very convenient to just export things and use ffi.C to access them. After 0.4 we don't really need to have the libraries linked in, but could switch to explicit loading instead using ffi.load. I'm thinking this would remove the need for the LJ patch, and would also mean that we no longer would require the Gtk development libraries at build time, only the runtime libraries when running. What do you think from the perspective of the Windows port?

robert-nix commented 8 years ago

Just tested using go-fmt, it fails trying to call g_unix_output_stream_new (the windows version of gio uses GWin32OutputStream instead). exec seems broken in more special ways, it only finds commands from the last directory listed in my $PATH, and running anything from exec fails with "No such file or directory". General editing functionality seems to all work fine, though. File browsing is a bit annoying since the interface doesn't understand Windows paths well (most notably, drive letters are a pain), but I can get it to do what it is meant to do with a few extra keystrokes

Switching to using ffi.load should work perfectly fine with the patch still in place, and the patch could be removed when ffi.C is only being used for the application exports. The only concern with using ffi.load with the patch is not being able to unload modules that are loaded via ffi, but howl never has reason to unload those modules anyway.

refi64 commented 8 years ago

@Mischanix The exec issues could be due to here and maybe here. They both attempt to split PATH on :, but on Windows, it should be a ;.

nilnor commented 8 years ago

All right, that all still sounds very positive :)

I'm not surprised about the process things causing problems, as that's one area that differs a lot between the two platforms. As you say there's the GWin32OutputStream for the Windows platform corresponding to the currently assumed GUnixOutputStream, so perhaps adding in support for that and choosing it would take this as a bit further (in howl.io.{InputStream,OutputStream}). But another issue that I also think could be your problem in your comment has to do with how howl.io.Process launches commands, where it runs them using /bin/sh unless the command is explicit. For Windows I guess this would run the cmd shell instead? Anyway, I'll mention that GIO provides a newer interface as well that's more portable, GSubProcess. There's some wrapper support for that already, but I didn't go that route as that's a newer API addition and it would mean cutting of support for older GIO versions and by extension older linux distro versions. Time has passed though, so perhaps now that's another alternative, but that would require more extensive rework.

The other things doesn't seem like show stoppers though, the aux module we can remove, and making sure we handle paths correctly does not sound like it should be undoable.

refi64 commented 8 years ago

Unfortunately, I can't seem to get this to work on Windows 10:

Ryan@DESKTOP-6B2AU8L MINGW64 ~/howl/src
$ ./howl.exe

** (howl.exe:6032): CRITICAL **: Failed to run script: C:\msys64\home\Ryan\howl\lib\howl\init.lua:160: C:\msys64\home\Ryan\howl\lib\howl\init.lua:140: C:\msys64\home\Ryan\howl\lib\howl\init.lua:72: cannot resolve symbol 'g_file_test': The specified procedure could not be found.

C:\msys64\home\Ryan\howl\lib\howl\init.lua:140: C:\msys64\home\Ryan\howl\lib\howl\init.lua:72: cannot resolve symbol 'g_file_test': The specified procedure could not be found.

Ryan@DESKTOP-6B2AU8L MINGW64 ~/howl/src
$
shviller commented 8 years ago

Unfortunately, I must say that on Windows 7 I'm having the same error as kirbyfan64.

Also, for those attempting to follow Mischanix's instructions, make sure you have msys2's version of tar (and probably wget too; as opposed to, say, GnuWin32), otherwise it will fail to install LuaJIT.

Another thing is that in my case, git checkout failed due to the whole aux thing (guys, thank you for being willing to rename it!). The only way I managed to get the actual sources was to download the zip from Github, create the offending dirs manually using msys2's mkdir -p, and then unzip -u (again, msys2's unzip):

cd howl
mkdir -p lib/howl/aux
mkdir -p lib/ljglibs/aux
mkdir -p site/source/versions/0.3/doc/spec/aux
mkdir -p site/source/versions/0.4/doc/spec/aux
mkdir -p howl/spec/aux
unzip -u howl-master.zip
nilnor commented 8 years ago

The aux directory has now been renamed, so at least one hurdle is gone :)

refi64 commented 8 years ago

Just tried again. Now it segfaults. :(

GDB says:

Program received signal SIGSEGV, Segmentation fault.
0x00420f1f in lj_vm_exit_interp ()
(gdb) bt
#0  0x00420f1f in lj_vm_exit_interp ()
#1  0x7feafab4 in ?? ()
Backtrace stopped: Cannot access memory at address 0xfd1615ec
(gdb)

So it's some kind of memory corruption...

I'll try building LuaJIT with assertions enabled and see what happens.

refi64 commented 8 years ago

IT WORKS!!! For some weird reason, I just had to rebuild LuaJIT.

Do note that some of the fonts look a little odd, and Pango said:

(howl.exe:8180): Pango-WARNING **: couldn't load font "Liberation Mono,Monaco Bold Not-Rotated 11", falling back to "Sans Bold Not-Rotated 11", expect ugly output.

(howl.exe:8180): Pango-WARNING **: couldn't load font "Liberation Mono,Monaco Not-Rotated 11", falling back to "Sans Not-Rotated 11", expect ugly output.

(howl.exe:8180): Pango-WARNING **: couldn't load font "Liberation Mono,Monaco Bold Italic Not-Rotated 11", falling back to "Sans Bold Italic Not-Rotated 11", expect ugly output.
refi64 commented 8 years ago

Seems like I spoke to soon. :(

Whenever I open the file with CRLF line terminators and hit "save", Howl screws up the line endings and inserts an extra CR every time I save...

shalabhc commented 8 years ago

For fonts, try copying the ttf or otf files into the fonts folder and restart?

nilnor commented 8 years ago

@kirbyfan64 I'm guessing that's because we didn't use the wb mode when writing (just changed this in 33a224f). Would be nice if you could try with locally modifying file.moon similar to the commit and see whether that solves the extra new lines problem. As for the fonts it would be interesting if you could pick a nice default font on Windows and then try appending that to the list of default fonts (see https://github.com/howl-editor/howl/blob/master/lib/howl/ui/theme.moon#L180).

refi64 commented 8 years ago

@nilnor I just merged in the Windows changes with Howl's master, and the line endings work correctly now. I'm playing with the fonts still.

Unfortunately, 80f4371f3426f4a1533eaab2e1fa7fb9f6fdd108 doesn't fix the aux issue; Howl still fails when trying to compile aux.moon. Because Windows.

refi64 commented 8 years ago

So, this is what I've got so far for the fonts: