- Where: zoom.us
- When: October 16, 4pm-5pm UTC (October 16, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: JF Bastien
- Email: [email protected]
- Name: Ben Smith
- Email: [email protected]
None required if you've attended before. Email JF Bastien or Ben Smith to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- An update on JF.
- Presentation: Rust and wasm-bindgen (Nick Fitzgerald)
- The
ImportObjectis required forWebAssembly.instantiateStreamingand can be difficult to pass in some cases, see systemjs/systemjs#1757. (Sven Sauleau) - Move proposals tracking to a new proposals repo
- We already have this information in tracking issues, and FutureFeatures.md
- Some people have told us that tracking a repo is less noisy than tracking the design repo/issues
- POLL: Should we create a proposals repo, and move the tracking issues there?
- Function references (Andreas Rossberg)
- Closure
None
None
- Alex Crichton
- Andreas Rossberg
- Benjamin Bouvier
- Ben Smith
- Dan Gohman
- Daniel Ehrenberg
- David Piepgrass
- Deepti Gandluri
- Derek Schuff
- Heejin Ahn
- Jacob Gravelle
- Jay Phelps
- JF Bastien
- Keith Miller
- Lars Hansen
- Luke Wagner
- Nick Fitzgerald
- Peter Jensen
- Richard Winterton
- Sergey Rubanov
- Sven Sauleau
- Thomas Lively
- TobinT
JF seconds
JF: Recently Ben has been doing most of the chairing. I think I should step down from being a chair.
BS: We all appreciate the work you’ve been doing so far, so thanks.
JF: It’s important to rotate, and it’s useful to advance things in different ways - it’s useful to step down and let other people lead.
BS: Thanks again.
[Nick Presenting] [ slides: fitzgen.github.io/wasm-cg-wasm-bindgen ]
TL: Can we use this for other languages as well?
NF: We could. It’s mostly a question of motivation. None of the people hacking on it now are super motivated to get other languages working. Questions about what the UI would look like in C++. A lot is pretty straightforward. Another front end constructing AST from diagram. We would need another codegen method for C++. It seems clear to me where we would extend it, wasm-bindgen is always going to be written in Rust but could be extended to support C++.
JG: I experimented with this a while ago, opened a GH issue [link]. It’s just a question of the porcelain. We may need a clang plugin or something; or maybe some other tool.
NF: The only parts that need a clang plugin, is the generated stuff that goes from a C++ type to the raw -- the functions that are actually exported. The trait methods themselves could be trait functions in C++.
JG: I think we don’t have enough to do it in a static way -- haven’t looked at it in a while.
NF: It’s progressed a bunch in 6 months.
The ImportObject is required for WebAssembly.instantiateStreaming and can be difficult to pass in some cases, see systemjs/systemjs#1757. (Sven Sauleau)
Links:
- Caching for compileStreaming + instantiateStreaming webpack/webpack#8157 (comment) (+ thread proposal API comment in Webpack)
- Initial issue systemjs/systemjs#1757
- Promise in import object WebAssembly/esm-integration#2
SS: I want to bring this up for systemjs. It is a javascript module system, so it has no compilation step. We want to use instantiateStreaming, but we need to pass import object and you don’t have it until you pass the module and you get the exports section. You have a cyclical thing here. Once solution is to use instantiateStreaming and then use new WebAssembly.Instance, but that is not possible because of Chrome’s 4k limit. We have some other solutions but they are super hacky. We don’t really have a good solution here.
DS: Is it possible to use compileStreaming then instantiate?
SS: If you use instantiateStreaming then it will compile twice right?
DS: But you can use compileStreaming instead.
SS: it still has the limits right?
DS: Only synchronous ones have this limitation.
SS: perhaps this will work. But instantiateStreaming is recommended way to use this --
LW: Have you seen the proposal to allow the instantiate functions to take a promise as import object?
SS: Yes, we’ve seen this.
LW: Would that fix it? Each individual value of the import object is allowed to be a promise -- that’s the proposal.
SS: If you have a cyclic dependency, the promise won’t ever resolve. I don’t think this will work in other cases.
DE: To get around the multiple download issue, can you use WebAssembly.compile, then use instantiate on that? The 4k limit won’t be applied.
SS: If you use compile then you have to download by hand --
DE: I thought you wanted to be able to download yourself so you can parse the wasm binary.
SS: Yes, we could do this with just one stream. It’s a lot of work though… another idea, Alex asked about thread proposal. If you use webpack and spawn a module into main and module into worker. One solution we mention is if we use instantiateStreaming with the same url in multiple cases it will provide the same module. It would be nice to use to ensure this in the spec. Maybe we could do this.
LW: It would be nice to follow up in the GH issue.
SS: [links to issues]
LW: What is issue with compileStreaming w/ instantiate? Other than cyclic.
SS: No issues probably. Thought it may have limit.
KM: WebKit won’t, any browser that does is probably a bug.
LW: Your constraints: you want to be able to inspect the imports? You want to be able to do it purely dynamic?
SS: Yes, this is one of the main issues. I’m expecting other systems will have this issue.
LW: I can imagine new APIs for this… helps in the future but not right now.
SS: We mention adding a new API, but it doesn’t seem right to do so.
- We already have this information in tracking issues, and FutureFeatures.md
- Some people have told us that tracking a repo is less noisy than tracking the design repo/issues
- POLL: Should we create a proposals repo, and move the tracking issues there?
BS: [describes above]
DS: If we do make this the source of truth then we would remove others?
BS: Maybe not remove, but link to.
DS: Currently design repo has two responsibilities: various design discussions as well as tracking new features. Do we need a bigger change here?
BS: I think we could do that; currently design repo exists as a catchall for anyone who wants to comment on WebAssembly too -- we could have a separate repo for that, but it’s a different question.
TL: The point of having a new repository is to allow people to follow the information on GH? If we just wanted info we could just add the chart to the design repo.
BS: Yes, it is kind of a workaround for how GH works -- it’s easier to follow a repository than to follow a set of issues.
DE: I like this idea, it’s easy to follow and I like the information. Having a contributor work on this (Sergey) makes it seem likely that it will be kept up to date too.
[Unanimous consent to move this to a new repo]
Link: https://github.com/chicoxyzzy/WebAssembly-proposals
AR: We have the reference types proposal. We have the GC proposal. Another feature is typed function references. It is a relevant feature. This is a question to the group -- whether we should amend one of the two other proposals, or whether to make a separate proposal. I want to push this forward in some form.
This feature is: with GC proposal we add a reference type. A simpler thing is a reference of a particular function type. We could get a function ref that is a subtype of anyfunc. It allows you to introduce a call_ref instruction that doesn’t need to be typechecked.
Should this be a separate proposal or merged into another.
LH: I think we should make it a separate proposal?
KM: Doesn’t a function type per proposal make a lot of pointer chasing?
LW: Tables are static like asm.js
KM: You aren’t going to compile that in, you may compile across multiple workers. So you still have to find the table. If you’re going to IC that, you could IC the type check too.
AR: The use case is different -- the current one is almost exclusively to support C function pointers. The typed functions would be for other languages. If you have a function reference as a first-class then you can call directly without using tables at all. Then tables are just for storing them as opaque types. In the same way that you can store numbers in memory. The use case is a bit different than how you currently use tables. You don’t need to do casts if you know their types.
KM: If you have a bunch of small tables -- if you knew statically the length then it might be ok, but that’s not how they currently work --
AR: This extension to tables is already part of reference types proposal, though.
KM: It seems like we may end up with a number of dependent loads.
AR: The more relevant use case is that you can call a function reference directly, without type checks.
DS: In terms of factoring proposals -- anyref gets its own proposal so it can feed into host bindings. Is this not related to host bindings?
AR: It isn’t probably for JS. It is separate from anyref, but it is also separate from GC proposal, since it doesn't require GC in the same way. It’s useful and independent from GC. Interesting interferences with GC proposal. Perhaps make a separate repo.
DS: We have sign extension as its own proposal. :-) We did a similar thing on threads, splitting things into their own proposals which logically chain together.