After some more fiddling, basic robot watching is pretty rock solid. I fixed some memory leaks and crashes, and I’ve moved on to breakpoints. And herein lies the conumdrum, as I’m trying to figure out the use cases here and how everything should work together. As it stands, breakpoints are not very useful, because you can only place them when debugging, and then the only option is to place a breakpoint at the currently executing line. The robot editor that shows up when debugging currently has no mechanism for scrolling around the robot’s code, so you’re limited to the view of about 10 lines of code that surround the current line. For breakpoints to be useful to a developer, I feel like either you should be able to place them either in editing mode (when you’re actually modifying the robot), which will lead to all kinds of terrible headaches trying to keep that information in sync with the robot’s contents, or else the debugging interface needs to have more interactivity. I’m leaning towards the latter option, but still open for discussion.
The other major consideration right now is what kind of lifetime breakpoints should have. Should they persist between debugging/testing sessions? Across boards? What should happen to the interface when the player switches boards and the debugged robot no longer exists? These are questions for which I don’t have good answers at the moment.