-
-
Notifications
You must be signed in to change notification settings - Fork 83
Improvements to oslib.watch
#386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| object WatchServiceWatcher { | ||
| implicit class WatchEventOps[A](private val e: WatchEvent[A]) extends AnyVal { | ||
| def contextSafe: Option[A] = Option(e.context()) | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arturaz let's make this a local private helper method rather than a public extension method, as we use extension methods very rarely in the com-lihaoyi projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does making the extension helper private work? I feel that it's better to have .contextSafe pop-up in autocomplete when you are typing evt.context. Helper function doesn't have that discoverability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's make it a normal method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm aware of the benefits of extension methods, but just stylistically we basically have ~never used them in these projects, and I don't feel like starting now haha.
|
@arturaz kicked off a publish here https://github.com/com-lihaoyi/os-lib/actions/runs/14881872790 |
Unfortunately it failed: |
|
This run seems to jhave worked https://github.com/com-lihaoyi/os-lib/actions/runs/14882228075 |
Currently watching files uses polling which is inefficient with large codebases. On my laptop `./mill --watch` uses 20% CPU just to watch the files for changes. This uses `oslib`'s `watch` module to watch for the file changes instead of polling them. We had to update oslib (com-lihaoyi/os-lib#386) to: - add a capability of filtering what folders it watches. This is needed because watching large generated folders like `out` or `.bloop` emits Java FS watcher `OVERFLOW` events. - remove the random `println`'s that `oslib.watch` had. The current approach to watching is to watch the workspace root via FS watching. FS watching only works with folders and we have to watch `root/build.mill`, and thus, `root/`, so everything else falls under it. Mac OS watcher performs watching recursively natively, but on linux oslib adds recursive watches itself, so we use `oslib.watch` filter to prevent watching anything that is not an ancestor of watched root. For example, if we have source at `root/module-a/src/`, we'll watch `root/`, `root/module-a/` and `root/`. Finally, events are filtered so that unrelated changes (like creating `root/random-file.txt`) does not trigger reevaluation. The fs watching is enabled by default and can be disabled via `--watch-via-fs-notify=false`. `0.12.x` version: #5073 --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
printlns inWatchServiceWatcherfilter: os.Path => Booleanparameter towatchOVERFLOWevents.