#8229 is a draft implementation of QUERY_FORMATTED
. The current playground wasm version on main seems to not be compatible with the current roc-playground, and I have no experience debugging this. So I was not able to test my code in the roc-playground. I could use some hints on what to do.
Should there be any special data structure? I currently just have the formatted string directly as data in the JSON.
The current playground is compatible with the roc-playground...
We have an e2e integration test, zig build playground-test -- --verbose
is what I usually run
That uses a WASM VM in zig to exercise the WASM interface
So I would expect to see that integration test updated also with the new API QUERY_FORMATTED
etc.
Then I usually head over to roc-playground and update it over there - to use the new API
5 messages were moved here from #contributing > Worklog (Draft PRs and coordination) by Luke Boswell.
When I build a release for the roc-playground I also prefer -Doptimize=ReleaseSmall
to get a smaller WASM binary, though it's not necessary for testing locally or anything.
playground-test works fine, with my small additional test for the formatter. Put plugging it to roc-playground it crashes on the RESET command, which I think should not be affected by my changes.
I'll have a look
I pushed a commit that fixes the RESET issue
Thanks for the help Luke, I think #8229 is ready for review. roc-playground#13 adds a formatted tab including an apply button (with a log of help from Claude, my web development is very rusty).
I don't love the formatted code being in another tab
I kind of assumed it would operate on the editor view
Maybe with a keybinding or possibly (with a delay) after you finished typing.
I'm not sure though
Screenshot 2025-08-27 at 20.13.03.png
For debugging formatting, a separate tab could be valuable, but as a regular user, you want it to apply on the main editor. Perhaps it's time to split for these use cases?
Maybe we leave it as is for now... its primary usefulness is debugging rn
I've got plans to add more functionality like writing and running apps in future, but we're not quite there yet with the platforms.
We can also play around with it easily enough now we have the core functionality wired in and working well.
Oh, I just saw the apply to button...
and I've noticed we have a memory leak if we click around a bunch it crashes :rip:
To repro click the "Apply to" button like 20 times
Screenshot 2025-08-27 at 20.20.20.png
If anyone has ideas for how we could detect or prevent this kind of issue in our WASM e2e test I'd love to hear about it.
I've spent ages trying to setup a realistic integration test, but this kind of thing keeps sneaking through.
Where is the current integration test?
test/playground-integration
Hmm, I can't find a test folder in the repo
https://github.com/roc-lang/roc/blob/main/test/playground-integration/main.zig
Oh, it's in the roc repo
I also thought about adding just an apply button, but I thought for debugging it's good to see what is happening first.
The button currently is just available when you are on the formatting tab, but we could make it available all the time, and probably just do something when there are no AST errors. Also what's your favorite format code key binding?
I think a button in the editor side could be more visible
For keybinding... we probably don't need anything -- I was just thinking out loud earlier
A keybinding actually sounds good to me, we could use that as the sole trigger to avoid accumulating a bunch of buttons over time
I pushed some changes that make the format code button always work when there is no parse error (otherwise it would remove code). It's not next to the share link button. The formatted tab is still visible for debugging.
With only keybinding the problem is always discoverability, but I think I could add one.
We could add "format with Ctrl+Something" below the editor or a button or hover effect to show all shortcuts.
I chose Ctrl+Shift+F for now, it's hard to find something that is not used by the browser or codemirror. Feel free to change it or add some mac specific one. For now I think it's good to have the button and the binding.
I finally had time to look at the memory leak. I think it's the FixedBufferAllocator, that only actually frees part of the buffer, if the most recent allocation is freed. I could not find out so far which allocation is not freed in order, but I don't think we can guarantee the free order if the js-host is in control of part of it? I tried to use the wasm_allocator
instead but this also didn't work.
I would like to clean up some code there anyway, so maybe I figure something out, but it would be nice if anyone with more knowledge about wasm and allocators could have a look.
Last updated: Sep 08 2025 at 12:16 UTC