Description
The command language for App::MoarVM::Debug is currently ad-hoc, counter-intuitive, requires lots of typing to do relatively simple tasks, doesn't handle errors like typos sensibly, doesn't allow more than one command per line, and many more issues.
Here is the "help" output from the current iteration of the language, if you can call it that:
This Problem Solving issue has the goal of writing a kind of command language that makes debugging more pleasant.
Here are properties for a command language to be used in a CLI debugger (but also available in TUI and GUI debuggers for power users?):
- Vaguely familiar to users of existing debuggers
- Ability to do repetitive things without much setup work
- Ability to refer to results of earlier commands without much extra typing
- Friendly to abbreviating commands and aliases
- Easy to implement tab completion for
- Allow bits and pieces of raku code in the commands where it makes sense
- Commands should generally also Do The Right Thing when asynchronous operations are involved (await, react/supply blocks, ...)
There are some things that make stealing liberally from, for example GDB, difficult:
- We can't just identify objects by their memory location like GDB, as they move around.
- the moarvm remote protocol allows you to get a "handle" to an object, which is a sequentially increasing integer
- a handle keeps an object alive so the garbage collector doesn't take it away while you could still refer to it
- this means that currently the user has to manually clean up handles
- Objects in Raku are of course more complex than structs. They have a meta-object protocol that controls aspects like what methods are available, or what types they match.
- most operations you might want to do to an object will involve invoking code in the debuggee. the moar remote protocol supports this, but it's currently very tedious to do from the existing CLI.
- Apart from the MOP, there's also the Associative and Positional roles that will very often be relevant, and there we should go through AT-POS / AT-KEY and friends.
You can not attach the moar remote to a process that hasn't been started with the debug port activated. We also now have an nqp::syscall(...) that can tell you if the debugger is on, so in theory, built-in classes can do some extra work when we have the debugger attached.
It already has a performance impact anyway, so if we do something like "for every Promise created, also store a traceback" it may be an acceptable price if we can benefit from the information in the debugger.