Speed Tables has been carefully coded to generate C code that will compile cleanly, specifically with the GNU C Compiler, gcc 3.3 and gcc 4.0. Right now we run the compiler with error warning levels set very high and any warnings causing the speed tables library generation process to fail. This has helped us to catch many bugs during development and we've done the work to make sure all the routines are being used with correct argument types, etc.
Should you come across a compiler warning that stops the speed table generation process, you may want to look at speed tables' software and try to fix it.
If you want to see what compiler commands speed tables is executing, you can turn on compiler debugging.
set ::ctable::showCompilerCommands 1
Do this after your "package require speedtable" and before you declare your C extensions.
How we invoke the compiler can be found in gentable.tcl. We currently only support FreeBSD and Mac OS X, and a general solution will likely involve producing a GNU configure.in script and running autoconf, configure, etc. We'd love some help on this.
Most syntax errors in a C extension definition will be caught by speed tables and reported. When sourcing a speed table definition, you may get the message
(run ::ctable::get_error_info to see speed table's internal errorInfo)
This means that speed tables has caught some kind of unexpected internal error within itself. It has suppressed its own error traceback because it isn't valuable to anyone who isn't looking to dig into the error.
If you're not running tclsh interactively, you'll probably want to do so and then source in whatever is causing the error. After you get the above error message, you can execute...
::speedtable::get_error_info
...to see what the commotion is about.
A known bug in early December of 2006 is that if you define two fields in a table with the exact same name, you'll get a semi-strange traceback rather than a nice message telling you what you did. That's kind of characteristic of what I'm talking about.
Speed Tables shouldn't ever dump core but, if it does, you may want to try to figure it out. If you want to be able to use your C debugger on the speed tables code, turn on compiler debugging after you've loaded the speedtable package and before you load your extension.
set ::ctable::genCompilerDebug 1
Ideally you'll also build Tcl with debugging enabled. When building Tcl, add --enable-symbols to your configure options to get a Tcl library that you can run your debugger over.
Run gdb on tclsh and when you hit your segmentation violation or whatever, if all is well, gdb should be on the line where the trap occurred and let you poke around all of the C variables and structures and the like.
If gdb can't find any symbols, try moving up through some stack frames (see gdb's documentation for more information). If in the speed tables routines you aren't getting file name and line number information and access to your local variables and the like, you probably haven't managed to build it with debugging enabled. Turn on showing compiler commands and make sure you see -g being specified when the commands are being run.
If you don't see the compiler being run, try deleting the contents of your build directory. That'll trigger a regeneration and recompile of the speed table code for your extension.
There are a number of variables that can be set to change the behavior of Speed Tables. Many of these are useful for debugging. They are globally configured in the file config.tcl in the Speed Tables installation directory. You can also change them after loading SpeedTables, for example:
set ::ctable::genCompilerDebug 1
This disables the trapping of errors into ::ctable::get_error_info
This builds and links the generated speed table with debug libraries.
this in addition includes the memory debug libraries, if available, and enables the memory method.
Displays the compile commands.
Includes pgtcl support, normally 1 on FreeBSD, 0 on OSX.
Includes support for shared memory tables, including the master and reader commands for the create method, and the share method. Normally 1.
Include support for the _dirty pseudo-field. Normally 1.
Changing these variables should trigger a rebuild of the table. If it doesn't, that's a bug, do let us know.