Update: Well, my current workaround is to just change
:barbary in this line to
:polling, pack up a new
hawk JAR and use maven to stick in in my
~/.m2 dir. The effect is that I’m not using native Mac system events any more and so taking a battery hit, but at least the hot reloading performance is back to normal.
wonder if it’s worth contributing some sort of PR adding a switch to hawk, if the barbary service fails then emit a warning and fall back to polling the fs.
result is no changes needed to figwheel.
we might have to do this in figwheel
if more folks make this change
I guess we could catch a missing-Carbon throw, and try to explicitly fall back to a polling watcher. I could document my steps on the github issue though, since making a custom hawk jar with the right version will fix all my figwheel projects on the specific machine and buy some time.
can we just catch this in figwheel and restart with polling?
I’ll look into it and PR it if I can.
I’m a bit concerned jna -> barbary -> hawk could take a while to work through… was looking at last updates and they seem to have—to their credit—not needed to be touched in years.
is it OK to catch the specific thrown exception, or should I try something more proactive like trying to check the Mac OS version?
just in case anyone else is having trouble on macOS Big Sur betas, here’s how to monkey-patch the hawk file watcher to at least be able to get some work done https://github.com/bhauman/figwheel-main/issues/253#issuecomment-654572662
@bhauman Here’s a first cut at dealing with the mac FS events. (I’m pretty sure I have some problems around over-catching exceptions, hence draft status). https://github.com/bhauman/figwheel-main/pull/254/files Now that I understand the mechanism better, maybe this problem could be best dealt with by expanding the documentation around https://figwheel.org/config-options.html#hawk-options a bit more. Falling back to polling feels like it could have some downsides but I’m having trouble articulating what they might be.1💯
I’m not using big sur
So am I correct in understanding that if folks just switch their config to polling on Big Sur this isn’t an issue?
I should have made that connection myself
@bhauman yep, it looks like after all that the one-liner
:hawk-options will take care of it.
(work smarter not harder etc. etc.)
@bhauman I think I found a windows bug? I’ve had the path for the bundling command using the wrong slashes for
\ instead of
/. I’m not overriding it, so it’s using whatever figwheel has defined…
so the default output-to has
/ in it?
that shouldn’t be happening at all
I’m trying to work out how it’s happening. So if I use cursive with the repl run configuration it happens, but if I use the terminal inside intellij it doesn’t… Are you doing some environmental detection to work out what paths to use?
I use generic paths
This might be a cursive bug instead of a figwheel-main bug…
(io/file “target” “cljs-out” “etc”)
ok, hmm. That should just work I think.
How do you call
I call it with output-to
It’s also failing to detect that under certain circumstances, ie saying that it isn’t installed…
even though it definitely is in wsl
I’m beginning to see why windows users find this hard…
it’s npx.exe right?
Well it was, I’m having more success at the moment using linuxbrew, so it actually installs
well that’s a problem then
because I’m detecting the os
In the latest version
you might not be running that code
which version is this? 0.2.8-snapshot?
we’re on 0.2.10-SNAPSHOT
Cool, will try that
Ok, so I believe that run configuration doesn’t use wsl, which is why it’s not working as I don’t think I set that up properly… however I can use it perfectly well by just calling the repl terminal version and then using nrepl to connect to it…