Sam Clegg

@tlively ?

Yes, the idea is tie match the flags that we use for memories. For example, in wabt we have: https://github.com/WebAssembly/wabt/blob/356931a867c7d642bc282fff46a1c95ab0e843f3/include/wabt/binary.h#L24-L29 and these flags are used for both memories and tables....

Fantastic. Thanks for all the work on this. I think #68 is now the only blocker.

@bvisness is there a command line flag I need to pass to spidermonkey to enable memory64? I'm trying to run some tests in emscripten CI.

Hmm.. I can't seem to make -P work: ``` $ /usr/local/google/home/sbc/.jsvu/engines/spidermonkey/spidermonkey -P wasm_memory64 Error: Invalid short option: -P $ /usr/local/google/home/sbc/.jsvu/engines/spidermonkey/spidermonkey -Pwasm_memory64 Error: Short option followed by junk: -Pwasm_memory64 ```

Can we remove the `--proxy-to-worker` maybe? My understanding is that it has very limited applications since it takes over the whole page, right?

> Do you mean we'd remove the whole `--proxy-to-worker` feature? > > I am under the impression that there would be active users of that feature still. Yes, I'm basically...

Looks like we can remove the whole feature: https://github.com/emscripten-core/emscripten/issues/25440. No comments yet on this.

> But later on I realize that it is not actually possible for Emscripten users to generate "system level" JS library wide `{{{ }}}` macros, the parsing order is a...

> The automatic `foo__sig: '....'` model helps automate this challenge in some cases, but it has [undesirable interactions with JSPI](https://github.com/juj/wasm_webgpu/blob/54c51d715d68f22a62e1f84eb072737e8a8270c0/lib/lib_webgpu.js#L672), and it results in pessimization of generated code size. Are...