- Where: zoom.us
- When: February 19, 5pm-6pm UTC (February 19, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: Ben Smith
- Email: binji@google.com
None required if you've attended before. Email 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.
- Update on producers section: tool-conventions/#93 points to likely non-use in practice and so next steps would be to either remove or soften wording.
- Discuss implementation and spec status of bulk memory. Move to phase 3? (Possible POLL.)
- Closure
None
None
- Alex Crichton
- Andreas Rossberg
- Ben Smith
- Ben Titzer
- Conrad Watt
- Daniel Ehrenberg
- Flaki
- Jacob Gravelle
- Keith Miller
- Lars Hansen
- Limin Zhu
- Luke Imhoff
- Luke Wagner
- Mitch Moore
- Nick Fitzgerald
- Pat Hickey
- Peter Jensen
- Sam Clegg
- Sergey Rubanov
- Sven Sauleau
- TatWai Chong
- Thomas Lively
- Ulrik Sorber
- Wouter Van Oortmersson
- Yury Delendik
Thomas seconds.
Update on producers section: tool-conventions/#93 points to likely non-use in practice and so next steps would be to either remove or soften wording.
LW: short update. Tools would emit by default. Emscripten team pointed out why not emitting by default. Changes the nature of it -- not useful for live telemetry. Changed some of the wording.
JG: My take: it still seems like a useful thing to have. Maybe not from emscripten perspective. Emscripten has an idea of how many people using it -- most wasms today. For other producers it might be more useful. I’ll add a link to GH link to chat.
AZ: Just to add -- market share issue is a factor, there’s also a code size issue and privacy leaking issue as well.
JG: For us it’s all code-size cost, not as much benefit to paying that cost. For F#.js perhaps it’s more useful, they may want to pay the cost.
LI: It may be possible to infer backend from generated wasm, so you don’t necessarily need the producer section -- you can get the same effect without putting it in there.
JG: If you look at the JS minifiers today, it doesn’t add this sort of thing. For end-to-end toolchain maybe the don’t care about the code size as much.
Flaki: Does this have any use-case for chaining tools, or just for human readable.
LW: Initially it was to have all the tools in production use this.
Discuss implementation and spec status of bulk memory. Move to phase 3? (Possible POLL.)
LH: Want to know what the status is. Want to know if it’s stable.
BS: [explaining status.] BS: I mean technically we are implementing, so we are in the implemention phase.
BS: All we miss currently is the testsuite. We both have our individual tests, so this might be just an issue of bringing them into the spec format.
AR: Have we resolved where to put the missing table stuff?
LH: The table indices? The bulk table instructions.
BS: table.grow and table.size?
LI: is there a proposal to cover C’s memchr command? That scan command makes scanning much faster, there’s a SSE2 version that’s much faster.
LW: I thought about this too, might be useful to fill.
BS: That sort of feature would probably get subsumed by the SIMD feature, depending on what we think would ship first.
BT: Another argument for memcopy is you can do virtual memory tricks, more than you can do for simd.
TL: Regarding splitting memory operations apart, it will probably happen in LLVM. They’re treated as two separate features. Doesn’t have to be same for spec and toolchain -- something to be aware of.
BS: for memchr if people are interested they should probably create a proposal for it
BS: for table[...]
LH: That’s true you need the value argument for table.grow … also table.fill.
AR: If we don’t want to add them to bulk then we can add them to reference types -- but that’s further along. Or we can have a third proposal.
LH: They would be dependent on reference types.
BT: Should be easy to add.
AR: Need some volunteer to spec that, then need to test. [LH: i can review]
BS: As far as the status is concerned, we don’t have tests for the bulk memory proposal, that’s the only thing keeping us from moving to phase 3.
AR: Somebody should write the tests I guess!
AI[BS]: I’ll work on this.
AR: Testing the reference interpreter as well is important.
BS: New dates proposed June 12-13
BS: The issue with that is actually pretty close to the TPAC meeting in Fukoka in September
BT: most folks will have to travel far for Japan.
DE: w3c has invited expert travelling, you can get support for travelling and financial support.
BT: Concern is environmental impact and logistics.
LH: Probably won’t go either.
LW: What about a smaller group for TPAC, such as people concerned with cross-cutting interactions, then later in-person meeting maybe November. Someone will have to host that, though, we can’t just piggyback on TPAC.
BT: I like that.
DE: The nice parts were where Anne and BZ could come in for other topics.
BS: So it feels we are sticking with the plan of the June CG in person meeting and a smaller meeting at TPAC, then a CG in person meeting in November, preferably early November to avoid issues stemming from the holidays.
DE: If somebody wants to host in Munich -- we could swap A coruna and munich for November and June. It won’t be as cold.
BT: I don’t think that’s impossible.
BS: Is it beneficial to anyone? BS: People sounded pretty supportive for the June meeting so let’s try to stick with that.
DE: Could we conclude the dates for the June meeting?
BS: There is not many other dates that work.
FM: Could we move it forward 1 day (11-12?)
DE: We wanted to keep it possible to travel on Monday.
BS: There is a holiday on Monday, so we don’t want folks to have to travel on their holiday.
[discussion about timing flights to a coruna]
DE: There are flights 6-times per day from a coruna.
Poll: Is it feasible to travel to a coruna for the in person meeting Yes: 15 No: 1
Poll: Is it feasible to travel to barcelona All: many yeses and a probably
BS: Should we investigate travel to Barcelona?
DE: That’s a lot of extra work for me, it seems like given the results a coruna works for most? Perhaps I can work with FM to find better flights.
[discussion about travel plans]
BS: There are constraints here -- hard to move forward a day due to travel, and it’s a lot of effort for DE to move to barcelona as well. Given that most can attend at the given days (Jun 12,13) we should go forward with that schedule.
FM: I probably won’t be able to attend then.
BS: Understood, this is tough to schedule. But we will have a VC setup available for remote viewing as well, Dan has used this in the past and has been able to communicate with the group using it.