--file-watch loses edits, and should more eagerly kill GHC if there is a new edit

[ezyang]

1. Run 'stack build --file-watch', wait to quiesce
2. Edit a file
3. While stack build is rerunning, after it built your file but before it finishes rebuilding the rest of the project, edit the file.

Expected result: Stack forcibly terminates the existing GHC build and starts again.

Actual result: Stack finishes the old build, and doesn't rebuild.

[borsboom]

I agree. At minimum, it should start a new build immediately after finishing the "old" build. Terminating the "old" build immediately would be great too.

[snoyberg]

See #822 for why we have the current behavior

[borsboom]

Well, that's annoying, but can't think of a way to fix it. I guess we should at least document the behaviour. Probably just here: https://github.com/commercialhaskell/stack/wiki/Build-command#other-flags. Adding it to GUIDE.md seems like overkill.

@snoyberg, would having --file-watch only watch files that would actually cause stack build to do work (e.g., files mentioned in the packages' .cabal files and any extra modules/TH dependencies we detect) help with this at all? Is there a reason --file-watch wasn't implemented that way in the first place?

[snoyberg]

It might help eliminate most of the cases, but infinite loops would still be possible. Also, I think some users (maybe even @ezyang) were confused as to why stack would start rebuilding immediately after it finished a previous build. Your suggestion of killing the previous build could work, but I wouldn't trust the semantics of the underlying processes to get everything right with a kill.

[ezyang]

I don't understand the diagnosis in #822. Why did TH cause an infinite loop? Is it because Stack is doing something fancy for dealing with TH dependencies?

I do remember Stack would continually rebuild after finishing a previous build. I prefer the current behavior to Stack finishing the entire build, and then trying again on a "stale" dirty flag. But killing GHC would be best.

Why isn't sending a C-C to GHC something you expect work? I expect people do this a lot and GHC can handle it reasonably.

[snoyberg]

Because TH has the ability to modify files, and it might modify files that are dependencies of the build (either source Haskell files, or addDependentFile).

I'm not sure how much I trust killProcess on Windows. In addition, getting all of the async exception logic working reliably in stack could be very tricky.

[ezyang]

I still don't understand. The cited example doesn't edit any files in the TH splice. Perhaps this was an interaction with #912? If TH is in fact editing hs source files... well, I don't think there's anything wrong with Stack infinite looping. In fact, how do you distinguish that from a human editing the file? (Stack could take a hash of the file and consider it unchanged if the hash doesn't change?)

Re async exception logic, wouldn't it be a matter of allocating a specific Haskell thread to execute the command / receive the async exception?

[drwebb]

I been struck by this behavior quite a few times (Disclaimer: I use stack build --test --file-watch as a poor man's test runner). Never the other
issue, though I'm sure it's annoying too. I'd say fixing --file-watch so
it doesn't loose edits sounds like a much more common occurrence, and even
as a trade-off file watch needs to be off while you have build errors in
Template Haskell splices. So if I could live in one world or the other and
it's a limitation that we choose one for the moment, I'd fix this issue in
favor of the other.

On Thu, Sep 10, 2015 at 4:22 PM, Edward Z. Yang notifications@github.com
wrote:

I still don't understand. The cited example doesn't edit any files in the
TH splice. Perhaps this was an interaction with #912
#912? If TH is in fact
editing hs source files... well, I don't think there's anything wrong with
Stack infinite looping. In fact, how do you distinguish that from a human
editing the file? (Stack could take a hash of the file and consider it
unchanged if the hash doesn't change?)

—
Reply to this email directly or view it on GitHub
#975 (comment)
.

Tristan Webb PhD
Haskell Application Engineer
FP Complete
San Diego, CA
M: 619-452-9545

[snoyberg]

Closing as wontfix.