Feb 19, 2025 | JavaScript subgroup (BA Guest Languages SIG)
- Opening, welcome and roll call
- Note: meeting notes linked in the invite.
- Please help add your name to the meeting notes.
- Please help take notes.
- Thanks!
- Announcements
- Submit a PR to add your announcement here
- Other agenda items
- [Till] Making Tomasz a StarlingMonkey reviewer
- [Till] JCO WASIp3 status?
| Attendee |
|---|
| Calvin Preweitt |
| Guy Bedford |
| Tomasz Andrzejak |
| Victor Adossi |
- Tomasz: We were able to close off everything for
FormData, last PR that was merged was parsing URL encodedFormDataas well – issue is closed, we should fully support FormData 🎉 - More passing tests
- Tomasz: Started to work on
AbortControllerandAbortSignal- This is a bit hard because all the event machinery needs to be implemented
- This is probably going to be moved slightly to the background to prioritize Jco work
- Guy: Looking at outstanding issues (we have one for
Event&EventTarget)...URLPatternis now part of WinterCGIntlis still large/important- Better handling of unicode property escapes
- NodeJS builtins (we’re still waiting for whether Rust could get used)
- Till: Would love to have Tomasz as a reviewer, he’s done a lot of fantastic work on StarlingMonkey, adding builtins. Ramp up was impressive from early patches to recent patches which are mostly in mergable shape
- Guy: Fully support
- Guy: Should we break out a StarlingMonkey maintainer meetings?
- Till: Yes, the meeting is split into two parts, but there is overlap in interests even if not in topics. There may come a point where we should split them out
- Guy: For now looks like the pressure isn’t there
- Till: Before the Rust crates were individually compiled and linked in via static libs, we got mostly lucky w/ no symbol collisions, but during some experimentation was able to improve this.
- This patch stops using those static libs and compiles all as one big crate – which means we can update our Rust version.
- PR increases Rust version to 1.80 – still behind but blocked on a Wizer bug
- Till: Abandoning work w/out P3 C-API for now
- Major changes to Host API header would be required, and even then it would be painful
- Rust implementation of the host API should be a longer term project that depends on an overhaul of the Host API header.
- Guy: FWIW We do implement our own Host APIs that don’t necessarily follow convention – it’s easier to change that now rather than when we have a p2 implementation
- Till: I would like to be able to get rid of C++ std lib things (ex. std::string, std::vector) as they’re kind of inflexible.
- Ex. can’t make std::vec after getting at the bytes in a Rust Vec
- Will free up getting rid of the abstractions for HostString and some other stuff
- That said this doesn’t change the fact that generating C++ bindings w/ bindgen is hard and the tooling isn’t in a great place yet
- Guy: HostString and HostBytes get used quite extensively in the Fastly codebase
- Till: We’re using std::string in some places, and getting rid of those would be beneficial… But the summary it turned out to be a bigger project w/ unsavory results.
- Niko is working on this which may brin things to a better state
- This will be useful for WIT things, because this will be able to generate WIT bindings from rust code
- Till: Quick status update on debugger stuff
- On branch, have debugging working for Wizer, going to clean this up so it can be PR’d (hopefully next week)
- During Wizening we can set a flag for debugging at runtime, and then an ENV var will be read to tell StarlingMonkey to use a debugger port
- This will enable separate evolution of the pieces of debugging infrastructure independent of StarlingMonkey
- Guy: Till found out that when componentizejs runs, it uses the existing SM engine and it assumes that P1 imports aren’t used (stubs them out), and that P2 imports in subsystems that are not expected to be used (ex. Env vars), and it stubs those out.
- This is necessary for hosts that want to run in restricted environments, but as we’ve found the stubbing code needed to be changed
- We do now get warnings for the test suite though – need to figure out a way to decide when to do the warnings
- One way might be to mark the environment as a feature, and if you want access then you need to specify it, and possibly changing options with the debugging mode.
- FS is also interesting because if you have stdio on, but not fs you can technically stub all the I/O based functions.
- Till: The warnings I added was from just being stumped by things not working properly. But with the proposed way of always compiling in the debugger and not trying to activate it at runtime, StarlingMonkey would now always try to use the WASI environment imports
- Having the debugger always compiled in shouldn’t mean that a component always warns.
- Guy: Worth noting – we only do the stubbing after the Wizer step
- Till: Like the idea of making this (debugging) a feature for ComponentizeJS, and if debugging is enabled, we’ll not stub the relevant ENV imports, and if you force it then we can error
- Guy: Debug basically means enabling STDIO, and maybe this is a new option versus the subsystem features.
- Till: will think about this and see what comes out and update the PR. This shouldn’t block a release since there is a lot of good features to get out, including important bugfixes (one w/ Buffers and on the SM side all of Tomasz’s FormData work)
- Guy: Will look to add a new env feature by the end of the week so we can avoid the warnings
- Victor: Calvin did exploration for integrating jco w/ the prototyping repo (i.e. cargo git deps), and ran into an issue w/ the dependency on
wit-bindgen-core. After talking to Joel we know that isn’t necessary standard – the Rust host async impl doesn’t depend on the code in there- I’ll be picking up where Calvin left of and implementing the new trampolines & intrinsics
- Calvin: There likely needs to be more investigation around this
- Some timeline discussions in the CG meeeting seems to indicate that april/may seems possible
- Not everything in the wasmtime host is available yet either – WaitableSets for example
- There are a bunch of things I need to do for WASM I/O, so not sure how timing will work
- Tomasz: How should we be pulling in the dependencies?
- Calvin: Jco uses some machinery that helps flatten some types, and wit-bindgen-core (which is normally used for guest bindings)
- Problem is that wit-bindgen-core does not implement the logic for async bindings
- Tomasz: Would be great to have another pairing session
- Victor: Yup, let’s get something scheduled early next week!
- Guy: AFAIK we don’t use any of the wit-bindgen functions, only the ABI primtitives right?
- Calvin: We use
abi::call, which uses the structure to do code emitting - Guy: This should be relatively minimal concern, just an integration point?
- Calvin: Seems like there were would be a sizable refactor that needs to be done to make that work.
- Guy: One option might be to fork it and integrate it locally, we could copy and paste it in or make a fork. Are there a lot of details in the ABI call that need changing?
- Calvin: We probably need a bit more investigation, not clear how large of a refactor it is
- Calvin: We use
- Guy: Updating the wasmtime submodule and updating the generated programs would be a good place to start.
- We’re on a fork due a change to the HTTP tests, but that should rebase easily and we can re-generate tests.
- Starting out w/ updating preview3 tests would be a good step
- Victor: Before that, I have been able to pull out async components and use them in the regular transpile tests, updating the preview3 tests could be the next step?
- Tomasz: Actually tried what you recommended Guy, and got stuck when the tests would fail
- Guy: this makes sense because transpile is the actual part that is failing (i.e. async bits not being implemented) – Transpile is the thing we need to make work.
- Victor: Maybe we could get a P3 `async` branch on the jco repository?
- Victor: Being able to have a long-lived branch for making progress on this would be helpful
- notes related to Node WASI subgroup go here