Stacksmith icon indicating copy to clipboard operation
Stacksmith copied to clipboard

Add a graphical debugger for Windows

Open uliwitness opened this issue 5 years ago • 3 comments

We already have ForgeDebugger for macOS, which is a GUI that uses sockets to communicate with an executing script.

Forge's Windows version currently contains a remote debugger that is just a stub. It should be changed to somehow open a connection to a debugger and send the very same bytes across as Leonie and ForgeDebugger use right now.

Note that the design should be done in a way so we can easily hide the nerdier stuff later. While it's helpful during development of Stacksmith itself to view the bytecode and the full stack, and step instruction-wise, the debugger should be built to also allow stepping line-wise and only showing source code, because that's the default mode in which end-users will eventually use it.

Also note that the user may, at any time, quit the script or the debugger. Either side should recover. (This is currently being worked on for ForgeDebugger on the Leonie side, where it will in the future be able to launch the debugger as needed).

uliwitness avatar Mar 30 '19 12:03 uliwitness

General workings of the debugger:

  1. When Leonie hits a breakpoint, it connects to the debugger using a socket on the specified host and port
  2. It will send the contents of relevant scripts to the debugger
  3. It will send the current stack to the debugger
  4. It will then tell the debugger it is done and wait for the debugger to tell it what to do
  5. When the user clicks a button in the debugger window, the debugger will send back commands to Leonie, like "step by one instruction" or "exit to top" or "continue running".

This means, while stopped in the debugger, just like C programs, Stacksmith will be blocked and beachball (on macOS).

uliwitness avatar Mar 30 '19 12:03 uliwitness

Note: On macOS, it made most sense to implement the debugger as a separate process. You also get the bonus of theoretically being able to run the debugger on a different computer or even platform than the script itself. It also means that the debugger GUI can be used with a script being run using the Forge command line tool.

In HyperCard's original UI, the debugger was just another window in HyperCard itself. If you can achieve this behaviour, e.g. by using threads or so, feel free to do that instead.

The main reason this wasn't done on macOS was that sharing the menu bar between two threads would have been nontrivial on macOS (all UI has to happen on the main thread), and we wanted proper edit menus etc. to be available to the users.

uliwitness avatar Mar 30 '19 12:03 uliwitness

If you're doing this as your first issue, the assumption is that you're familiar with inter-application communication (using sockets or whatever is appropriate on Windows), and generally writing a Windows GUI application. This ticket is mostly UI, and a bit of raw network communication.

It would also be helpful if you were good at reading macOS code, as there is no specification for the network protocol, though that could be written if needed.

uliwitness avatar Mar 30 '19 12:03 uliwitness