A couple years ago, I spent a little bit of my free time working on a debugger for Project Oberon 2013: https://crussell.keybase.pub/junk/oberon-debugger.png h

A couple years ago, I spent a little bit of my free time working on a debugger for Project Oberon 2013: https://crussell.keybase.pub/junk/oberon-debugger.png https://crussell.keybase.pub/junk/oberon-debugger.png When you enter debug mode, the sidebar to control the debugger appears, and the system shrinks to a picture-in-picture view, which can bee seen in the lower right, while the main viewport is overtaken by a readout/log of the executing machine instruction, optionally interleaved with the corresponding line from the original source (if you load that module's debugging symbols). I ended up scuttling this approach, because the graphical nature of the debugger made progress too slow. I started over with a GDB-inspired, CLI-based debugger shell called `rewrd`. It was my first proof-of-concept for what I've been calling "homologous UIs", which can run equally well when invoked directly in the terminal or when double-clicked to open (which causes it to run in the browser). https://crussell.keybase.pub/junk/rewrd.png https://crussell.keybase.pub/junk/rewrd.png I took the guts of `rewrd` and made a proof-of-concept for a homologous build system derived from Peter De Wachter's Python-based build scripts that can be used to generate a disk image suitable for use in the Oberon emulator. Here's a demo, running once in the browser, and then the same script running from the command-line: https://www.youtube.com/watch?v=TUpd70Mu0Ek https://www.youtube.com/watch?v=TUpd70Mu0Ek