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.
debugOn, then errors instead throw you into the debugger, from which you can examine the evaluationa and call stacks. Use
debugOffto disable the debugger again. (You can instead tweak the @$s.breakEnable flag directly if you prefer.)
skt.tsocket logic and internal timeslicing logic, which may prevent timely printout. One way around this is to enable logging by invoking Muq
./muq --logfile=xyzzy.logand 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.logfrom the Unix commandline.
./muq --logfile=xyzzy.log --log-bytecodesafter 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.logBytecodesand
nil --> .muq.logBytecodes.
Want to write a better debugger? Go for it!
Go to the first, previous, next, last section, table of contents.