Debugging hosted python scripts

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging hosted python scripts

Keith Rome

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 | [hidden email]

www.wintellect.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Markus Schaber-6

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: [hidden email] [mailto:[hidden email]] Im Auftrag von Keith Rome
Gesendet: Donnerstag, 31. März 2011 04:52
An: [hidden email]
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 | [hidden email]

www.wintellect.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Markus Schaber-6
In reply to this post by Keith Rome

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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] Im Auftrag von Keith Rome
Gesendet: Donnerstag, 31. März 2011 04:52
An: [hidden email]
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 | [hidden email]

www.wintellect.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Keith Rome

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 | [hidden email]

www.wintellect.com

 

From: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] Im Auftrag von Keith Rome
Gesendet: Donnerstag, 31. März 2011 04:52
An: [hidden email]
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 | [hidden email]

www.wintellect.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Jeff Hardy-4
In reply to this post by Keith Rome
On Wed, Mar 30, 2011 at 8:52 PM, Keith Rome <[hidden email]> 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
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Jimmy Schementi-3
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 <[hidden email]> wrote:

> On Wed, Mar 30, 2011 at 8:52 PM, Keith Rome <[hidden email]> 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
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Dino Viehland
In reply to this post by Jeff Hardy-4


Jeff wrote:

> On Wed, Mar 30, 2011 at 8:52 PM, Keith Rome <[hidden email]>
> wrote:
> > 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.

There's certainly nothing that does this today - this is effectively "how to do
stackless on IronPython."  There've been similar questions on the mailing list
on how to do this (for greenlets) in the past.  There's basically two changes
which need to happen to get this working:

        1. We need to re-write the trees we produce so all local variables are
hoisted into a heap allocated data structure.  We already do this for generators
and for sys.settrace support so that one's not so hard.
        2. We need to re-write the trees so that rather than performing a dynamic
operation they yield control back to a loop which then performs the dynamic
operation.
        3. We might need to do #2 but with certain built in calls (for example
import if you don't want imports to block, maybe some other built-in operations
as well).

Doing #2 isn't that difficult either - it's really just a tree rewrite that changes each
Dynamic node (or one of the DLR outer layers dynamic like nodes) into a node which
returns a call site plus arguments.  The outer loop can then dispatch into the call
site or it can yield appropriately.  

Finally this needs to be combined with the debugging mechanism which it's self
is just an AST re-write.  sys.settrace uses the same basic rewrite we need for #1 to
hoist the variables.  In addition to that it introduces the line, call, exception, etc...
callbacks as well.  I think the final tweak here would be to make those yield control
back to the dispatch loop which then can then make the sys.settrace call.

Finally you'll probably need to update functions so that if they're called "externally"
(not directly from the dispatch loop) that they setup a new dispatch loop.  So the
delegates that are held in the FunctionCode object will need to be distinct from the
normal delegates (this is similar to how we have a normal delegate and a light throwing
delegate today).  

I'd suggest by trying to add the stackless re-write and dispatch loop to the DebugInfoRewriter
class (or a fork of it) and then getting simple stackless function calls going.    Then you can
worry about fitting it in with the rest of the system.

I could even see us adding this back to the core if it worked out to be sufficiently on the side
which if implemented just as these AST rewrites it could be.
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Dino Viehland
In reply to this post by Jimmy Schementi-3
Jimmy wrote:
> 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.

It's non-blocking in the same way that sys.settrace is non-blocking though, you
still need to pump messages while you're in sys.settrace if you want it to
feel like a non-blocking GUI API.  And that could eventually stack overflow if you
have lots of App -> Script -> App -> Script -> App -> Script transitions.  But
it is the right place to start looking.


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Jimmy Schementi-3
On Thu, Mar 31, 2011 at 12:53 PM, Dino Viehland <[hidden email]> wrote:
Jimmy wrote:
> 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.

It's non-blocking in the same way that sys.settrace is non-blocking though, you
still need to pump messages while you're in sys.settrace if you want it to
feel like a non-blocking GUI API.  And that could eventually stack overflow if you
have lots of App -> Script -> App -> Script -> App -> Script transitions.  But
it is the right place to start looking.

Right, thanks for the clarification.

By the way, I've solved the app-hanging issue by running all IronPython code on a non-UI thread, and having any user IronPython code manipulate "dispatching" data structures (DispatchingObservableCollection, DispatchingPropertyChangedObject, etc ... basically implementations which dispatch to the UI thread if being used from a non-UI thread). Those structures are data bound to the UI. Not very general-purpose, or very performant, but it solved my problem.

_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Creating Symbolic Links via IronPython

Lukáš Duběda
Hi there everyone,

I've been trying to find a solution for creating Symbolic Links
via IronPython scripting, but it seems there is not a direct
way of doing this via .NET and since I don't know C#, I have
hard times "translating" C# snippets I've found on the net
to IronPython. For example:

