Go 1.11 WebAssembly modules about life HOT 17 OPEN

The fix for this issue is to update to the latest version of wagon ... and then you'll hit go-interpreter/wagon#69

from life.

I have gotten this working in olin.

Relevant commits:

• Xe/olin@6937a85
• Xe/olin@0e7b58e
• Xe/olin@d4c95c6
• Xe/olin@eb35964

Example web assembly module and its output:

xena at luna in ~/go/src/github.com/Xe/olin/internal/abi/wasmgo on master
❯ go test -v
=== RUN   TestWasmGo
=== RUN   TestWasmGo/github.com/Xe/olin/internal/abi/wasmgo.testNothing
nothing
--- PASS: TestWasmGo (1.66s)
    --- PASS: TestWasmGo/github.com/Xe/olin/internal/abi/wasmgo.testNothing (1.66s)
PASS
ok      github.com/Xe/olin/internal/abi/wasmgo  1.696s

More info here.

from life.

@Xe - syscall/js is always included when building for the js/wasm platform. The current model in Go1.11 basically assumes that your Web Assembly runtime is the browser. And the only way to pass anything between the host and the WASM module is via the syscall/js callback APIs.

from life.

Hi guys,
I've managed to create a minimal, hardcoded exec.ImportResolver that can actually work with Go1.11 GOOS=js GOARCH=wasm executables.
You could use it for tinkering around or getting ideas about creating your own stuff.
It's definitely gonna change as i'm going to adapt it to event-sourcing and concurrency, but it's at least something.
What i have here is:
panic printing
Log() function
Call() function that allows you to asynchronously handle Callbacks, once VM is waiting for external event.
see usage example at: https://gitlab.com/albert_einstein/kwasm/tree/master/example

Any usage of other external communications (i.e. stdin,/stdout, http, sockets, files and etc) will cause your VM to mysteriously fail.

from life.

Instead of trying to support go's js/wasm target, how about wasi/wasm?

https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md

Relevant issue: golang/go#31105

from life.

Friends, we are still having this issue, even using the updated version of wagon (using @mastersingh24 's fork). Anyone able to use life at the moment?

from life.

Keeping this thread updated: it seems that including most of the standard library brings in syscall/js somehow. This is getting annoying fast. I am going to fork the Go compiler with a custom GOOS (olin or dagger, can't pick which) at https://github.com/Xe/go. I will need to do a lot of low-level runtime hacking in order to genericize the code for js/wasm to work on webassembly in general, while still offering the Javascript features for things that need JS.

from life.

Yay weird linker errors: Xe/go@37bc30e

from life.

from life.

@mastersingh24 could you please update us on the status of this issue?
I thought go-interpreter/wagon#69 was going to be closed in go-interpreter/wagon#70, but that hasn't been merged yet.

from life.

@mastersingh24 how much of browser runtime can be pulled into life?

from life.

Can we use something like Otto to replace the JS runtime?

from life.

I have looked into using Otto to replace the JS runtime. I don't feel comfortable doing it because I don't know how much deviation it has from how browser JS does it.

from life.

Any updates with Go 1.12?

from life.

Go 1.12 is actually no better here.
FWIW - people might want to checkout tinygo ... it creates much cleaner WASM and does not assume the browser as the host environment

from life.

I got parts of the runtime working in Olin. Here's the code: https://github.com/Xe/olin/tree/master/internal/abi/wasmgo

from life.

The wasi/wasm target post-dates this issue

from life.