Derek Schuff

I'm definitely interested in moving debugging forward. This particular proposal is just a small adaptation to the existing scope and functionality of source maps (i.e. as purely a line-table facility...

> This was also previously discussed as an addition to the MVP, and more recently as an option for better memory management. The 2 links you used there are the...

Adding read/write methods on wasm memories (as a substitute for ArrayBuffer views) might serve this use case too, but would still mean that arraybuffer views could never be reliably used...

We are also very close to having milestone 3 support in Binaryen. That's currently our priority ("we" being Chrome's wasm tools team) so you might also check that out. On...

Thinking about the exception identity here... IIUC: When an exception is originated from wasm: 1. the first time it propagates into JS `opaqueData` is null (so it lands in 12.2...

If I understand correctly, it sounds like: 1) You believe the EH proposal in its current form (let's call it "MVP EH") would not conflict in principle with your ideas...

> So I think what you are suggesting in your plan is that, with appropriate signaling to the community, we can expect enough V1 programs to have been recompiled into...

This has been discussed in the context of a new proposal we call "memory control" (See https://github.com/WebAssembly/memory-control and the [discussion](https://github.com/WebAssembly/design/issues/1439) proposing it)

Based on our previous discussions, I think the conclusion was that we do want to do this. As you said, I think that it would be a WebAssembly.Tag object, and...

> I've already read that code. I know what it does. It isn't necessary for this example, I’d like to repeat the objection that it’s not fair to compare the...