Vugu question

[bradleypeabody]

@ethanfrey

I started looking at your code, and would love to reuse some of it (like https://github.com/vugu/vjson) and ideally contribute back in some way if I can. Is there a better way to reach out to you than responding to this issue?

Sounds great to me. I see all the github issues for github.com/vugu/vugu and related projects so feel free to ask questions there. I'm on the Gophers Slack. And brad at vugu dot org also works.

[ethanfrey]

Thank you for responding @bradleypeabody, I don't have many quesitons right now, as we are currently working on the low-level bindings between wasm and our cosmwasm-vm runtime (custom ways to pass binary data different than JS land and some callbacks). But once we got a "ping-pong" example working, I would love to check with you on some libraries you used and gotchas of what can or cannot be done (I know a good chunk of the standard lib is not supported, but probably doesn't matter for app development). Also, if there are any common libraries that are blockers, let me know... we might want the same and can help port them.

The one general issue I have now is getting the same code to run under Go and TinyGo. We use a few different packages under one root. To get it to compile in TinyGo, we have to remove the go.mod file and refer to the other packages as import "../std". This of course doesn't work when trying to run go test. Where I need a go.mod file and absolute imports. It would be great to run native Go unit tests on the code and then compile to wasm. I assume you got this working somehow, but since much of the TinyGo bindings come out of codegen, it was a bit hard to follow exactly how you configured it all.

Any ideas on proper module handling?

@KamiD is also working heavily on getting TinyGo wasm to work with cosmwasm

[bradleypeabody]

@ethanfrey Okay cool and that all makes sense.

On the imports, part of the reason I ended up making the devutil package and wrapping the build process is due to this same issue. The current implementation either uses docker's -v option to map folders to make a GOPATH when TinyGo is called, or if docker is not used, to build locally it copies everything into a temp dir - making the GOPATH on the fly for each build. However per this tinygo-org/tinygo#941 there is now module support in TinyGo, which I plan on looking at soon and if that works well with Vugu, it should make things a lot simpler.

As regards testing, while I'm sure it can be improved (and I hope to put something together meant for outside just Vugu's own maintenance), what I ended up doing was making a docker container that acts as a webserver and runs headless Chrome and then the _test.go stuff drives it - building each test, creating a headless browser and then browsing to it and verifying that the pieces on the page look correct. The guts of it are here: https://github.com/vugu/vugu/tree/master/wasm-test-suite

[KamiD]

@ethanfrey Okay cool and that all makes sense.

On the imports, part of the reason I ended up making the devutil package and wrapping the build process is due to this same issue. The current implementation either uses docker's -v option to map folders to make a GOPATH when TinyGo is called, or if docker is not used, to build locally it copies everything into a temp dir - making the GOPATH on the fly for each build. However per this tinygo-org/tinygo#941 there is now module support in TinyGo, which I plan on looking at soon and if that works well with Vugu, it should make things a lot simpler.

good advise, I will try it in my environment

[webmaster128]

Closing this here because the Go standard library for CosmWasm smart contracts is developed in a different repository (still private). Feel free to continue the conversation over there.