Intent to work on TclPro debugger
Opened this issue · 24 comments
Created a private repository with initial release of upgraded debugger, and invited resuna, bovine and lehenbauer as collaborators. The repository contains the code as well as a Linux-specific starkit and starpack (in the bin directory) to make it easier to play with.
Bumping notification of completed TclPro debugger upgrade. Feedback requested. Please let me know if there is a problem with the invites to the private GitHub repository containing the code.
How would I launch it on OS X?
I don't have a Mac handy, but after compiling the tclparser extension, one should be able simply to source the main.tcl file. The name of the extension file in the tclparser package pkgIndex.tcl file will have to be changed I suppose.
On it. Got to update some stuff on my Mac before I can build anything. Thanks Apple.
While I'm fighting with Sierra, where are you on the second part of this?
Get the source-level debugger working again with Tcl 8.6 and accepted into the Tcl core
The debugger is functionally complete and working on Linux with Tcl 8.6. No changes to the core are required. I updated the OS-specific parts of the code so everything should work on Mac and Windows as well, but my ability to test on those platforms is limited. I wanted feedback on your priorities before chasing OS-specific goals.
Can you add me to the private repo so that I can see the work so far? Karl just added me to the flightaware organization.
Peter, is it OK to add snoe925 to the debugger repo?
Yeppers!
Done.
Bumping request for feedback on debugger.
I am have a bug the socket reading with Tcl Events only reads the first message and/or vwait is broken. I have to make a test case from the production code in order to reproduce,
Can you add me to the private repo? Shannon did a demo of the debugger and I'd like to take a look at it.
Peter, is it OK to add pm-conej to the debugger repo?
Can I get an update of where you are in terms of validating whether the debugger code satisfies the conditions of the bounty?
Karl, Peter and I discussed the status. We all agree that the conditions of the bounty are met to our really limited ability to test it. We just want some more time to use the new debugger. I have used it quite a bit. We just would like to get a few more people using it (either via Github or internally).
It is our understanding that the debugger does not change the Tcl core correct? I am inferring that from my testing. Can you confirm that? This is the only specific in the claim to verify.
Here are some details just so you have an understanding of some problems we have tried to track down.
We have not been able to reproduce a "production" problem we have with socket event code. My attempt to make a test program created a completely different behavior. I think you answered that in the issue I opened. We have a different production event loop that stops processing after one message with a breakpoint. That is the file events stop completely. Instead of message, break, message, break, ... we get message, then nothing. This has been hard to boil down out of the full production codebase. If I can reproduce this, I will create an issue.
We would really like to have this working with Apache Rivet scripts. But that is out of scope. This might be as trivial as allowing the extension .rvt files to work. If I can get Rivet working, I would have many more people to test.
It is our understanding that the debugger does not change the Tcl core correct?
That's correct. All changes are within the Tcldebugger codebase itself.
We would really like to have this working with Apache Rivet scripts.
Please note on page 36 of the TclPro users's guide, you'll find directions on how to specify multiple filename-matching patterns which let you control which files are and are not instrumented. Including *.rvt files should be straightforward.
My attempt to make a test program created a completely different behavior.
I took a second look at the test program you posted. You can work around the issue by providing an overloaded version of the "update" command which doesn't process events forever; e.g.:
proc update {} {
foreach ch [chan names sock*] {
if {![catch {chan event $ch readable} callback]} {
{*}$callback
}
}
}
This proc checks each socket once and runs its callback script if one exists, then returns. When I include this in the code you provided, the program runs and terminates as expected. If you can tolerate this kind of simulation in a test environment, it might help you track down your issue.
I would be pleased to start a consulting relationship with you to help you find ways to use the debugger most effectively in your development and test environments.
@blacksqr please contact me so that we can pay you for this bounty. You can email me at my corporate address or contact me via Twitter as SNoe925.
Thanks, I will do so. What's your corporate email address?
Hi, will the upgraded TclPro Debugger be available to the general public?
I just pushed a new repo flightaware/TclProDebug