Sam Clegg

(BTW since #1728 landed you don't need to add `--wasm ../../interpreter/wasm` to the `run.py` command line since the default should always work).

> Oops, sorry, my bad. Please see #1829. > > @sbc100, normally this runs on CI via node, but that is deactivated on this branch because current node.js cannot handle...

> I'm fine with either, but don't feel knowledgeable enough to set that up. ;) I'll take a stab at it. I'd also love it if we could run some...

I tried running the spec tests under JS and things still seems broken in various ways. I downloaded https://nodejs.org/download/v8-canary/v${VERSION}/node-v23.0.0-v8-canary20240819f52f1c2f1c-linux-x64.tar.xz and then did: ``` $ NODE=$HOME/bin/node-v23.0.0-v8-canary20240819f52f1c2f1c-linux-x64/bin/node $ (cd interpreter && opam...

> @sbc100, is this after #1832? Doh! Sorry my local wasm-3.0 branch was behind.

Can this issue be closed now?

Thanks for the PR @ktock. This looks like a fairly large and complex PR, and I'm out sick right now I'm afraid so I'm not sure when I will have...

Would we also then provide stub versions of the pthread APIs that fail at runtime (when not building with pthread support)? This is what emscripten does BTW: https://github.com/emscripten-core/emscripten/blob/main/system/lib/pthread/library_pthread_stub.c

You should be able to open devtools and set a breakpoint in the `worker.onerror` function (e.g. on the `var message = 'worker sent an error!';` line). At that point `e`...

No ideas some to mind I'm afraid. Chrome 93 is quite old now (looks like almost 3 years old). Is there some reason you are targetting such as n old...