For a while I've been thinking about a GUI app meant to make it easier to both debug and understand the compiler and the binaries it produces.
I want it to:
Flamegraphs have helped us a lot and I think there's a lot of untapped potential for other graphical/interactive tools.
@Rasheed Starlet wanted to contribute to Roc and is willing to get started on this GUI project :heart:
My first thoughts were to try to make this in Roc with Luke's roc-htmx-playground.
I would love to hear your thoughts!
That sounds nice, definitely make sure to start small and scope out single tools. Like hard to cover everything.
One thing that would be super awesome to profile is whenever roc ends up cloning data cause of refcounts not being unique. Super common performance issue. Probably could instrument roc binaries to record this somehow. But that is a full project unto its own before we even get to gui
Pretty cool yeah, I am excited about this
Also most all these you are mentioning just fly over my head but that makes it more exciting a task to take on
From what I understand, we need the compiler to dump AST and IRs of different stages so we can just visualize them then?
We could run the server, and have the server drive the roc cli. So everything is controlled/driven from the web UI. When user clicks "See llvm IR for app.roc"; the server could run roc build --emit-llvm-ir --no-link --o .cache/app-llvm-ir-123.ll app.roc or similar -- and then parse that output and present it to the user.
I would not start with llvm ir as the target
I would pick something higher level and simpler like one of our internal irs
Oh yeah, I was just thinking about how the flow might work. I'd definitely want to pick Josh's parsing stuff as the first target I think.
As a general workflow/UX -- you run e.g. roc build with a debugging environment variable set like ROC_PRINT_PARSE_AST or ROC_TRACE_PARSER, and then roc produces a structured output file e.g. 20240713_roc_parse_ast.txt or 20240713_roc_parser_trace.txt that you can then upload into the web UI and interact with.
Future extension the web ui includes a file explorer and can set up the debugging commands to drive the roc cli and grab the debugging output files.
So I guess the first thing we need to do is identify a suitable (useful?) candidate to start with and try it out.
One idea could be to print out the AST after parsing and desugaring, but before the rest of can?? I just happen to know from the work on ! desugaring that we could put something here that formats the roc_parse::Expr nodes.
Maybe not useful long term... but that could be something simple we could start with to test out the whole debugging concept end-to-end.
Yeah, having desugaring visualization would be very helpful for understanding advanced concepts. And for bug reports. That's actually might be a part of the future roc playground
Well at that point I linked, you could easily print out the before and after AST, and be able to compare for each top-level definition which would be super cool.
Cool ideas! "encourage the development of debugging/visualisation tools" is already happening :)
I did some additional research and htmx does not seem recommended for more complex interactive visualizations. Given that info, going with elm seems like the best option. I've heard it's very similar to Roc :p
I've also contributed to elm-visualization in the past and that should be able to handle complex interactive visualizations.
works for me!
also check out https://terezka.github.io/line-charts/
A decent elm-based ast explorer:
https://github.com/peterszerzo/elm-code-explorer
Demo: https://elm-code-explorer.surge.sh/
I've been thinking about this some more (as someone with very little compiler engineering experience).
We have this diagram with the compiler stages .
I'd love to be able to take a module/app/package/platform etc and be able to "see" the IR's at each stage.
My understanding is that these are distinct stages in the compiler pipeline, with the outputs from one feeding into the next.
and be able to "see" the IR's at each stage.
:100: that one has been on my mind for a long time as well
@Rasheed Starlet have you been able to make any progress with the elm+basic webserver example? No problem if not but I may look at it myself to unblock others from contributing
Yes sir, I will make it available then we take it from there please
I'd also been thinking about seeing the IR in different stages! Specifically, I was wondering whether it'd be possible and/or a good idea to be able to render the IR at different phases using Roc syntax as much as possible, so following along with the compiler as it processes code is as accessible as possible.
render the IR at different phases using Roc syntax
This is a little confusing to me, the IRs are what they are, although some parts may possibly be augmented; when we have for example IdenId 34 we could look that up and replace it with foo inside a custom debug view.
so following along with the compiler as it processes code is as accessible as possible.
A practical way to achieve this may be to enable side-by-side viewing of the different IRs in the debug viewer.
Last updated: Jun 16 2026 at 16:19 UTC