[IronPython] __doc__ on None
Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 ___ 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/03/07 Sanghyeon Seo wrote: Thanks to optimization works on delegate invocation, IronPython now runs faster on Mono. Conservatively, you can expect 5% speedup for 1.1, and 10% speedup for 2.0a1. Current svn mono should be a few percent faster as well (optimized string.CompareOrdinal). I got a few more insights into the performace issues with version 2.0 as well: if you try to run pystone with more passes (200, 300, 500 K) you'll notice the reported performance is significantly higher. 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). The good news is that most of the additional methods compiled are just because we haven't implemented in mono code sharing for generic methods with reference generic arguments. The bad news is that we haven't scheduled the time yet to implement code sharing. I guess these data points will help us to prioritize 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
[IronPython] Backporting of bugs to 1.1
We are focusing most of our efforts on the 2.0 branch and the DLR. We are not automatically backporting bug fixes to 1.1. We will consider doing that for specific bugs based on priority and how much it affects customers. However, given our limited resources and wanting to keep 1.1 as stable as possible, our preference is to minimize development in the 1.1 branch and focus on the 2.0 branch. 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 8:46 AM To: Discussion of IronPython Subject: [IronPython] __doc__ on None Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 ___ 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] Backporting of bugs to 1.1
Shri Borde wrote: We are focusing most of our efforts on the 2.0 branch and the DLR. We are not automatically backporting bug fixes to 1.1. We will consider doing that for specific bugs based on priority and how much it affects customers. However, given our limited resources and wanting to keep 1.1 as stable as possible, our preference is to minimize development in the 1.1 branch and focus on the 2.0 branch. 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. We need to divert standard output to capture output from user code. If user code uses threads (which it can do) - then the thread-local idea won't work. 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). All the best, Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 8:46 AM To: Discussion of IronPython Subject: [IronPython] __doc__ on None Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 ___ 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] Backporting of bugs to 1.1
Could you check if the thread-local static was null (uninitialized), infer that that this was a new user-created thread, and then initialize the static to the output stream you wanted for that thread? We can investigate the perf degrade of IPy 2.0 on .NET 3. I can't say if we can fix it completely until we do some investigations, but this is something that we would like to invest in anyway. Btw, did you say you are not willing to depend on .NET 3 or did you mean you are not willing to depend on IPy 2.0? When are you planning on releasing your product? (You could reply just to me if you want). We can use this as input to our decision on our servicing plans for 1.1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 10:05 AM To: Discussion of IronPython Subject: Re: [IronPython] Backporting of bugs to 1.1 Shri Borde wrote: We are focusing most of our efforts on the 2.0 branch and the DLR. We are not automatically backporting bug fixes to 1.1. We will consider doing that for specific bugs based on priority and how much it affects customers. However, given our limited resources and wanting to keep 1.1 as stable as possible, our preference is to minimize development in the 1.1 branch and focus on the 2.0 branch. 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. We need to divert standard output to capture output from user code. If user code uses threads (which it can do) - then the thread-local idea won't work. 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). All the best, Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 8:46 AM To: Discussion of IronPython Subject: [IronPython] __doc__ on None Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
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. 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 to output to. Would that solve the entire isolation problem for you? Our current code is nice and elegant, whilst yours sounds hacky. :-p Actually its just a solution we didn't think of, although it isn't quite as nice as running them in separate engines which we do now, and does give us *some* measure of isolation. (It is slightly less likely that a badly written user script will now kill the whole application, although obviously still very easy.) The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. Which is a problem - but we can always say don't do that then... I think we still like our current use of multiple engines, and would prefer to see that supported in IronPython 2.0, even with a
Re: [IronPython] Backporting of bugs to 1.1
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. -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
