3 ms·

Looks good! Just for my understanding, what would be the advantage of working with wasm binaries instead of, let's say, C external libraries or DLLs via ctypes?

Looks good! Just for my understanding, what would be the advantage of working with wasm binaries instead of, let's say, C external libraries or DLLs via ctypes? I can think of: 1. Portability of the wasm binaries Is easier interoperability between data types an advantage as well? Ctypes can be a nightmare when passing around structs and pointers (and pointers of pointers, etc.)

make3 7y ago
My first impression is that the goal of this project is to run binaries that were likely built for other purposes like the web, not that they actually think that making libraries into webasm and running them into python has any particular advantages vs other options that already exist
sanxiyn 7y ago
There's also sandboxing. You shouldn't load untrusted DLL, but loading potentially untrusted WASM is a design goal of WebAssembly.
flohofwoe 7y ago
I have an actual real-world use case for this :) Shader-cross-compilation for 3D frameworks: https://floooh.github.io/2017/05/15/oryol-spirv.html https://floooh.github.io/2017/05/15/oryol-spirv.html I'm hooking python scripts as custom-build-jobs into C/C++ projects which (for instance) takes care of compiling GLSL shader code into HLSL (D3D), MSL (Metal) and various GLSL versions (for GLES2, GLES3 and desktop GL). Khronos provides C++ projects which help with this stuff: https://github.com/KhronosGroup/glslang https://github.com/KhronosGroup/glslang https://github.com/KhronosGroup/SPIRV-Cross https://github.com/KhronosGroup/SPIRV-Cross So I'm using Python to hook my custom build jobs into the C/C++ build system (via cmake), but I still need to invoke native command line tools (or DLLs) which wrap around those Khronos libraries. Currently this means building (at least) 3 executables for Windows, macOS and Linux, and "distribute" those precompiled exes with my python code. It looks like with this python+wasmer solution, I can instead compile the Khronos libraries into WASM modules, and the result runs "anywhere" where wasmer runs (e.g. also Raspberry Pi, BSDs etc...). That's really cool stuff :)
justanegg 7y ago
could be useful for TDD
JackC 7y ago
Portability might also bring along with it easier reproducible builds? Right now I believe if you use wheels, you basically have to trust that the distributed binary matches the source code. I saw a case where a package was taken over by a new maintainer who released wheels for an existing source release, and everyone basically shrugged and said, eh, this is probably fine, because there was no easy way to check. It sounds much easier to build an automated system that could check if wasmer-based packages are faithfully compiled from source, because there's only one compile target. Sandboxing also sounds valuable, as mentioned by a sibling. I'm thinking of projects like imagemagick that run all kinds of untrusted input through all kinds of processing. It would be nice if there was a simple default way to write data processing libraries the way djb would write them.[1] [1] https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf

make3 7y ago

My first impression is that the goal of this project is to run binaries that were likely built for other purposes like the web, not that they actually think that making libraries into webasm and running them into python has any particular advantages vs other options that already exist

sanxiyn 7y ago

There's also sandboxing. You shouldn't load untrusted DLL, but loading potentially untrusted WASM is a design goal of WebAssembly.

flohofwoe 7y ago

I have an actual real-world use case for this :) Shader-cross-compilation for 3D frameworks: https://floooh.github.io/2017/05/15/oryol-spirv.html https://floooh.github.io/2017/05/15/oryol-spirv.html I'm hooking python scripts as custom-build-jobs into C/C++ projects which (for instance) takes care of compiling GLSL shader code into HLSL (D3D), MSL (Metal) and various GLSL versions (for GLES2, GLES3 and desktop GL). Khronos provides C++ projects which help with this stuff: https://github.com/KhronosGroup/glslang https://github.com/KhronosGroup/glslang https://github.com/KhronosGroup/SPIRV-Cross https://github.com/KhronosGroup/SPIRV-Cross So I'm using Python to hook my custom build jobs into the C/C++ build system (via cmake), but I still need to invoke native command line tools (or DLLs) which wrap around those Khronos libraries. Currently this means building (at least) 3 executables for Windows, macOS and Linux, and "distribute" those precompiled exes with my python code. It looks like with this python+wasmer solution, I can instead compile the Khronos libraries into WASM modules, and the result runs "anywhere" where wasmer runs (e.g. also Raspberry Pi, BSDs etc...). That's really cool stuff :)

justanegg 7y ago

could be useful for TDD

JackC 7y ago

Portability might also bring along with it easier reproducible builds? Right now I believe if you use wheels, you basically have to trust that the distributed binary matches the source code. I saw a case where a package was taken over by a new maintainer who released wheels for an existing source release, and everyone basically shrugged and said, eh, this is probably fine, because there was no easy way to check. It sounds much easier to build an automated system that could check if wasmer-based packages are faithfully compiled from source, because there's only one compile target. Sandboxing also sounds valuable, as mentioned by a sibling. I'm thinking of projects like imagemagick that run all kinds of untrusted input through all kinds of processing. It would be nice if there was a simple default way to write data processing libraries the way djb would write them.[1] [1] https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf