Re: [IronPython] Debugging support PythonEngine
The first issue is probably the same that IL offset 0 does not
have any debug information.
Calling the delegate “add” steps into a
DynamicMethod which confuses VS. A workaround for now is to add this statement before
creating the PythonEngine.
IronPython.Compiler.Options.GenerateDynamicMethods
= false;
This disabled the use of DynamicMethods altogether and will
instead use AssemblyBuilder. This is not generally recommended or supported since
you are going to leak memory since AssemblyBuilder memory cannot be reclaimed.
However, VS seems to be better able to deal with AssemblyBuilder during stepping,
and it might be good enough for you. This is a case where we will would need to
teach the tool (VS) to handle DynamicMethods differently than it currently
does.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kristof Wagemans
Sent: Thursday, August 17, 2006 1:54 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Debugging support PythonEngine
It’s good to hear that it’s fixable. But, off course,
here’s the next one J.
With the same little script:
x = 1
y = 2
def Add(a, b):
x = a + b
return x
z = Add(x, y)
print z
And the following C# code:
EngineOptions options = new EngineOptions();
options.ClrDebuggingEnabled = true;
PythonEngine _pe = new PythonEngine(options);
delegate int Add(int a, int b);
_pe.ExecuteFile(@" script path ");
Add add = _pe.EvaluateAs("Add");
int var1 = add(2, 3);
int var2 = add(3, 4);
The following happens:
(I use a release version of Ironpython (RC2). There are no debug
symbols present, so that I don’t step into the engine code.)
I step into ExecuteFile (F11) and get into native code. After a few
lines of native code, I can go back to the source code view and I’m in
the Python script file. Maybe this is a similar issue as with stepping into a
function?
Next, I get a delegate to the Python Add function. The first time I
step into the add delegate I get the stepping into a function problem and then
I’m inside the function. But, when I try to step into the next add
delegate this doesn’t work anymore: the line is marked in green in Visual
Studio and I remain in the C# code. The next step into command resumes on the
next line in the C# code. I can’t see a reason why it would fail with the
next add. Setting a breakpoint in the Python function stops the execution at
that point in both cases.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Shri Borde
Sent: Thursday 17 August 2006 20:25
To: Discussion of IronPython
Subject: Re: [IronPython] Debugging support PythonEngine
I have opened this bug - http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=2248
- to track the issue with stepping in. We are not emitting any line number
information for IL offset 0.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] PythonEngine.SetVariable
Now it has become: PythonEngine.Globals["myVar"] = myVar; -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Cosby Sent: Friday 18 August 2006 2:34 To: IronPython Users Subject: [IronPython] PythonEngine.SetVariable At one point, PythonEngine.SetVariable was replaced by PythonEngine.SetGlobal. I don't find either of them in RC1. Why is this? Jon ___ 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 support PythonEngine
It’s good to hear that it’s
fixable. But, off course, here’s the next one J.
With the same little script:
x = 1
y = 2
def Add(a, b):
x = a + b
return x
z = Add(x, y)
print z
And the following C# code:
EngineOptions options = new
EngineOptions();
options.ClrDebuggingEnabled = true;
PythonEngine _pe = new
PythonEngine(options);
delegate int Add(int a, int b);
_pe.ExecuteFile(@" script
path ");
Add add = _pe.EvaluateAs("Add");
int var1 = add(2, 3);
int var2 = add(3, 4);
The following happens:
(I use a release version of Ironpython
(RC2). There are no debug symbols present, so that I don’t step into the
engine code.)
I step into ExecuteFile (F11) and get into
native code. After a few lines of native code, I can go back to the source code
view and I’m in the Python script file. Maybe this is a similar issue as
with stepping into a function?
Next, I get a delegate to the Python Add
function. The first time I step into the add delegate I get the stepping into a
function problem and then I’m inside the function. But, when I try to
step into the next add delegate this doesn’t work anymore: the line is
marked in green in Visual Studio and I remain in the C# code. The next step
into command resumes on the next line in the C# code. I can’t see a
reason why it would fail with the next add. Setting a breakpoint in the Python
function stops the execution at that point in both cases.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde
Sent: Thursday 17 August 2006
20:25
To: Discussion
of IronPython
Subject: Re: [IronPython]
Debugging support PythonEngine
I have opened this
bug - http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=2248
- to track the issue with stepping in. We are not emitting any line number
information for IL offset 0.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] PythonEngine.SetVariable
At one point, PythonEngine.SetVariable was replaced by PythonEngine.SetGlobal. I don't find either of them in RC1. Why is this? Jon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 1.0 RC2
Sources are in separate zip file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Varga Sent: Thursday, August 17, 2006 7:00 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 1.0 RC2 Hi, This release does not seem to include sources/tests. Is this intentional, or it is a bug ? Zoltan On 8/17/06, Dino Viehland <[EMAIL PROTECTED]> wrote: > > > > > Hello IronPython Community, > > > > We have just released IronPython 1.0 RC2. This build includes fixes for all > known blocking issues against RC1, and we're anticipating that this build > will be the same as 1.0 final unless we hear otherwise. We're looking for > any feedback, but in particular we'd like to know of any blocking issues > discovered against this build or fundamental language incompatibilities. > Please try out the latest build over the next 2 weeks and let us know if you > encounter any issues as soon as possible. > > > > We'd like to thank everyone in the community for your bug reports and > suggestions that helped make this a better release: Kevin Bjorke, Kevin Chu, > Mark Rees, Stanislas Pinte, and Timothy Fitz. > > > > Thanks and keep in touch, > > > The IronPython Team > > > > More complete list of changes and bug fixes: > > > CodePlex bug 2199: ReflectedPackage exposes internal types > > Several exception handling fixes including issue with break in except block > > CodePlex 2014 - __getitem__ on old style classes cannot be called as x[1,2] > > CodePlex 2015 - list.__rmul__ returns Ops.NotImplemented for subclass of > long > > CodePlex 2016 - Power with module on classes with __pow__ throws > > CodePlex 2023 - Cannot convert class whose __int__ returns long to int > > CodeDom reports file & line numbers based upon External Source information > > CodeDom auto-adds unknown namespaces to import list > > CodePlex 1752 - Issue with yield in finally > > Bugfix: CodePlex 1388 - TypeError when calling __init__ with keyword > argument 'args' > > Bugfix: CodePlex 1886 - Powmod throws ValueError for large numbers > > BugFix: CodePlex 1887 - powmod is very slow for large numbers > > Bugfix: 1357 - MD5.Create call raises TypeError - multiple overloads > conflict for static methods with same name in type hierarchy > > Bugfix: CodePlex 1393 - "get_DefaultFont() takes exactly -1 arguments (-1 > given)" when accessing static property with self (now a better error > message) > > Bugfix: CodePlex 1361 - help() function in ironpython shows incorrect > behavior > > Bugfix: CodePlex 1399 -Accessing generic methods requires use of explicit > tuple syntax > > Bugfix: CodePlex 1694 -Issue with yield in finally > > Bugfix: CodePlex 1728 - ipy shows different output when we use __new__ > > Bugfix: CodePlex 1731 - __init__ replaces the dictionary > > Static type Compiler produces overflow exception with following script code > in the web project integration with Visual Studio > > Winforms tutorial tweaks > > Bugfix: CodePlex 1417 - True division behaves differently for Execute and > Evaluate on PythonEngine > > Bugfix: CodePlex 1468 - List items are different when i use the htmlparser > > Bugfix: CodePlex 1732 - ipy throws error instead of returning complex number > > > > > ___ > 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] Debugging support PythonEngine
I have opened this bug - http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=2248 - to track the issue with stepping in. We are not emitting any line number information for IL offset 0. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, August 16, 2006 12:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine We have started doing some work for improving debugging as shown by the VSIP sample (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx). However, it still needs more work for it to be production-quality. By tools support, I was referring more to VSIP sample. We don’t have a concrete timeline for when we will be able to improve it further. Btw, using your sample script below, in most cases, I am able to step from Python code into C# code in IronPython.dll if I hit F11 in VS. However, when IronPython.dll calls the method Add, we step into native code for a while before actually reaching the source code for Add. This looks like something we can fix by changing the debug information we generate. After doing this fix, it would be possible to mark IronPython.dll as library code (either using DebuggerNonUserCodeAttribute or through some other scheme), and be able to step from Python code into a Python method. x = 1 y = 2 def Add(a, b): return a + b z = Add(x, y) ß Stepping in here takes you to IronPython.dll source code, then native code, and then the source code for Add print z From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Saturday, August 12, 2006 1:38 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Thanks for the info. It’s good to hear that there will be improvement possible in this area in the future. Although, the way I interpret your explanation, it’s not going to be anytime soon (or even this year), because you need enhancements to the underlying platform to make this possible. I’ve experimented a bit with System.Diagnostics.DebuggerNonUserCodeAttribute to see if it wasn’t possible to skip stepping into IronPython code. Unfortunately, the point where I get stuck in the assembly instructions is in generated code. I don’t understand this part of the code well enough to know if it’s possible to make the debugger skip these lines. Maybe this is why you need the changes to the platform? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 21:04 To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine Yes, we will definitely be working on improving the debugging support as it is a critical part of the development process. However, full support will need work in all parts of the tool chain including VS. Python local variables are implemented as normal MSIL variables (except in cases like closures). Hence, VS is able to display them. Currently, the best way to debug Python functions in VS while using PythonEngine would be to enable EngineOptions.ClrDebuggingEnable, open the PY file in VS and put a breakpoint where you want. Stepping in and out of Python functions will step you through methods in IronPython.dll . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Friday, August 11, 2006 12:36 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Are there plans to improve the debugging experience in the future or are you at a point where it is “as good as it gets”? Being able to debug makes writing and using python scripts a lot easier. Inside functions I can see not only the function parameters but also the newly defined local variables. Are these different from the global variables? I would have expected that the function locals are also stored inside a dictionary. Is it possible to step into python functions without getting into assembly instructions? This is very frustrating and degrades the debugging experience a lot. This is the more important issue for me. I’m not going to be using global variables frequently, but mostly functions loaded in the PythonEngine that are called from C#. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 0:30 To: Discussion of IronPython Cc: Glenn Hackney Subject: Re: [IronPython] Debugging support PythonEngine If EngineOptions.ClrDebuggingEnabled is set, we use AssemblyBuilder, TypeBuilder, etc for PythonEngine.Executed. The code generated by AssemblyBuilder, TypeBuilder, etc supports PDB debug information tracking for the methods, and so you will be able to set breakpoints in the code. However, it does not guarantee a perfect debugging experience. PythonEngine.ExecuteFile will use a dictionary for storing global variables, and these will not be visible b
Re: [IronPython] IronPython 1.0 RC2
Zoltan - you can find 2 download files for each release: one is binary only; the other has source/test (so that you can build it yourself). See: http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Varga Sent: Thursday, August 17, 2006 7:00 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 1.0 RC2 Hi, This release does not seem to include sources/tests. Is this intentional, or it is a bug ? Zoltan On 8/17/06, Dino Viehland <[EMAIL PROTECTED]> wrote: > > > > > Hello IronPython Community, > > > > We have just released IronPython 1.0 RC2. This build includes fixes > for all known blocking issues against RC1, and we're anticipating that > this build will be the same as 1.0 final unless we hear otherwise. > We're looking for any feedback, but in particular we'd like to know of > any blocking issues discovered against this build or fundamental language > incompatibilities. > Please try out the latest build over the next 2 weeks and let us know > if you encounter any issues as soon as possible. > > > > We'd like to thank everyone in the community for your bug reports and > suggestions that helped make this a better release: Kevin Bjorke, > Kevin Chu, Mark Rees, Stanislas Pinte, and Timothy Fitz. > > > > Thanks and keep in touch, > > > The IronPython Team > > > > More complete list of changes and bug fixes: > > > CodePlex bug 2199: ReflectedPackage exposes internal types > > Several exception handling fixes including issue with break in except > block > > CodePlex 2014 - __getitem__ on old style classes cannot be called as > x[1,2] > > CodePlex 2015 - list.__rmul__ returns Ops.NotImplemented for subclass > of long > > CodePlex 2016 - Power with module on classes with __pow__ throws > > CodePlex 2023 - Cannot convert class whose __int__ returns long to int > > CodeDom reports file & line numbers based upon External Source > information > > CodeDom auto-adds unknown namespaces to import list > > CodePlex 1752 - Issue with yield in finally > > Bugfix: CodePlex 1388 - TypeError when calling __init__ with keyword > argument 'args' > > Bugfix: CodePlex 1886 - Powmod throws ValueError for large numbers > > BugFix: CodePlex 1887 - powmod is very slow for large numbers > > Bugfix: 1357 - MD5.Create call raises TypeError - multiple overloads > conflict for static methods with same name in type hierarchy > > Bugfix: CodePlex 1393 - "get_DefaultFont() takes exactly -1 arguments > (-1 given)" when accessing static property with self (now a better > error > message) > > Bugfix: CodePlex 1361 - help() function in ironpython shows incorrect > behavior > > Bugfix: CodePlex 1399 -Accessing generic methods requires use of > explicit tuple syntax > > Bugfix: CodePlex 1694 -Issue with yield in finally > > Bugfix: CodePlex 1728 - ipy shows different output when we use __new__ > > Bugfix: CodePlex 1731 - __init__ replaces the dictionary > > Static type Compiler produces overflow exception with following script > code in the web project integration with Visual Studio > > Winforms tutorial tweaks > > Bugfix: CodePlex 1417 - True division behaves differently for Execute > and Evaluate on PythonEngine > > Bugfix: CodePlex 1468 - List items are different when i use the > htmlparser > > Bugfix: CodePlex 1732 - ipy throws error instead of returning complex > number > > > > > ___ > 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 1.0 RC2
Hi, This release does not seem to include sources/tests. Is this intentional, or it is a bug ? Zoltan On 8/17/06, Dino Viehland <[EMAIL PROTECTED]> wrote: > > > > > Hello IronPython Community, > > > > We have just released IronPython 1.0 RC2. This build includes fixes for all > known blocking issues against RC1, and we're anticipating that this build > will be the same as 1.0 final unless we hear otherwise. We're looking for > any feedback, but in particular we'd like to know of any blocking issues > discovered against this build or fundamental language incompatibilities. > Please try out the latest build over the next 2 weeks and let us know if you > encounter any issues as soon as possible. > > > > We'd like to thank everyone in the community for your bug reports and > suggestions that helped make this a better release: Kevin Bjorke, Kevin Chu, > Mark Rees, Stanislas Pinte, and Timothy Fitz. > > > > Thanks and keep in touch, > > > The IronPython Team > > > > More complete list of changes and bug fixes: > > > CodePlex bug 2199: ReflectedPackage exposes internal types > > Several exception handling fixes including issue with break in except block > > CodePlex 2014 - __getitem__ on old style classes cannot be called as x[1,2] > > CodePlex 2015 - list.__rmul__ returns Ops.NotImplemented for subclass of > long > > CodePlex 2016 - Power with module on classes with __pow__ throws > > CodePlex 2023 - Cannot convert class whose __int__ returns long to int > > CodeDom reports file & line numbers based upon External Source information > > CodeDom auto-adds unknown namespaces to import list > > CodePlex 1752 - Issue with yield in finally > > Bugfix: CodePlex 1388 - TypeError when calling __init__ with keyword > argument 'args' > > Bugfix: CodePlex 1886 - Powmod throws ValueError for large numbers > > BugFix: CodePlex 1887 - powmod is very slow for large numbers > > Bugfix: 1357 - MD5.Create call raises TypeError - multiple overloads > conflict for static methods with same name in type hierarchy > > Bugfix: CodePlex 1393 - "get_DefaultFont() takes exactly -1 arguments (-1 > given)" when accessing static property with self (now a better error > message) > > Bugfix: CodePlex 1361 - help() function in ironpython shows incorrect > behavior > > Bugfix: CodePlex 1399 -Accessing generic methods requires use of explicit > tuple syntax > > Bugfix: CodePlex 1694 -Issue with yield in finally > > Bugfix: CodePlex 1728 - ipy shows different output when we use __new__ > > Bugfix: CodePlex 1731 - __init__ replaces the dictionary > > Static type Compiler produces overflow exception with following script code > in the web project integration with Visual Studio > > Winforms tutorial tweaks > > Bugfix: CodePlex 1417 - True division behaves differently for Execute and > Evaluate on PythonEngine > > Bugfix: CodePlex 1468 - List items are different when i use the htmlparser > > Bugfix: CodePlex 1732 - ipy throws error instead of returning complex number > > > > > ___ > 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
[IronPython] IronPython and Glade 3.0
hi,
how can i use glade with ironpython? i search the net and i only found something like:
gxml = Glade.XML("path_to_glade_file", "window1", None)
gxml.Autoconnect(this)
but that does not work.
can anybody help me please, can anybody send me an working helloworld.glade and helloworld.py PLEAS!
thanks,
dragan
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] VS2005 Iron Python
Did u have a look at the output window? It should give all the program outputs... (don't know if it's the aswer u were looking for..) cheers, Fabio -Original Message- From: Jeff Collett <[EMAIL PROTECTED]> To: users@lists.ironpython.com Date: Wed, 16 Aug 2006 15:10:58 -0500 Subject: [IronPython] VS2005 Iron Python Hi, A question for anyone using the VS2005 IronPython IDE. I start a python console app, but when I attempt to run it within VS2005 it just shows an empty console window. I can run the py program fine if I use the command line IronPython. I am wondering if/how one can run the program within the IDE. Thanks Jeff Although this e-mail and any attachments are believed to be free of any virus or other defect which might affect any computer system, it is the responsibility of the recipient to check that it is virus-free and the sender accepts no responsibility or liability for any loss, injury, damage, cost or expense arising in any way from receipt or use thereof by the recipient. The information contained in this electronic mail message is confidential information and intended only for the use of the individual or entity named above, and may be privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please contact the sender immediately, delete this material from your computer and destroy all related paper media. Please note that the documents transmitted are not intended to be binding until a hard copy has been manually signed by all parties. Thank you. ___ 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
