Skip to content

Latest commit

 

History

History
257 lines (175 loc) · 9.7 KB

CG-02-06.md

File metadata and controls

257 lines (175 loc) · 9.7 KB
Raw

WebAssembly logo

Agenda for the February 6th video call of WebAssembly's Community Group

  • Host: Google Hangouts
  • Dates: Tuesday Febrary 6th, 2018
  • Times: 17:00–18:00 UTC (9AM–10AM Pacific Time)
  • Location: same Google Hangouts link as before
  • Contact:

Registration

None required if you've attended before. Email JF Bastien to sign up if it's your first time. The meeting is open to CG members only.

Logistics

The meeting will be a Google Hangouts call.

Agenda items

  1. Opening, welcome and roll call
    1. Opening of the meeting
    2. Introduction of attendees
  2. Find volunteers for note taking (acting chair to volunteer)
  3. Adoption of the agenda
  4. Proposals and discussions
    1. Review of action items from prior meeting.
    2. Rename memory operations (carry-over from the previous call)
    3. Advance Sign-extension operators proposal
      1. Spec text: https://webassembly.github.io/sign-extension-ops/
      2. Has tests and reference interpreter implementation
      3. Should we add i32.sext?
    4. Advance Import/export Mutable Globals proposal
      1. Spec text: https://webassembly.github.io/mutable-global
      2. Has tests and reference interpreter implementation
      3. Should we add accessors for mutability and type?
    5. Discussion: How should we hand out WebAssembly repos for proposals. (Brad Nelson)
      1. Current phases document implies we hand them out when appropriate, but is vague on what the bar is.
      2. Phases Doc
      3. POLL: We should liberally hand out repositories for proposals brought to the CG. This can be done between meetings by directly contacting chairs at their discrection.
      4. POLL: We should require a CG meeting vote to create a github.com/WebAssembly repo for a Phase 0 proposal.
    6. Propose we create an unmanged-closures repo (Mark Miller).
      1. POLL: We should create an unmanaged-closures repo for this phase 0 proposal.
    7. Propose we create a js-types repo (Andreas Rossberg).
      1. Overview
      2. POLL: We should create a js-types repo for this phase 0 proposal.
    8. Future in-person meetings
    9. Other items TBD
  5. Closure

Agenda items for future meetings

None

Schedule constraints

None

Meeting notes

Roll Call

  • Arun Etmr
  • Ben Smith
  • Ben Titzer
  • Brad Nelson
  • Dan Gohman
  • Deepti Gandluri
  • Eric Holk
  • JF Bastien
  • Jacob Gravelle
  • Lars Hansen
  • Lin Clark
  • Luke Wagner
  • Malcolm White
  • Marcos Diaz
  • Mark Miller
  • Martin Bing
  • Michael Bebenita
  • Michael Holman
  • Michael Starzinger
  • Paolo Severini
  • Pat Hickey
  • Peter Jensen
  • Richard Winterton
  • Sean Dinwiddie
  • Sean Westfall
  • Sergey Rubanov
  • Sven Sauleau
  • Trabelsi Marwen
  • Tyler McMullen
  • William Maddox
  • Yury Delendik

Opening

Adoption of the agenda

Adopted.

Find volunteers for note taking (acting chair to volunteer)

JF volunteers

Discussions

Review of action items from prior meeting.

Tracked in the meetings repo’s issues

Future in-person meetings

Tentatively mid-April hosted by Fastly in SF, or Mozilla in Mountain View. Otherwise Google can find space.

Rename memory operations

Ben Smith

carry-over from the previous call

Renaming grow_memory and memory_size to mem.grow and mem.size. Let’s look at the PR #649 in spec repo and discuss next meeting.

Advance Sign-extension operators proposal

Ben Smith

Was split from thread repo.

    1. [Spec text](https://webassembly.github.io/sign-extension-ops/)
    1. Has tests and reference interpreter implementation

Should we add i32.sext? Decided not to do for now, nobody cares enough

Requirements to enter implementation phase:

  • Test suite has been updated to cover the feature in its forked repo.
  • The test suite should run against some implementation, though it need not be the reference interpreter.
  • Formal notation in the spec need not be updated.

It’s in Firefox nightly, and in spec interpreter (in the repo fork).

POLL: move this proposal to implementation phase?

Unanimous consent

AI: Ben to update the repo with the status, and JF to update the tracking issue.

Advance Import/export Mutable Globals proposal

Ben Smith

Similar state, but not quite as baked.

    1. [Spec text](https://webassembly.github.io/mutable-global) (for core and JS APIs)
    1. Has tests and reference interpreter implementation

Should we add accessors for mutability and type? Might be covered by Andreas’ JS types proposal.

Implemented for immutable globals in Firefox. Lars is working on the rest. Haven’t seen any web compatibility issues so far.

  • Michael: do we have usecases for this now besides threads?
  • Ben: mostly trying to get ahead of web compat issues.
  • Luke: also toolchains can put the stack pointer in there.
  • Brad: also, nice shared libraries with threads.
  • Michael: I’d like to have it stand on its own before we move forward.
  • Ben: also, you can’t export an i64 for now.
  • JF: what if we ask for this feature to be used by a toolchain? The way we’ve worded the phase document is VM-centric, but really this is being driven by toolchains right now, so the requirement on having one implementation should be on toolchains.
  • Dan: LLVM emits this today.
  • Michael: I’m good with this if LLVM emits it today.

POLL: move this proposal to implementation phase?

Unanimous consent

AI: Ben to update the repo with the status, and JF to update the tracking issue.

Discussion: How should we hand out WebAssembly repos for proposals.

Brad Nelson

Current phases document implies we hand them out when appropriate, but is vague on what the bar is. Where does one request, who approves, and who creates the repo?

Phases Doc

  • File an issue on the design repo. Discuss there, and start basic design work.
  • Add to schedule for the next CG video call or in-person meeting.
  • Vote on whether we think this might be something we want to do at some point in time. Is it in scope for the CG?
  • Repo and tracking issue are created.

POLL: We should liberally hand out repositories for proposals brought to the CG. This can be done between meetings by directly contacting chairs at their discretion.

Tabled

POLL: We should require a CG meeting vote to create a github.com/WebAssembly repo for a Phase 0 proposal.

Unanimous consent

AI: Brad and JF to update the phases proposal.

Propose we create an unmanaged-closures repo

Mark Miller

  • Current repository: https://github.com/erights/wasm-linkage
  • Mark: The name is bad.
  • Mark: Some things in the GC proposal are good but can be moved out. Opaque functions. When linking different modules, they don’t have common indices. You also want protected entry points. Closures don’t imply dynamic allocation.
  • Eric: has anyone else contributed to this repo?
  • Mark: not right now.
  • Dan: what do you expect the producers to do with this?
  • Mark: example, Salesforce expressed interest. With module linkage rules, the module can be a perfect sandbox to prevent code to do anything unauthorized. Expressivity problem with least-??? Plugins. Similar to frozen realms in JavaScript. Don’t share address space (disjoin memories and tables), but have rich API which passes functions and closures. Leverages perfect sandboxing of WebAssembly, but with more expressiveness, and without needing dynamic allocation.
  • Dan: what languages do you expect them to use?
  • Mark: Google Earth does something similar, with plugins, in C++.
  • JF: I think what Dan is getting to is how does a C++ toolchain know what to generate from this feature? Attributes, lambdas, etc?
  • Mark: won’t be an accidental outcome of existing toolchains. Andreas suggested adding an explicit constructor which takes the function and the payload, and gives you a closure. He didn’t like it, but thinks it’s the natural way to do it.

POLL: We should create an unmanaged-closures repo for this phase 0 proposal (move Mark’s repo to the WebAssembly organization).

Unanimous consent

AI: Mark to coordinate with Brad. JF will create tracking issue.

Propose we create a js-types repo

Brad for Andreas Rossberg

Overview

Examine information in a module’s headers from JavaScript. This is a comprehensive introspection proposal. We have a few open issues in the design repo, this does more.

POLL: We should create a js-types repo for this phase 0 proposal.

unanimous consent

AI: Brad to work with Andreas on repo. JF to create tracking issue.