Re: [IronPython] How to place static class in script name space
To pre-load various module imports into our execution environment, I am doing
something like this at application startup (we have a number of modules that we
pre-load):
dynamic builtin = Engine.GetBuiltinModule();
dynamic import = builtin.__import__;
var DefaultImports = new string[] { "math", "clr", "sys", "string",
"cmath", "re" /*etc...*/ };
CachedModules = new Dictionary();
foreach (var mod in DefaultImports)
CachedModules.Add(mod, import(mod));
And then later on, just before executing a new script each time, I create a new
empty scope using Engine.CreateScope() and then I inject all of the cached
modules that were previously imported:
foreach (var mod in CachedModules)
LocalScope.SetVariable(mod.Key, mod.Value);
PreCompiled.Execute(LocalScope);
This allows each script invocation to reside in its own somewhat isolated
sandbox, while only importing those commonly used modules once.
You should be able to do something similar to the above, using the builtin
__import__() function. From looking over the IronPython source, it looks like
you should be able to call it like this (I haven't tested it in this way, but I
believe it should work):
dynamic AppModule = import("App", null, null, "AppFrame");
This should effectively mimic exactly what happens when you run the statement
"from AppFrame import App".
Many Bothan spies have died in bringing you this information.
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 Dino Viehland
Sent: Monday, June 13, 2011 1:22 PM
To: Discussion of IronPython
Subject: Re: [IronPython] How to place static class in script name space
We specifically allow from staticclass import * because we treat a static class
as if it were like a module. So you could simply run that line of code in the
scope on behalf of the user. Otherwise you'll need to re-create getting the
dynamic members and then setting them in the scope. Then you can use
PythonOps.GetAttrNames to get the defined names and finally
PythonOps.GetBoundAttr to get the actual members which you'll then set in the
scope.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Tom Unger
Sent: Monday, June 13, 2011 10:16 AM
To: 'users@lists.ironpython.com'
Subject: [IronPython] How to place static class in script name space
I am using IronPython for scripting an application. To make writing scripts
easier I want to place several objects in the script name space so they can be
easily used. I got stuck with how to place a reference to a static object,
"App", in the name space. This is probably a simple operation and just don't
know what it is.
1. Python import works:
from AppFrame import App
gives the script access to the static fields and methods on App.
But I want to eliminate the need for each script to do that import by setting
up the scope with:
scriptScope.SetVariable("App", App);
This does not compile because App is a static class, not an object.
How does my hosing application place a reference to the static class in the
script's scope such that it can be used as if it was imported?
Thanks
Tom
Seattle
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools for Visual Studio now accepting contributions
Please forgive my ignorance on this matter (I don't currently use any of the integrated VS functionality - have been working with embedding the runtime in an existing application), but what is the difference between "IronPython Tools" and "Python Tools for Visual Studio"? I was under the impression this was the same thing? Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | kr...@wintellect.com www.wintellect.com -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, May 11, 2011 4:26 PM To: Discussion of IronPython Subject: Re: [IronPython] Python Tools for Visual Studio now accepting contributions Jeff wrote: > This is excellent news. > > I think the plan should now be to deprecate the IronPython tools and > remove them from IronPython 3.0. They'll stay in future 2.7 releases, > but perhaps they should be disabled by default to make installing PTVS easier? That sounds like a good idea to me and it should be a pretty simple change. ___ 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
Re: [IronPython] IronPython for Silverlight 5?
The docs for System.Type claims that you cannot subclass from it in Silverlight. Is this being relaxed in v5? Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | kr...@wintellect.com www.wintellect.com On Apr 14, 2011, at 6:49 PM, "Tomas Matousek" wrote: > Couldn't you just subclass Type? It's methods are virtual and can be > overridden. I don't think you need to emit a real RuntimeType. > > Tomas > > -Original Message- > From: users-boun...@lists.ironpython.com > [mailto:users-boun...@lists.ironpython.com] On Behalf Of Keith Rome > Sent: Thursday, April 14, 2011 3:30 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython for Silverlight 5? > > After looking into what it takes to implement ICustomTypeProvider it seems > like it would be a nightmare for dynamic object support. You have to produce > actual custom Type instances, presumably using TypeBuilder and emitting IL > opcodes to handle the getter/setter accessors. If the databinding system > caches those dynamically-created Types then it could cause problems because > what happens when we add a new member via expando after binding once (or > remove one that previously existed)? But if they don't cache the Type objects > then it seems like the overhead might be absurd from constructing these > things again and again (and you can't use TypeBuilder without first creating > a dynamic assembly and module). > > I really hope they alter course and go with ICustomTypeDescriptor instead (or > even IDynamicMetaObjectProvider if that is feasible). I really don't > understand how they expect the current system to work for "dynamic > properties" because there is nothing dynamic at all about a System.Type > instance. The best it can hope to be is a snapshot of the metadata from a > dynamic object as of some point in time. > > > Keith Rome > Senior Consultant and Architect > MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 > | kr...@wintellect.com www.wintellect.com > > > -Original Message- > From: users-boun...@lists.ironpython.com > [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Thursday, April 14, 2011 4:11 PM > To: Discussion of IronPython > Cc: Chad Brockman > Subject: Re: [IronPython] IronPython for Silverlight 5? > > On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland wrote: >> Jeff wrote: >>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman >>> wrote: >>>> I see Silverlight 5 now has something besides simple reflection >>>> (ICustomTypeProvider) - >>>> >>>> http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data >>>> >>>> Will we see an update to Iron*/DLR to support binding to dynamic >>>> objects any time soon? This will open fantastic options for using >>>> IronPython in Silverlight. >>> >>> If someone provides a patch, yes. >>> >>> We actually need someone with an interest in Silverlight to keep an >>> eye on it and make sure that we don't break SL support and new >>> features like this. We don't have anyone in that role right now. >> >> If anyone's interested on working on this it'd probably mean adding an >> implementation of this onto OldInstance as well as adding it onto our >> new-style instances whose classes are created by NewTypeMaker. Adding >> the interface is probably pretty easy, making it return useful things may be >> a little more difficult. >> >> I'm a little surprised they didn't go with the already existing >> ICustomTypeDescriptor. > > Are you really surprised? :) > > It is still in Beta. Maybe there's a slight chance their minds could be > changed? I'm guessing they don't have the rest of System.ComponentModel > either, so they didn't want to add just one interface. > > - 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 > > > > > ___ > 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
Re: [IronPython] IronPython for Silverlight 5?
After looking into what it takes to implement ICustomTypeProvider it seems like it would be a nightmare for dynamic object support. You have to produce actual custom Type instances, presumably using TypeBuilder and emitting IL opcodes to handle the getter/setter accessors. If the databinding system caches those dynamically-created Types then it could cause problems because what happens when we add a new member via expando after binding once (or remove one that previously existed)? But if they don't cache the Type objects then it seems like the overhead might be absurd from constructing these things again and again (and you can't use TypeBuilder without first creating a dynamic assembly and module). I really hope they alter course and go with ICustomTypeDescriptor instead (or even IDynamicMetaObjectProvider if that is feasible). I really don't understand how they expect the current system to work for "dynamic properties" because there is nothing dynamic at all about a System.Type instance. The best it can hope to be is a snapshot of the metadata from a dynamic object as of some point in time. Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | kr...@wintellect.com www.wintellect.com -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Thursday, April 14, 2011 4:11 PM To: Discussion of IronPython Cc: Chad Brockman Subject: Re: [IronPython] IronPython for Silverlight 5? On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland wrote: > Jeff wrote: >> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman >> wrote: >> > I see Silverlight 5 now has something besides simple reflection >> > (ICustomTypeProvider) - >> > >> > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data >> > >> > Will we see an update to Iron*/DLR to support binding to dynamic >> > objects any time soon? This will open fantastic options for using >> > IronPython in Silverlight. >> >> If someone provides a patch, yes. >> >> We actually need someone with an interest in Silverlight to keep an >> eye on it and make sure that we don't break SL support and new >> features like this. We don't have anyone in that role right now. > > If anyone's interested on working on this it'd probably mean adding an > implementation of this onto OldInstance as well as adding it onto our > new-style instances whose classes are created by NewTypeMaker. Adding > the interface is probably pretty easy, making it return useful things may be > a little more difficult. > > I'm a little surprised they didn't go with the already existing > ICustomTypeDescriptor. Are you really surprised? :) It is still in Beta. Maybe there's a slight chance their minds could be changed? I'm guessing they don't have the rest of System.ComponentModel either, so they didn't want to add just one interface. - 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
Re: [IronPython] IronPython for Silverlight 5?
The logical thing would seem to be adding ICustomTypeProvider to ExpandoObject or DynamicObject, but these are both in System.Core so more or less out of our hands. Or has the Silverlight team extended those classes to support this new interface (I haven't pulled down the SL5 bits to check)? And it begs the question of why did the Silverlight team feel we need yet another (incompatible) custom type info implementation? Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | kr...@wintellect.com www.wintellect.com -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Thursday, April 14, 2011 10:32 AM To: Discussion of IronPython Cc: Chad Brockman Subject: Re: [IronPython] IronPython for Silverlight 5? On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman wrote: > I see Silverlight 5 now has something besides simple reflection > (ICustomTypeProvider) - > > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data > > Will we see an update to Iron*/DLR to support binding to dynamic > objects any time soon? This will open fantastic options for using > IronPython in Silverlight. If someone provides a patch, yes. We actually need someone with an interest in Silverlight to keep an eye on it and make sure that we don't break SL support and new features like this. We don't have anyone in that role right now. - 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
Re: [IronPython] BeginInvoke from C# to IronPython
Not sure if you are aware, but calling a delegate like that via BeginInvoke()
is really just the same thing as using ThreadPool.QueueUserWorkItem(). You
might save yourself a lot of hassle by omitting the Class1 and event handler
funny business, and just pass your callback directly to QUWI:
import clr
clr.AddReference("System")
from System import Threading
def testCallback(foo):
# print might not be safe here due to threading... but Debug.WriteLine() is
thread-safe
from System import Diagnostics
Diagnostics.Debug.WriteLine(foo)
# test using sync call
testCallback("sync")
# test using async call
cb = Threading.WaitCallback(testCallback)
Threading.ThreadPool.QueueUserWorkItem(cb, "async")
Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | kr...@wintellect.com
www.wintellect.com
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Matthew Green
Sent: Sunday, April 10, 2011 12:47 AM
To: users@lists.ironpython.com
Subject: [IronPython] BeginInvoke from C# to IronPython
Hi everyone,
I came across a simple C# httplistener
(http://www.paraesthesia.com/archive/2008/07/16/simplest-embedded-web-server-ever-with-httplistener.aspx).
I decided to have a quick play with it and leave the listener in C# and make
the client calls and callback in IronPython. After multiple attempts I failed
to get C#'s BeginInvoke call to callback to IronPython. That catch shows a "The
object must be a runtime Reflection object." error.
I implemented this short example which failed to callback to the Python
function and hits the catch after trying to BeginInvoke -
--
C#:
using System;
using System.Globalization;
using System.Net;
using System.Threading;
namespace test
{
public class Class1
{
public event EventHandler IncomingRequest = null;
public void testInvoke()
{
SomeEventArgs e = new SomeEventArgs(1);
try
{
if (this.IncomingRequest != null)
{
this.IncomingRequest.BeginInvoke(this, e, null, null);
}
}
catch
{
//failed
}
}
}
}
public class SomeEventArgs : EventArgs
{
public int RequestContext;
public SomeEventArgs(int anarg)
{
this.RequestContext = anarg;
}
}
Python:
import clr
clr.AddReference("test")
from test import *
def testcallback(foo, bar):
pass
thing = Class1()
thing.IncomingRequest += testcallback
thing.testInvoke()
--
I get the feeling I'm missing some basic knowledge about how IronPython
functions are added as events. But I feel like I'm getting distracted and
looking at all the wrong things. Thanks for your help!!!
___
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
Re: [IronPython] Debugging hosted python scripts
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 lo
Re: [IronPython] Debugging hosted python scripts
This is an avenue we have considered, but I do not believe it will not work for the Silverlight scenario. 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:51 AM To: Discussion of IronPython Subject: Re: [IronPython] Debugging hosted python scripts Hi, Another remark I forgot to write: Visual Studio Debugger attaches to an external process, so they don't have the problem of VS freezing the app is frozen. You could also go the way of using an external debugger process (and communicate e. G. via COM, or have the debugger using the .NET debugging APIs.) Regards, Markus Von: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] Im Auftrag von Markus Schaber Gesendet: Donnerstag, 31. März 2011 09:49 An: Discussion of IronPython Betreff: 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/>
[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
