Crunch CRiSP File Editor 6 - Manual (Page 31)

Page 31
messages on <stdout>. This function is only really useful if you are using a GUI version of
CRiSP, since otherwise the printf() output will destroy your screen and make it difficult to
read the output.
The printf() function is useful for tracing a macro's execution, by sprinkling printf()
functions within your macro.
message() and error()
These primitives are similar to printf() but write their output to the status line of the current
window. This is fairly useful but because there is only one line for the status information
one message will overwrite any previous message and hence this is not a good thing for
fast output where you need to see a sequence of printed messages. The major difference
between the message() and error() primitive is that one displays in the normal foreground
color, and the other in the error color.
The other difference between message() and error() is the use of the pause_on_error()
macro. This primitive can be used to pause execution of a macro whenever an error
message is displayed, i.e. it affects the display of messages with the error() primitive but
not the message() primitive. If pause_on_error() is called with no arguments then it
toggles the pause state. When pausing is enabled messages displayed with the error()
function will have a '..' appended to them. To continue execution simple press any
character. This gives a primitive form of single-stepping.
status_message()
This is a macro, not a primitive, is a useful macro which operates like the message()
primitive but displays a message on the status bar message area. To use this macro,
simply call it but specify the first parameter as -1. The -1 indicates to use the status bar on
the current dialog box. If no status bar is present then this macro performs a message()
primitive for you.
Macro tracing
The debug() primitive is used to trace execution of a macro. When debug is enabled, CRiSP will log the
execution of all macros to a debug file. By default this is located in the /tmp directory and is called
/tmp/crisp.log. You can override the place where this file is created by specifying the environment variable
$CRISP_LOG and setting it to the name of a file where debug is written to. (If the /tmp directory does not
exist, e.g. for a Windows system, then the current directory is used by default).
There are a number of different ways to use the debug() primitive. You can either just execute the command
at the Command: prompt - useful for debugging an interactive session, e.g. where you select menu options
or hit toggle buttons etc. Alternatively you can embed the debug() primitive in your own macro to trace
specific pieces of code.
If debug() is called with no parameters then it simply toggles the debug mode. When debug is turned on, any
existing crisp.log file is deleted/truncated. The output of the debug command is a trace all macro primitives
executed together with some extra information. The top of a debug file contains various environment
information usually needed for technical support. The first part of the file is not really relevant to end-users
but is useful when forwarding the file to a support person.
The trace output which is logged is the execution of the underlying '.m' language. Remember that crunch
macros are compiled into an internal lisp-like format, and it is this which is the assembly language of the
editor. For example, here is a very small sample of debug output:
CRiSP DEBUG ENABLED: sunos41 CR_SUNOS41 v4.2.0d
Environment:
CRCONFIG=/home/fox/.Crisp
CRFILE=newfile
CRHELP=/home/fox/crisp/help
CRPATH=/home/fox/crisp/x11/../macros;.;/home/fox;/usr/local/crisp/macro
s
CRROOT=/home/fox/crisp
CRTERM=xcrisp-col
HOME=/home/fox
PATH=/home/fox/bin.sun4:.:/usr/etc:/home/fox/bin:/usr/ccs/bin:/etc:/usr
/sbin:/usr/local/bin:/bin:/usr/bin:/usr/etc:/sbin:/usr/ccs/bin:/usr/ucb