Given Luke was working on the playground, would it make sense to have an eye on getting also the playground in a state where perhaps sources can be easily shared for AoC?
Having a ready to run environment would likely reduce the friction and get more people to give it a spin and we could share solutions and somehow do a sort of review of interesting or recommended solutions?
(thinking out loud if e.g. somehow tests would work and be rendered in a tab in the sense of these ones fails and these ones succeed that could even serve as a sort of „do it yourself“ tutorial, where the tasks could be explained using predefined tests and a comment and if you get stuck you get linked to other solutions)
Hi Tobias,
The source code can currently be shared using the "share link" button, or did you have something else in mind?
Ah, didn’t see that before. Are there any plans to support tests / a sort of test view in it as well?
No specific plans yet but I think it makes sense
Supporting tests should be very doable. We have everything we need wired up already. We also have roc test working. If anyone wants to implement this I'm happy to help.
When I find time this week, I will have a look at it.
@Luke Boswell Since you offered to help:
roc-lang/roc-playground#15 and roc-lang/roc#8244 show my first drafts. Is this going in the right direction?
Anyone has ideas for a good UI? Should the test results just be another tab, or a special area?
I‘d say a tab with the tests and results would be a good first start. A long time stretch goal might be something in the direction of https://wallabyjs.com/docs/intro/standalone/ but that would be way more complex and likely something that should also then be provided by default not just in the playground (if at all something that’s being targeted by the „core“)
Given all examples in the playground now display warnings or errors, would it somehow make sense to display somewhere in the playground on which version (or release / nightly) the playground runs (and eventually a comment in the samples for which version they were intended?)
Good idea, I made https://github.com/roc-lang/roc-playground/issues/21 for this.
It should display the version in a console.log when it loads I think. Also we should be able to update the Playground anytime with a new build, I keep forgetting. Just build it frok main branch and copy paste the playground.wasm into the the other repo.
We should probably automate that I think.
Luke Boswell said:
We should probably automate that I think.
I'll take care of that.
playground.wasm will be published (starting tomorrow) once a day alongside the nightly releases: https://github.com/roc-lang/nightlies/releases
I broke the playground, looking at it now...
Good time to try out the claude chrome extension
It works well, for others who are interested , these are the relevant docs: https://code.claude.com/docs/en/chrome
Anton said:
I broke the playground, looking at it now...
I've fixed a bunch of things but still have some flaky memory issues that I'm working on...
Anything to check or support with?
Thanks, but I think I'm down to a final flaky memory issue. I will let you now when it is deployed and ready to test. This will likely be tomorrow because of the nightly playground.wasm build.
It's really easy to exceed the browser call stack size with Can.canonicalizeExpr. We've talked about fixing some deep recursion before. Did you happen to already have something planned for this @Richard Feldman?
yeah there are some parts of the code base that just need to be made non-recursive. usually Claude can do it, over the course of multiple attempts. :sweat_smile:
Hmm, with call stack truncation disabled for logging I see it's actually only 27 calls deep :thinking:
Will continue tomorrow...
The fix ended up being really simple :) zig build playground -Doptimize=ReleaseSmall
Then likely released tomorrow? Shall I check and see if I can update the samples?
Then likely released tomorrow?
Yes
Shall I check and see if I can update the samples?
I already updated them locally :)
@Luke Boswell can https://github.com/lukewilliamboswell/roc-platform-template-zig be built for use with wasm?
Zig template doesn't currently build for Wasm target, the host would need to be modified to support that. What would Stdout.line! mean in freestanding wasm? maybe we could add wasi as a target.
We have a wasm test platfrom https://github.com/roc-lang/roc/tree/main/test/wasm
Yeah, using the wasm test platform probably makes the most sense
Yeah, so we're now basically just missing some sort of input / output (or output for now, assuming hardcoded inputs)? So a sort of console / similar to the repl?
Uhu, console for output sounds good
Naive question:
CleanShot 2026-01-09 at 08.50.08.png
Is the type for string supposed to be error? If not how to be investigate where the issue is?
If you create a snapshot, and then run that you should be able to reproduce the bug.
I think zig build snapshot -- path/to/snapshot.md is how you run one individually
The snapshots are located here https://github.com/roc-lang/roc/tree/main/test/snapshots to see the format you can use (there's a few different types)
If you can repro and make a GH issue that would be super helpful, even if you aren't sure about a fix and PR
fwiw, i put this code as a test case in the type checking suite and it infers correctly. maybe this is an issue with how the playground is hooked up?
I'll take a look
Fixed in PR#9003
Last updated: Jun 16 2026 at 16:19 UTC