e-dant

Near-zero is a bit loose. It keeps a relatively compact in-memory representation. You’re about right with your estimate. Having measured just now, it’s about 30mb for 1 million directories.

The baseline Watcher’s efficiency has a wide spread. When there are many thousands of nested subdirectories, the CPU approaches the limit of the thread it’s on. Flatter directories, or many files without nested subdirectories, do not have nearly as much of an effect. I’ve seen it run on around 10 million paths on a very flat test directory.

So, near-zero is somewhat misleading. There’s a wide spread in efficiency. It was my judgement that deeply nested directory trees were far less common in practice then, so I wrote “near-zero” in the optimistic case.

It uses polling under the hood (at least, I’m sure it does. It uses whatever std::filesystem uses, which is almost certainly polling).

You are right. I’ll make sure to give a deeper breakdown in the readme.

More technically, here’s what we have:

A “baseline” filesystem watcher which uses only the standard library. It has been made to beat kqueue. And it does.

A platform filesystem watcher for Darwin is used, but certain event properties are handled by the standard library. Namely, the event time and the path type.

A platform filesystem watcher is schedule for Windows. Work hasn’t been started.

A platform filesystem watcher for Linux (> 2.4 or so) was toyed with but ultimately rejected out of accuracy concerns. It was far more efficient than the cross-platform implementation “warthog”, no doubt, but it lacked accuracy. Work is being done to get most of the benefits from both worlds.

There are problems with the “baseline” watcher (which I’ve named “warthog” because it’s sturdy and reliable). But those are potential efficiency losses when watcher more than a few million paths. They are, thankfully, not accuracy or safety problems.

Maybe you can see the solution emerging here?

Here’s where we’re going next:

The most efficient kernel watchers can be used on most platforms, but checked for their accuracy periodically by the “warthog” watcher.

It’s difficult to get it perfectly right.

There is ongoing work attempting to make it more perfect.

I expect a year or two before this is complete.

For now though, it does do what it says. The tests I’ve run show that it is accurate over large amounts of events and time. For under 1 million files and/or directories, it uses a near-zero amount of resources. Testing on older processors shows similarly positive results.

But this is so far from perfect. This is only the groundwork. Most of the bugs have yet to be discovered. The platform support, more often than not, uses the safe “baseline” watcher in favor of accuracy.

Ned14 of Boost fame has given the project some expert advice which will help it along smoothly.

I’ve gone back and forth with inotify on Linux. Ned14 gave a great rundown of the ideal next steps for a best-possible implementation.

You can check out issue/10 for a full description of how it works now, why neither inotify nor our current solution is ideal, and where the project will be going next.

What do you mean?

No perfectly good reason. I will look into that before version 1.

It’s efficient because it beats kqueue while reporting events accurately.

A proper benchmarking program is in the works, however manual testing does show only minimal resource usage.

For more, see this issue: https://github.com/e-dant/watcher/issues/10

I should test this. I haven’t seen a problem with that so far in my personal usage, so I’m inclined to say probably.

That’s a good test case. I’ll make an issue.

It does one or the other. There are concerns about OS filesystem event hooks.

The current solution isn’t ideal, and is being addressed here: https://github.com/e-dant/watcher/issues/10

It’s being addressed here:

https://github.com/e-dant/watcher/issues/10

All are supported.

Although, to be more efficient, I need to write system API calls for Windows.

That will be the 1.0 release.

I thought we call it software because it breaks when I touch it

Those considering doing something like this (such as the author) might consider using my library:

https://github.com/e-dant/watcher

It hooks into system APIs where viable. (Otherwise, it uses std::filesystem.)

It’s meant to be as or more:

- Easy to use

- Efficient

Than all similar libraries.

Metrological?

My whole heart agrees.

I’ve often chalked this up to founders following the money. If everything is secondary to that — if it’s not for the love of software — you become bedfellows with technical debt and flashy bloatware.

But you have something to write your investors about.

Being antithetical to bloat, I see real innovation in FOSS.

Slava Ukraini

I have had plenty of problems making cross platform apps — and that’s my specialty and my niche, I do it every day. Not just cross platform, but across embedded devices, browsers, servers; truly cross platform.

I have, instead, found the platforms most difficult to work with are 1. android for its heavy reliance on Java (which is not an appropriate language on plenty of embedded systems and on systems where efficiency means money), 2. windows for its poor system api and heavily restrictive marketplace, and 3. Apple for its heavily restrictive marketplace.

Note, though, that none of this has to do with the web and web-like technologies. There is nothing stopping React or similar App frameworks from being deployed on mobile devices.

And, for the record, there is legal precedent for app lockdowns like these. We don’t need more laws — we need to enforce the precedent we already have. Find a lawyer who can be convinced that Windows DirectX and ie are illegal tying arrangements… find a lawyer that could be convinced of the difference between Metal and OpenCL+OpenGL.

That’s why we have these problems; it’s a lack of understanding from the departments responsible for prosecuting these illegal tying arrangements.

Yes, right up until said startups and enterprises 1. cannot afford the outrageous cloud expense or 2. Need to scale to low-power devices (such as wearables) and to customers who are security conscious

I hate the whole javascript ecosystem to the core.

Hey I just finished my progressive web app with these 10 cool react components I found on NPM which fit surprisingly well into our startup’s cloud-native Vue interface.

I tried to put the code up on GitHub but it wouldn’t let me upload a 10gb repository (and that was without our proprietary fork of mysql :)

I am fundamentally skeptical of anything that needs a runtime for anything other than security and profiling.

I am extra skeptical of any framework that needs 50mb memory baseline.

I am triple skeptical of anything that uses brand-new packages and components like legos.

*Iterations on React are welcome.*

I often feel like my primary language, c++, is somewhere between niche and mainstream.

It leaves ample opportunities to do something in a niche way. I am often disenchanted after reading many open-source, ostensibly high-quality c++ libraries — namely Apple’s WebKit and a few parts of Google’s Filament. That said, there are a few gems of c++ that I can’t describe as anything but archetypally niche.

Nlohhman’s JSON library (also, the constexpr fork of that library), and the CTRE library for compile time regular expressions are absolute gems.

A Latin Perl module:

https://users.monash.edu/~damian/papers/HTML/Perligata.html

Author’s reasons are fascinating.

Agreed. I think there’s a way to support the FSF’s mission while disapproving of and pushing against the leadership. What compounds this is that there are no direct alternatives to the FSF. The EFF comes close, but it’s different.

It’s a close call, to be sure.

I checked this link about a month show. I hoped they’d have reached their goal by now.

As programmers, it is important to field support for Free Software.

Dictionary of Obscure Sorrows

As of writing there is no disclosure of any particular license on their website for sublime text.

I must have overlooked this. While most of my programming is over ssh with vim, I’ve very much enjoyed Sublime on my own systems. Minimalism and unobtrusiveness has been very appealing to me. Free software is more important, though, so perhaps it’s back to vim, then.

I wish that the Xi editor was maintained more efficiently than it is.

Are you aware of good IDE’s besides vim and emacs? What do you use? I love vim but sometimes I just want something “friendlier” for a change.

Luckily, because my clients postpone my bills for months and try to settle for less I don’t have to worry about things like being “over invested” or “in a bubble.”