project wrap up:

if the screen captures i posted here didn't make much sense to you, believe it or not, that was actually the whole point of my project. and by that i mean that the goal was to build something tailor made for me to better understand an algorithm i'm working on. and without knowledge of that algorithm, the data just doesn't make a whole lot of sense.

i wanted to figure out what it would take to create a custom visualization and how that process could be streamlined. because i think custom algorithm visualizations are a huge thing we're missing out on, not only for debugging, but also for internal developer documentation. some things are just much easier to understand with an interactive visual.

but while it's certainly nice to have visualizations, there's a question of whether they make "economic sense" to create. for example, if you spend 6 hours to build a visualization, which then allows you to fix a bug in 1 hour, and without the visualization it would have taken you 5 hours to fix the issue, then you saved -2 hours. in other words, you lost time. though there is a potential argument to be made that the tool may pay more dividends in the future, when you or some other dev comes back to the algorithm. then again, since the tool is tied closely to the implementation, there are also additional future costs for maintenance to be considered.

in practice, it took me around 10 hours to build the tool (excluding project setup time), and i spent around 7.5 hours using the tool to debug issues. if we exclude potential future time savings or costs (and points for "i just like doing this sort of thing"), then the tool would have had to save me at least 10 hours of debugging time. while it did certainly accelerate debugging significantly, i think that the savings are well below 10 hours, maybe around 2-3 hours. if we then also factor project setup time back in, i think we may have some anecdotal evidence for why "building custom visualizations" is just not a thing we do, unless we really need it.

my goal is now to bring down the time it takes to create such visualizations to under 2 hours and ideally closer to 30 minutes.

day 5: added interactive navigation.
been using the tool (alongside graphviz) and have identified and fixed 5 bugs so far that would have been pretty hard to diagnose otherwise. &dataflowdebugger

day 4: now showing the diff between outputs when processing the work list forwards vs backwards. if my implementation was correct, this view would be empty. but then i also wouldn't need a dataflow debugger 🌚
added tabs to explore the history of dataflow nodes in each of the logs. &dataflowdebugger

success: i just found the first bug in the dataflow analysis :weewah:
in this step, r3 becomes ? in vals_out, but for some reason it remains unmodified in restored_vals_out.
right now, i'm just manually changing which log file to view and which dataflow node to display in the lua script. would be nice if i didn't have to restart the program all the time, but it's already kinda usable, so that's nice. &dataflowdebugger

day 2:
created a structured log of "things happening in the dataflow analysis".
then experimented with a generic viewer for that log, where specific log messages could be replaced with a custom ui builder.
ended up not really liking that. so tomorrow, i'll pre-process the log to build a more useful data structure. and then just build custom uis for different debugging use cases. &dataflowdebugger

day 1: just some project setup.

plan is to do some structured logging, then figure out how to visualize that in a way that's useful.
decided to use lua both for the log format and the ui implementation, hoping that that will give me a fast iteration cycle.
didn't have much time today, and most of that went into creating lua bindings for my ui library.