jimtcl
jimtcl copied to clipboard
msteveb
debugscript command
Initial implementation of a minimal interactive script debugger. Commands are familiar to gdb users. Allows developer to examine or change variables or perform other actions at a Jim command line while single-stepping through Tcl script.
Code style generally follows that of Jim.
Hi Steve B!
As a 20-year prolific Tcl user, I'd like to get more familiar with Jim's codebase and its improvement process, in order to write some significant extension libs.
Feedback welcome.
Thanks. Looks interesting. I actually have something similar myself out-of-tree, it has never become "production ready". I'll push mine to a branch so you and others can have a look, and I'll also look through yours to see if we can come up with something we are willing to support into the future. Will be a couple of weeks before I get to this though.
Take a look here: https://github.com/msteveb/jimtcl/commits/xtrace
But as I say, I won't be able to get to this for a while.
Will do, thanks.
Meantime, I've begun to port Ffidl to Jim. That should soon give Jim access to a number of GUI toolkits and many other libraries. As someone pointed out in the wiki, I bet a large number of Tcl binary extensions would have never been binary if that library had been adopted early enough. Jim now has a chance to correct that oversight and take the other path.
Does anyone know if someone has already ported Ffidl or something similar to Jim? What were the technical problems? And the same question for calling GUI toolkits like Tk, GTK, and wxWidgets from Jim? Am I headed into a trap here?
It would be nice to have an FFI module as part of Jim's codebase.
Does anyone know if someone has already ported Ffidl or something similar to Jim?
There was a PR for libffi bindings, but it stalled: https://github.com/msteveb/jimtcl/pull/55.
And the same question for calling GUI toolkits like Tk, GTK, and wxWidgets from Jim?
Jim has experimental bindings for SDL in the tree. I haven't seen any bindings for actual GUI toolkits. GTK should be doable. You can't use wxWidgets from C. Rather than bind Tk's directly through its rather large C API, it's would be better to take a more generic approach and let Jim create Tcl 8.x interpreters and evaluate code in them (or vice versa).
Take a look here: https://github.com/msteveb/jimtcl/commits/xtrace
Thanks Steve. At first glance your debugger looks more elaborate than what I've done. I basically added a core command that acts as a breakpoint (with syntactic allowance for more future functionality). That sets a flag causing the interp to single-step through the remainder of that stack frame. Before each script command, the interp prints the command on stdout and gives the developer an interactive jimsh-like prompt. There he can do any Jim action including viewing and modifying variables, until he decides to step again, or continue full speed. That primitive approach gives an extreme ratio of functionality to overhead, both in interp source and runtime resource. It's had only minimal testing so far. It might take some massaging to be production-ready, e.g. to factor out the added bloat in the eval function, but it seems like a valuable core feature. It's one I've often wished for in mainline tclsh. I was very happy to see how readily Jim was able to do it.
dbohdan - thanks for the tips re: gui's.
Also I had a good look at PR #55. Seems like that approach would need considerable wrapping by script, even more than ffidl, and then it would be prohibitively slow to run. Still could be a helpful thing to have around, at least as a benchmark for my ffidl effort. Did anyone besides the author actually see it work at all?
Did anyone besides the author actually see it work at all?
I think I built it at the time. Does it not build for you? I'd use Ffidl in Tcl 8.6 as the primary benchmark.
The heart of my debugger is the xtrace command. The idea is to push all the decision making out to a script/command rather than build it in.
I mentioned my concerns about the libffi port in #55. It seemed very cumbersome (and possibly slow). If ffidl gives a better interface, that would be good.
I just got my source port of Ffidl to [load] into Jimsh!
:-)
It's still rough. It hasn't even passed a smoke test yet, beyond just building and loading up without error. But that took a considerable amount of Ffidl source adaptation, and a few small tweaks to Jim to expose functions etc.
My source so far is at https://github.com/cb750mark/ffidl/tree/0.80-jim and https://github.com/cb750mark/jimtcl/tree/0.79-ffidl-support Feel free to take a look, and/or move the conversation about it over to there. Just don't expect much of it to work correctly yet. I'm expecting a number of bugs from known risky areas.
i've just created a new Github "organization" as a place to hold conversations about Jim and Ffidl code. msteveb and dbohdan, you are both invited.
You two should have received your email invites to @TheMarkitecht/TclTeam just now. I'm now moving the repos into that org so that team can use them.
I started a discussion for us about the Ffidl port, at https://github.com/orgs/TheMarkitecht/teams/tclteam/discussions/1
Feel free to start any other new discussions at @TheMarkitecht/TclTeam as well.
In real-world use, I found my debugger seems to consistently skip the customary substitution pass at the start of evaluating each command typed. For example set libs($root) looks for an array element named $root instead of c as it should, because $root == c. Skipping that subst seems like a bug in my new code that will need to be fixed, most likely by inserting the missing API call. I'm not yet sure how that happened, since I patterned its REPL loop after the one in jimsh.
Sorry for the force-push just now. I had to do that while scrubbing my personal contact info from the commits. All current and future commits in all repos should be authored by my brand "TheMarkitecht".
If you cloned that repo, please clone again to avoid trouble. Thanks.
I'm going to close out this ticket. I think the xtrace command is sufficient for now