3 ms·
Well -- Tcl happens to be difficult to debug w/ tools because it's so dynamic -- but that said, let me tell you what I run into, and how I resolve. I compile C
by bch 14y ago
Well -- Tcl happens to be difficult to debug w/ tools because it's so dynamic -- but that said, let me tell you what I run into, and how I resolve.
I compile C (original C, or bindings to libraries) and enable all warnings, use Tcl C APIs to do C memory management (allows electric-fence like behaviour where I've got optional guards on allocated mem), and I'm pretty familiar w/ the Tcl C API. When something is horribly wrong, I'll get a core dump and the full stack trace will indicate the path from Tcl, on up into my bindings, and further into the library in question. From there, typically with a small amount of inspection and testing it's easy to isolate the problem area and fix. This way I've solve application (Tcl script) code, my library bindings, and errors in 3rd party (open source) libs -- I've got no doubt that there's room for improvement in my process -- either by tools or techniques. That said, I feel productive and happy with what I've got going on now. When I want performance in Tcl, I punt and push it to C. When I want dynamic control or nice interfaces, I punt and drive it with Tcl.
- scott_s 14y agoI think that's a reasonable process, and probably the best you can do with current tools. But even though it's reasonable given your software stack, it's still much more involved than just using gdb on C code. (Note that I'm not arguing that it's never worthwhile to use a higher level language to drive C code, just that I think Katz has a valid point regarding debugging.)
- niggler 14y ago" I'm pretty familiar w/ the Tcl C API" The Tcl C API is fairly simple, and that's by design. There's a very slim chance you loused something up in the interface. Dealing with the interface from Erlang, or with many other higher level languages, is like pulling teeth.