Skip to content

Latest commit

 

History

History
338 lines (178 loc) · 17.6 KB

WG-02-10.md

File metadata and controls

338 lines (178 loc) · 17.6 KB

WebAssembly logo

Agenda for the February 10th video call of WebAssembly's Working Group

  • Where: zoom.us
  • When: February 10, 2021 at 4pm-5pm UTC ( February 10th, 8am-9am PST )
  • Location: on calendar invite to registered attendees
  • Contact:
    • Name: Derek Schuff, Luke Wagner

Registration

If you are a Working Group member no registration is required.

If you are a Community Group member who would like to observe, registration details to follow shortly.

Logistics

The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.

Agenda items

  1. Opening, welcome and roll call
    1. Opening of the meeting
    2. Introduction of attendees
  2. Find volunteers for note taking (chair to volunteer).
  3. Adoption of the agenda
  4. Proposals and discussions
    1. Review of action items from prior meeting.
    2. POLL: standardize phase 4 proposals (Andreas Rossberg)
      1. Bulk Memory operations
      2. Reference types
    3. Discuss next steps for the working draft (Eric Prud'hommeaux)
  5. Closure

Agenda items for future meetings

None.

Schedule constraints

None.

Meeting Notes

Attendees:

Luke Wagner

Andreas Rossberg

Conrad Watt

Deepti Gandluri

Derek Schuff

Jakob Kummerow

Wouter Van Oortmerssen

Thomas Lively

Sergey Rubanov

Zhi An Ng

Eric Prud'hommeaux

Proposals and Discussions

Announcement/proposal: New chairs for working group: Luke Wagner, Derek Schuff have agreed to do this.

Consensus poll for LW and DS co-chair for WG. No objection, passes.

Technically, it turns out Fastly has not finished joining the W3C yet, so we should wait until that happens before making this official.

1. POLL: standardize phase 4 proposals (Andreas Rossberg)

1a. Bulk Memory operations

No relevant open issues on either of the repositories - landing this means we land both of them. Proposals are mutually dependent on each other, so they have to be merged together, not in isolation.

Current plan: Merge both from the Reference types proposal.

DS: general question, any other proposals in the pipeline that has this kind of mutual dependency?

AR: Don’t think so and hope not - we added some features the wrong way and we didn’t see the implications right away - if done differently would have left out all the tables out of the bulk proposals, etc. There were no technical reasons to separate them this way.

DS: it was because we wanted the memory part for threads, the table part is kinda independent

AR: only place where they were more closely related and kinda ugly if we did one and not other, changes in data and element section. It wouldn’t be a problem but a little ugly. Not aware of any other set of proposals that would have the same problem. Hope we learned a lesson there.

LW: Acyclicy is valuable

AR: we didn’t see that there was a cycle in there at first

TL: Related feature of the bulk memory proposal that we would do differently - I don’t know any use in the wild of the bulk table instructions. If we were doing it now we would be careful that the operations should be something that would be in use.

AR: fair concern, on the other hand, it’s also fair to say that there is some level of consistency within the language, here I think you can argue either way. I wouldn’t take it to the extreme, i have seen it in some discussions that I do not entirely agree with, every instr has to be individually motivated, when there is a set of similar things and not have random holes in the matrix in some form. Different topic I guess.

DS: we can go for a consensus poll, say we want to merge these 2 proposals as outlined in slides. Any discussions/objections on this.

LW:Asked FF implementors if they knew of any outstanding proposals - none so far.

DS: will take that as a yes.

AR: will create this PR, not sure how much work it will be. Think before, the things were merged by Ben, and I did the reviews for that. For this one, it’s a bit larger, and supposedly been reviewed in detail before. Always better if someone looks again.

DS: I can definitely look, one of the things I have to do is figure out how to build the doc and get familiar with all of that aside from technical stuff. I can figure that out as I go.

AR: another thing I want to ask. If i remember correctly, is it Ben or Brad who figured out how to do a diff on the doc somehow?

TL: Rings a bell, don’t remember

EP: are you thinking about doing various editions of Working Draft? I did by hand, and it is miserable.

AR: We have two/three documents we can produce - there is a pdf, and different page html - one of them had an option of producing a diff.

EP: a lot of variation, they all kinda suck, don’t be optimistic

DS: i can find out and see what...

AR: Another thing that came up was that if there should be some kind of appendix on the spec, not a detailed spec, but just a note about which instructions were added with the spec - we should also cover the ones we’ve already merged. That might be good to add before we have an official W3C branded version of this

EP: it was a big burden before, X and I are trying to figure out. We have this rule about eating our own dogfood, making sure document is accessible. Anyone has idea what happens if you read sphinx docs with screen reader? Speaks in your ear.

AR: Probably horrible.

EP: The rendered on, math is going to be hard, ways to get annotation to make it not suck too badly. That’s what we were trying to do before. Looking for some way to achieve that.

LW: in some ways, the prose description should correspond to the math equations. It’s a alt text for the formulas.

EP: That’s a fair point, maybe the annotations should say don’t read this part aloud

AR: was wondering if we should have nicer kind of layout for the separate formulas, so that some background or frame around them, more nicely separated from prose text. Not sure how to produce that from sphinx.

EP: It’s possible that that would allow us to set CSS media control

AR: There’s still going to be some amount of math in the prose - when you abstract some aprt of the spec - don’t know how you would pronounce that

EP: if you can the attention of T. V. Raman they can probably help. Is there a particular chunk of the document that we can give someone to look at, typical piece that sets a low/high bar for complexity.

AR: I would pick some random parts from validation - for each instruction it has the prose and then...

LW: complex rule, the instantiate rule

AR: that would be the rule, instantiation rule, in the execution section.

EP: instantiate is the top bar, lower bar is either validation or some execution. Will see if I can get his attention.

AR: just pick some instruction in both rule.

AR: Is this something <accessibility - screen reader> someone requested?

EP: part of the w3c process, basically is w3c eating its own dogfood. And a reasonable number of people in the community who need these technologies. Would like to publish sphinx, a bit of css to put w3c in the top.

  1. Discuss next steps for the working draft (Eric Prud'hommeaux)

AR: what is our timeline for cutting a new official version of standard. Don’t think we discuss that properly. We have merged a bunch of stuff.

EP :Typically the working group gets to split the difference between keeping the world informed and making a good first impression - we have to worry about keeping the world informed - the other thing is producing the document which we can do with sphinx and a little bit of css

AR: we are still at version 1.0, published ~2 years ago? Wonder if after merging these proposals, will be a natural point in time to have 1.1. Don’t think there are any other proposals that are nearly landing right now.

EP: When Brad set this up, he kept a naming scheme that would allow us to have Wasm 2, 3. We don’t have anything backward incompatible so we can go with 1.1..

AR: yea think the version on the doc is 1.0, so we can use 1.1. From my perspective makes sense, it’s not a fundamental change.

EP: Is this uncontroversial - are there any places where it’s not backward compatible?

AR: Not in any relevant way

TL: if we ask for other proposals, SIMD is about to land, not sure if we want to cut it in so soon.

AR: that’s at phase 3 right?

TL: we’re voting for phase 4 at the next meeting.

AR: still a lot of movement on the PR as far as i can tell, still a lot of code reviews.

TL: right, don’t think it’s ready to move to phase 5 soon, but if we are asking if proposals going to land, maybe wait for SIMD so we can include that as well, since it’s going to be phase 4 soon. Or not, then we can put into the next version.

EP: We can have another working draft any time we want - around november we wanted to talk about if we want a new patent policy. Does anyone have any opinions? Should we switch to the new patent policy - does anyone have an objection to an evergreen policy?

DS: what we were deciding was a new patent policy which will give us the option to move to a living document.

EP: we don’t have to, Philip wants to use new policy anyway, slightly more aggressive towards lawyer, but no one complained, so we have the green light for them. So all WebAssembly members inadvertently given it green light. It is up to us to say if we want to do that. We can make a decision now, or wait 2 weeks and have it on an agenda.

LW: What was the issue - existing discussion?

DS: cg meeting, don’t think there was a thread about it.

LW: I remember there was a discussion...

EP: if you want some details I can give you now, possible for us to figure out which meeting it was. We talked at a couple of consecutive meetings.

LW: Maybe just - links to patent policy would be helpful, what it means to be a living document etc. In general like the sound of it - want more details.

EP: let me go dig that up. Switching to a new patent policy doesn’t commit us to a living doc, it just gives up the latitude to do switch. Living document means you get to stay in CR and iterate there a while. And also that’s what some groups, like HTML, don't’ really remember. Other groups with more formalism, this has been tested as of version 1.1, better meet the needs of customers.

LW: When you iterate in CR, are there no version numbers produced as a part of that?

EP: don’t think so, you use dates, means less synchronization with the test suite.

LW: There’s the sphinx rendered that goes live, and separately there’s a thing that goes through bikeshed - I don’t think anyone really reads those compared to the web versions...

EP: right, think there might be some reason for a person with a screen reader. It’s a giant monolithic document, real swapper. Think most people would avoid it, because it takes so long to load.

LW: Do they have the hyperlinks between the uses and definitions - that’s my favorite feature

EP: yea. In fact it relies on mathjax, so you can click on stuff.

LW: In the final output I thought maybe the JS would have stripped away

AR: output using Katex. Multi page document uses mathjax, it’s more accurate, then the katex involves brave hacks by brad to make it look ok. Maybe that has improved by now, not sure. We should explore that mathml is coming back?

EP: We could become a usecase for them

LW: that’s how i use in FF, use mathml instead of mathjax.

AR: Would be cool if we could use them - mathjax is crazy but it has limitations and is pretty slow

EP: think that would be fabulous, also make accessibility stuff someone else’s problem. Found links to process documents and stuff like that. This is on my laptop, not on the hangout, will paste them to DS.

Links to process docs: https://www.w3.org/2020/Process-20200915/ https://www.w3.org/2019/Process-20190301/#GAProcess https://www.w3.org/Consortium/Patent-Policy-20200915/

LW: is mathml close enough to what’s currently written in sphinx? Or is it totally different?

AR: it would get generated.

LW: is mathml close enough to what’s written in latex.

AR: You mean writing manually? It’s a nightmare you don’t want to do that - whole insanity with SGML syntax - lots of nesting etc. with formulas etc. it’s not great.

EP: hard to compete with something that’s effectively DSL. will be cool to have that. Other thing to explore, sphinx has svg output, but no links in it. There’s a possibility there, but no one seems to know anyone who knows in sphinx. Need someone interested to dive into that, to get SVG generator to include the links. Not sure who can do that feature quickly.

AR: another problem with Sphinx, pinned fairly old version, cos they keep breaking stuff. Some plugin stuff we did to enable some macros would not work with newer versions. Someone would have to upgrade it. Tried to figure out how it works and failed, can’t be bothered right now. No idea if it would take someone who has intimate knowledge of sphinx.

EP: If we found out someone could answer the questions..

AR: in retrospect we should never have used sphinx

LW: If you would start from scratch, what would you use? AR: latex obviously. Initially we decided to ues markdown. Actually much more overhead due to the embeddings and all the markup you have to do to embed tiny pieces of math.

LW: Do you think this is just a matter of paying a contractor to do a manual port?

AR: we have all these proposal repos which are forks, any kind of changes done will create massive conflict across the board.

LW: We can graft the outstanding diffs.. Shared memory work is significant and outstanding, quite a few proposals have spec text written in them

AR: quite a few proposals that already have spec texts. I know because I wrote some of them. Even then it is painful when you have non-trival changes upstream, already merging conflict there. Can’t imagine how bad it would be if you made complete structure change.

LW: Would need a rewrite from scratch with a diff

AR: write a tool to write the conversion.

LW: if the better tool is latex, we should get it in sooner or later.

AR: IF there’s any good point in time to do that, right now certainly sounds like a bad time - if the number of active proposals slows a little with most of the features we were envisioning already being in..

EP: ideally people lose interest and wander off

AR: Latex just produces one big..

ZN: we already can convert the rst to latex? We check in the latex instead of the rst?

AR: We would have to find and investigate tooling to create a multipage webpage

LW: multi-page webpage, yes, i like it.

AR: There are tools that do that, but don’t have experience with that - how difficult in general it will be - I have heard wildly different stories about that

EP: nice opportunity to use a different toolchain

AR: every toolchain has its own set of problems. General fear that this is quite an investment for some time, to switch to some other toolchain. Not entirely sure it is significant and worth the effort. Maybe the pain isn’t high enough yet.

DS: If we’re looking for ways to significantly improve our process, what would the alternative be? Do we keep sphinx, Brad had a made a hack and we got three different outputs - if we don’t want to rewrite everything, or package everything etc..

AR: The tooling is there, it’s a hack but it’s automated and it’s there. There isn’t something much to do unless something breaks.. That could happen - the last change was when Ben rewrote the script for the table, we have various workarounds for the issues, but at least for now they work so there’s no immediate thing to do modulo the release process

LW: just the production of the bikshedded w3c

AR: that’s automatic, but the officially stamped out, not sure if anything else done there

AR: would have to ask brad, not sure what he did, maybe it’s part of automation. I’m pretty sure there are some editorial things. At that time a lot of stuff, mostly involved katex. Maybe it’s all automated now.

DG (Chat): Not to derail the conversation, but I realized we don't have another meeting on the schedule - should we talk about meeting cadence in the last couple of minutes even though it's not on the agenda?

AR: sounds good. Vaguely remember we decided this should be monthly, but cancelled if no agenda.

DS: yea that seems fine, we’ll have a few more things to talk about in the future. That’s what happened, we had things to talk about regularly, then nothing. Monthly sounds about right to the rest of you?

EP: makes sense

AR: no one set up an agenda doc, nowhere to put PRs, if the new chair can put up agenda…

DS: sounds like a problem we can fix. This time slot is good for everyone?

EP: good

AR: good for me too

LW: any reason we can’t splat out the rest of the year, or dynamically? I can set up reminder to make an agenda 2 weeks ahead of each.

DS: don’t see a problem scheduling in advance too.

AR: my impression was that we did it a couple at a time, at least for CG meeting, why not.

<General consensus, time slot mostly works for everyone>

DS: i posted the links to patent policy, probably discuss next time, get that out of the way, AI for anyone who cares to look at that so we can decide on that next week.

EP: vague recollection that we would decide by email/issue. Wll be nice to let philip if we are eligible before a month or two. Do you think we can reach a decision on a charter before a month is up?

AR: the patent issue?

EP: yea.

AR: I’m fine with anything

DS: we could do a auto switch and say, if anyone doesn’t object in a week, we will do it by default.

EP: seems sensible, not sure anyone cares.

DS: Anyone can take a look at the policy..