From eba2b1a3b4291d996c290b032f0a4845987e1e85 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Fri, 11 Oct 2019 08:39:31 -0700 Subject: [PATCH] Catch up on posting the meeting notes to the WASI repository. --- meetings/2019/WASI-08-15.md | 70 ++++++++++++++++++++++++++++++++++++- meetings/2019/WASI-08-30.md | 20 ++++++++++- meetings/2019/WASI-09-12.md | 55 ++++++++++++++++++++++++++++- meetings/2019/WASI-09-26.md | 25 ++++++++++++- 4 files changed, 166 insertions(+), 4 deletions(-) diff --git a/meetings/2019/WASI-08-15.md b/meetings/2019/WASI-08-15.md index 1159c9324..8062b2745 100644 --- a/meetings/2019/WASI-08-15.md +++ b/meetings/2019/WASI-08-15.md @@ -50,4 +50,72 @@ Installation is required, see the calendar invite. ## Meeting Notes -Posted after meeting. +Attendees: + +Dan Gohman +Till Schneidereit +Alex Crichton +Luke Wagner +Jacob Gravelle +Sam Clegg +Andrew Scheidecker +Mark S. Miller +Johnnie Birch +Stefan Junker +Andrew Brown + +Meeting notes: +Topic: Weak Imports: https://github.com/WebAssembly/WASI/pull/47#issuecomment-521061962 +sbc: moved back to custom section design +[please fill in notes here] +MarkM: could a rename be considered—I always think of weak references +Sbc: very strong precedence in C/C++ +MarkM: weak/optional imports should be brought up with TC39 +Luke: [posts a link https://github.com/guybedford/proposal-weak-imports] +Dan: good question, should we rename? +Stefan: +1 on “optional” +Mark: would “optional” be confusing? +Seems like “no” +Dan: seems like consensus +Sbc: [takes an action item to rename] +Dan: anyone opposed to landing the PR once the rename is done? +[no] +Dan: let’s do it +Topic: Interface description based on Module types (https://github.com/WebAssembly/WASI/pull/74) +Dan: lots of stuff going on around OCap, and that should go on +But in parallel, we need a simple text format +This PR introduces a stripped down text format (see PR description for details) + +Mark: should we introduce a term such as “compartment” to describe sets of instances which share memories and tables? +Sam: This relates to the concept of “shared-nothing linking” which we have been introducing. +Luke: In full generality, we won’t need the term compartment, because we’ll just have references and different linking approaches. +Luke: if we want wasi_unstable to become wasi, we need to spec ways to send capabilities between modules. We don’t if we just have references +Till: brings up the question if we need to support wasi_unstable, instead of just breaking it +[discussion] +Mark: This is a useful concept, whether or not it’s something +[discussion] +Luke: getting back to the proposal, looks good for the transitional role +Dan: idea is, once we have a parser for this, we could land it, and have it be the specification +Could generate header files and documentation from it +Sbc: comments go into some kind of comment syntax? +Dan: double-semicolon +Sbc: need some kind of include mechanism +Dan: yes, good point. Want to really keep this simple +Luke: same requirement came up in conversations with Andreas about defining types in one module and using them in another +Luke: but as long this is all structural, can just agree on structure of types +Dan: + +Dan: We need to factor out types so they can be shared between multiple modules. Maybe something like a #include mechanism? +Mark: #include would be unfortunate in any kind of standards context. +Luke: We could put multiple modules in one file +Dan: Could we design a more declarative form which achieves the same goal but doesn’t have the same problem? +Mark: It’s premature to do a lot of IDL design work +Dan: agree + +Timezone discussion +Till, Johnnie: conversations about voting, and people not being able to attend all meetings. Perhaps we can find a way to do votes offline to allow people to vote even if they can’t attend the meeting. +Sam: Another option is to do the vote in the meeting, but hold it open for a week or so after to allow others to vote. +Till: That does change the dynamics. +Johnnie: Would it makes sense to record the meetings? +Dan: What if we ask the CG to record their meetings? We can follow their lead. +Johnnie volunteers to take that to the CG. diff --git a/meetings/2019/WASI-08-30.md b/meetings/2019/WASI-08-30.md index fd2f274a1..cbd14a725 100644 --- a/meetings/2019/WASI-08-30.md +++ b/meetings/2019/WASI-08-30.md @@ -43,4 +43,22 @@ Installation is required, see the calendar invite. ## Meeting Notes -Posted after meeting. +Attendees: + +Dan Gohman +Xin Wang +Leon Wang +Arun Purushan +Till Schneidereit +Tyler McMullen +Sam Clegg + +Meeting notes: + +Time zone: +XW: Seems like we can move to the previous time. +DG: We can be flexible in the future too. + +XW: Presentation on WASI for Embedded + +DG: Update on https://github.com/WebAssembly/WASI/pull/74 diff --git a/meetings/2019/WASI-09-12.md b/meetings/2019/WASI-09-12.md index edcf5f95d..e8bf1a518 100644 --- a/meetings/2019/WASI-09-12.md +++ b/meetings/2019/WASI-09-12.md @@ -36,4 +36,57 @@ Installation is required, see the calendar invite. ## Meeting Notes -Posted after meeting. +Attendees: + +Dan Gohman +Sam Clegg +Pat Hickey +Yury Delendik +Artur Jamro +Mark McCaskey +Alex Crichton +Jacob Gravelle +Mingqiu Sun +Nathaniel McCallum +Luke Wagner +Johnnie Birch + +Meeting notes: + +Agenda seconded by Pat + +Dan: Last meeting was at a different time than usual. There were only 6 attendees. We are going to resume meetings at the normal time, 1600 UTC. + +Dan: Next topic is WITX. + +Independent of WASI, there is a new file format called WIT from the interface-types proposal. Its a lot like WAT, but it does not have function bodies. + +WITX is WIT with extensions. It has some of the types from interface-types. The idea is that WITX is not a stable format, its going to evolve to align with WIT as interface types evolves. + +Fortunately our needs are pretty simple at the moment: we are adding strings, arrays, enums, and structs to the wit file. + +We want WITX to be the way we specify WASI apis. It feels like a better place than the C header file we started with. + +Pat: lucet-idl tool has a witx parser in development. + +Working on hooking up this parser to the C and Rust interface generators. +Goal, be able to feed witx files into lucet-idl and generate C headers and Rust interfaces. + +Can be used to generate libc definitions for WASI + + +Stefan: Does WITX have modules? + +Dan: Yes, but the file we have at the moment attempts to be the exact same wasi_unstable module we have right now. Once we land this, we can immediately start factoring that module into multiple modules, and witx should support that. + +Sam: Is there a way to use types from a different module? + +Dan: Yes, there is a `use` mechanism, and in the PR there’s two witx files, wasi_unstable’s first declaration is to `use “typenames.witx”` + +Dan: Next agenda item: Phased API development (PR 88). Apologies for getting this up late. + +Stefan: Could there be a standalone parser implementation somewhere? + +tdoPat: I’ll make the lucet-idl parser and validator for witx into its own crate, and that crate will live in the WASI repo. + +Johnnie: I followed up on whether we can record these meetings, I talked to the W3C and they expressed the same concerns we heard here about privacy, making people feel comfortable speaking up. They suggested I talk to the WASM CG, but given that I’ve heard the same feedback from multiple places, I’m going to just drop the issue. diff --git a/meetings/2019/WASI-09-26.md b/meetings/2019/WASI-09-26.md index 2534b24a3..704aed13a 100644 --- a/meetings/2019/WASI-09-26.md +++ b/meetings/2019/WASI-09-26.md @@ -34,4 +34,27 @@ Installation is required, see the calendar invite. ## Meeting Notes -Posted after meeting. +Attendees: + +Dan Gohman +Andrew Brown +Mark Bestavros +Leon Wang +Alex Crichton +Peter Huene +Luke Wagner +Yury Delendik +Pat Hickey +Artur Jamro + +Meeting notes: + +DG: WASI modularization draft PR is up, comments are welcome + +Also, this makes the start of the point where we can start taking PRs for new API proposals, in the form of PRs which add and modify witx files. + +Pat: We’re working on an HTTP API proposal. + +Dan: There are also people working on Berkeley sockets APIs. Note that though there is a potential for overlap here, it makes sense to develop both. + +Pat: In cases of overlap like this, the higher-level APIs may even by polyfillable on top of the lower-level APIs.