modd -> devd communication doesn't work on Windows

[lamarqua]

I'm trying to get a simple setup for an Elm single page app.

I've got this modd.conf

@shell = exec

src/**/*.elm {
    prep: elm-make src/App.elm --warn --output elm.js
}

elm.js index.html main.css {
    daemon: devd -m .
}

Any changes to the elm files successfully trigger a recompilation into elm.js. No problems here. The changes to elm.js, index.html and main.css are also sucessfully detected by modd: >> sending signal hangup appears any time I change one of these.

My problem is that the livereload functionality somehow doesn't work. A breakpoint inside .devd.livereload.js at the onmessage callback shows that the websocket code never gets executed.

Livewatch does work fine whenever I run devd standalone, and the same breakpoint gets hit without a problem. I also tried a bunch of options for devd, but none changed the result.

Getting the same problem with Chrome and Firefox dev edition. I'm on Windows 7 x64 Pro.

If, however, I run devd in livewatch mode separately from modd (with the daemon line removed from the conf), I get whatever I wanted to achieve. But that seems a bit silly.

I'd be happy to provide additional info or help debugging. Thanks!

[cortesi]

Hi there. Devd injects the livereload payload into the section of the page. Does the page you're serving have one?

[lamarqua]

Yes, it does.

[cortesi]

OK, could you please verify for us that the livereload payload is being injected into the page? Do that by viewing source, and looking for code like this in the header section:

<script src="/.devd.livereload.js"></script>

If the code is there, could you please look in the browser dev console and see if you see any issues with loading the payload, or with executing it (errors on console). If the code is NOT there, could you please show me what the initial section of the page looks like (that is, everything up to the body tag), so I can try to figure out why it's not there.

[lamarqua]

The code is there and is run (verified by running through the debugger). The console shows:

.devd.livereload.js:131 DevdReconnectingWebSocket attempt-connect ws://devd.io/.devd.livereload
.devd.livereload.js:147 DevdReconnectingWebSocket onopen ws://devd.io/.devd.livereload

[lamarqua]

Erm... has the separate modd calling devd w/livereload setup ever worked for anyone on Windows?

daemon.go calls Process.Signal On windows this function is implemented in exec_windows.go

func (p *Process) signal(sig Signal) error {
    handle := atomic.LoadUintptr(&p.handle)
    if handle == uintptr(syscall.InvalidHandle) {
        return syscall.EINVAL
    }
    if p.done() {
        return errors.New("os: process already finished")
    }
    if sig == Kill {
        err := terminateProcess(p.Pid, 1)
        runtime.KeepAlive(p)
        return err
    }
    // TODO(rsc): Handle Interrupt too?
    return syscall.Errno(syscall.EWINDOWS)
}

🤔

So it seems that go on Windows doesn't handle anything else than SIGKILL...

(Which is weird, since, after testing with modd with daemon +sigterm: devd -m . in the config, the devd subprocess is killed... so I must be wrong somewhere...)

Looking up the go issues on signal handling on Windows as well as MSDN documentation, it seems that signals basically don't work except for very specific cases. (I'm still confused as to what works and what doesn't, so I'll read up about the situation and add further comments here. I'll also get a go debugger set up.)

[frou]

What's the conventional way to tickle a child process on Windows? Do a dummy write on a pipe?

[frou]

Hello @lamarqua and @cortesi

On my fork, I've given modd the ability to send signals on Windows using "piped signals" (made up name). When necessary, modd can establish a pipe to the stdin of daemons it starts and will write the string representation of the signal it wishes to send as a line on that pipe.

https://github.com/frou/modd/commit/4ad97bbb7cf065d34f2e6134e86221c62dbc0172

I've also updated devd to be able to consume SIGHUP in that way to cause a livereload.

https://github.com/frou/devd/commit/faf340b584fa9df5a079f343bff1eaba5b007a2c

What you think?

[cortesi]

@frou These sound like valuable additions. If you don't mind, could you lodge a PR on the modd project to begin with, and we can get the ball rolling?

[frou]

@cortesi - Yep I will when I get a chance. For starters, it needs refined a bit because Go's string representation of the signal values has an odd mix of tenses, e.g. "quit" , "killed" , "interrupt" , "terminated"

[ronjouch]

Here, devd 0.8 breaks livereload under Arch Linux (which used to work fine under 0.7). Script is injected to head but my browser's console shows:

Firefox can’t establish a connection to the server at ws://localhost:8888/.devd.livereload.
The connection to ws://localhost:8888/.devd.livereload was interrupted while the page was loading.

@cortesi @frou @lamarqua I'm confused by this issue and I don't have a modd.conf (should I have one, if my use case is to reproduce 0.7 behavior?). Am I facing the same problem as what's reported here, or should I open a separate issue? Especially, I read several mentions of Windows here, but I run Arch Linux.

[frou]

@ronjouch modd is a completely separate program that is optional, so you do not need to worry about it or its config file. This issue is indeed about the peculiarity of interprocess signals on Windows, so your problem is something else.

[ronjouch]

@frou thanks, and sorry for the noise. In the meantime another user created a report similar to mine: https://github.com/cortesi/devd/issues/87

[cortesi]

I wonder if hacking up a custom signalling system for Windows is somewhat obsoleted by WSL now? WSL works very well, and modd + devd can run there with support for native signals. Thoughts, anyone?

[frou]

That's probably part of a wider question in Windows developer land. Namely, is the native Windows CLI a lost cause? And is it unreasonable to expect all OSS-aware Windows developers to be WSL users? (AFAIK it's still an optionally-installed feature)

[lamarqua]

I wonder if hacking up a custom signalling system for Windows is somewhat obsoleted by WSL now? WSL works very well, and modd + devd can run there with support for native signals. Thoughts, anyone?

I might be a luddite but I still use Windows 7