[Interop.DllImport("kernel32.dll", EntryPoint="CreateSymbolicLinkW",
CharSet=Interop.CharSet.Unicode)]
public static extern int CreateSymbolicLink(string lpSymlinkFileName,
string lpTargetFileName, int dwFlags);

So, I thought asking here would probably be the best place for
the best advice (i.e. what to avoid using etc...).

Any advice on this topic would be much appretiated!

Thanks a lot in advance, cheers,

Lukáš Duběda
Director
[T] +420 602 444 164

duber studio(tm)
[M] [hidden email]
[W] http://www.duber.cz

[A] R.A.Dvorského 601, Praha 10
[A] 10900, Czech Republic, Europe
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Creating Symbolic Links via IronPython

Markus Schaber-6
Hi,

Either you create a c# wrapper dll that exposes this function, and reference that DLL from Ironpython.

Or you use the clrtype class (which can be found at http://ironpython.codeplex.com/wikipage?title=Samples) - this allows you to assign c# Attributes to python methods, so you can define the DLLImport method.)

Best regards

Markus Schaber

___________________________
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: [hidden email] | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:users-
> [hidden email]] Im Auftrag von Lukáš Dubeda
> Gesendet: Donnerstag, 31. März 2011 21:43
> An: Discussion of IronPython
> Betreff: [IronPython] Creating Symbolic Links via IronPython
>
> Hi there everyone,
>
> I've been trying to find a solution for creating Symbolic Links via
> IronPython scripting, but it seems there is not a direct way of doing this
> via .NET and since I don't know C#, I have hard times "translating" C#
> snippets I've found on the net to IronPython. For example:
>
> [Interop.DllImport("kernel32.dll", EntryPoint="CreateSymbolicLinkW",
> CharSet=Interop.CharSet.Unicode)] public static extern int
> CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName, int
> dwFlags);
>
> So, I thought asking here would probably be the best place for the best
> advice (i.e. what to avoid using etc...).
>
> Any advice on this topic would be much appretiated!
>
> Thanks a lot in advance, cheers,
>
> Lukáš Duběda
> Director
> [T] +420 602 444 164
>
> duber studio(tm)
> [M] [hidden email]
> [W] http://www.duber.cz
>
> [A] R.A.Dvorského 601, Praha 10
> [A] 10900, Czech Republic, Europe
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Creating Symbolic Links via IronPython

Steve Dower
You should be able to use ctypes for this. For example, the following
works fine from CPython (I don't have IronPython handy on this
computer):

from ctypes import windll
windll.kernel32.CreateSymbolicLinkA("c:\\py.exe", "c:\\python27\\python.exe", 0)

The only difference may be calling CreateSymbolicLinkW instead of *A -
the return value should be non-zero if it succeeds. Also, if you're
running ipy64.exe you may need to override
CreateSymbolicLinkW.argtypes with suitable values - otherwise it will
assume and it sometimes assumes wrong.

On Fri, Apr 1, 2011 at 17:40, Markus Schaber <[hidden email]> wrote:

> Hi,
>
> Either you create a c# wrapper dll that exposes this function, and reference that DLL from Ironpython.
>
> Or you use the clrtype class (which can be found at http://ironpython.codeplex.com/wikipage?title=Samples) - this allows you to assign c# Attributes to python methods, so you can define the DLLImport method.)
>
> Best regards
>
> Markus Schaber
>
> ___________________________
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
>
> Email: [hidden email] | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>
>> -----Ursprüngliche Nachricht-----
>> Von: [hidden email] [mailto:users-
>> [hidden email]] Im Auftrag von Lukáš Dubeda
>> Gesendet: Donnerstag, 31. März 2011 21:43
>> An: Discussion of IronPython
>> Betreff: [IronPython] Creating Symbolic Links via IronPython
>>
>> Hi there everyone,
>>
>> I've been trying to find a solution for creating Symbolic Links via
>> IronPython scripting, but it seems there is not a direct way of doing this
>> via .NET and since I don't know C#, I have hard times "translating" C#
>> snippets I've found on the net to IronPython. For example:
>>
>> [Interop.DllImport("kernel32.dll", EntryPoint="CreateSymbolicLinkW",
>> CharSet=Interop.CharSet.Unicode)] public static extern int
>> CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName, int
>> dwFlags);
>>
>> So, I thought asking here would probably be the best place for the best
>> advice (i.e. what to avoid using etc...).
>>
>> Any advice on this topic would be much appretiated!
>>
>> Thanks a lot in advance, cheers,
>>
>> Lukáš Duběda
>> Director
>> [T] +420 602 444 164
>>
>> duber studio(tm)
>> [M] [hidden email]
>> [W] http://www.duber.cz
>>
>> [A] R.A.Dvorského 601, Praha 10
>> [A] 10900, Czech Republic, Europe
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Creating Symbolic Links via IronPython

Lukáš Duběda
Interesting! Thank you, I'll try that.

Also thanks Markus Schaber, another thing
to look at. :)

Cheers,

Lukáš Duběda
Director
[T] +420 602 444 164

