Debugging

Debugging in TinTin is like hitting yourself in the face over, and over, and over. It hurts. And makes you feel dumb. These are some debugging tricks I’ve learned along the way that help make it a little less painful.

Verbose Configuration

TinTin’s verbosity can be increased for debugging purposes with the command:

#config {VERBOSE} {ON};

However, this will not apply to command files loaded with the read command. These will need to be explicitly loaded with the command:

#line verbose #read <filename>

This will also increase the verbosity of the #DEBUG command, however that output always goes to the console and cannot be sent to a logfile.

Console Debugging

The included #DEBUG features provides some helpful data when needed. By default, debugging information is written the console and is enabled with:

#DEBUG {LIST} {ON};

To display all the debugging lists, use:

#DEBUG

To enable all the debugging lists, use:

#DEBUG {ALL} {ON};

The verbosity of the debugging information can be increased by enabling verbose config:

#CONFIG {VERBOSE} {ON};

Unfortunately, output generated by #CONFIG {VERBOSE} {ON} cannot be sent to log files.

Debug Logging

You can log debugging output to a separate file:

#log APPEND debug.log;
#debug {ALL} {LOG};

Note: #DEBUG’s verbosity is increased by #CONFIG {VERBOSE} {ON} and will be sent to the log, but is also sent to the console. No way around this at present.

Debugging Command Files

If a command file is not behaving as expected - a useful debugging technique is to write the class out to a temporary file and review it. This very often exposes extremely common syntax errors - chunks of commands may be missing, identifying a position where to look for the source of the bug.

Extraneous Input

Sometimes you’ll get the following message in your console when loading command files into the startup session:

#NO SESSION ACTIVE. USE: #session {name} {host} {port} TO START ONE.

Essentially, this identifies that some command file loaded some configuration that malfunctioned and attempted to write some data to the session, rather than run as a command. Unfortunately the information is not displayed or logged, so identifying what it was and what caused it can be tricky.

The following alias will capture all the extraneous input and write it to the console in bright colors:

#alias {%*} {
    #showme {<fab>MSG:INPUT       %0};
}

The downside to this technique is that it captures ALL input, that is not not a tintin command - all user defined commands, such as aliases and functions, will be captured and displayed rather than executed. This breaks most of my framework, so it’s only useful on demand, and only after I’ve identified the immediate location of the malfunctioning code.

ANSI Bleeding

If colors are “bleeding”, there is an included configuration setting that may resolve the issue:

#config {COLOUR PATCH} {ON};