Windows #261
Windows #261
Conversation
Includes LuaJIT patches to make Windows ffi semantics match the way Howl expects.
|
Re AppVeyor, that would be great. The specs are bound to break pretty fast by mistake otherwise. |
lib/howl/io/process.moon
Outdated
| @pid = @_process.pid | ||
| @working_directory = File opts.working_directory or get_current_dir! | ||
| @stdin = OutputStream(@_process.stdin_pipe) if @_process.stdin_pipe | ||
| @stdout = InputStream(@_process.stdout_pipe) if @_process.stdout_pipe | ||
| @stderr = InputStream(@_process.stderr_pipe, PRIORITY_LOW - 10) if @_process.stderr_pipe | ||
| @stdout_done = nil | ||
| @stderr_done = nil |
lib/howl/io/process.moon
Outdated
| @@ -127,7 +148,14 @@ class Process | |||
|
|
|||
| send_signal: (signal) => | |||
| signal = signals[signal] if type(signal) == 'string' | |||
| C.kill(@pid, signal) | |||
| if jit.os == 'Windows' | |||
There was a problem hiding this comment.
I think that sounds good, that will clean up the diffs a lot.
| require 'ljglibs.gio.input_stream' | ||
| ffi = require 'ffi' | ||
| core = require 'ljglibs.core' | ||
| {:ref_ptr} = require 'ljglibs.gobject' |
There was a problem hiding this comment.
We need to run this PR through the new linter later before merging btw to catch all of these things (e.g. unused var above).
|
Well, at some point I guess I broke processes again...ugh... |
|
Wow, this is really, really weird... So, And it seems that
How does that sound? |
|
I would like to try your Windows patch (and possibly add support for cross-compilation in .travis.yml). Could you please rebase your branch on current master? Thanks. |
|
@kirbyfan64 - is this PR still good? Maybe we can merge even if not everything on windows is fixed? |
|
@shalabhc Uhh...yeah... I still can't figure out what the hell is going on with processes. Meanwhile, I just shoved a nasty retry-three-times loop when the troublesome error appears. Messy, but Windows I/O seems to generally only be solvable with retry loops. As an aside, here's a zip file with the binaries: https://www.dropbox.com/s/3d3extidx56h1t7/howl.zip?dl=0 (created using the new https://www.dropbox.com/s/7whewn5d43ug6o8/howl-setup.exe?dl=0 |
|
@kirbyfan64 tried both the zip file and the installer on my windows 10 machine. The executable just exited without any error, nothing appeared on the screen. (PS: I don't have msys2 installed, thought maybe it is not needed for running it) |
|
Okay guys, this is really, really bad... The problemBasically, everything's broken again, especially since I got a new computer with an upgraded MSYS2 (since the old one kinda...met an unfortunate end):
Here's the fundamental problem I've noticed: using MSYS for this is never going to work correctly. The entire concept of a UNIX environment that's not really UNIX inside of Windows has caused nothing but endless pain, and I'm incredibly sick of trying to mess with it. It surprises me that these broken binaries are what the GTK+ project recommends using... The new planScrew MSYS2. I've stumbled upon this GTK+ building project. The new idea is to instead use Visual Studio for building. I have no clue how this is going to end up, but it can't possibly be any worse. Meanwhile...I literally set up Howl with my entire custom config to work flawlessly under Windows Subsystem for Linux w/ VcXsrv in under an hour. I'll probably write up somewhere how to install it, but if you're looking for a quick way to get Howl working under Windows until I get everything here working, this is probably the way to go. |
|
@kirbyfan64 it sounds like you've had good success with the subsystem for Linux and VcXsrv. Could we (and I really mean you :)) do a detailed write-up of this that we can put on the site as installation instructions? |
Closes #201. I still have to figure out why the tests are failing on Travis, but I figured I might as well put this up so that you guys can review.
TL;DR of this pull request: Windows is weird.