[IronPython] Backporting of bugs to 1.1

[Shri Borde]

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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
> michael.foord at resolversystems.com
>
> 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 at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com