Closed przemo-hemmersbach closed 4 years ago
I'm also unable to see the expected behavior described above. Similar to the OP, I'm on Windows 10 trying to run the minimal example pretty much using the same versions. Works great on Mac though!
EDIT: If I run it in powershell or command prompt as opposed to Git Bash, it actually does work great on Windows!
ANOTHER EDIT: Running in Git Bash for Windows does not output anything UNTIL you hit CTRL+C. I'm not yet sure what to make of that, but wanted to provide that piece of info in case it helps anyone come up with a fix.
I've used cabal 3.0 and executed final .exe
by hand in cmd.exe
still no luck.
Pooling manager will trigger action while taking from 1 to 7% of CPU and 50MB of ram.
Non pooling manager will not trigger action, no matter what.
Tested both by just swapping that boolan in ManagerConf
@klcantrell Which GHC do you use? Which specific version of hfsnotify?
SOLVED:
Turns out my cabal config was missing -threaded
flag for GHC.
I assume that my stack configuration was also incorrect and -threaded was never really passed to GHC.
With that flag and no changes to code, app works with less them 4MBs and takes 0.1% - 0.3% of CPU.
Great to know that -threaded
flag is required for this to work. Faced a similar issue and found your comment helpful @przemo-hemmersbach
Sorry for the delay, I missed this when it was posted in March.
For what it's worth, we put this requirement front and center in the readme: https://github.com/haskell-fswatch/hfsnotify
I'm open to suggestions/PRs on how to surface it better.
https://hackage.haskell.org/package/fsnotify
Hoogle also shows requirements correctly.
Failsafe improvement would such Cabal/Stack configuration in hfsnotify that if dependent code do not use -fthreaded, it will fail cabal build on windows. However, I neither know if its possible at all, nor how to do it if it's doable.
I was aware of requirement, and I though (incorrectly) that this flag is enabled. User error.
Versions: filenotify ==0.3.* (lts-15.5) Windows: 10 Professional stack: 2.1.3
Steps to reproduce: 1) Minimal working example from docs. 2) Test folder 3) Moving files to test folder
Expected behavior: Full paths of those files printed to console
What happens instead: Nothing.
Workaround: Forcing pulling with custom configuration. However it causes 1-8% usage of CPU on my multicore system and is too expensive (lengthening interval of pulling brought down lower bound to that 1%, but spikes stayed at 8%). It also causes spike in memory usage (~3MB without pulling vs up to 40MB), but I'm not sure if that's due to app actually doing it's work.
Additional info: Once I had workaround, I witched pulling off (False) to see if that still works, but no. Custom configuration with pulling off do not work.
I've cloned this repo and run tests. All tests pass. However tests use somewhat different code then minimal working example, and because watcher is very generic, I didn't tried (yet) to port that code to my project to see if that fixes the issue.
PS Is
threadDelay
compounding response time of the watcher when pulling is enabled? Could CPU usage be effect ofthreadDelay
?