Debugging

I'd love to see GUI-driven multiprocess debugging for Muq.

What we actually have at the moment is... primitive. As in stone age. Here are some hints for coping.

• Writing code in small increments and testing it frequently helps. MUF is designed for interactive code execution, which makes this easier.
• You can print out stuff using the comma operator. I use this a lot.
• Normally, when the interpreter discovers an error, it prints out a diagnostic and returns you to the prompt. If you can do debugOn, then errors instead throw you into the debugger, from which you can examine the evaluationa and call stacks. Use debugOff to disable the debugger again. (You can instead tweak the @$s.breakEnable flag directly if you prefer.)
• Printout generated via the comma operator has to go through the message streams and skt.t socket logic and internal timeslicing logic, which may prevent timely printout. One way around this is to enable logging by invoking Muq ./muq --logfile=xyzzy.log and then use log, instead of the regular comma operator -- this will do an immediate C write directly to the logfile, bypassing all the message stream, timeslice and socket interface logic. You can either examine the logfile later, or else watch it in realtime using tail -f xyzzy.log from the Unix commandline.
• As a last resort, you can invoke Muq by something like ./muq --logfile=xyzzy.log --log-bytecodes after which it will log every bytecode executed to xyzzy.log. Keep in mind that Muq can easily execute a million bytecodes per second normally, so this can fill disk fast -- not to mention slow down the interpreter a lot! You can switch bytecode logging on and off in softcode by doing (respectively) t --> .muq.logBytecodes and nil --> .muq.logBytecodes.

Want to write a better debugger? Go for it!

Go to the first, previous, next, last section, table of contents.