Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly from the Ground Up

wasmgroundup.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: WebAssembly from the Ground Up

#41

Post by flohofwoe »

fooker wrote: post #35
flohofwoe wrote: post #33

Earlier quoted context omitted.

> I want to run something that execs a command line tool, both in the browser. Doable yet? If it's not possible from Javascript, it's also not possible from WASM, it's as easy as that. If your command line tool can be compiled to WASM and works within the restrictions of the browser sandbox, it's trivial. But if you want to start a native command line tool from within the browser, it's pretty much impossible (and for…

I meant: I want a program compiled to wasm capable of running in the sandbox calling another command line tool also compiled to wasm. Right now the call is through an exec system call, but that can be changed.

In VSCode extensions this is trivial, this is how you create the 'executable':

https://github.com/floooh/vscode-kcide/blob/main/src/wasi.ts

...and this is how you run it:

https://github.com/floooh/vscode-kcide/blob/2dfc621aade4a2be...

The asmx.wasm file is a vanilla POSIX cmdline tool which loads and saves files via fopen/fread/frwrite/fclose, and the tool has been compiled with the WASI SDK: https://github.com/WebAssembly/wasi-sdk

The resulting VSCode extension (https://marketplace.visualstudio.com/items?itemName=floooh.v...) then even runs in the VSCode browser version (https://vscode.dev/)

But AFAIK there's currently no easy way to get a similar easy to use WASI wrapper in browsers (it's definitely possible though because the VSCode browser version does it - VSCode basically has a filesystem abstraction which works for native filesystems as well as virtualized web filesystems like github repositories).

Re: WebAssembly from the Ground Up

#42

Post by moron4hire »

peterangular wrote: post #7
haykuro wrote: post #5

Earlier quoted context omitted.

You don't want to use PHP (a server-sided language) to solve a client-side problem.

PHP devs: "hold my beer."

'Member when a major crypto exchange, which had original been a market place for Magic the Gathering cards (so it was not a mountain named Gox), was hacked and everyone's crypto stolen because the owner had implemented his own SSH server in PHP?

Re: WebAssembly from the Ground Up

#43

Post by AndruLuvisi »

marianoguerra wrote: post #23
pdubroy wrote: post #21

Earlier quoted context omitted.

Edit: changed slightly to provide a more useful answer. No, it doesn't — not this version of the book at least. We only cover WebAssembly 1.0. That said, as my co-author says below, there's really not much to tail calls. Once you've worked through the book, you'd be able to grok tail calls pretty quickly. As an aside — 2.0 was announced just a few weeks after we launched the book, and 3.0 a few months ago. And with 3…

Co-author here. if you are interested in tail calls you just need to understand the call instruction which we cover in the book and then replace it with either: - return_call , the tail-call version of call - return_call_indirect , the tail-call version of call_indirect More info here: https://github.com/WebAssembly/tail-call/blob/main/proposals...

Thank you both for the replies.

Re: WebAssembly from the Ground Up

#44

Post by titzer »

fooker wrote: post #22

What's the state of wasm for porting multi-process code? I want to run something that execs a command line tool, both in the browser. Doable yet?

We have a research project called WALI (WebAssembly Linux Interface) here: https://github.com/arjunr2/WALI

It's experimental, but there is a toolchain that can compile most C/Posix programs and run them on the prototype implemented in the WAMR engine. And yes, exec works! In fact, we are able to run bash and Lua and memcached, among other things.

Re: WebAssembly from the Ground Up

#45

Post by fooker »

titzer wrote: post #44
fooker wrote: post #22

What's the state of wasm for porting multi-process code? I want to run something that execs a command line tool, both in the browser. Doable yet?

We have a research project called WALI (WebAssembly Linux Interface) here: https://github.com/arjunr2/WALI It's experimental, but there is a toolchain that can compile most C/Posix programs and run them on the prototype implemented in the WAMR engine. And yes, exec works! In fact, we are able to run bash and Lua and memcached, among other things.

Neat! Let me take a look.

Re: WebAssembly from the Ground Up

#46

Post by achierius »

ethin wrote: post #37

Wasm is such a cool technology. The spec though for me leaves a lot to be desired. Oh, the first few chapters are fine, but when you get to the binary and text formats that's when it all breaks down for me. For whatever reason, Wasm loves OCaml. This wouldn't really be a bad thing if they didn't come up with their own custom language to denote syntactic elements of both formats instead of using EBNF or similar. I dis…

Like with many things, the reference interpreter is in ocaml because one sufficiently motivated insider wanted it to be.

Re: WebAssembly from the Ground Up

#48

Post by kowfm »

I'm not gonna lie, this Little course book thing is incredibly fantastic. Well written, well structured code. It really helped me to connect the spec to the binary format in my brain.

Also because it uses Ohm.js to write the Parser/Lexer from a BNF definition, almost 100% of the focus is on WebAssembly and how to compile it, instead of flexing and parsing.

Go buy it.

Re: WebAssembly from the Ground Up

#49

Post by potsandpans »

achierius wrote: post #46
ethin wrote: post #37

Wasm is such a cool technology. The spec though for me leaves a lot to be desired. Oh, the first few chapters are fine, but when you get to the binary and text formats that's when it all breaks down for me. For whatever reason, Wasm loves OCaml. This wouldn't really be a bad thing if they didn't come up with their own custom language to denote syntactic elements of both formats instead of using EBNF or similar. I dis…

Like with many things, the reference interpreter is in ocaml because one sufficiently motivated insider wanted it to be.

I think ocaml (ml-y languages in general perhaps) lend themselves to interpreters quite nicely. Similarly with Rust.

Maybe there's an intersection between PL nerdery and interpreter authoring, and I fall into that bucket and am biased.

Post reply on HN