Closed sebres closed 7 years ago
If someone would like to read a bit about abovementioned tclSE, here yet a short description why and how I wrote tclSE...
We want it to be open source. We want to be able to set breakpoints and step through a function. We'd like to be able to require some package or something that would allow us to connect to a running Tcl program and start debugging it. For instance, mod_rivet adds a Tcl interpreter to Apaache. We'd like to be able to get into the debugger to debug the interpreter when it fetches a certain page.
I've all that... (except "some package or something that would allow us to connect to a running Tcl program").
That is currently realized as tcl-command (debug on
or debug orient
) inside tcl-debugger, that should be called in yours servlet runner (or across rivet binding)...
In my sublime binding it calls a configured URL to my tcl-server (nginx-fcgi-module) to attach remote debugging, where following scenario is possible:
# attach/detach debugger URL-proc:
proc /debug/ {} {
# start / stop remote debugging:
if {[getargv on "off"]} {
debug configure -remote [getargv host]:[getargv port]
debug on
} else {
debug off
}
}
...
proc url-mapper {...} {
# check debugger was on ....
debug orient
# call url-mapped command:
/$uri/
}
My current problem is - I've no GUI (only debugger tcl-module resp. library). So it should be then integrated in something other as SublimeText (because of "we want it to be open source."). Any suggestions? Best if such IDE or editor are expandable with own modules... (but please no eclipse and co. ;) It should be script-able or at least C/C++/C#.
A GUI would be really nice but if it worked similarly to gdb I think we could live with it.
Understood. I'll see what I can do here after finishing of clock speed-up (#4).
If you don't mind me putting in my 2¢ worth, and not to discourage sebres, but it sounds like ramdebugger already has many of the described features. It can debug remotely, has a gui, and can act as a gdb front end to boot.
Maybe ramdebugger could be used as a starting point for a package that meets all requirements.
P.S. I'd really be interested to see a version of the sublime integration code that works with vanilla Tcl.
Maybe ramdebugger could be used
Possibly as GUI basis... Because as debugger it is IMHO not really suitable (at least it was so, as I touch it last time many years ago). Apart from the only older version support (I think it was 8.4 or even 8.3 only). But as idea for GUI... must take a look, Thanks.
P.S. I'd really be interested to see a version of the sublime integration code that works with vanilla Tcl.
Unfortunately I develop several years not with vanilla Tcl. Always missing time for dressing of the source code of my fork. It's still worse because my SublimeText (resp. this intergration) works not with vanilla python (I'm a really hacker ;)
Close as not interested
Is only "Tcl Pro package" accepted? I'm asking because...
I've own remote tcl-debugger and tcl-profiler library, that can be integrated into several editors (or IDEs). I use it together with SublimeText.... The library (with my sublimetext integration over python binding) enables me to debug, set breakpoints (also conditional), view and watch variables (also more complex types like dicts, lists, etc.), view the scope, traverse over compiled uplevels as well as show the call stack... Can do step into, trace over, run until return, etc.
Or even in code coverage mode it shows the lines not covered in test-cases.
But it is a library, so without integration into IDE resp. Editor it is just a large piece of code only... If desired I can try to integrate it in some open source editor... Or rewrite as GUI (would be more expensive, and I don't know that to write own IDE or editor would be good idea at all)...
About the profiler, example shows better as words:
That was profiler-output for the following code, that additionally filtered functions by total time < 10ms:
It is extremely configurable, so e. g. I can output calling arguments also for commands with time over N ms, for example to see slowly SQL statements on prepare or execute, etc.
About the code coverage mode: it is extremely integrated with my tclSE-mod (my own fork of tcl). I don't believe, that I could easy port it to original tcl.core, without modifying of it.