[IronPython] Debugging hosted python scripts

Markus Schaber m.schaber at 3s-software.com
Thu Mar 31 00:48:42 PDT 2011


Hi,

 

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.

 

Grüße,

Markus

 

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

 

 

 

Keith Rome

Senior Consultant and Architect

MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS

Wintellect | 770.617.4016 | krome at wintellect.com <mailto:rome at wintellect.com> 

www.wintellect.com <http://www.wintellect.com/> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20110331/db64d6fd/attachment-0001.htm>


More information about the Users mailing list