Stream: ideas

Topic: Roc debugging GUI


view this post on Zulip Anton (Jul 12 2024 at 17:48):

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.

view this post on Zulip Anton (Jul 12 2024 at 17:48):

@Rasheed Starlet wanted to contribute to Roc and is willing to get started on this GUI project :heart:

view this post on Zulip Anton (Jul 12 2024 at 17:48):

My first thoughts were to try to make this in Roc with Luke's roc-htmx-playground.

view this post on Zulip Anton (Jul 12 2024 at 17:48):

I would love to hear your thoughts!

view this post on Zulip Brendan Hansknecht (Jul 12 2024 at 21:45):

That sounds nice, definitely make sure to start small and scope out single tools. Like hard to cover everything.

view this post on Zulip Brendan Hansknecht (Jul 12 2024 at 21:48):

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

view this post on Zulip Rasheed Starlet (Jul 12 2024 at 21:49):

Pretty cool yeah, I am excited about this

view this post on Zulip Rasheed Starlet (Jul 12 2024 at 21:51):

Also most all these you are mentioning just fly over my head but that makes it more exciting a task to take on

view this post on Zulip Kiryl Dziamura (Jul 12 2024 at 23:13):

From what I understand, we need the compiler to dump AST and IRs of different stages so we can just visualize them then?

view this post on Zulip Luke Boswell (Jul 12 2024 at 23:22):

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.

view this post on Zulip Brendan Hansknecht (Jul 12 2024 at 23:42):

I would not start with llvm ir as the target

view this post on Zulip Brendan Hansknecht (Jul 12 2024 at 23:43):

I would pick something higher level and simpler like one of our internal irs

view this post on Zulip Luke Boswell (Jul 12 2024 at 23:59):

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.

view this post on Zulip Luke Boswell (Jul 13 2024 at 08:11):

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.

view this post on Zulip Luke Boswell (Jul 13 2024 at 08:12):

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.

view this post on Zulip Luke Boswell (Jul 13 2024 at 08:18):

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.

view this post on Zulip Luke Boswell (Jul 13 2024 at 08:20):

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.

view this post on Zulip Kiryl Dziamura (Jul 13 2024 at 08:23):

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

view this post on Zulip Luke Boswell (Jul 13 2024 at 08:25):

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.

view this post on Zulip Anton (Jul 13 2024 at 10:51):

Cool ideas! "encourage the development of debugging/visualisation tools" is already happening :)

view this post on Zulip Anton (Jul 13 2024 at 10:57):

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.

view this post on Zulip Richard Feldman (Jul 13 2024 at 11:22):

works for me!

view this post on Zulip Richard Feldman (Jul 13 2024 at 11:23):

also check out https://terezka.github.io/line-charts/

view this post on Zulip Kiryl Dziamura (Jul 13 2024 at 11:24):

A decent elm-based ast explorer:

https://github.com/peterszerzo/elm-code-explorer

Demo: https://elm-code-explorer.surge.sh/

view this post on Zulip Luke Boswell (Aug 03 2024 at 00:42):

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.

view this post on Zulip Anton (Aug 03 2024 at 09:19):

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

view this post on Zulip Anton (Aug 03 2024 at 09:25):

@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

view this post on Zulip Rasheed Starlet (Aug 03 2024 at 09:43):

Yes sir, I will make it available then we take it from there please

view this post on Zulip Jasper Woudenberg (Aug 03 2024 at 12:33):

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.

view this post on Zulip Anton (Aug 03 2024 at 13:13):

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