File watching fails on MacOS Big Sur beta #253
Comments
|
@chancerussell does the following watcher work on Big Sur? |
|
Actually forget that. It would be nice if we could fall back on a simple java based watcher when things like this happen. |
|
Yeah, according to their issues they’re bit by the same exact problem. |
|
I found a temporary workaround by falling back to polling, so Figwheel can at least run in a (slightly) degraded fashion. As far as I can tell, the major cost is degraded battery / higher power consumption. The hawk lib checks to see if it's working on macOS, and uses a multimethod to set up a Barbary watcher. Thus, I can just swap in that multimethod before I start up figwheel. In my (ns user
(:require [figwheel.main.api :as fig]))
;; Patch hawk for macOS Big Sur
;; hawk can't find the carbon lib any more, so the underlying barbary watcher
;; doesn't work for getting OS-level file change events. We have to fall back to
;; polling by monkey-patching the barbary-vending multimethod for now.
(import [hawk SensitivityWatchEventModifier])
(require '[hawk.watcher])
(defmethod hawk.watcher/new-watcher :barbary [_]
(prn "WARN - falling back to filesystem polling on macOS")
(let [sensitivity SensitivityWatchEventModifier/HIGH]
(hawk.PollingWatchService. sensitivity)))
(fig/start {:mode :serve} "dev")It doesn't have to be in |
Changes to the latest beta version of macOS broke the mechanism that we're using to observe filesystem change events. It's more than just filesystem observation that has broken: any attempt to run a hot-reloading workflow crashes the Figwheel process with an uncaught exception at startup. (Note that build-once still works, since it doesn't try to access filesystem events). The underlying hawk library does have an implementation of a less-efficient polling watcher. Figwheel can use this to provide hot-reloading even when native events aren't available. This commit wraps the `hawk.core/watch!` function to catch any exception that's thrown, and re-try with the same options *except* that it explicitly starts a polling watcher. See also - gjoseph/BarbaryWatchService#13 - java-native-access/jna#1216 Part of bhauman#253.
|
Of course, now that I've taken enough time to look through the code in preparing a PR, I see that we can explicitly opt-out of using the OS's FS events with https://figwheel.org/config-options.html#hawk-options . I don't think I understood why that would be useful before. This is a lot simpler than my shenanigans above. |
|
In summary, this problem is a temporary problem that is being worked on and will hopefully be fixed by the time Big Sur is released this fall. Folks that are using the Big Sur preview need to fall back to a I.E. :hawk-options {:watcher :polling}Big thanks to @rgm for taking the time to track this down. |
|
I'm not sure where this leaves the "real" fix ... is it something like having figwheel rely directly on the patched jna dependency in |
|
We'll make sure that hawk has this fix. |
|
FYI, JNA 5.6.0 has been released. |
Mac OS 11 (aka. "Big Sur") made some changes to the way that the Carbon library is located, causing JNA calls to fail. This has been fixed in JNA 5.6.0; see java-native-access/jna#1216 Since Barbary is implemented on JNA, this is causing downstream projects that rely on file watching to crash on JVM start when used on Mac OS 11. Examples: - bhauman/figwheel-main#253 - thheller/shadow-cljs#767
|
@bhauman I got to thinking, dealing with this issue: would the ability to manually trigger builds be a useful add? I used to run into polling battery-drains in Meteor.js because of how they originally implemented their own file watcher and so I've tried to rely as much as possible on more dedicated tools like http://eradman.com/entrproject/ instead of a hodgepodge of a SASS watcher here and a gulp thing there, with another for the test watcher, etc. etc. In Gary Bernhardt's old Destroy All Software videos he would set up a manual unit test trigger in his editor (eg. for vim it would be something like But it did get me thinking: could the default Figwheel server on 9500 listen for a POST, instead of watching the filesystem? This would be reasonably straightforward to hook up per the above, eg. > find src -name ".clj*" | entr curl -X POST http://localhost:9500/_build`.I just got to thinking I'd been here before with Javascript file watchers rotting, and maybe this could add some extra advanced abilities, eg. being able to observe static EDN or JSON data under I guess the challenge would be to communicate to Figwheel which namespaces to hot-reload ... maybe by hashing the contents of known files on the classpath? I'm happy to try taking a crack at this if you think it's a reasonable idea. (Apologies if some or all of this already exists. Often I don't appreciate the words in the manual until I re-read them after musing like this for a while). |
|
@rgm In order to capture the full behavior of figwheel a triggered build would have to run through all the files for changes, because figwheel watches javascript and plain Clojure files as well. After the build figwheel can do its own detection of what has changed and do its magic. So really this would be a manual file poll. This is what gets called when the watcher finds changes: This of course would also affect CSS watching etc. Creating an end point for this makes sense. But of course there is also the REPL connection so you could add a This deserves more thought. |
Hm, I hadn't really followed but I had some time to read through tonight. Perhaps it's enough to bind that |
|
After upgrading to macOS This setting helps: :hawk-options {:watcher :polling}but feels not great. I've tried to run Could you, please publish it if possible? |
|
I'm experiencing the same thing on the Apple M1. Any update on a new release? EDIT: Ack, my bad! My issue is purely wkf/hawk related, not figwheel. Sorry! |
When starting up file watching via wkf/hawk, an exception is thrown. After a little digging, this looks to be caused by changes to how MacOS loads dylibs in 11.0+.
It looks like the JNA folks are already working on a fix, so once that lands, we can update (or fork) BarbaryWatchService, then update wkf/hawk to use it.
Stack trace:
The text was updated successfully, but these errors were encountered: