- 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: [email protected]
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.