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!

[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.

frou/modd@4ad97bb

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

frou@faf340b

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"

[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