Go 1.11 WebAssembly modules

[mastersingh24]

Have you guys done any testing with modules created via Go 1.11? I assume it might likely be an issue with wagon?

Simple test.go:

package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hello World")
}

Using Go 1.11rc1:
GOOS=js GOARCH=wasm go build -o test.wasm test.go
and then
./life -entry main /Users/gsingh/Projects/golang/src/webassembly/test.wasm
with result

panic: unexpected EOF

goroutine 1 [running]:
main.main()
	/Users/gsingh/tmp/life/main.go:81 +0x72c

Maybe related to go-interpreter/wagon#69 ?

[mastersingh24]

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

[julioholon]

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?

[Xe]

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.

[Xe]

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.

[Xe]

Yay weird linker errors: Xe/go@37bc30e

can we add issues to the go repo for dagger ?

…

On Thu, 6 Sep 2018 at 15:49 Christine Dodrill ***@***.***> wrote: Yay weird linker errors: ***@***.*** <Xe/go@37bc30e> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATuCwoqeNKb98vxksB2xELKgUBhXz3DZks5uYSfigaJpZM4WEJOv> .

[mastersingh24]

@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.

[dobegor]

@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.

[Immortalin]

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

[Immortalin]

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

[Xe]

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.

[gladkikhartem]

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.

[Immortalin]

Any updates with Go 1.12?