Re: [IronPython] Working towards IronPython 2.7 RTM
Would be nice if we could tag issues in the issue tracker with for 2.7 or something similar so people could know which issues were on the docket for including in 2.7. This might help people who want to contribute to do so. http://ironpython.codeplex.com/workitem/list/advanced slide On Thu, Jan 20, 2011 at 10:08 PM, yngipy hernan yng...@gmail.com wrote: I would like to get my hands wet with IronPython as well but it is not straight forward where to start. I am no expert but I can hack around code so I would need guidance where to start. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Meaning of issue tracker fields (Was: Working towards IronPython 2.7 RTM)
On Fri, Jan 21, 2011 at 6:58 AM, Slide slide.o@gmail.com wrote: Would be nice if we could tag issues in the issue tracker with for 2.7 or something similar so people could know which issues were on the docket for including in 2.7. This might help people who want to contribute to do so. I've been thinking about this as well. I don't know what the Release field is supposed to mean; I could see it being either 'bug found in this release' or 'bug (to be) fixed in this release'. I think we should take the latter interpretation and set Release to 2.7 for the stuff we want to fix, and then use the 'Impact' field to determine what's actually going to be fixed. The main reason is that it makes searching for release-blocking bugs much easier. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Meaning of issue tracker fields (Was: Working towards IronPython 2.7 RTM)
On Fri, Jan 21, 2011 at 8:51 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jan 21, 2011 at 6:58 AM, Slide slide.o@gmail.com wrote: Would be nice if we could tag issues in the issue tracker with for 2.7 or something similar so people could know which issues were on the docket for including in 2.7. This might help people who want to contribute to do so. I've been thinking about this as well. I don't know what the Release field is supposed to mean; I could see it being either 'bug found in this release' or 'bug (to be) fixed in this release'. I think we should take the latter interpretation and set Release to 2.7 for the stuff we want to fix, and then use the 'Impact' field to determine what's actually going to be fixed. The main reason is that it makes searching for release-blocking bugs much easier. - Jeff ___ This sounds great. Just need to make sure only certain people can mark something as bug (to be) fixed in this release field so random people don't just start marking things as going to be fixed in 2.7 :-) slide -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Working towards IronPython 2.7 RTM
On Thu, Jan 20, 2011 at 10:08 PM, yngipy hernan yng...@gmail.com wrote: I would like to get my hands wet with IronPython as well but it is not straight forward where to start. I am no expert but I can hack around code so I would need guidance where to start. For instructions on getting the code, see http://ironpython.codeplex.com/wikipage?title=Respository%20InstructionsreferringTitle=Home. If you have any tips for improving it, let us know. Getting it to build is probably the second-most-difficult part, after installing git :). For a nice easy fix to start with, take a look at http://ironpython.codeplex.com/workitem/29928. You can either attach a patch to the issue, or (preferably) create a fork on GitHub and send us a pull request. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Meaning of issue tracker fields (Was: Working towards IronPython 2.7 RTM)
On Fri, Jan 21, 2011 at 8:55 AM, Slide slide.o@gmail.com wrote: This sounds great. Just need to make sure only certain people can mark something as bug (to be) fixed in this release field so random people don't just start marking things as going to be fixed in 2.7 :-) You have to be a 'developer' on the Codeplex project to edit those fields. I also get a report every day of all that changes to the issue tracker, so I'd spot anything odd fairly quickly. If anyone wants developer access, just look at a few bugs, see if they're still valid, produce a few testcases or patches, and we'll be happy to give you the permission to edit them freely. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Which modules collection to use?
Hi Pulled src from github. The devel set up instructions (http://ironpython.codeplex.com/wikipage?title=Respository%20Instructions) and all the script magic already in place is just great as things compile and run. Very cool. However, need help figuring some things out, please: 1. Neither the release, nor the debug deployment copies the standard module files into Lib. Is there magic in place for that already, like a project file that has the deployment paths spelled out? 2. There are two copies of modules sets. One in cPython/Lib, there other is in IronPython/27/Lib. The answer is probably obvious, but which set of modules do I need to copy? 3. Before I found the bundled module collections, I tried modules from 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] and saw code in modules blowing up left and right. It's obvious that the modules collection in IronLanguages is stale, but i wonder how stale it is... Are they from 2.5/2.6 time? If the next IPY release is 2.7 do we need to go and update the modules bundled with 2.7? Daniel. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Which modules collection to use?
Daniel wrote: Pulled src from github. The devel set up instructions (http://ironpython.codeplex.com/wikipage?title=Respository%20Instructions) and all the script magic already in place is just great as things compile and run. Very cool. However, need help figuring some things out, please: 1. Neither the release, nor the debug deployment copies the standard module files into Lib. Is there magic in place for that already, like a project file that has the deployment paths spelled out? We have a copy of the std lib in External.LCA_RESTRICTED\Languages\IronPython\27\Lib. I generally just set IRONPYTHONPATH at that directory which is much better than copying it on every build. For releases the MSI builder will pick it up out External.LCA_RESTRICTED\Languages\CPython\27\Lib. The difference between those two directories is the tests - the IronPython dir has various changes to disable failing tests, occasionally adds some extra tests, etc... The 2 dirs are also useful for doing 3 way merges when updating the standard library. That way you know what the last version we pulled was. 2. There are two copies of modules sets. One in cPython/Lib, there other is in IronPython/27/Lib. The answer is probably obvious, but which set of modules do I need to copy? [conveniently answered above] 3. Before I found the bundled module collections, I tried modules from 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] and saw code in modules blowing up left and right. It's obvious that the modules collection in IronLanguages is stale, but i wonder how stale it is... Are they from 2.5/2.6 time? If the next IPY release is 2.7 do we need to go and update the modules bundled with 2.7? These are all from the 2.7 timeframe and should be from 2.7.0 at the very earliest. If you windiff the CPython lib dir w/ your 2.7.1 install Lib dir you should be able to see the differences. I'm surprised that things are blowing up - maybe there's some site packages breaking things in your install? ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Which modules collection to use?
Thx on the IRONPYTHONPATH hint. Regarding what blows up: copy'n'paste Lib folder from cPython 2.7.1 into /Debug/.., followed by bdc 6 Warning(s) 0 Error(s) Time Elapsed 00:00:37.34 C:\workipy IronPython 2.7 Beta 1 DEBUG (2.7.0.10) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import os Traceback (most recent call last): File stdin, line 1, in module File C:\work\ironlang\Bin\Debug\Lib\os.py, line 398, in module File C:\work\ironlang\Bin\Debug\Lib\UserDict.py, line 84, in module File C:\work\ironlang\Bin\Debug\Lib\abc.py, line 109, in register File C:\work\ironlang\Bin\Debug\Lib\abc.py, line 151, in __subclasscheck__ File C:\work\ironlang\Bin\Debug\Lib\_weakrefset.py, line 69, in __contains__ TypeError: cannot create weak reference to 'classobj' object Daniel. On Fri, Jan 21, 2011 at 17:24, Dino Viehland di...@microsoft.com wrote: Daniel wrote: Pulled src from github. The devel set up instructions (http://ironpython.codeplex.com/wikipage?title=Respository%20Instructions) and all the script magic already in place is just great as things compile and run. Very cool. However, need help figuring some things out, please: 1. Neither the release, nor the debug deployment copies the standard module files into Lib. Is there magic in place for that already, like a project file that has the deployment paths spelled out? We have a copy of the std lib in External.LCA_RESTRICTED\Languages\IronPython\27\Lib. I generally just set IRONPYTHONPATH at that directory which is much better than copying it on every build. For releases the MSI builder will pick it up out External.LCA_RESTRICTED\Languages\CPython\27\Lib. The difference between those two directories is the tests - the IronPython dir has various changes to disable failing tests, occasionally adds some extra tests, etc... The 2 dirs are also useful for doing 3 way merges when updating the standard library. That way you know what the last version we pulled was. 2. There are two copies of modules sets. One in cPython/Lib, there other is in IronPython/27/Lib. The answer is probably obvious, but which set of modules do I need to copy? [conveniently answered above] 3. Before I found the bundled module collections, I tried modules from 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] and saw code in modules blowing up left and right. It's obvious that the modules collection in IronLanguages is stale, but i wonder how stale it is... Are they from 2.5/2.6 time? If the next IPY release is 2.7 do we need to go and update the modules bundled with 2.7? These are all from the 2.7 timeframe and should be from 2.7.0 at the very earliest. If you windiff the CPython lib dir w/ your 2.7.1 install Lib dir you should be able to see the differences. I'm surprised that things are blowing up - maybe there's some site packages breaking things in your install? ___ 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] Which modules collection to use?
Daniel wrote: Thx on the IRONPYTHONPATH hint. Regarding what blows up: copy'n'paste Lib folder from cPython 2.7.1 into /Debug/.., followed by bdc 6 Warning(s) 0 Error(s) Time Elapsed 00:00:37.34 C:\workipy IronPython 2.7 Beta 1 DEBUG (2.7.0.10) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import os Traceback (most recent call last): File stdin, line 1, in module File C:\work\ironlang\Bin\Debug\Lib\os.py, line 398, in module File C:\work\ironlang\Bin\Debug\Lib\UserDict.py, line 84, in module File C:\work\ironlang\Bin\Debug\Lib\abc.py, line 109, in register File C:\work\ironlang\Bin\Debug\Lib\abc.py, line 151, in __subclasscheck__ File C:\work\ironlang\Bin\Debug\Lib\_weakrefset.py, line 69, in __contains__ TypeError: cannot create weak reference to 'classobj' object This is a bug in IronPython, here's the simple repro: class C: pass import weakref weakref.ref(C) OldClass just needs to have an IWeakReferencable implementation added to it. Looks like this is new in 2.7.0 and I'm guessing something in 2.7.1 now depends upon it. Maybe there just wasn't a test case for it or we have it disabled in the IronPython dir. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com