Re: [IronPython] Backporting of bugs to 1.1
Sanghyeon Seo wrote: 2007/6/5, Michael Foord [EMAIL PROTECTED]: Also on systems with .NET 3, there is a reported speed degradation moving from 1 to 2, which we can't afford (and we aren't willing to depend on .NET 3 yet I'm afraid). I think you meant systems *without* .NET 3. I did. :-) Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
Shri Borde wrote: Michael, how does multiple engines help you when several pieces of user-code are running concurrently? It seems that if you are willing to live with some restrictions (like every thread having a single output stream), you should be able to live without multiple engines. We could make this easier by formalizing this design pattern, but you may be able to achieve your required semantics of only redirecting stdout without that. The users may have several user interface windows open at one time, each relating to a different data-set. Although only one window is 'active', several can be processing data at the same time - and executing user code as a result. Each window has an IronPython engine associated with it, in which the data-sets are processed. This way output from each data-set goes to its window. User code *can* spin off new threads if they want, but because they are executing 'inside' their engines - output goes to the right place. If you can suggest a way we can achieve this without multiple engines, then we are interested. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml We have not finalized on the single engine story yet, but we are leaning towards it at the moment. Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. Michael Foord said: That is the problem: if we have several pieces of user-code running concurrently then we wouldn't know which output stream it belonged to. (If we only had one stream at a time we could override sys.stdout from the Python side.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, May 02, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Both you and Tony bring up a very good point. I believe that we can solve the thread problem by using .NET's ExecutionContext. I've never actually tried that, I just know it exists, so I'll need to look into that. That will cause the context to be flown to thread pool threads, newly created threads, and other various async points within the CLR. One reason for its existence today is for security so the CLR is pretty good at making sure this always gets flowed (there are various ways to do operations which don't flow it, but they all have Unsafe in their name). Based upon Tony's description of I'm starting to believe the swappable SystemStates rather than multiple PythonEngines are the right solution - especially given that CPython is using a similar technique and even more so if ExecutionContext solves the async/threading problem. Thanks for all your feedback and let me know if you have any more. I'll take it all to our discussion about the hosting APIs next week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 12:19 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Dino Viehland wrote: I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... I was a bit tongue in cheek - but top-posting suffers from the same readability issues on mailing lists as it does in usenet posts. Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. It occurs to me that your suggestion won't work for us if the user spawns any threads of their own (which is highly likely) - unless we can tell what thread it was spawned from... Meanwhile I'll try and digest the rest of *this* thread... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 9:06 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) My guess is that you have to use outlook. It does seem to encourage top-posting. ;-) Dino Viehland wrote: The scripts are running on multiple threads? Usually - although sometimes code is executed on the GUI thread, but in this case we always know where to send the output. The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream
[IronPython] Debugging IronPython - Question
Hello!
I have a question regarding debugging of IronPython. I use version 1.1
and debugged a modified version of the first.py file from the Tutorial
directory:
--
def add(a, b):
add(a, b) - returns a + b
temp1 = a*2
temp2 = b*2
temp3 = temp1+temp2
return temp3 / 2
def factorial(n):
factorial(n) - returns factorial of n
if n = 1: return 1
return n * factorial(n-1)
print Hello from IronPython!
number = 5
result = factorial (number)
print Factorial(,number,) is ,result
result2 = add(5,7)
print 5 + 7 =,result2
First, I debugged this program with Visual C# 2005 Express, i.e. MS CLR
debugger. I set a breakpoint on last line of add() function and got the
correct values of locals and parameters:
a 5 object{int}
b 7 object{int}
tbstatusfalse bool
temp1 10 object{int}
temp2 14 object{int}
temp3 24 object{int}
$line 21 int
retval nullobject
Then I tried to debug this program with the Mono debugger (MDB) under
Linux. If I compile the Python file before with -X:SaveAssemblies, I can
set a breakpoint on the same line. The show locals and show params
commands give me the variable names, but incorrect or missing values:
(mdb) show locals
tbstatus = (System.Boolean) true
temp2 = (object) object (0x0738a000)
temp3 = (object) (System.Int32) 14
temp1 = (object) (System.Int32) 24
$line = (System.Int32) 473472
retval = (object) object (0x0015)
(mdb) show params
a = (System.Object) { }
b = (System.Object) { }
I suspect the Mono Debugger does something wrong, but I'm not sure. Is
it possible that Mono does something different with IronPython as .NET
under Windows?
What's this tbstatus variable for?
Does anyone have experience with debugging IronPython under Linux?
Best greetings + thanks,
Harald Krapfenbauer
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. None of the 1.1 bugs are blocking us, we have just discovered them as we develop. If we encounter a blocking bug we will shout loudly. :-) Given that we are so close to release, and that switching to 2.0 will mean non-trivial changes (which wasn't true of 1.0 - 1.1 - thank you), we will stick to 1.1 for the moment. Eventually we will have to move to 2.0 of course (and would like to). As 2.0 is still in alpha, we would like to think that the 1.X branch hasn't been abandoned by 'the team'. In the very long run we will move to executing user code inside appdomains, but currently that would result in a lot of cross domain calls that would hurt our performance in a big way. As resolving this would be a lot of work it isn't yet a high priority for us - and won't be for quite a long time. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Sockets and Standard Library Modules in IronPython
Hello all, A plea to 'the team'. urllib and urllib2 are Python standard libraries modules that provide a high level interface to accessing internet resources. They are widely used. These modules are broken for the official IronPython distribution, but they work with FePy thanks to patches that Seo has applied. Seo says that the IronPython support for Python sockets has improved greatly in IronPython 1.1 - but unfortunately not to the point where these modules functions. This is a request for these issues to be addressed as soon as possible. :-) Many Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] -S option has an additional side effect
-S option disables the import of the module site. But in IronPython, it has an additional (probably unintended) side effect of not including Lib directory in sys.path. This is different from CPython. -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython now runs faster on Mono
On 06/05/07 Sanghyeon Seo wrote: This is because we JIT many more methods in 2.0 and the JIT time is accounted in the results. Adding a warmup call to pystone.py will get the 1.1 and 2.0 results much closer than they appear to be with a default run (58k vs 46k in the default and 59k vs 55k with the warmup on my pentium M 1.6). How do I add a warmup call to pystone.py? Add: pystones(1) at the end of the file just before main(loops). It should be 1 instead of 1, but the code is buggy and will result in a division by zero error (and 1 may not be enough on a fast box, so if you get an error you'll need to increase it...). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Sockets and Standard Library Modules in IronPython
I would suppose getting these libs to work would also make httplib2 work as well. httplib2 is a *great* library that does an excellent job with caching, etags and authentication, all of which are huge regarding RESTful services (ie Atom Publishing Protocol). I only mention it in hopes of fueling the fire to get these things working :) Thanks! Eric Larson On 6/5/07, Fuzzyman [EMAIL PROTECTED] wrote: Hello all, A plea to 'the team'. urllib and urllib2 are Python standard libraries modules that provide a high level interface to accessing internet resources. They are widely used. These modules are broken for the official IronPython distribution, but they work with FePy thanks to patches that Seo has applied. Seo says that the IronPython support for Python sockets has improved greatly in IronPython 1.1 - but unfortunately not to the point where these modules functions. This is a request for these issues to be addressed as soon as possible. :-) Many Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ 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] -S option has an additional side effect
Thanks! Filed as CodePlex Work Item #10778 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10778). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Tuesday, June 05, 2007 4:41 AM To: Discussion of IronPython Subject: [IronPython] -S option has an additional side effect -S option disables the import of the module site. But in IronPython, it has an additional (probably unintended) side effect of not including Lib directory in sys.path. This is different from CPython. -- Seo Sanghyeon ___ 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] Sockets and Standard Library Modules in IronPython
Thanks for reporting this Michael. Are there any open work items on CodePlex WRT socket that are blocking urllib/urllib2 from being used? If not, please let me know and I'll investigate this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: Tuesday, June 05, 2007 3:11 AM To: Discussion of IronPython Subject: [IronPython] Sockets and Standard Library Modules in IronPython Hello all, A plea to 'the team'. urllib and urllib2 are Python standard libraries modules that provide a high level interface to accessing internet resources. They are widely used. These modules are broken for the official IronPython distribution, but they work with FePy thanks to patches that Seo has applied. Seo says that the IronPython support for Python sockets has improved greatly in IronPython 1.1 - but unfortunately not to the point where these modules functions. This is a request for these issues to be addressed as soon as possible. :-) Many Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ 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] Sockets and Standard Library Modules in IronPython
2007/6/6, Eric Larson [EMAIL PROTECTED]: I would suppose getting these libs to work would also make httplib2 work as well. httplib2 is a *great* library that does an excellent job with caching, etags and authentication, all of which are huge regarding RESTful services (ie Atom Publishing Protocol). I only mention it in hopes of fueling the fire to get these things working :) I must mention that httplib2 already works with IPCE. Actually I submitted a patch for that in December 2006! See http://sourceforge.net/mailarchive/forum.php?thread_name=5b0248170612180038x2eb2d8c9t3a655e0d5eff1060%40mail.gmail.comforum_name=httplib2-discuss -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Sockets and Standard Library Modules in IronPython
On 6/5/07, Sanghyeon Seo [EMAIL PROTECTED] wrote: 2007/6/6, Eric Larson [EMAIL PROTECTED]: I would suppose getting these libs to work would also make httplib2 work as well. httplib2 is a *great* library that does an excellent job with caching, etags and authentication, all of which are huge regarding RESTful services (ie Atom Publishing Protocol). I only mention it in hopes of fueling the fire to get these things working :) I must mention that httplib2 already works with IPCE. Actually I submitted a patch for that in December 2006! See http://sourceforge.net/mailarchive/forum.php?thread_name=5b0248170612180038x2eb2d8c9t3a655e0d5eff1060%40mail.gmail.comforum_name=httplib2-discuss Of course they work with IPCE! It would just be nice if they could work out of the box :) Eric **FWIW, I do use IPCE and it rocks! ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
I have attached a sample at the bottom of http://msdn2.microsoft.com/en-us/library/system.threading.executioncontext.aspx showing how state can be automatically propagated across thread boundaries. You should be able to set the desired output stream for each thread processing your data. Even if user code spawns new thread, the output stream information can automatically be propagated to the children thread. Would this work for you? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: Tuesday, June 05, 2007 1:30 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Shri Borde wrote: Michael, how does multiple engines help you when several pieces of user-code are running concurrently? It seems that if you are willing to live with some restrictions (like every thread having a single output stream), you should be able to live without multiple engines. We could make this easier by formalizing this design pattern, but you may be able to achieve your required semantics of only redirecting stdout without that. The users may have several user interface windows open at one time, each relating to a different data-set. Although only one window is 'active', several can be processing data at the same time - and executing user code as a result. Each window has an IronPython engine associated with it, in which the data-sets are processed. This way output from each data-set goes to its window. User code *can* spin off new threads if they want, but because they are executing 'inside' their engines - output goes to the right place. If you can suggest a way we can achieve this without multiple engines, then we are interested. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml We have not finalized on the single engine story yet, but we are leaning towards it at the moment. Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. Michael Foord said: That is the problem: if we have several pieces of user-code running concurrently then we wouldn't know which output stream it belonged to. (If we only had one stream at a time we could override sys.stdout from the Python side.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, May 02, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Both you and Tony bring up a very good point. I believe that we can solve the thread problem by using .NET's ExecutionContext. I've never actually tried that, I just know it exists, so I'll need to look into that. That will cause the context to be flown to thread pool threads, newly created threads, and other various async points within the CLR. One reason for its existence today is for security so the CLR is pretty good at making sure this always gets flowed (there are various ways to do operations which don't flow it, but they all have Unsafe in their name). Based upon Tony's description of I'm starting to believe the swappable SystemStates rather than multiple PythonEngines are the right solution - especially given that CPython is using a similar technique and even more so if ExecutionContext solves the async/threading problem. Thanks for all your feedback and let me know if you have any more. I'll take it all to our discussion about the hosting APIs next week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 12:19 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Dino Viehland wrote: I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... I was a bit tongue in cheek - but top-posting suffers from the same readability issues on mailing lists as it does in usenet posts. Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. It occurs to me that your suggestion won't work for us if the user spawns any threads of their own (which is highly likely) - unless we can tell what thread it was spawned from... Meanwhile I'll try and digest the rest of *this* thread... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
I agree that you should stick with 1.1 if you are close to release. We will fix critical blocking bugs in 1.1 as needed. However, to keep that branch stable, the bar will be high. Do shout if you run into blocking issues. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: Tuesday, June 05, 2007 2:30 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. None of the 1.1 bugs are blocking us, we have just discovered them as we develop. If we encounter a blocking bug we will shout loudly. :-) Given that we are so close to release, and that switching to 2.0 will mean non-trivial changes (which wasn't true of 1.0 - 1.1 - thank you), we will stick to 1.1 for the moment. Eventually we will have to move to 2.0 of course (and would like to). As 2.0 is still in alpha, we would like to think that the 1.X branch hasn't been abandoned by 'the team'. In the very long run we will move to executing user code inside appdomains, but currently that would result in a lot of cross domain calls that would hurt our performance in a big way. As resolving this would be a lot of work it isn't yet a high priority for us - and won't be for quite a long time. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ 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
