search

ndmitchell / ghcid

Very low feature GHCi based IDE
Other
1.13k stars 114 forks source link

Reloading doesn't work quite often #310

Open asheshambasta opened 4 years ago

asheshambasta commented 4 years ago

I can reproduce this quite reliably. It seems to me that the project doesn't get reloaded most of the time between ghcid restarts. My workflow is the following: 

  I'd like to: 
  - ignore warnings 
  - use `stack ghci` as the repl _command_ 
  - run a particular `--test` command.
    The test command in this case simply fires up my main function with some arguments. 

--- 

However, ghcid simply doesn't seem to detect file changes anywhere in the project for most of the time, and I need to keep restarting it to get it to start reloading on changes. 

Version info:

Auto reloading GHCi daemon v0.7.5


I'm using NixOS:

Linux quasar-nixos-tr 5.4.6 #1-NixOS SMP Sat Dec 21 10:05:23 UTC 2019 x86_64 GNU/Linux

ndmitchell commented 4 years ago

Can you pass --verbose and share the full log. That will tell us what files it is waiting on and see why it's broken.

asheshambasta commented 4 years ago

@ndmitchell thanks for the quick response. Here's the output with --verbose, and as the logs at the end say: I made some changes to src/Network/Frontend/Login/Lib.hs and it seems to me that ghcid catches the notification (via changes in TAGS instead of the .hs file) but doesn't restart the :main function.

I'm unsure of the inner workings of ghcid so I'm not sure if this helps.

asheshambasta commented 4 years ago

Another strange thing I'm noticing is that changes in my ~ are being picked up: 

%WAITING: Notify signaled
%NOTIFY: Modified "/home/ashesh/.histfile" 2020-03-16 09:43:41.875765261 UTC False
%WAITING: Notify signaled
%NOTIFY: Modified "/home/ashesh/.histfile" 2020-03-16 09:44:08.402526586 UTC False
%WAITING: Notify signaled
%NOTIFY: Modified "/home/ashesh/.histfile" 2020-03-16 09:44:11.965825107 UTC False
%WAITING: Notify signaled
%NOTIFY: Modified "/home/ashesh/.histfile" 2020-03-16 09:45:04.60124685 UTC False
%WAITING: Notify signaled
%NOTIFY: Modified "/home/ashesh/.histfile" 2020-03-16 09:46:03.79569727 UTC False
%WAITING: Notify signaled
%NOTIFY: Modified "/home/ashesh/.psql_history" 2020-03-16 10:08:18.717236727 UTC False

Is that expected?

ndmitchell commented 4 years ago

The abstraction Ghcid uses says that if anything in a directory changes it then checks all files and continues on if any of the interesting ones change. That's partly for cross-platform happiness. Since your .ghci file is in ~ it watches the home directory, but these fire a change which is immediately ignored, so fairly cheap.

I think the issue is that by default ghcid won't run the tests if there are warnings. You can override that behaviour with --warnings. Does that solve it?

asheshambasta commented 4 years ago

@ndmitchell thanks, I now understand the reasoning behind watching ~ for changes. As for the warnings, I do have the -W in my ghcid-run.sh but that doesn't seem to do the trick. It seems to me that the reloading works some times: and it continues to work for that session. And sometimes it just doesn't. I have to keep restarting ghcid-run.sh until it reloads on each change.

ndmitchell commented 4 years ago

Is the -W getting to ghcid or not? I just pushed a patch to HEAD that makes ghcid show the arguments it got when run with --verbose. Would be good to ensure that the warnings and test really do get through.

Is the trace you attached earlier for one of the times where it got stuck? It said it was watching the files::

%WAITING: /home/ashesh /home/ashesh/code/homebot/rpi/motion-detect-camera /home/ashesh/code/homebot/rpi/motion-detect-camera/app /home/ashesh/code/homebot/rpi/motion-detect-camera/src/Cluster /home/ashesh/code/homebot/rpi/motion-detect-camera/src/Control /home/ashesh/code/homebot/rpi/motion-detect-camera/src/Lib/Parse /home/ashesh/code/homebot/rpi/motion-detect-camera/src/Network /run/user/1000/haskell-stack-ghci/7b57b5b9

Is the file you were trying to modify in one of those directories?

Can you also try passing --poll as that avoids the file watching and instead polls for files.

asheshambasta commented 4 years ago

@ndmitchell I'm assuming the -W is getting to ghcid: the code has several warnings and by default the behaviour is only to run --test when there are no warnings.

And yes, the trace was when ghcid was stuck. I'm not sure if the directories being watched are watched with any depth at all: or is the watching only at the depth of the directory? Or are we watching dirs. recursively? If we're watching files recursively, the answer is yes, the file is in the same hierarchy. If not, then it isn't, but it is somewhere in ./src.

I'll try with the --poll and later with the HEAD and report back.

asheshambasta commented 4 years ago

@ndmitchell I can confirm that the --poll option also doesn't work for me. I've not yet tried your changes from HEAD but it seems to me that the reloads work properly (without --poll) for the first few times and then completely stop after a while. And sometimes the reloading doesn't work at all and sometimes it does for hours. Restarting the ghcid process several times fixes the issue and then it gets stuck again.

In this case the codebase has no warnings, so running ghcid without -W and --test reloads okay. The --test command fires up a Wai application server which is a never ending process. So my guess is that --test is a process that should exit (was that the intention of the --test flag?)

In any case, it seems to me that the fact that reloading works intermittently points to some problem.

If you can point me to the relevant part of the code or to where I can get started, I wouldn't mind taking a look myself.

ndmitchell commented 4 years ago

It doesn't watch recursive directories. The --test program is expected to exit, and if it doesn't, we send a ctrl-c to it.

From the sounds of it, it seems that ghcid wasn't watching where you were changing? It watched a parent directory, but not the final in question. So is it always not watching there? Or do you sometimes change files it is watching? Assuming the problem is it isn't watching the right place, then you need to figure out why it isn't watching there. Generally it watches by looking at error messages and :show modules to figure out what is loaded. All of that is in the trace, so the thing to do is figure out why it doesn't think your file is interesting. And that's likely to be a mis-parsed error, an unreported dependency or something similar. While you could go to the code, the verbose output is usually more illuminating until you have identified what's wrong.