5 ms·
Neat, a few of these accepted proposals were the topic of my Master's thesis a couple years ago: https://github.com/jacobmischka/uwm-masters-thesis https://gith
by jacobmischka 4y ago
Neat, a few of these accepted proposals were the topic of my Master's thesis a couple years ago: https://github.com/jacobmischka/uwm-masters-thesis https://github.com/jacobmischka/uwm-masters-thesis
Exciting to see a major release, though admittedly it seems a little arbitrary if there aren't any breaking changes (and very problematic if there are?).
- MuffinFlavored 4y agoAs somebody familiar with WebAssembly, how would you do FFI? like say you wanted to make a J2534 DLL http://www.drewtech.com/support/passthru.html http://www.drewtech.com/support/passthru.html How would you export these DLL functions or even call functions from other DLLs (dlopen/dlsym, etc.)
- gary_0 4y agoYou can import host functions and data to a WASM VM much like you would with, say, an embedded Python VM. The exact API depends on which VM implementation and host language you're using. dlopen/dlsym support is still in the works (for example, see [0]). You can't call function pointers directly from WASM, naturally, but it is possible to wrap dlsym so you can use it from a WASM program. There just isn't a standardized/pre-made way to do it yet, so you'd have to write the glue code yourself. [edit] The Emscripten WASM toolchain seems to support dlopen/dlsym, see: https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md https://github.com/WebAssembly/tool-conventions/blob/main/Dy... [0] https://github.com/wasmerio/wasmer/issues/1995 https://github.com/wasmerio/wasmer/issues/1995
- bluejekyll 4y agoYou may want to look into WASM interface types, which is defining what amounts to an IDL for WASM so that different languages have common calling conventions: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... I don’t know if there’s a better intro article. I believe this is the current iteration of the proposal: https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro...
- infogulch 4y agoWA will likely never publish anything backwards-incompatible, this is the web after all. If WA's worst versioning sin is 'abusing' the major version to collect a number of currently implemented proposals under a canonical name, I'll live. And pray that nobody from the USB or HDMI standards committees get anywhere near.
- nagisa 4y agoWell, backwards compatibility is really a spectrum and the interpretation of the concept can fall at either end of the spectrum depending on what a person is working on. As far as wasm is concerned, there are at least two known discrepancies that made into this draft as documented here https://github.com/WebAssembly/spec/issues/1439 https://github.com/WebAssembly/spec/issues/1439. Especially the last comment by Alex here seems interesting to me – on one hand the observable result of the execution changes for the same program. On another, who is going to bother writing such programs? Should WebAssembly specification be allowed to assume nobody does and make changes such as these?
- Lorin 4y agoIt's such novel tech, why bother with backwards compat between major versions until more developers use it?
- saurik 4y agoWell like, I'd think there would want to be some consistency in the meaning between WebAssembly 1.0/2.0 and WebGL 1/2?
- pjmlp 4y agoWebGL vs WebGPU shading languages.
- tomcam 4y agoPDFs here: https://github.com/jacobmischka/uwm-masters-thesis/releases/tag/1.0.0 https://github.com/jacobmischka/uwm-masters-thesis/releases/...