If you're interested in building your own debugger, take a look at http://devhawk.net/2009/07/08/MicrosoftScriptingDebugging.aspx. Microsoft.Scripting.Debugging.dll gives you APIs for non-blocking debugging by rewriting the expression tree. This doesn't require the interpreter.
~Jimmy On Mar 31, 2011, at 12:02 PM, Jeff Hardy <jdha...@gmail.com> wrote: > On Wed, Mar 30, 2011 at 8:52 PM, Keith Rome <r...@wintellect.com> wrote: >> 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. > > I think this is going to be your biggest issue with debugging - AFAIK > the Python engine is not designed to be suspendable; it relies on > .NET's normal thread suspension mechanism to handle that case. If the > scripts are on the UI thread, and the debugger is on the UI thread, > that 's going to be an issue. > > Now, if the engine were running in interpreted mode (i.e. it doesn't > try to convert Python to IL), it would probably be possible to suspend > it without suspending the thread, but I have no idea how much work > that would be. (Heck, it might already support it - Dino?) My hunch is > that it wouldn't be a huge amount of work, but I'm not familiar with > the interpreter loop at all. > > - Jeff > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
