proof-of-concept playground by bakkot · Pull Request #1597 · bytecodealliance/wasm-tools

bakkot · 2024-06-08T22:02:28Z

You can try print playground and the parse playground.

It's extremely basic and not very pretty, but it does work. I've only implemented wasm-tools parse so far because I want to give maintainers a chance to weigh in on the approach before doing more work. I'm happy to implement another for wasm-tools print as well, and maybe a third for dump+objdump+metadata show if you think that's worth doing. EDIT: and the wasm-tools print one.

I'm using cargo-component and jco, mostly because I thought that would be more fun than wasm-bindgen. Unfortunately I did need to target wasm32-wasi since I get an unreachable when targeting wasm32-unknown-unknown. And there does not seem to be a simple way to provide my own shims of the preview-1 functions when using cargo component; it unconditionally translates them to preview-2. But that's fine because jco has built in support for shimming preview-2. This adds about 50Kb of (unminimized) JavaScript, but whatever.

This includes a new workflow which a) ensures the playground builds in every PR and b) uploads the built artifact to gh-pages on every commit to main. I think you'll need to manually enable GitHub pages and set the source to "GitHub Actions" for this to actually do anything, but it's possible the included actions will take care of that.

I've commented out the main CI for the sake of not taking up a bunch of resources while iterating on this. I'll revert that before marking this as ready, of course.

alexcrichton

Thanks so much for this it looks great to me! I've got a few minor comments but I'm happy to land the overall structure and iterate in-tree as necessary.

I think I just frobbed the button to say github pages comes from actions, so I think that's ready to go?

alexcrichton · 2024-06-09T02:24:45Z

+[package]
+name = "component"
+edition = "2021"
+


Might be worth adding a publish = false here, and as part of the main workspace thisi can also use edition.workspace = true along with [lints] workspace = true too

Hm, actually, adding [lints] workspace = true prevents building because the lints don't like the code that cargo component generates. I've removed it for the moment; happy to take other suggestions.

Ah ok no worries, I can try to work on that once this lands.

alexcrichton · 2024-06-09T02:25:51Z

+  run:
+    shell: bash
+
+jobs:


Mind adding this to the main.yml file as well? The final "gate everything here" job could gate on the build job here and the deploy job could continue to depend on main. Otherwise though this looks great!

I learned about actions/{configure-pages,upload-pages-artifact,deploy-pages} here, I didn't know what those were before!

I'm not totally sure what you're asking here - are you suggesting getting rid of playground.yml and moving both of these new jobs into main.yml? I was aiming to have this run after commits land on main, which that file doesn't (appear to) do. But I guess if everything goes through the merge queue it ends up being roughly equivalent?

Hm good point yeah. We try to keep CI automation on the main branch itself pretty light and instead defer most of the work to the merge queue when possible. For example release binaries are built on the merge queue and then when the commit gets pushed to main the release binaries are uploaded for tagged commits.

My initial thinking is that something similar could be done here where the build job executes as part of main.yml on the merge queue and then the deploy job runs like publish.yml on pushes to main.

That being said when I write it all down it feels like that may be overly complicated. Do you know if it would be difficult to split it up like that? If so the downside of having playground.yml is that I'll need to update the CI settings to gate on this workflow in addition to the current gated workflows for the merge queue, but that's not the end of the world as this won't really change much over time.

Do you know if it would be difficult to split it up like that?

Just looked and the answer appears to be that yes, it's (a little) difficult. Artifacts are meant to be used within a single workflow. To make this work, you'd need to download and re-upload them in the publish job - there doesn't appear to be a (supported) way to publish an artifact from a different run.

You're already downloading artifacts from a previous run in publish.yml, but in trying it on my own fork I couldn't immediately get that to work - it's failing to find the run_id, despite that working in this project, and I don't have enough experience or interest in GitHub actions to debug it further.

bakkot · 2024-06-09T03:12:09Z

I'll go ahead and make the print page as well, then, and add a root index.html which I guess just redirects to the github project (unless you want to have a separate page listing the tools, but that seems a bit redundant). Then I think think it should be fit to land.

bakkot · 2024-06-09T17:50:37Z

Alright, added the printer as well. This is good to go from my end once the CI thread above is resolved. Which I'm happy to do but if you'd find it easier to make the changes yourself rather than explaining them that's also fine.

alexcrichton · 2024-06-10T14:51:09Z

+impl wasmprinter::Print for StringWriter {
+    fn write_str(&mut self, s: &str) -> std::io::Result<()> {
+        self.0.push_str(s);
+        Ok(())
+    }
+}


If you're interested in getting particularly fancy here it might be neat to hook into the start_* methods and emit <span> entries to have highlighted colos on the web too. That's fine to do later though as a follow-up as well.

Ooh, fun, I'll play around with that.

Done, following roughly the terminal colors used for the same parts.

alexcrichton · 2024-06-10T14:52:42Z

@@ -0,0 +1,85 @@
+<!doctype html>


For discoverability and sharing code do you think that it'd be reasonable to have only one landing page for the various tools and and sort of "tabs" between them to explore different functionality?

Can do. Are you thinking of one HTML page, or multiple pages that link to each other? Having multiple makes it easier to bookmark a specific tool, though I guess I could use the #fragment and some JS to make that possible with a single page.

I was thinking one page, but I'm not wed to the idea either. It mostly just seemed like there was some duplication between the styles/js/etc. Having links to each page from the other I think is also fine.

I added links from each page to the other. There's not really much duplicated that isn't already shared - they use the same core stylesheet and worker, it's just the actual relevant UI which differs.

alexcrichton · 2024-06-10T14:52:59Z

+[package]
+name = "component"
+edition = "2021"
+


Ah ok no worries, I can try to work on that once this lands.

alexcrichton

All looks reasonable to me, thanks again for providing the foundation for all this!

alexcrichton · 2024-06-10T23:47:32Z

Looks like the deploy worked, yay! I've got some minor follow-ups but when you feel it's ready I think it'd be great to link this from the README in the root of the repo as well

This commit is an attempt to migrate from `JamesIves/github-pages-deploy-action`, a third party action, to what appears to be a more official action under the `github.com/actions` organization. This was first pioneered in bytecodealliance/wasm-tools#1597 and it looked like it would work well over here too.

proof-of-concept playground

36e8db4

alexcrichton reviewed Jun 9, 2024

View reviewed changes

make playground part of the workspace

28dc466

bakkot added 3 commits June 8, 2024 20:13

do not use the workspace lints

30cd189

print

c8a4164

add redirect

ca0f0a1

alexcrichton reviewed Jun 10, 2024

View reviewed changes

bakkot added 5 commits June 10, 2024 14:35

color printing

e623d0a

checkbox for printing skeletons

401cb1b

cross-link, also make parse errors red

631f0b1

allow CI to run

7a5d295

I guess we cannot avoid committing this generated file

e03b44e

alexcrichton approved these changes Jun 10, 2024

View reviewed changes

alexcrichton added this pull request to the merge queue Jun 10, 2024

Merged via the queue into bytecodealliance:main with commit 92861f1 Jun 10, 2024

bakkot deleted the playground branch June 11, 2024 01:42

alexcrichton mentioned this pull request Jun 13, 2024

Try migrating to a "more official" github pages provider bytecodealliance/wasmtime#8800

Merged

Conversation

bakkot commented Jun 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bakkot commented Jun 9, 2024

Uh oh!

bakkot commented Jun 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Jun 10, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

bakkot commented Jun 8, 2024 •

edited

Loading

bakkot commented Jun 9, 2024 •

edited

Loading