dcodeIO

Results 453 comments of dcodeIO

There is still some uncertainty around this subject in the spec. Could well be that `anyref` is removed, or that `externref` is reintroduced, and I can't really tell from the...

One way to think about this could be that *global* elements have a second internal name, e.g. `~lib/string/String` can also be looked up internally with just `String`. So by convention,...

Hmm, perhaps a check that `elementsByName.get(theShortName)` exists, i.e. that the assumption that the short name can be used holds.

Binaryen's Wasm code is embedded in Binaryen's JS code as a base64 blob. That leads to the following situation: 1. The JavaScript code that includes the large blob is parsed...

Open to ideas on how to also enable the case where a view is desired. Right now, the bindings do what's always safe, i.e. copy, plus I didn't see a...

ArrayBuffers are currently copied as well (there's `__liftBuffer` and `__lowerBuffer` for these). An ArrayBufferView would lose the type (and is merely an interface anyway), so one could technically just pass...

Are these instructions planned in Wasm? Otherwise it seems that these should not look like instructions but using the generic variant is preferred.

I believe `i8x16.shuffle` is the (only) instruction existing in Wasm, motivating the generic variant (that also provides convenient fillers), while there is no `i16x8.shuffle` in Wasm. Thought the convention is...

Background: Doesn't happen automatically currently, because then we'd have to GC table entries via RC from heap objects hooked with a finalizer or something. Not yet supported :)

So if I understand correctly, the type-disjoint bit is the difference to #2253 here, exposing the underlying value as a quasi field. The observation that this can quickly go into...