Skip to content

Latest commit

 

History

History
108 lines (95 loc) · 7.16 KB

guest-js-02-05-2025.md

File metadata and controls

108 lines (95 loc) · 7.16 KB

Agenda

  1. Opening, welcome and roll call
    1. Note: meeting notes linked in the invite.
    2. Please help add your name to the meeting notes.
    3. Please help take notes.
    4. Thanks!
  2. Announcements
    1. Submit a PR to add your announcement here
  3. Other agenda items
    1. Resource shadowing due to import mapping (@vados-cosmonic)

Attendees

Attendee
Calvin Preweitt
Guy Bedford
Tomasz Andrzejak
Victor Adossi

Notes

StarlingMonkey

  • Guy: Current Streaming/FormData PR awaiting review from Till?
    • Tomasz: Yes, Till has some comments around null pointer checking
    • Added a Rust library to handle some of the parsing for multipart data that was required
    • Fuzzer has been running for a night, no issues found yet
    • Guy: Will ping Till that there’s another PR to review, Fastly has 2 customers that are interested in this
  • Guy: Note that we have shared implementation for headers & req/response fetch – I have to pull in diffs, so if there is a way to refactor to enable referencing shared functions that would be good.
    • Tomasz: There’s a small section in request/response that could be done
  • Guy: Can we support a build without FormData? I.e. toggling the built-in?
    • Tomasz: Easiest way would be to stub the isInstance fn, most stuff in req/resp is checking via isInstance calls.
    • Guy: Also, in the install method, we could set methods rather than having generalized macro-based methods
  • Guy: GC PR?
    • Tomasz: Need to find time to experiment with that, E2E tests not passing
    • The PR also uses the branch of StarlingMonkey
    • Guy: Different build if this adds overhead?
      • Tomasz: Only enabled during debug?
    • Guy: let’s figure out those tests then get the upstream updated with debug build
  • Guy: FormData is definitely important
    • Tomasz: right now the parser is very strict, would be good to get some initial feedback

ComponentizeJS

  • Guy: Till found a bug in the use of sbrk and tracked it down
  • Outstanding TODOs, regular expression unicode properties (StarlingMonkey has the same issue), we’ve discussed this before… Along with Intl build
  • Guy: Am I right in assuming that the focus is on the Jco side for now and not on the Componentize side?
    • Victor: Large blocker to participating in the P3 release is jco (transpilation) more so than StarlingMonkey, since there are components that can be run.

JCO

  • Victor: some PRs under way
    • WebIDL PR (now ready since webidl can be used as a binary)
  • Victor: After Calvin’s PR got merged we were realized that we needed to update the dependencies
    • Historically there was a wasmtime “async” branch by Joel, and now there is a wasip3-prototyping repo
    • Toolchain (wasm-tools, wit-bindgen, etc) is being updated live, you should be able to use the async stuff
  • We should be able to now start trying to use the upstream stuff since the deps in jco have been updated
  • Victor: Met with Tomasz and did a walk through of the jco & componentize codebases
  • There are at least two things that need to get done
    • Shims
    • Lower level Async impl
  • Guy: Great to see the upstream updates, Alex helped to set up a system that made it easy to update the intrinsics.
    • If we have JSPI, and implement Async, then it should be possible to implement it synchronously right?
    • Calvin: there’s the callback in the API right?
    • Guy: In theory an async component bound to preview3 could work just like p2 impl without async implementation changes
      • Victor: So an async component calling the host synchronously
      • Technically you need to support both but we have async components so we can call a sync host.
      • There is some other stuff - ErrorContext can be sent along with a stream at the close time
    • Promises and JS streams have an error slot, we could use that?
    • Victor: In function bindgen I wrote some await stuff but it’s not clear that the function itself is async — the code
      • Guy: Can’t you assume that you’re going to already be in the async function based on the entrance point?
      • Victor: Yes that should work – need to pass the fact that we’re in an async fn down
    • Guy: What is the first simplest test case for an async component? Is it fine to just support the fully sync host?
      • Victor: Async component -> Sync host is the easiest one to get done first, simple value over a future should be the simplest
    • Calvin: stepping through it, trying to get components to build
  • Victor: Some links
  • Calvin: Have you been able to build some example components?
    • Victor: yep – the example-test-programs crate, you can build one and pull the binary out, will send over command
  • Guy: Any questions we should discuss today?
    • Tomasz: Have to try to grind through before I have some reasonable questions,
    • Guy: there’s a script in the base folder of jco (cargo xtask generate-preview2-tests?) that builds the wasmtime tests – an auto-generated test folder
    • If we want to claim async support, we should be able to pull in those tests and track the preview3 tests.
    • Tomasz: So I should try and adapt this?
    • Guy: Yes, there are some clocks test so might be a good place to start
  • Victor: reorganizing code? Maybe if we’re a Js project primarily then maybe the rust code should move
    • Guy: Well in the future, jco could be primarily a rust project, so that’s not necessarily true
    • A crates & packages folder is probably reasonable representative
    • Victor: Do we want to reserve the jco name on cargo?
  • Guy: there was a bug posted on the p2 implementation
  • Victor: Do we want to ge thte debug build?
    • Guy: only recently did we get a possible build w/ stack traces, but it needs to be tested
    • Someone needs to try it out and confirm that it’s working

Node WASI subgroup

  • notes related to Node WASI subgroup go here