I've been participating in the wheel reinvention j...
# devlog-together
k
I've been participating in the wheel reinvention jam over at Handmade network. My entry plays with tools for debug by print, along 2 dimensions: ā€¢ (pictured) hiding debug prints by default in the editor, so that we can save them in version control and share debugging tricks with collaborators without it getting overwhelming and always in our collective faces. ā€¢ (vaporware) rendering debug logs in extensible graphical ways. The tool shouldn't need to know how to render every single type possible; instead it just reads a special representation within a codebase to learn how to render the types in that domain.
s
Do you have a video of the second bullet point (rendering debug logs). I've always wanted to experiment with something like that.
k
I'm working on that šŸ™‚ The jam is still ongoing.
s
Super cool I'm guessing you didn't provide a message in your assert?? šŸ™‚
I would guess that your environment would need to let the programmer determine how to visualize the logs
I'd also be really curious to see aggregations, within runs of a program and also across runs of a program. With some nice data visualization to show things like "here's the length of this array over time", or "here's the average number of keys in this object over time".
k
Yeah, the editor lives in a different directory, but when I pass in a file from the current codebase it loads it in as part of its source code. Super unhygienic but gets the prototype done. I have some ideas in the direction you indicate, but only one day remaining šŸ™‚ We'll see how it goes. Whoa, I keep forgetting I can pass in messages to Lua's
assert
! Thanks for the reminder. I shouldn't need to add debug prints to get more information on a failed assertion šŸ™‚
j
It would be fun to show the values floating by the code (think Lighttable) when you click on one of the game screens šŸ™‚
k
Heh, I have to keep resisting the temptation to insert debug prints into my renderer. It's all right there in the logs! šŸ˜„
@Jack Rusher I never considered that! After a few minutes of thinking about it, how do you like this approach instead? Trying to follow Edward Tufte, poorly. I could show the velocity numbers inside the image as well, once I've had enough sleep to position them at the head of the "arrow". Basically my thinking is that any integration between the panes is more code for the tool to manage. Offloading the visualization responsibilities to each codebase will hopefully keep the tool simpler over time. I still don't have a clear articulation though of what I need a tool for and what responsibilities to offload. First cut: anything involving a single point in time is the client codebase's responsibility, while the tool is responsible for aggregation. Even there, though, I could imagine managing some window of history in the codebase and having each frame show a looping animation of the nearby trajectory. And it would be a lot less code in the codebase than in the tool.
s
what I need a tool for and what responsibilities to offload
One thing I would use it for is exploring new large code bases. A lot of time spent there is just figuring out things like "If I call this function, what other functions does it call and in what situations." Or, how are these entities related, like "does a Foo always have a Bar". As this code executes, how many Bars does this Foo have on average. I see it as a way to provide active documentation. Even a custom debugger of sorts, where the user maintains debugging code making it easy to spin up a debugging session. Kind of like how react has a custom react debugger, it would be cool to be able to have that but specific to your app.
k
I'm going to stop monopolizing the channel, but here's the final demo. I've also published the repo: https://codeberg.org/akkartik/spokecone.love Things to notice in the demo: ā€¢ The client program logs section headers following a specific convention. ā€¢ The editor recognizes the convention to associate log lines with nested sections. Sections are collapsed by default, but you can click on them to expand. ā€¢ Clicking on a log line takes you to the line of code that generated it.