- Where: zoom.us
- When: January 5th, 5pm-6pm UTC (January 5th, 9am-10am Pacific Daylight Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair 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.
- Announce next SOIL Seminar on Fri Jan 15 at 1pm PT: "Compiling Project Everest to WebAssembly" by Jonathan Protzenko (Ross Tate) [2 min]
- Update on the Branch Hinting proposal (Yuri Iozzelli) [10 min]
- Discuss activating the new GitHub Discussions feature for various repos (Ross Tate) [10-15 min]
- Closure
None
None
Jay Phelps
Francis McCabe
Sergey Rubanov
David Piepgrass
Yury Delendik
Yuri Iozzelli
Nick Fitzgerald
Léo Andrès
Fatih
Paolo Severini
Ezzat Chamudi
Ryan Hunt
Arun Purushan
Nicholas Yang
Lars hansen
Daniel Wirtz
Rick Battagline
Thomas Lively
Luke Wagner
Mingqiu Sun
Asumu Takikawa
Till Schneidereit
Ioanna Dimitriou
Ross Tate
Derek Schuff
Deepti Gandluri
Nabeel Al-Shamma
Sean Jensen-Grey
Dan Weber
Rich Winterton
Eric Prud’hommeaux
Ben Titzer
Petr Penzin
Wouter Van Oortmerssen
Gen Ashley
Sam Clegg
Luke Imhoff
Paul Dworzanski
Update on Branch Hinting proposal Slides
YI presenting
YI: looking for feedback, how to link hints to code, forward compatibility
TL: instruction index and branch instr index might not be compatible with feature detection proposal, because it has conditional blocks. That would change the instruction indices depending on what features are supported. A byte index would work with that.
RT: I suspect you’re not the first person that’s going to want this - we should have a general solution that works for more use cases.
NF: debug info uses byte offset within the code section. It may make sense to match up with that.
DS: Similar thing we have is, when we have engines print stack traces, they have offsets in the module than the code section offsets - which we can fix in the future, but that’s another case where we are using a similar thing - we can talk about whether we use offsets in the module/code - but there is a precedent for both
YI: Definitely not a function offset then?
DS: Right. RW: If you were using a module offset - do you have separate SSE/AVX modules
DS: This is the Wasm offset
LW: in the future we may get multiple code sections, so “which code section” becomes an issue
RT: Byte offset sounds like the right idea, what would it be relative to? Sounds like that
DG: Any other feedback? YI, is this feedback you can make forward progress with?
YI: yeah, this is good feedback. It sounds like these issues are relevant and pretty compelling argument for a byte offset of some kind.
DG: also a suggestion from Ben Tizer in chat, suggested a pair of function index + byte offset, since this is stable over module transforms and deletion/reordering of functions
RT: SOIL seminar next friday at 1PM EST about Project Everest from Jonathan Protzenko at MSR (general link at http://soil-initiative.org/seminar/) and event link here.
RT: Github has released Github discussions as a new feature, still in beta. At a high level, it compliments issues - some of them there are two kind of formats - open ended discussions, and questions. Seems like it would be a good fit for what we are doing
DG: what about morphing discussions into issues, for things which become more appropriate for that?
RT: Issues can be turned into discussions, but the other way around is still in beta. Sometimes it’s not known whether there is a concrete issue that we have, something that we want to change, etc. Once it’s known, an issue can be created.
FM: is this intended to be like Quora or Stack Overflow?
RT: There’s a Q&A thing that looks like Stack Overflow/Quora - not entirely sure if that’s what they’re going for - People do that already in questions - so that issues aren’t closed that are questions and are easy to find
EP: Are they threaded, like email?
RT: The Q&A are, the open ended discussions look just like the issues mostly
DW: my impression on discussions so far: not very different from issues, but has threaded discussion, allowing to reply to a specific post
RT: you’re allowed to have different categories of discussion, which can be different for different repos. We could impose some structure for really big general repos like the design repo.
DS: We should try a pilot and see how it goes
RT: the ones suggested by default are “Q&A”, “ideas”, and general
DG: we could try opt-in per-proposal, even if not a really narrow pilot. Particular suggestions?
RT: I’ve been working with EH and GC. I know some of the things I’ve brought up in EH are really discussion items that would be good for discussion
TL: it would be good to let champions opt-in and try it out for now and see how it goes. When we get some experience then we could put together some recommendations for how to use it
DW: looks like not actually threaded, but more like replying to top-level posts only
FM: One of the things about Quora/SO is you get the idea of a “settled” response to a question. It could turn into a kind of FAQ. That could be helpful for people unfamiliar with the proposals to get up to speed on what discussions and conclusions have been made. It’s a useful feature one could look for in this kind of tool.
RT: Right now, when you close an issue it goes away, there’s not a good forum to keep it alive as a reference.
DG: yeah, that would be nice. Not sure if there’s currently a way to do that other than maybe keeping a living document (e.g. md) with a list of those discussions.