> It only supports a subset of Javascript close to ES5 [...]
I have not read the code of the solver, but solving YouTube's JS challenge is so demanding that the team behind yt-dlp ditched their JS emulator written in Python.
To declare "open source", you have to provide a way for the public to get access to the source code. But there seems to be none at least for the time being.
I wrote my first SPSC circular buffer implementation in TS upon reading the previous post on futex [0] from the same author. It was more intricate than it had seemed, until I finally sat down and wrote my own code.
I recently started playing with these in game design as well to coordinate networking and game threads in a lock free manner. If it fits your use case it is truly a free lunch! They definitely have a lot of edge cases and are not easy to implement, but they aren't too crazy either.
By a quick glance, yes, this is what I want: a channel to communicate between processes via a piece of shared memory, protected by a pair of futexes.
In JS ecosystem, buffers that allow data loss is more common (aka ring buffers), but ringbuf.js [1] is the only complete implementation to my knowledge. In my use case on I/O between WASM modules where data must be transferred as-is, the process must block on buffer overrun/underrun in a synchronous manner. Therefore a circular buffer is required. I could not find such a niche library written in JS, so I decided to bite the bullet and reinvent the wheel [2].
After a quick glance, it seems that you don’t maintain the reading/writing status in the shared memory. That means you have to make a syacall in every read/write call. You could look into the kaze-core for an alternative implementation, which doesn’t require any syscall if possible.
Btw, kaze-core uses a `used` atomic variable, to avoid reading both readPos/writePos in routine - they are not atomic at all.
That is a fair assessment. Maintaining read/write pos and peek them at every operation is a big performance hit. The impact is amplified if each invocation needs a syscall. That is exactly what futexes address: Allowing spin locks to remain in user space and avoid entering the kernel as long as contention is low.
In JavaScript, atomic operations are relatively lightweight, so their overhead is likely acceptable. Given that, I am open to adjusting my code to your suggested approach and seeing how it performs in practice.
I am not meant to be harsh, but note that it fails on a small number of test cases, on v0.21 that is ~900 out of ~50k. Strictly speaking it cannot be described as standard-comforming unless there is some reason behind every failed test. A better way to strive on standard conformance, like QuickJS takes, is to pin down the ecma262 revision and make it 100% compliant.
That may be fair. The better wording may even be specification compliant, but none of the Boa maintainers made this post (we found out about it after the fact).
We, the maintainers, could probably sit down some day and try to triage the failures into a documented txt file, but the overhead on that might make it hard to maintain for an open source project. Plus a large amount of the failures are just new specification features that nobody has implemented yet.
I really appreciate the clear and detailed project description, the only concern is the title on HN. Failing on tests is fine, especially when it demands huge efforts to triage and reiterate on the project structure for them.
Nitpick: SQL is a programming language. But for most CRUD tasks you should rely less on SQL's programming capabilities until processing information is too expensive outside the SQL server/engine. The advice is also for maintainability.
reply