Closed vdice closed 2 years ago
Q: Should we just call this Go
and have TinyGo
be a dependency/implementation detail (for building binaries compiled for wasm/wasi)? Or leave it all as TinyGo
?
@vdice I would stick to TinyGo. We don't want to set the expectation that users will get the Google Go compiler and ecosystem.
Still not sure how to get debug runs via wasmtime working. Printing the output in case it rings a bell for others:
$ wasmtime run tinygo.wasm -g
Error: failed to run main module `tinygo.wasm`
Caused by:
0: Debug information error
1: comp_dir
It seems TinyGo uses GDB for debugging but I'm not sure if there's good VS Code launch support for this? (I spent some time getting gdb set up on my local OS X system, which included some code signing hurdles.. so not sure how user-friendly it'd be)
Any thoughts @itowlson ?
No, sorry. Have you reached out to the TinyGo folks for their guidance on debugging Wasm builds?
Ok, this should be ready for review! Apologies, to fix up commit signature, I squashed commits.
The changes added since dusting this PR off are: adding Hippo support (following patterns in pre-existing yo wasm projects) and bumping TinyGo version. Running via wasmtime w/ the debug flag now works!
While this is in review, I'll look into testing the hippo scenario on an example project...
Update re: hippo testing. Can confirm that the flow of deploying the tinygo wasm module (based on the default source code on this branch) via the Hippo flow to a local hippo/bindle combo works. Have not tested the GH action for deploying to Hippo, as steps to deploy a publicly-accessible Hippo instance are TBD at this time.
Any chance a review might be possible in the near future? Looks like we have some great improvements that could be added once this initial PR is in place. See https://github.com/vdice/yo-wasm/pull/1. Thanks!
TODO
wasmtime run tinygo.wasm -g
currently fails)