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
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | kr...@wintellect.com<mailto:r...@wintellect.com>
www.wintellect.com<http://www.wintellect.com/>

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@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

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-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] Im Auftrag von Keith Rome
Gesendet: Donnerstag, 31. März 2011 04:52
An: users@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 | kr...@wintellect.com<mailto:r...@wintellect.com>
www.wintellect.com<http://www.wintellect.com/>

_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to