[IronPython] Debugging hosted python scripts

Keith Rome rome at Wintellect.com
Wed Apr 6 17:38:52 CEST 2011

Just to follow up on this topic since I think it probably interests more than just myself - but so far the nested dispatcher frame system (WPF does not have Application.DoEvents()) seems to be working. To solve the problem of each breakpoint creating a new dispatcher frame which never terminates if you "Stop" this simple debugger, I am tracking the nesting of those frames internally and using a custom exception to unwind all of them when necessary. I think this will work well as long as the number of breakpoints / steps is kept to a reasonable level.

My main worry is that stepping through repeatedly will eventually reach some nesting limit or the managed stack will deplete. Where that exhaustion point may be found I am not exactly sure yet - but since these are typically short "scriptlets" used to drive things like calculated fields and validations, I believe it will be OK.

If there are any obvious flaws with this approach that I am failing to account for, then please point them out to me. I am hopeful this continues to work out as the other alternatives suggested seem to have a significantly higher implementation cost.

Keith Rome
Senior Consultant and Architect
Wintellect | 770.617.4016 | krome at wintellect.com<mailto:rome at wintellect.com>

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Schaber
Sent: Thursday, March 31, 2011 3:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Debugging hosted python scripts


If you are sure that you can control the potentially arising reentrancy problems (best by avoiding reentrancy completely, e. G. by disabling the parent windows), then Application.DoEvents inside the trace handler may help.


Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Keith Rome
Gesendet: Donnerstag, 31. März 2011 04:52
An: users at lists.ironpython.com
Betreff: [IronPython] Debugging hosted python scripts

I am hoping someone can point me in the right direction here. If there are no examples out there to review, then perhaps a hint or two about where I can look in the IronPython hosting API to achieve what I want...

We currently have a line of business application, written entirely in C#, that embeds the IronPython runtime. We offer a GUI script editing environment (using the SyntaxEditor control from Actipro Software, which works great for this). This script editor exists as just another dialog window in our application where the user can extend the business objects behind the application in various ways. The scripts are stored in a database, not in files on the local file system. We have great support for syntax highlighting, compiler error "squiggles", even Intelliprompt functionality. I am now building live debugging support into our script editor GUI, which is where I have run into some difficulty.

I have been going down the path of using ScriptEngine.SetTrace() and inspecting frames in the callback. This works fine if I am not doing anything interactive. For example, dumping some information to Debug.WriteLine(). However what I really need (I think?) is to be able to suspend the script execution during a trace callback. I don't see a clear way to do this though. The script runtime simply continues execution when my callback returns. I have done some work around running the debugged script on a background thread, and then blocking it during "breakpoint" callbacks - but these scripts are normally run within the UI thread because they interact with data structures that are often databound to UI controls, and running them from a background thread is becoming a minefield of cross-thread violations. I cannot simply run the script in the UI thread, because blocking in the trace callback would make the application unresponsive.

It seems like there should be some way to suspend/stop the script while in a trace callback (preserving all python stack and scope information), and then (optionally) later resume that execution frame by frame as the user "steps" through code. The only thing I see that might do what I want is possibly get an AST first and kick it through CallTracing() after hooking my trace callback? Is that what I should be doing?

I have spent some time digging through the IronPython Tools assemblies to see how this kind of thing was achieved when integrating with Visual Studio's debugger experience. I don't see it using SetTrace(), and so I assume this is taking an entirely different approach and not sure there is anything there that really provides what I need.

One last thing to mention is that our application is compiled against both WPF and Silverlight targets, so any solution needs to work in both environments.

Not looking for hand-holding here - just a nudge in the right direction. Even some examples of something along these lines as implemented in pure Python might be enough for me to figure out the rest.

Many thanks in advance,

Keith Rome
Senior Consultant and Architect
Wintellect | 770.617.4016 | krome at wintellect.com<mailto:rome at wintellect.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20110406/6977f43b/attachment.html>

More information about the Ironpython-users mailing list