duber studio(tm)
[M] [hidden email]
[W] http://www.duber.cz

[A] R.A.Dvorského 601, Praha 10
[A] 10900, Czech Republic, Europe

On 1.4.2011 8:58, Steve Dower wrote:

> You should be able to use ctypes for this. For example, the following
> works fine from CPython (I don't have IronPython handy on this
> computer):
>
> from ctypes import windll
> windll.kernel32.CreateSymbolicLinkA("c:\\py.exe", "c:\\python27\\python.exe", 0)
>
> The only difference may be calling CreateSymbolicLinkW instead of *A -
> the return value should be non-zero if it succeeds. Also, if you're
> running ipy64.exe you may need to override
> CreateSymbolicLinkW.argtypes with suitable values - otherwise it will
> assume and it sometimes assumes wrong.
>
> On Fri, Apr 1, 2011 at 17:40, Markus Schaber<[hidden email]>  wrote:
>> Hi,
>>
>> Either you create a c# wrapper dll that exposes this function, and reference that DLL from Ironpython.
>>
>> Or you use the clrtype class (which can be found at http://ironpython.codeplex.com/wikipage?title=Samples) - this allows you to assign c# Attributes to python methods, so you can define the DLLImport method.)
>>
>> Best regards
>>
>> Markus Schaber
>>
>> ___________________________
>> We software Automation.
>>
>> 3S-Smart Software Solutions GmbH
>> Markus Schaber | Developer
>> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
>>
>> Email: [hidden email] | Web: http://www.3s-software.com
>> CoDeSys internet forum: http://forum.3s-software.com
>> Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
>>
>> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: [hidden email] [mailto:users-
>>> [hidden email]] Im Auftrag von Lukáš Dubeda
>>> Gesendet: Donnerstag, 31. März 2011 21:43
>>> An: Discussion of IronPython
>>> Betreff: [IronPython] Creating Symbolic Links via IronPython
>>>
>>> Hi there everyone,
>>>
>>> I've been trying to find a solution for creating Symbolic Links via
>>> IronPython scripting, but it seems there is not a direct way of doing this
>>> via .NET and since I don't know C#, I have hard times "translating" C#
>>> snippets I've found on the net to IronPython. For example:
>>>
>>> [Interop.DllImport("kernel32.dll", EntryPoint="CreateSymbolicLinkW",
>>> CharSet=Interop.CharSet.Unicode)] public static extern int
>>> CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName, int
>>> dwFlags);
>>>
>>> So, I thought asking here would probably be the best place for the best
>>> advice (i.e. what to avoid using etc...).
>>>
>>> Any advice on this topic would be much appretiated!
>>>
>>> Thanks a lot in advance, cheers,
>>>
>>> Lukáš Duběda
>>> Director
>>> [T] +420 602 444 164
>>>
>>> duber studio(tm)
>>> [M] [hidden email]
>>> [W] http://www.duber.cz
>>>
>>> [A] R.A.Dvorského 601, Praha 10
>>> [A] 10900, Czech Republic, Europe
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Creating Symbolic Links via IronPython

Vernon D. Cole
Just to make sure we are all on the same page here, the original post said:
>>>>
>>>> I've been trying to find a solution for creating Symbolic Links via
>>>> IronPython scripting, [...snip...]
>>>> [Interop.DllImport("kernel32.dll", EntryPoint="CreateSymbolicLinkW",
>>>> CharSet=Interop.CharSet.Unicode)] public static extern int
>>>> CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName,
>>>> int
>>>> dwFlags);
>>>>
Are we talking about making a Windows version of the standard library routine:
>os.symlink(source, link_name)
>Create a symbolic link pointing to source named link_name.
>
>Availability: Unix.
?

And, if so, should we (can we) put in in the standard library?
--
Vernon
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Creating Symbolic Links via IronPython

briancurtin
On Fri, Apr 1, 2011 at 20:32, Vernon Cole <[hidden email]> wrote:
Just to make sure we are all on the same page here, the original post said:
>>>>
>>>> I've been trying to find a solution for creating Symbolic Links via
>>>> IronPython scripting, [...snip...]
>>>> [Interop.DllImport("kernel32.dll", EntryPoint="CreateSymbolicLinkW",
>>>> CharSet=Interop.CharSet.Unicode)] public static extern int
>>>> CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName,
>>>> int
>>>> dwFlags);
>>>>
Are we talking about making a Windows version of the standard library routine:
>os.symlink(source, link_name)
>Create a symbolic link pointing to source named link_name.
>
>Availability: Unix.
?

And, if so, should we (can we) put in in the standard library?

The standard library includes Windows support for os.symlink as of 3.2.

_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Debugging hosted python scripts

Keith Rome
In reply to this post by Markus Schaber-6

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 | [hidden email]

www.wintellect.com

 

From: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] Im Auftrag von Keith Rome
Gesendet: Donnerstag, 31. März 2011 04:52
An: [hidden email]
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 | [hidden email]

www.wintellect.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com