Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intent to work on TclPro debugger #25

Open
blacksqr opened this issue Jan 16, 2017 · 24 comments
Open

Intent to work on TclPro debugger #25

blacksqr opened this issue Jan 16, 2017 · 24 comments

Comments

@blacksqr
Copy link

No description provided.

@blacksqr
Copy link
Author

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.

@blacksqr
Copy link
Author

blacksqr commented Mar 2, 2017

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.

@resuna
Copy link
Member

resuna commented Mar 2, 2017

How would I launch it on OS X?

@blacksqr
Copy link
Author

blacksqr commented Mar 2, 2017

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.

@resuna
Copy link
Member

resuna commented Mar 2, 2017

On it. Got to update some stuff on my Mac before I can build anything. Thanks Apple.

@resuna
Copy link
Member

resuna commented Mar 3, 2017

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

@blacksqr
Copy link
Author

blacksqr commented Mar 3, 2017

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.

@snoe925
Copy link

snoe925 commented Mar 3, 2017

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.

@blacksqr
Copy link
Author

blacksqr commented Mar 3, 2017

Peter, is it OK to add snoe925 to the debugger repo?

@resuna
Copy link
Member

resuna commented Mar 3, 2017

Yeppers!

@blacksqr
Copy link
Author

blacksqr commented Mar 3, 2017

Done.

@blacksqr
Copy link
Author

Bumping request for feedback on debugger.

@snoe925
Copy link

snoe925 commented Mar 20, 2017

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,

@pm-conej
Copy link

pm-conej commented Apr 4, 2017

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.

@blacksqr
Copy link
Author

blacksqr commented Apr 4, 2017

Peter, is it OK to add pm-conej to the debugger repo?

@resuna
Copy link
Member

resuna commented Apr 4, 2017 via email

@blacksqr
Copy link
Author

Can I get an update of where you are in terms of validating whether the debugger code satisfies the conditions of the bounty?

@snoe925
Copy link

snoe925 commented Apr 19, 2017

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.

@blacksqr
Copy link
Author

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.

@snoe925
Copy link

snoe925 commented May 2, 2017

@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.

@blacksqr
Copy link
Author

blacksqr commented May 2, 2017

Thanks, I will do so. What's your corporate email address?

@jorge-leon
Copy link

Hi, will the upgraded TclPro Debugger be available to the general public?

@pm-conej
Copy link

pm-conej commented Jul 3, 2017 via email

@snoe925
Copy link

snoe925 commented Jul 3, 2017

I just pushed a new repo flightaware/TclProDebug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants