From luismg at gmx.net Thu Mar 24 03:16:25 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Wed, 23 Mar 2005 23:16:25 -0300 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <080601c53017$81f0f340$1302a8c0@luis> Available to download here: http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742 I wonder why it hasn't been announced here... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at microsoft.com Thu Mar 24 03:44:40 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Wed, 23 Mar 2005 18:44:40 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> Thanks, Luis for announcing this while I was away at PyCon in DC today. Here's what might be an easier url for folks. http://workspaces.gotdotnet.com/ironpython All of the details for making this release came together just in time for my PyCon keynote this morning, and I have just gotten back from the conference and had a chance to send mail to this list. This is the release that I should have made about 2 months after IronPython 0.6 and joining MS. I'm sorry that it took so long and that I haven't been able to really participate in this list during all this time. The good news is that IronPython is back moving forward full steam ahead. Please come download the 0.7 release from the above URL and let us know how it works for you. Many of the bugs that you reported on this list should be already fixed and the site above has a nice bug tracking tool for you to tell us about any that we forgot. We're going to be driving hard now to the right IronPython 1.0. We'll be producing frequent releases to get there, but we need your help in providing the feedback to help us make the right decisions so that IronPython 1.0 will really address your needs. It would be great if people could join the online forum at the above url for discussing IronPython; however, I'm going to keep this mailing list open for a while for those who prefer it. Thanks - Jim ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Luis M. Gonzalez Sent: Wed 3/23/2005 6:16 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Ironpython 0.7 released! Available to download here: http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742 I wonder why it hasn't been announced here... From jvm_cop at spamcop.net Thu Mar 24 04:11:17 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Wed, 23 Mar 2005 22:11:17 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmon d.corp.microsoft.com> Message-ID: <4.3.2.7.2.20050323220911.044e8b20@mail.comcast.net> At 09:44 PM 3/23/2005, Jim Hugunin wrote (in part) >Thanks, Luis for announcing this while I was away at PyCon in DC today. Is the text (or PDF / PPT / AVI / MP3) of your PyCon keynote available? J. Merrill / Analytical Software Corp From terry at triplett.org Thu Mar 24 07:45:19 2005 From: terry at triplett.org (Terry L. Triplett) Date: Thu, 24 Mar 2005 01:45:19 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <200503240145.19166.terry@triplett.org> On Wednesday 23 March 2005 21:44, Jim Hugunin wrote: Congratulations, and thanks. This is a happy day. > Here's what might be an easier url for folks. > > http://workspaces.gotdotnet.com/ironpython Is this IronPython's new home, or will ironpython.com still be maintained in some way? I also noticed the license change from the CPL to the Shared Source license (which doesn't seem all that bad from a brief reading, but IANAL). Some discussion of this change beyond what was mentioned in the FAQ might be helpful in clarifying any wider implications this might have. (I apologize in advance for risking a licensing flamewar by bringing this up). I'd like to see IronPython continue to be distributable everywhere that CPython might be found that also happens to have a compliant CLR implementation. I'm thinking of *cough* Mono and *cough* Linux. Someday I'd like to able to issue an "emerge ironpython" or "apt-get ironpython" or "rpm -i ironpython" without invoking the wrath of the Redmond Gods or starting a Gnu stampede. There, I said it. --T From fredrik at pythonware.com Thu Mar 24 08:45:48 2005 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 24 Mar 2005 08:45:48 +0100 Subject: [IronPython] Re: Ironpython 0.7 released! References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <4.3.2.7.2.20050323220911.044e8b20@mail.comcast.net> Message-ID: "J. Merrill" wrote: >>Thanks, Luis for announcing this while I was away at PyCon in DC today. > > Is the text (or PDF / PPT / AVI / MP3) of your PyCon keynote available? summaries are available here: http://www.postneo.com/2005/03/23/keynote-ironpython http://tinyurl.com/6cnhd http://tinyurl.com/6r9vu (very brief) From dw-lists.ironpython.com at botanicus.net Thu Mar 24 11:57:12 2005 From: dw-lists.ironpython.com at botanicus.net (David Wilson) Date: Thu, 24 Mar 2005 10:57:12 +0000 Subject: [IronPython] Ironpython 0.7 released! [.NET 2 URL] In-Reply-To: <200503240145.19166.terry@triplett.org> References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <200503240145.19166.terry@triplett.org> Message-ID: <20050324105712.GA66885@thailand.botanicus.net> For anyone else having trouble finding the .NET 2.0 download: http://www.microsoft.com/downloads/details.aspx?FamilyID=B7ADC595-717C-4EF7-817B-BDEFD6947019&displaylang=en Happy hacking! David. -- ... do you think I'm going to waste my time trying to pin physical interpretations upon every optical illusion of our instruments? Since when is the evidence of our senses any match for the clear light of reason? -- Cutie, in Asimov's Reason From jeffg at ActiveState.com Thu Mar 24 19:04:30 2005 From: jeffg at ActiveState.com (jeff griffiths) Date: Thu, 24 Mar 2005 10:04:30 -0800 Subject: [IronPython] Ironpython 0.7 released! [mono?] In-Reply-To: <20050324105712.GA66885@thailand.botanicus.net> References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <200503240145.19166.terry@triplett.org> <20050324105712.GA66885@thailand.botanicus.net> Message-ID: <4243012E.3020809@activestate.com> David Wilson wrote: > For anyone else having trouble finding the .NET 2.0 download: > > http://www.microsoft.com/downloads/details.aspx?FamilyID=B7ADC595-717C-4EF7-817B-BDEFD6947019&displaylang=en Has anyone tried this with Mono, on OS X or Linux? Jim: are there slides available from your talk? cheers, JeffG > > Happy hacking! > > > David. > From david.ascher at gmail.com Thu Mar 24 19:37:39 2005 From: david.ascher at gmail.com (David Ascher) Date: Thu, 24 Mar 2005 13:37:39 -0500 Subject: [IronPython] Ironpython 0.7 released! [mono?] In-Reply-To: <4243012E.3020809@activestate.com> References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <200503240145.19166.terry@triplett.org> <20050324105712.GA66885@thailand.botanicus.net> <4243012E.3020809@activestate.com> Message-ID: On Thu, 24 Mar 2005 10:04:30 -0800, jeff griffiths wrote: > Has anyone tried this with Mono, on OS X or Linux? 0.7 requires .Net 2.0, which Mono isn't up to yet. From kfarmer at thuban.org Thu Mar 24 20:28:41 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 24 Mar 2005 11:28:41 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: And there was much rejoicing... From terry at triplett.org Thu Mar 24 21:50:05 2005 From: terry at triplett.org (Terry L. Triplett) Date: Thu, 24 Mar 2005 15:50:05 -0500 Subject: [IronPython] Ironpython 0.7 released! [mono?] In-Reply-To: References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <4243012E.3020809@activestate.com> Message-ID: <200503241550.05695.terry@triplett.org> > wrote: > > Has anyone tried this with Mono, on OS X or Linux? > > 0.7 requires .Net 2.0, which Mono isn't up to yet. Although not that far off. Today's 1.1.5 release includes the following statement: Summary of C# 2.0 features supported Today Mono 1.1.5's C# compiler supports anonymous methods, iterators, partial classes, static classes, covariance and contravariance, property accessor accessibility, fixed size buffers and inline warning control from the 2.0 specification. Generics, Nullable Types are supported as well on the branched `gmcs' compiler (included). Still missing for full 2.0 support: namespace alias qualifier, external assembly alias and friend assemblies. Having said that, the IronPythonConsole runs on my Gentoo Linux machine using yesterday's Mono subversion snapshot. I get the prompt, and can run *very* simple things (like a 2-liner that calculates and prints the golden ratio), but it chokes on just about everything else at the moment. From david.ascher at gmail.com Thu Mar 24 22:05:33 2005 From: david.ascher at gmail.com (David Ascher) Date: Thu, 24 Mar 2005 16:05:33 -0500 Subject: [IronPython] Ironpython 0.7 released! [mono?] In-Reply-To: <200503241550.05695.terry@triplett.org> References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <4243012E.3020809@activestate.com> <200503241550.05695.terry@triplett.org> Message-ID: On Thu, 24 Mar 2005 15:50:05 -0500, Terry L. Triplett wrote: > > wrote: > > > Has anyone tried this with Mono, on OS X or Linux? > > > > 0.7 requires .Net 2.0, which Mono isn't up to yet. > > Although not that far off. Today's 1.1.5 release includes the following > statement: I should correct my earlier statement. Apparently, as you're pointing out, Mono may very well be able to run it. I think I oversimplified what Jim said at the talk. --david From jimhug at microsoft.com Fri Mar 25 03:53:32 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Thu, 24 Mar 2005 18:53:32 -0800 Subject: [IronPython] Ironpython 0.7 released! [mono?] Message-ID: <695D7C410F74A644B5335E47FB73E17E03794931@RED-MSG-52.redmond.corp.microsoft.com> jeff griffiths wrote: > Jim: are there slides available from your talk? I don't have those up anywhere yet. I'd like to add screencasts of the demos to go along with them as the demos are a key piece of the talk. I'll look into getting this up as soon as I get back from DC. Thanks - Jim From jimhug at microsoft.com Fri Mar 25 03:59:31 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Thu, 24 Mar 2005 18:59:31 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> Hi Miguel, Are there any problems that you have with the terms of the IronPython license, or is it just the lack of the OSI stamp? I think the terms of the license are both clear and quite open. If it's just a matter of the OSI stamp, I'm not going to be much help there. You should give this feedback to Jason Matusow, the director of Shared Source at Microsoft. Jason has a fairly new blog here http://blogs.msdn.com/jasonmatusow/. Jason talks a lot on his blog about the notion of "open" as well as about the extremely wide range of different projects that are released under the Shared Source umbrella. IronPython is going to be run as a very transparent and interactive project. I expect to have lots of active discussions with our user community about different features and about what they're trying to do with IronPython. I've been having a great time doing that f2f with people at PyCon and when I get back from DC I'll want to continue this process online. In our first day of release we've already had 6 bugs filed in the bug database and 5 of them are now marked fixed. To really close this loop we also need to make very frequent releases - at a minimum every 2 weeks and ideally more often. That said, we're not going to be accepting any external code contributions to the core engine at this time. One reason not to do this is that we want to be careful with the IronPython code to keep the IP very clean so that it can be comfortably used both by small projects as well as by large commercial projects. There would be a lot of legal work for me to get the right sort of contribution process setup to do this carefully enough to make all the lawyers happy here. I think my time could be better spent driving the implementation of IronPython and working with the user community to come up with the best set of features to solve their problems. The best way to contribute to IronPython today is by submitting simple easy to reproduce bug reports and well thought out and clearly explained feature requests. Thanks to those of you who've already done that. Given the early and rapidly changing state of IronPython, as a developer I'd much rather have a clear test case than a patch file for almost any bug because I can usually develop the fix myself faster than I can understand and validate an externally submitted patch. Often bugs will be in areas under rapid development and the right fix requires understanding not just the code where it is, but the model in my head of where the code should be going. Based on my experience with both AspectJ and Jython I'm rather confident that at this stage of the project external code contributions would slow things down rather than speeding them up. BTW - I'm also confident that the higher quality and easier to reproduce bug reports we can get from the community the faster we'll be able to get to a solid 1.0. Another place that people should be able to contribute is with building some of the C-based Python extension modules for IronPython. I don't think that we're quite ready for that kind of help just yet, but in a month or so I'd like to reopen a discussion about how we could structure that project so that it would work for both the core IronPython developers and for others in the community who would like to contribute. I believe that the best software projects are those with a central architect/benevolent dictator who can drive a consistent vision for the overall design and implementation of a system. The only weakness of this system is that you have to trust that this dictator will remain both actively working on the project and benevolent. I could write a lot of text asking you to trust me that this project will be run that way; however, I prefer to convince people by actions rather than words. I personally believe that the single best thing about a BSD-style license is that it provides the community with the ultimate check on the project leadership. If their concerns and needs aren't being addressed then the community can fork the code base and go their own way. Forks are a terrible thing for projects and happen pretty rarely. Forks are also expensive for the community because they now have the whole code base to grow and maintain. Good projects should always be responsive to their community of users, and the ability to fork is one way to make sure this happens. Thanks - Jim Miguel de Icaza wrote: > Hello, > > Congratulations on the release of IronPython 0.7, it was a long > awaited improvement. There are many outstanding questions on my part. > > It is a bit of a shame that the license is stamped as "Shared > Source" because there are so many licenses labeled as "Shared Source" > that this will introduce questions that are not necessary. > > It would also be nice if this was submitted to OSI for approval, to > get a rubber stamp from them in terms of whether IronPython 0.7 will be > possible to redistribute in the future on open source operating > systems. > > What will be the process to contribute to IronPython? Patches to > get IronPython working out of the box on Mono used to be on this list, > but they do not seem to be integrated (understandably, it has been a > long time), but what will be the policy now that IronPython is > copyrighted by Microsoft? > > Is this a Microsoft project, that happens to have its source code > published, or is this is an open source project that happens to be lead > and funded by Microsoft? > > Miguel. From lupus at ximian.com Fri Mar 25 16:03:47 2005 From: lupus at ximian.com (Paolo Molaro) Date: Fri, 25 Mar 2005 16:03:47 +0100 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <20050325150347.GR14394@debian.org> On 03/24/05 Jim Hugunin wrote: > Are there any problems that you have with the terms of the IronPython > license, or is it just the lack of the OSI stamp? I think the terms of I think it is unfortunate to call the license "Shared Source License for IronPython". Everyone (and with good reason) considers any "Shared Source" labelled license a crappy^Wnon free license like Rotor's. Releasing such different licenses under the same name is misleading and will do only damage to the IronPython project. > the license are both clear and quite open. If it's just a matter of the > OSI stamp, I'm not going to be much help there. You should give this The license looks like a free software license at first sight, though more people should look at it and give legal advice, of course. I think point 2 should be clarified: 2. That if you distribute the Software in source code form you do so only under this license (i.e. you must include a complete copy of this license with your distribution), and if you distribute the Software solely in object form you only do so under a license that complies with this license. It seems to mean that modified sources must be dirstributed only with this license and not any license that complies with it, while the binary can be distributed with a compatible license. It's fine (though likely redundant) to require that the license should not be changed and included in the sources. It should just make it clear that distributing modified sources with a compatible license for the changes is ok. > IronPython is going to be run as a very transparent and interactive > project. I expect to have lots of active discussions with our user I suggest you use this mailing list as the primary communication channel (besides being very slow, the gotdotnet forum requires .NET passport). > process online. In our first day of release we've already had 6 bugs > filed in the bug database and 5 of them are now marked fixed. To really It's unfortunate the bug tracker requires .NET passport (even to only view the filed bugreports). > close this loop we also need to make very frequent releases - at a > minimum every 2 weeks and ideally more often. My suggestion is to have a publicly accessible cvs or svn server as well, so people can test the changes in a more timely manner (and reduce your "make a release" pressure which is going to take away from your hacking time). > That said, we're not going to be accepting any external code > contributions to the core engine at this time. One reason not to do Well, this doesn't sound like good news. People are earger to contribute (and part of a benevolent dictator's job is to make others work for him;-). > where the code should be going. Based on my experience with both > AspectJ and Jython I'm rather confident that at this stage of the > project external code contributions would slow things down rather than Well, you're not forced to apply all the patches that are contributed:-) > overall design and implementation of a system. The only weakness of > this system is that you have to trust that this dictator will remain > both actively working on the project and benevolent. I could write a > lot of text asking you to trust me that this project will be run that > way; however, I prefer to convince people by actions rather than words. We're certainly interested in IronPython be a good project for everyone, you, the MS and Mono programmer communities, the python users. I hope this time your work at MS will allow you to communicate with the community more and better than what happened since the 0.6 release. > base to grow and maintain. Good projects should always be responsive to > their community of users, and the ability to fork is one way to make > sure this happens. Indeed, Everyone hopes that won't happen, but it's good to have the choice. Happy hacking! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jvm_cop at spamcop.net Fri Mar 25 17:33:21 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Fri, 25 Mar 2005 11:33:21 -0500 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <4.3.2.7.2.20050325113048.061e29d0@mail.comcast.net> (Sorry if you get this twice, Jim. Perhaps you should change the list setup so that "reply-to" is to the list, not just to the sender of the message.) At 09:59 PM 3/24/2005, Jim Hugunin wrote (in part) >Are there any problems that you have with the terms of the IronPython >license, or is it just the lack of the OSI stamp? I think the terms of >the license are both clear and quite open. Here's a sentence from the FAQ concerning patents: [quote] This license grants you a patent license to use and distribute the Software under any Microsoft patent claims that read on the Software itself. [end quote]. I had never before seen the phase "that read on" in my native language (English), but it appears multiple times in the license, and in a relatively small number of other discussions of licensing I've found on the net -- google for "patents that read on" OR "patent claims that read on" Can someone explain what it means, in English that non-lawyers might understand? (I also posted this question as feedback on Jason Matusow's blog.) J. Merrill / Analytical Software Corp From joe at notcharles.ca Fri Mar 25 18:43:01 2005 From: joe at notcharles.ca (Joe Mason) Date: Fri, 25 Mar 2005 12:43:01 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <20050325150347.GR14394@debian.org> References: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> <20050325150347.GR14394@debian.org> Message-ID: <20050325174301.GA2547@notcharles.ca> On Fri, Mar 25, 2005 at 04:03:47PM +0100, Paolo Molaro wrote: > On 03/24/05 Jim Hugunin wrote: > > Are there any problems that you have with the terms of the IronPython > > license, or is it just the lack of the OSI stamp? I think the terms of > > the license are both clear and quite open. If it's just a matter of the > > OSI stamp, I'm not going to be much help there. You should give this > > The license looks like a free software license at first sight, though > more people should look at it and give legal advice, of course. I think > point 2 should be clarified: That's the main problem - there are already a ton of Open Source licenses that have been scrutinized, including ones with the patent clause and similar. What is it that you're trying to do that isn't covered by one of these? Using an existing license (OSI certified or not) saves confusion because people don't have to waste as much time scrutinizing your license before they can jump in and start contributings, if they recognize it they'll already know what the ramifications are. Joe From mahs at telcopartners.com Fri Mar 25 22:43:45 2005 From: mahs at telcopartners.com (Michael Spencer) Date: Fri, 25 Mar 2005 13:43:45 -0800 Subject: [IronPython] Test Module for IronPython 0.7 Message-ID: FePyers: Here is freestanding test module for built-ins, shamelessly appropriated from pypy Since FePy0.7 lacks assert at this point, its hard to test even the builtins So, asserts are replaced with if test: pass else: raise AssertionError (this process used automatic code-generation via the AST- no guarantees of correctness) raises function is provided in the module 2.4 features are commented out tests is a dict of test functions since introspection of cls dicts doesn't yet work call with testall() ...try to make sense of the output and file bugs as appropriate at http://www.gotdotnet.com/workspaces/bugtracker/home.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742 Enjoy Michael """Hacked version of pypy/module/test/test_builtin.py that has no dependencies and does not use assert, which is not implemented on FePy 0.7""" class AppTestBuiltinApp: def test_import(self): m = __import__('pprint') if (m.pformat({ }) == '{}'): pass else: raise AssertionError if (m.__name__ == 'pprint'): pass else: raise AssertionError raises(ImportError, __import__, 'spamspam') raises(TypeError, __import__, 1, 2, 3, 4) def test_chr(self): if (chr(65) == 'A'): pass else: raise AssertionError raises(ValueError, chr, -1) raises(TypeError, chr, 'a') def test_intern(self): raises(TypeError, intern) raises(TypeError, intern, 1) s = 'never interned before' s2 = intern(s) if (s == s2): pass else: raise AssertionError s3 = s.swapcase() if (s3 != s2): pass else: raise AssertionError s4 = s3.swapcase() if (intern(s4) is s2): pass else: raise AssertionError def test_globals(self): d = {'foo' : 'bar' } exec 'def f(): return globals()' in d d2 = d['f']() if (d2 is d): pass else: raise AssertionError def test_locals(self): def f(): return locals() def g(c=0, b=0, a=0): return locals() if (f() == { }): pass else: raise AssertionError if (g() == {'a' : 0, 'b' : 0, 'c' : 0 }): pass else: raise AssertionError def test_dir(self): def f(): return dir() def g(c=0, b=0, a=0): return dir() def nosp(x): return [y for y in x] if (f() == [ ]): pass else: raise AssertionError if (g() == ['a','b','c', ]): pass else: raise AssertionError class X: pass if (nosp(dir(X)) == [ ]): pass else: raise AssertionError class X: a = 23 c = 45 b = 67 if (nosp(dir(X)) == ['a','b','c', ]): pass else: raise AssertionError def test_vars(self): def f(): return vars() def g(c=0, b=0, a=0): return vars() if (f() == { }): pass else: raise AssertionError if (g() == {'a' : 0, 'b' : 0, 'c' : 0 }): pass else: raise AssertionError def test_getattr(self): class a: i = 5 if (getattr(a, 'i') == 5): pass else: raise AssertionError raises(AttributeError, getattr, a, 'k') if (getattr(a, 'k', 42) == 42): pass else: raise AssertionError if (getattr(a, u'i') == 5): pass else: raise AssertionError raises(AttributeError, getattr, a, u'k') if (getattr(a, u'k', 42) == 42): pass else: raise AssertionError def test_sum(self): if (sum([ ]) == 0): pass else: raise AssertionError if (sum([42, ]) == 42): pass else: raise AssertionError if (sum([1,2,3, ]) == 6): pass else: raise AssertionError if (sum([ ], 5) == 5): pass else: raise AssertionError if (sum([1,2,3, ], 4) == 10): pass else: raise AssertionError def test_type_selftest(self): if (type(type) is type): pass else: raise AssertionError def test_iter_sequence(self): raises(TypeError, iter, 3) x = iter(['a','b','c', ]) if (x.next() == 'a'): pass else: raise AssertionError if (x.next() == 'b'): pass else: raise AssertionError if (x.next() == 'c'): pass else: raise AssertionError raises(StopIteration, x.next) def test_iter___iter__(self): mydict = {'a' : 1, 'b' : 2, 'c' : 3 } if (list(iter(mydict)) == mydict.keys()): pass else: raise AssertionError def test_iter_callable_sentinel(self): class count (object): def __init__(self): self.value = 0 def __call__(self): self.value += 1 return self.value x = iter(count(), 3) if (x.next() == 1): pass else: raise AssertionError if (x.next() == 2): pass else: raise AssertionError raises(StopIteration, x.next) def test_enumerate(self): seq = range(2, 4) enum = enumerate(seq) if (enum.next() == (0, 2)): pass else: raise AssertionError if (enum.next() == (1, 3)): pass else: raise AssertionError raises(StopIteration, enum.next) raises(TypeError, enumerate, 1) raises(TypeError, enumerate, None) def test_xrange_args(self): raises(ValueError, xrange, 0, 1, 0) def test_xrange_up(self): x = xrange(2) iter_x = iter(x) if (iter_x.next() == 0): pass else: raise AssertionError if (iter_x.next() == 1): pass else: raise AssertionError raises(StopIteration, iter_x.next) def test_xrange_down(self): x = xrange(4, 2, -1) iter_x = iter(x) if (iter_x.next() == 4): pass else: raise AssertionError if (iter_x.next() == 3): pass else: raise AssertionError raises(StopIteration, iter_x.next) def test_xrange_has_type_identity(self): if (type(xrange(1)) == type(xrange(1))): pass else: raise AssertionError def test_xrange_len(self): x = xrange(33) if (len(x) == 33): pass else: raise AssertionError x = xrange(33.200000000000003) if (len(x) == 33): pass else: raise AssertionError x = xrange(33, 0, -1) if (len(x) == 33): pass else: raise AssertionError x = xrange(33, 0) if (len(x) == 0): pass else: raise AssertionError x = xrange(33, 0.20000000000000001) if (len(x) == 0): pass else: raise AssertionError x = xrange(0, 33) if (len(x) == 33): pass else: raise AssertionError x = xrange(0, 33, -1) if (len(x) == 0): pass else: raise AssertionError x = xrange(0, 33, 2) if (len(x) == 17): pass else: raise AssertionError x = xrange(0, 32, 2) if (len(x) == 16): pass else: raise AssertionError def test_xrange_indexing(self): x = xrange(0, 33, 2) if (x[7] == 14): pass else: raise AssertionError if (x[-7] == 20): pass else: raise AssertionError raises(IndexError, x.__getitem__, 17) raises(IndexError, x.__getitem__, -18) raises(TypeError, x.__getitem__, slice(0, 3, 1)) def test_xrange_bad_args(self): raises(TypeError, xrange, '1') raises(TypeError, xrange, None) raises(TypeError, xrange, (3 + 2j)) raises(TypeError, xrange, 1, '1') raises(TypeError, xrange, 1, (3 + 2j)) raises(TypeError, xrange, 1, 2, '1') raises(TypeError, xrange, 1, 2, (3 + 2j)) ## def test_sorted(self): ## l = [ ] ## sorted_l = sorted(l) ## if (sorted_l is not l): ## pass ## else: ## raise AssertionError ## if (sorted_l == l): ## pass ## else: ## raise AssertionError ## l = [1,5,2,3, ] ## sorted_l = sorted(l) ## if (sorted_l == [1,2,3,5, ]): ## pass ## else: ## raise AssertionError ## ## def test_sorted_with_keywords(self): ## l = ['a','C','b', ] ## sorted_l = sorted(l, reverse=True) ## if (sorted_l is not l): ## pass ## else: ## raise AssertionError ## if (sorted_l == ['b','a','C', ]): ## pass ## else: ## raise AssertionError ## sorted_l = sorted(l, reverse=True, key=lambda x: x.lower()) ## if (sorted_l is not l): ## pass ## else: ## raise AssertionError ## if (sorted_l == ['C','b','a', ]): ## pass ## else: ## raise AssertionError ## def test_reversed_simple_sequences(self): ## l = range(5) ## rev = reversed(l) ## if (list(rev) == [4,3,2,1,0, ]): ## pass ## else: ## raise AssertionError ## if (list(l.__reversed__()) == [4,3,2,1,0, ]): ## pass ## else: ## raise AssertionError ## s = 'abcd' ## if (list(reversed(s)) == ['d','c','b','a', ]): ## pass ## else: ## raise AssertionError ## def test_reversed_custom_objects(self): ## ## class SomeClass: ## ## ## def __reversed__(self): ## return 42 ## obj = SomeClass() ## if (reversed(obj) == 42): ## pass ## else: ## raise AssertionError def test_cmp(self): if (cmp(9, 9) == 0): pass else: raise AssertionError if (cmp(0, 9) < 0): pass else: raise AssertionError if (cmp(9, 0) > 0): pass else: raise AssertionError def test_cmp_more(self): class C: def __eq__(self, other): return True def __cmp__(self, other): raise RuntimeError c1 = C() c2 = C() raises(RuntimeError, cmp, c1, c2) def test_cmp_cyclic(self): a = [ ] a.append(a) b = [ ] b.append(b) from UserList import UserList c = UserList() c.append(c) if (cmp(a, b) == 0): pass else: raise AssertionError if (cmp(b, c) == 0): pass else: raise AssertionError if (cmp(c, a) == 0): pass else: raise AssertionError if (cmp(a, c) == 0): pass else: raise AssertionError a.pop() b.pop() c.pop() def test_coerce(self): if (coerce(1, 2) == (1, 2)): pass else: raise AssertionError if (coerce(1L, 2L) == (1L, 2L)): pass else: raise AssertionError if (coerce(1, 2L) == (1L, 2L)): pass else: raise AssertionError if (coerce(1L, 2) == (1L, 2L)): pass else: raise AssertionError if (coerce(1, 2.0) == (1.0, 2.0)): pass else: raise AssertionError if (coerce(1.0, 2L) == (1.0, 2.0)): pass else: raise AssertionError if (coerce(1L, 2.0) == (1.0, 2.0)): pass else: raise AssertionError raises(TypeError, coerce, 1, 'a') raises(TypeError, coerce, u'a', 'a') def test_return_None(self): class X: pass x = X() if (setattr(x, 'x', 11) == None): pass else: raise AssertionError if (delattr(x, 'x') == None): pass else: raise AssertionError def test_divmod(self): if (divmod(15, 10) == (1, 5)): pass else: raise AssertionError def test_callable(self): class Call: def __call__(self, a): return (a + 2) if not not callable(Call()): pass else: raise AssertionError if callable(int): pass else: raise AssertionError def test_uncallable(self): class NoCall (object): pass a = NoCall() if not callable(a): pass else: raise AssertionError a.__call__ = lambda : 'foo' if not callable(a): pass else: raise AssertionError def test_hash(self): if (hash(23) == hash(23)): pass else: raise AssertionError if (hash(2.2999999999999998) == hash(2.2999999999999998)): pass else: raise AssertionError if (hash('23') == hash('23')): pass else: raise AssertionError if (hash((23,)) == hash((23,))): pass else: raise AssertionError if (hash(22) != hash(23)): pass else: raise AssertionError raises(TypeError, hash, [ ]) raises(TypeError, hash, { }) def test_eval(self): if (eval('1+2') == 3): pass else: raise AssertionError if (eval(' \t1+2\n') == 3): pass else: raise AssertionError def test_compile(self): co = compile('1+2', '?', 'eval') if (eval(co) == 3): pass else: raise AssertionError raises(SyntaxError, compile, '-', '?', 'eval') raises(ValueError, compile, '"\\xt"', '?', 'eval') raises(ValueError, compile, '1+2', '?', 'maybenot') raises(TypeError, compile, '1+2', 12, 34) def test_isinstance(self): if isinstance(5, int): pass else: raise AssertionError if isinstance(5, object): pass else: raise AssertionError if not isinstance(5, float): pass else: raise AssertionError if isinstance(True, (int, float)): pass else: raise AssertionError if not isinstance(True, (type, float)): pass else: raise AssertionError if isinstance(True, ((type, float), bool)): pass else: raise AssertionError raises(TypeError, isinstance, 5, 6) raises(TypeError, isinstance, 5, (float, 6)) def test_issubclass(self): if issubclass(int, int): pass else: raise AssertionError if issubclass(int, object): pass else: raise AssertionError if not issubclass(int, float): pass else: raise AssertionError if issubclass(bool, (int, float)): pass else: raise AssertionError if not issubclass(bool, (type, float)): pass else: raise AssertionError if issubclass(bool, ((type, float), bool)): pass else: raise AssertionError raises(TypeError, issubclass, 5, int) raises(TypeError, issubclass, int, 6) raises(TypeError, issubclass, int, (float, 6)) def test_staticmethod(self): class X: def f(*args, **kwds): return (args, kwds) f = staticmethod(f) if (X.f() == ((), { })): pass else: raise AssertionError if (X.f(42, x=43) == ((42,), {'x' : 43 })): pass else: raise AssertionError if (X().f() == ((), { })): pass else: raise AssertionError if (X().f(42, x=43) == ((42,), {'x' : 43 })): pass else: raise AssertionError def test_classmethod(self): class X: def f(*args, **kwds): return (args, kwds) f = classmethod(f) class Y (X): pass if (X.f() == ((X,), { })): pass else: raise AssertionError if (X.f(42, x=43) == ((X, 42), {'x' : 43 })): pass else: raise AssertionError if (X().f() == ((X,), { })): pass else: raise AssertionError if (X().f(42, x=43) == ((X, 42), {'x' : 43 })): pass else: raise AssertionError if (Y.f() == ((Y,), { })): pass else: raise AssertionError if (Y.f(42, x=43) == ((Y, 42), {'x' : 43 })): pass else: raise AssertionError if (Y().f() == ((Y,), { })): pass else: raise AssertionError if (Y().f(42, x=43) == ((Y, 42), {'x' : 43 })): pass else: raise AssertionError tests = {AppTestBuiltinApp: [ 'test_xrange_indexing', 'test_issubclass', 'test_getattr', 'test_locals', 'test_chr', 'test_hash', 'test_xrange_args', 'test_type_selftest', 'test_xrange_len', 'test_uncallable', 'test_return_None', 'test_divmod', 'test_xrange_down', 'test_iter_sequence', 'test_globals', 'test_compile', 'test_isinstance', 'test_vars', 'test_cmp_more', 'test_sum', 'test_intern', 'test_iter___iter__', 'test_eval', 'test_cmp', 'test_coerce', 'test_iter_callable_sentinel', 'test_import', 'test_xrange_bad_args', 'test_xrange_up', 'test_dir', 'test_cmp_cyclic', 'test_staticmethod', 'test_classmethod', 'test_xrange_has_type_identity', 'test_enumerate', 'test_callable']} def raises(exc, callable, *args): try: callable(*args) except exc: return raise AssertionError def testall(): for cls in tests: inst = cls() for attr in tests[cls]: func = getattr(inst, attr) try: func() except AssertionError: print "Failed Assertion: %s.%s" % (cls.__name__,attr) except Exception, err: print err From ianm at ActiveState.com Sat Mar 26 03:38:39 2005 From: ianm at ActiveState.com (Ian MacLean) Date: Sat, 26 Mar 2005 11:38:39 +0900 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <20050325150347.GR14394@debian.org> References: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> <20050325150347.GR14394@debian.org> Message-ID: <4244CB2F.30409@activestate.com> Paolo Molaro wrote: >On 03/24/05 Jim Hugunin wrote: > > > >>IronPython is going to be run as a very transparent and interactive >>project. I expect to have lots of active discussions with our user >> >> > >I suggest you use this mailing list as the primary communication channel >(besides being very slow, the gotdotnet forum requires .NET passport). > > > >>process online. In our first day of release we've already had 6 bugs >>filed in the bug database and 5 of them are now marked fixed. To really >> >> > >It's unfortunate the bug tracker requires .NET passport (even to only >view the filed bugreports). > > +1 on both of these. No offence but gotdotnet is a fairly crappy collaborative dev environment. Mailing lists have the advantage of being a push medium - ie we don't have to go and check the forum every time somthing is updated. Its curious that after the Wix and wtl projects decided to use sourceforge IronPython is going to gotdotnet. Understandably MS has an interest in promoting gotdotnet. It would be nice if it were made a bit more usable first. Ian From sriramk at gmail.com Sun Mar 27 11:13:15 2005 From: sriramk at gmail.com (Sriram Krishnan) Date: Sun, 27 Mar 2005 14:43:15 +0530 Subject: [IronPython] Object ids and hash code Message-ID: <42467933.395e1ed0.5f10.6490@mx.gmail.com> I saw that IronPython 0.7 uses System.Runtime.CompilerServices.RuntimeHelpers to get the hash code of an object (thereby removing the need for the Reflection.Emit/util dll hack in 0.6). However, if I remember correctly, .NET hash codes are *not* guaranteed to be unique. Brad Abrams talks about it here http://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx. Doesn't this open up problems when 2 objects have the same id? Thanks, Sriram From ryan4096 at bellsouth.net Mon Mar 28 06:55:39 2005 From: ryan4096 at bellsouth.net (Ryan Williams) Date: Sun, 27 Mar 2005 23:55:39 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E03794938@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <1111985739.22403.7.camel@localhost.localdomain> This sounds a little shady to me, and not altogether "benevolent". Why the licensing change? I think that it would probably work out better if ironpython remained open source... Why switch to gotdotnet? Personally, I'd prefer a mailing list (like this one), and a public cvs/svn server someplace. You mention not accepting external contributions, "to make all the lawyers happy here"...does this mean that ironpython is now a microsoft thing? On Thu, 2005-03-24 at 18:59 -0800, Jim Hugunin wrote: > Hi Miguel, > > Are there any problems that you have with the terms of the IronPython > license, or is it just the lack of the OSI stamp? I think the terms of > the license are both clear and quite open. If it's just a matter of the > OSI stamp, I'm not going to be much help there. You should give this > feedback to Jason Matusow, the director of Shared Source at Microsoft. > Jason has a fairly new blog here http://blogs.msdn.com/jasonmatusow/. > Jason talks a lot on his blog about the notion of "open" as well as > about the extremely wide range of different projects that are released > under the Shared Source umbrella. > > IronPython is going to be run as a very transparent and interactive > project. I expect to have lots of active discussions with our user > community about different features and about what they're trying to do > with IronPython. I've been having a great time doing that f2f with > people at PyCon and when I get back from DC I'll want to continue this > process online. In our first day of release we've already had 6 bugs > filed in the bug database and 5 of them are now marked fixed. To really > close this loop we also need to make very frequent releases - at a > minimum every 2 weeks and ideally more often. > > That said, we're not going to be accepting any external code > contributions to the core engine at this time. One reason not to do > this is that we want to be careful with the IronPython code to keep the > IP very clean so that it can be comfortably used both by small projects > as well as by large commercial projects. There would be a lot of legal > work for me to get the right sort of contribution process setup to do > this carefully enough to make all the lawyers happy here. I think my > time could be better spent driving the implementation of IronPython and > working with the user community to come up with the best set of features > to solve their problems. > > The best way to contribute to IronPython today is by submitting simple > easy to reproduce bug reports and well thought out and clearly explained > feature requests. Thanks to those of you who've already done that. > Given the early and rapidly changing state of IronPython, as a developer > I'd much rather have a clear test case than a patch file for almost any > bug because I can usually develop the fix myself faster than I can > understand and validate an externally submitted patch. Often bugs will > be in areas under rapid development and the right fix requires > understanding not just the code where it is, but the model in my head of > where the code should be going. Based on my experience with both > AspectJ and Jython I'm rather confident that at this stage of the > project external code contributions would slow things down rather than > speeding them up. BTW - I'm also confident that the higher quality and > easier to reproduce bug reports we can get from the community the faster > we'll be able to get to a solid 1.0. > > Another place that people should be able to contribute is with building > some of the C-based Python extension modules for IronPython. I don't > think that we're quite ready for that kind of help just yet, but in a > month or so I'd like to reopen a discussion about how we could structure > that project so that it would work for both the core IronPython > developers and for others in the community who would like to contribute. > > I believe that the best software projects are those with a central > architect/benevolent dictator who can drive a consistent vision for the > overall design and implementation of a system. The only weakness of > this system is that you have to trust that this dictator will remain > both actively working on the project and benevolent. I could write a > lot of text asking you to trust me that this project will be run that > way; however, I prefer to convince people by actions rather than words. > > I personally believe that the single best thing about a BSD-style > license is that it provides the community with the ultimate check on the > project leadership. If their concerns and needs aren't being addressed > then the community can fork the code base and go their own way. Forks > are a terrible thing for projects and happen pretty rarely. Forks are > also expensive for the community because they now have the whole code > base to grow and maintain. Good projects should always be responsive to > their community of users, and the ability to fork is one way to make > sure this happens. > > Thanks - Jim > > Miguel de Icaza wrote: > > Hello, > > > > Congratulations on the release of IronPython 0.7, it was a long > > awaited improvement. There are many outstanding questions on my > part. > > > > It is a bit of a shame that the license is stamped as "Shared > > Source" because there are so many licenses labeled as "Shared Source" > > that this will introduce questions that are not necessary. > > > > It would also be nice if this was submitted to OSI for approval, > to > > get a rubber stamp from them in terms of whether IronPython 0.7 will > be > > possible to redistribute in the future on open source operating > > systems. > > > > What will be the process to contribute to IronPython? Patches to > > get IronPython working out of the box on Mono used to be on this list, > > but they do not seem to be integrated (understandably, it has been a > > long time), but what will be the policy now that IronPython is > > copyrighted by Microsoft? > > > > Is this a Microsoft project, that happens to have its source code > > published, or is this is an open source project that happens to be > lead > > and funded by Microsoft? > > > > Miguel. > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jimhug at microsoft.com Mon Mar 28 18:35:35 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Mon, 28 Mar 2005 08:35:35 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> Ian MacLean wrote: > Paolo Molaro wrote: > >On 03/24/05 Jim Hugunin wrote: > >>IronPython is going to be run as a very transparent and interactive > >>project. I expect to have lots of active discussions with our user > >I suggest you use this mailing list as the primary communication channel > >(besides being very slow, the gotdotnet forum requires .NET passport). > > > >>process online. In our first day of release we've already had 6 bugs > >>filed in the bug database and 5 of them are now marked fixed. To really > >It's unfortunate the bug tracker requires .NET passport (even to only > >view the filed bugreports). > > > +1 on both of these. No offence but gotdotnet is a fairly crappy > collaborative dev environment. Mailing lists have the advantage of being > a push medium - ie we don't have to go and check the forum every time > somthing is updated. I'm in complete agreement that we've got work to do on the IronPython community site. This feedback is great. I've had my first experiences using the forums this last week, and I'm not particularly excited about them either. One thing that we're investigating is NNTP access to the gotdotnet forums. If we can get this setup I hope that people will give that a try and see how that works for them. We're going to keep looking at those kinds of options to make the gotdotnet site work better for people. However, so long as you find this mailing list to be the best way to discuss IronPython then it won't be going away. I agree that the bug database could also use some improvement, but it would be great if we could figure out how to make the current version work for people today. Some people will see needing a .NET passport as a hurdle to filing bug reports and any hurdles we add here are a mistake. Nevertheless, have you tried to get a .NET passport? It's a fairly simple process and it should work on any OS. While this is a little cumbersome, I don't think that it's much different from most bug trackers that will require a valid email address before accepting bug reports. Do you have a technical reason that you don't want to/can't get a passport to file bugs? Thanks - Jim From jvm_cop at spamcop.net Mon Mar 28 23:24:37 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 28 Mar 2005 16:24:37 -0500 Subject: [IronPython] Passport (was: Ironpython 0.7 released!) In-Reply-To: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmon d.corp.microsoft.com> Message-ID: <4.3.2.7.2.20050328161418.0525fa18@mail.comcast.net> At 11:35 AM 3/28/2005, Jim Hugunin wrote (in part) >Do you have a technical reason that you don't want to/can't get a passport to file bugs? My impression is that Passport behavior when you want to have more than one of them is a problem, because -- in order to avoid having you constantly enter Passport info -- various things try to pass your Passport identity invisibly to other things. I have a Passport to identify myself to the MSDN site; I would not have one otherwise. I would want to have a different Passport for other things (like using GDN), and it's hard to make that happen reliably because one can be "signed in" with a particular Passport without knowing it, and without having an obvious way to "sign off". That's not horrible, in this case, but it is annoying. The people who think that we all want to have a single "identity" on the net and do everything "as" that identity are not considering the privacy implications of having everything you do be associated with a single identity. I certainly want to have at least two identities -- work and personal -- and actually want to have numerous ones in each of those contexts. P.S. Jim, please consider changing the behavior of the list so the default Reply-To: is the list and not the sender of the message to which you're replying. You almost were the only recipient of this message! J. Merrill / Analytical Software Corp From nbastin at opnet.com Mon Mar 28 23:40:29 2005 From: nbastin at opnet.com (Nicholas Bastin) Date: Mon, 28 Mar 2005 16:40:29 -0500 Subject: [IronPython] Passport (was: Ironpython 0.7 released!) In-Reply-To: <4.3.2.7.2.20050328161418.0525fa18@mail.comcast.net> References: <4.3.2.7.2.20050328161418.0525fa18@mail.comcast.net> Message-ID: <4f9b3874d6b185e0ba82a59e4a15b2aa@opnet.com> On Mar 28, 2005, at 4:24 PM, J. Merrill wrote: > At 11:35 AM 3/28/2005, Jim Hugunin wrote (in part) >> Do you have a technical reason that you don't want to/can't get a >> passport to file bugs? > > My impression is that Passport behavior when you want to have more > than one of them is a problem, because -- in order to avoid having you > constantly enter Passport info -- various things try to pass your > Passport identity invisibly to other things. This is most of my problem with Passport. If I get a passport login, and some site like GDN needs more than just login and email from me, I have to enter this information. This is fine, because I want to access GDN. However, now any other passport site can access this information from me if I accidentally go there, regardless of whether I really wanted to log into their site or not. I like to make a choice of what sites I give my personal info to, and signing up to Passport gives my personal information to an unbounded number of sites, over which I have no control. When I create a login for sourceforge, for example, I know that only sourceforge has that information (assuming they're not lying to me about what they do with the data, but I have to have a certain level of trust here), and that accessing another site won't result in my personal data being transferred automatically. -- Nick From count-ironpython at flatline.de Tue Mar 29 00:01:02 2005 From: count-ironpython at flatline.de (Andreas Kotes) Date: Tue, 29 Mar 2005 00:01:02 +0200 Subject: [IronPython] Licence regrets Message-ID: <20050328220101.GR25172@aleph.priv.flatline.de> Hi Jim! I'm sorry, but I have to say this: I deeply regret the licence decision. Instead of adapting a fair and working OSI-style license like the revised BSD license, IronPython was made 'special' by encumbering it with legal non-sense which only truly benefits a small group of people/companies by harming all others. This is going to kill momentum and credibility, while only gaining a little money in the short run. A terrible cost, and a terrible loss. Please reconsider reviewing and adapting the BSD license, which allows free commercial and non-commercial use, free modification without being forced to release the source / intellectual property to anyone, and is otherwise widely accepted and respected. The decision what code goes in which repository where belongs and will keep to belong in the hands of the owner of the repository, that is, as long as you are the accepted and respected leader of the IronPython development you'll stay the person setting the policy / the BDFLUS. If it's no longer your decision because you sold it - tough luck. Then you created something beautiful for the community which you now have allowed 'the dark side' to put a reasonable stake in. It will grow and thrive, but it will have an ugly zit sitting where it might never be allowed to heal. Kind regards, Count -- Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. -- Bruce Lee (1940-1973, martial artist, actor, director, author) From jonathan-lists at cleverdevil.org Tue Mar 29 00:34:00 2005 From: jonathan-lists at cleverdevil.org (Jonathan LaCour) Date: Mon, 28 Mar 2005 22:34:00 +0000 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <1112049240.4248865845a56@webmail.barclay.textdrive.com> Jim, and others, > I'm in complete agreement that we've got work to do on the IronPython > community site. This feedback is great. I think that "work to do" is probably an understatement. I think the Passport thing is probably a showstopper for many Open Source people. I am not going to argue the technical merits for this, but to many OSS people, Passport is considered some great evil. It doesn't really matter if there is a technical reason or not, that is the way it is perceived. It doesn't matter how good the site is, its not going to get used if Passport is required. This is obviously a problem. There are other, better, alternatives out there, although I am sure that you don't have a huge choice in this issue being that gotdotnet is Microsoft's baby. I can't blame you here, but its a hurdle to be sure. Maybe you could make it possible for people to file bug reports with just a valid email address, and no passport? This might solve the problem. > I've had my first experiences using the forums this last week, and I'm > not particularly excited about them either. One thing that we're > investigating is NNTP access to the gotdotnet forums. If we can get > this setup I hope that people will give that a try and see how that > works for them. We're going to keep looking at those kinds of options > to make the gotdotnet site work better for people. However, so long as > you find this mailing list to be the best way to discuss IronPython then > it won't be going away. The forums aren't good, and probably never will be as good as a mailing list. NNTP is probably worse, because while it is more like a mailing list, its harder to access. You said it yourself: a mailing list is the best way to go. SourceForge projects have both available, and 90% of projects (in my estimation) use their mailing lists a lot, and their forums a little. I would say to shut down the forums, and make the mailing list the appropriate way to deal with things. This will please your target community greatly. I for one can't think of anything better than a mailing list here. > I agree that the bug database could also use some improvement, but it > would be great if we could figure out how to make the current version > work for people today. Some people will see needing a .NET passport as > a hurdle to filing bug reports and any hurdles we add here are a > mistake. Nevertheless, have you tried to get a .NET passport? It's a > fairly simple process and it should work on any OS. While this is a > little cumbersome, I don't think that it's much different from most bug > trackers that will require a valid email address before accepting bug > reports. Do you have a technical reason that you don't want to/can't > get a passport to file bugs? What I said above still applies: make it work without passport, and we will be happy. Otherwise: you will lose a very large portion of your community. It doesn't matter if there are good reasons (technical or political), all that matters is the result. I want IronPython to have a strong community, and I am sure that Microsoft and You do too! The issue that you haven't addressed in this email is the license. I know its probably because you have some serious discussion to do, but I want to go ahead and register my agreement that the license has some issues that would be really easy to fix. I agree with you that the license itself is fairly straightforward, but you would be much better served by picking ANY OSI approved license. As far as I am concerned, your target audience with IronPython is the Python community and the Open Source .NET community. By and large, this means Python people and Mono people. I am in both camps, and I would have to say that I would be totally satisfied if IronPython used a simple, non-viral BSD like license. If you adopted the same license as the Mono folks use, I think it would go really really far, and you would immediately cause all of the issues to disappear. Just to show you the potentially disastrous effects of the choice, take a look at what is already happening: http://usefulinc.com/edd/blog/contents/2005/03/26-ironpython/read http://usefulinc.com/edd/blog/contents/2005/03/26-boo/read Edd Dumbill is a Mono hacker who really liked IronPython. Now, he evaluating Boo, another dynamic .NET scripting language, instead. This guy wrote a .NET book, and might even write a book about IronPython (which would be a big deal if you ask me) if he was able to get over the license thing. I am really worried that you are missing an opportunity here. We all have great respect with what you have done so far, but I bet you that most of us would be fairly unlikely to contribute given the current state of affairs. If you ask me, a simple license change, keeping the mailing lists, and not requiring a passport to file bugs would solve most of the issues. The other issue is your statement about external people not being able to contribute patches. This is a big problem. I won't file bugs if you don't give me the opportunity to help out in a tangible way. Its clearly not an open source project then: its "shared source" to the core. Which do you want to be? Decide so that I can choose to participate or not. Personally, I don't see why you can't have a public SVN or CVS repository containing IronPython. Accept patches, review them (you don't have to apply bad ones). If you don't have time to review them, find at least one more person you trust to be a committer. If you really wanted to impress: make that additional committer a well-respected mono hacker. This would truly show the community that you guys are committed to making IronPython the best .NET scripting language on any platform. So, to review my pie-in-the-sky wishes to guarantee IronPython success: 1. Switch to a similar, but respected license. - Bonus points for picking the same license as mono. 2. Ditch the gotdotnet forums. Make the mailing list "the way". 3. Don't require a passport to file bugs. 4. Have a public SVN or CVS repository. 5. Be open to accepting external patches. 6. Have at least one other "committer" (to help lighten the load on you). - Bonus points if this person is outside Microsoft. - Extra bonus points if this person is a respected Mono hacker. Items 1, 3, and 5 are non-negotiable to me. If you don't do these at least, I guarantee that the project will stagnate, and something like Boo will become more widely accepted (especially by Open Source types). Anyway. I don't want to criticize you too much, as I think IronPython is a great piece of work. I would just hate to see such a great opportunity be missed! -- Jonathan From kfarmer at thuban.org Tue Mar 29 01:54:27 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 28 Mar 2005 15:54:27 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: Random comments while I wallow in J2EE madness... My only complaint about Passport is that there's no way to merge accounts (and I specifically would like to do so for GDN). Having a wallet of Passports to allow per-site assignation would be great but this is not the place for such suggestions. GDN: please keep the mailing lists.. GDN's fine as a place to distribute, but having dealt with it for the past couple years just doesn't work out very well. Licensing and submissions: Having dealt with the poor QC record of various projects that'd take any and all contributors, I'd be far more interested in just getting a copy of the binaries, and a place to dump bug reports. I don't need any sort of CVS if updatesare published with the 2-week regularity that's being hoped for. I also don't need any CVS access to submit changes, and would prefer such access to be close to absent across the board, for quality control. So in that, I must disagree at least in part with LaCour, but I do agree that having another avenue to deal with updates would be good. That said, despite what some may claim, software isn't free and any IP issues are really between Jim, MS, and Guido/PSF. The late-1990s "Open Source" and the 1980s "public domain" are two different concepts that get interchanged far too often. It's been bad enough that "Open Sores" is a common enough statement from -- and definitely doesn't buy any legitimacy with -- my cohorts. Give us corporate backing and let the legal department protect the legitmate interests. It's all part of the business of the professional software industry. Frankly, Dumbill should just get over it and evaluate technical merits, not camp politics. Jim and MS have more-or-less committed to giving us something we've wanted a long time, which until FePy came along was declared nigh impossible. Personally, I'd pay to have a first-class, IDE-supported release, provided the quality was up to the standards I've come to expect from C#. I'd also pay for Cw, but that's another story (any updated rumors on that one, Jim?). ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jonathan LaCour Sent: Mon 3/28/2005 2:34 PM To: users-ironpython.com at lists.ironpython.com Subject: RE: [IronPython] Ironpython 0.7 released! From count-ironpython at flatline.de Tue Mar 29 01:56:11 2005 From: count-ironpython at flatline.de (Andreas Kotes) Date: Tue, 29 Mar 2005 01:56:11 +0200 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <1112049240.4248865845a56@webmail.barclay.textdrive.com> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> Message-ID: <20050328235611.GS25172@aleph.priv.flatline.de> Hello again, * Jonathan LaCour [20050329 00:39]: > So, to review my pie-in-the-sky wishes to guarantee IronPython success: > 1. Switch to a similar, but respected license. > - Bonus points for picking the same license as mono. > 2. Ditch the gotdotnet forums. Make the mailing list "the way". > 3. Don't require a passport to file bugs. > 4. Have a public SVN or CVS repository. > 5. Be open to accepting external patches. > 6. Have at least one other "committer" (to help lighten the load on you). > - Bonus points if this person is outside Microsoft. > - Extra bonus points if this person is a respected Mono hacker. > > Items 1, 3, and 5 are non-negotiable to me. If you don't do these at least, I > guarantee that the project will stagnate, and something like Boo will become > more widely accepted (especially by Open Source types). > > Anyway. I don't want to criticize you too much, as I think IronPython is a great > piece of work. I would just hate to see such a great opportunity be missed! I could not agree more. Anything less will make IronPython 'nice', but nothing more - at least not until Microsoft pushes it heavily, then it will be another nice, forced, and despised steal by Microsoft. sorry for being this candid, but I think this needs to be clear. Regards, Count -- Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. -- Bruce Lee (1940-1973, martial artist, actor, director, author) From fred.dixon at gmail.com Tue Mar 29 02:22:04 2005 From: fred.dixon at gmail.com (Fred Dixon) Date: Mon, 28 Mar 2005 19:22:04 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <20050328235611.GS25172@aleph.priv.flatline.de> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> <20050328235611.GS25172@aleph.priv.flatline.de> Message-ID: Short and sweet. No Passport for me. The lic. is an issue, if it cant be fixed the Boo is good enough for me. I'll just have to figure out how to use the python Lib's with Boo. On Tue, 29 Mar 2005 01:56:11 +0200, Andreas Kotes wrote: > Hello again, > > * Jonathan LaCour [20050329 00:39]: > > So, to review my pie-in-the-sky wishes to guarantee IronPython success: > > 1. Switch to a similar, but respected license. > > - Bonus points for picking the same license as mono. > > 2. Ditch the gotdotnet forums. Make the mailing list "the way". > > 3. Don't require a passport to file bugs. > > 4. Have a public SVN or CVS repository. > > 5. Be open to accepting external patches. > > 6. Have at least one other "committer" (to help lighten the load on you). > > - Bonus points if this person is outside Microsoft. > > - Extra bonus points if this person is a respected Mono hacker. > > > > Items 1, 3, and 5 are non-negotiable to me. If you don't do these at least, I > > guarantee that the project will stagnate, and something like Boo will become > > more widely accepted (especially by Open Source types). > > > > Anyway. I don't want to criticize you too much, as I think IronPython is a great > > piece of work. I would just hate to see such a great opportunity be missed! > > I could not agree more. Anything less will make IronPython 'nice', but > nothing more - at least not until Microsoft pushes it heavily, then it > will be another nice, forced, and despised steal by Microsoft. > > sorry for being this candid, but I think this needs to be clear. > > Regards, > > Count > > -- > Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! > All fixed set patterns are incapable of adaptability or pliability. > The truth is outside of all fixed patterns. > -- Bruce Lee (1940-1973, martial artist, actor, director, author) > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From sriramk at gmail.com Tue Mar 29 02:49:16 2005 From: sriramk at gmail.com (Sriram Krishnan) Date: Tue, 29 Mar 2005 06:19:16 +0530 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <1112049240.4248865845a56@webmail.barclay.textdrive.com> Message-ID: <4248a612.0a848da5.081a.ffffc9bb@mx.gmail.com> >Passport is considered some great evil. It doesn't really matter if there is a technical reason or not, that is the >way it is perceived. It doesn't matter how good the site is, its not going to get used if Passport is required. This makes me wonder - has anyone here tried signing up for Passport? It is a 2 minute process and not too dissimilar to the other login schemed on other websites. Signing up for a Passport account is not too different (process-wise) from signing up for a Sourceforge account. I understand that there is this perception of Passport being evil -but people should actually try it out before making up their minds,IMHO. If you're tried it out and you don't like it, I would like to hear why. What's the difference between signing up for a Passport to file bugs and signing up in the Mozilla bugzilla to file bugs? Thanks, Sriram From KarmaSlave at MyRealBox.com Tue Mar 29 02:56:06 2005 From: KarmaSlave at MyRealBox.com (Burning) Date: Mon, 28 Mar 2005 19:56:06 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> <20050328235611.GS25172@aleph.priv.flatline.de> Message-ID: <4248A7A6.20101@MyRealBox.com> Having a problem with the license because of the name is as silly as having problems with the .NET Framework just because its under the ".NET" umbrella, in my personal opinion. It seems like many people who have issues with the license haven't quite read it yet. Fred Dixon wrote: >Short and sweet. >No Passport for me. >The lic. is an issue, if it cant be fixed the Boo is good enough for me. >I'll just have to figure out how to use the python Lib's with Boo. > > http://docs.codehaus.org/display/BOO/Recipes http://docs.codehaus.org/display/BOO/Using+IronPython+From+Boo From count-ironpython at flatline.de Tue Mar 29 03:08:12 2005 From: count-ironpython at flatline.de (Andreas Kotes) Date: Tue, 29 Mar 2005 03:08:12 +0200 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <4248A7A6.20101@MyRealBox.com> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> <20050328235611.GS25172@aleph.priv.flatline.de> <4248A7A6.20101@MyRealBox.com> Message-ID: <20050329010812.GT25172@aleph.priv.flatline.de> Heya, * Burning [20050329 03:01]: > Having a problem with the license because of the name is as silly as > having problems with the .NET Framework just because its under the > ".NET" umbrella, in my personal opinion. It seems like many people who > have issues with the license haven't quite read it yet. would you prefer 'coffee' or 'trink made from boiled shredded beans'? if it is/should be the same, why give it another name? why not stick to something adopted, approved, and - above all - well-known? why introduce something new if it 'should mean the same'? use the same, damnit! Count -- Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. -- Bruce Lee (1940-1973, martial artist, actor, director, author) From kfarmer at thuban.org Tue Mar 29 03:15:18 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 28 Mar 2005 17:15:18 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: Because not everybody -- particularly lawyers -- is convinced of the protections offered by various OS licenses. Let's face it, there are a *lot* of flavors of coffee. I happen to prefer mine decaf, blond, and sweet. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Andreas Kotes Sent: Mon 3/28/2005 5:08 PM would you prefer 'coffee' or 'trink made from boiled shredded beans'? if it is/should be the same, why give it another name? why not stick to something adopted, approved, and - above all - well-known? why introduce something new if it 'should mean the same'? use the same, damnit! From lobrien at knowing.net Tue Mar 29 03:23:11 2005 From: lobrien at knowing.net (Larry O'Brien) Date: Mon, 28 Mar 2005 15:23:11 -1000 Subject: SPAM-LOW: Re: [IronPython] Ironpython 0.7 released! In-Reply-To: <20050328235611.GS25172@aleph.priv.flatline.de> Message-ID: <20050329012348.8EBE784D47@che.dreamhost.com> > 3. Don't require a passport to file bugs. Hmmm... I thought an at-least-partial solution might be to write a bug-filing proxy, but it seems to be against the Passport TOS: "You must enter into a different legal agreement with Microsoft if you wish to offer the .NET Passport Services to users of your own application, Web site, or Web service. You may not use any software or hardware that reduces the number of users directly accessing or using the .NET Passport Services (sometimes called "multiplexing" or "pooling" software or hardware)." Larry From jonathan-lists at cleverdevil.org Tue Mar 29 03:29:48 2005 From: jonathan-lists at cleverdevil.org (Jonathan LaCour) Date: Mon, 28 Mar 2005 20:29:48 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <4248a612.0a848da5.081a.ffffc9bb@mx.gmail.com> References: <4248a612.0a848da5.081a.ffffc9bb@mx.gmail.com> Message-ID: > This makes me wonder - has anyone here tried signing up for Passport? > It is > a 2 minute process and not too dissimilar to the other login schemed on > other websites. Signing up for a Passport account is not too different > (process-wise) from signing up for a Sourceforge account. You are saying nothing that most of us already know. As I stated -- it doesn't matter about reality. The only thing that matters here is perception. I know thats a hard sell. > I understand that there is this perception of Passport being evil -but > people should actually try it out before making up their minds,IMHO. Lofty goal. Won't change the world though. > If you're tried it out and you don't like it, I would like to hear why. > What's the difference between signing up for a Passport to file bugs > and > signing up in the Mozilla bugzilla to file bugs? Other people have already outlined their reasoning on this list. Those reasons sound pretty logical to me, and I am not about to argue with their _perception_. And, you logic flips on its end as well... if there is no difference in filing bugs in bugzilla vs. gotdotnet, and so many people seem to dislike gotdotnet, why not just use bugzilla (or something else...)? -- Jonathan From count-ironpython at flatline.de Tue Mar 29 03:30:58 2005 From: count-ironpython at flatline.de (Andreas Kotes) Date: Tue, 29 Mar 2005 03:30:58 +0200 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: References: Message-ID: <20050329013058.GU25172@aleph.priv.flatline.de> Heya, * Keith J. Farmer [20050329 03:24]: > Because not everybody -- particularly lawyers -- is convinced of the > protections offered by various OS licenses. Let's face it, there are > a *lot* of flavors of coffee. I happen to prefer mine decaf, blond, > and sweet. the variety of coffee^WOSI-approved licenses available is quite stunnig, why not help strengthen the trust in the existing ones by helping to legally prove them instead of giving lawyers yet another possibilty to cost money and time which should go elsewhere for work which won't help elsewhere? Regards, Count -- Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. -- Bruce Lee (1940-1973, martial artist, actor, director, author) From thane at magna-capital.com Tue Mar 29 03:31:07 2005 From: thane at magna-capital.com (Thane) Date: Mon, 28 Mar 2005 18:31:07 -0700 Subject: [IronPython] Thoughts on IronPython In-Reply-To: <20050328235611.GS25172@aleph.priv.flatline.de> Message-ID: <20050329013124.6EFCC84D4A@che.dreamhost.com> Dear Jim (and anyone else interested in the future of IronPython), I've attached below emails that seem to echo a lot of the sentiment coming from the Open Source/Free Software community regarding IronPython. The essence of these messages is generally: "You must do this, this, and this (insert list of demands/requests here), or I'm not going to contribute to your project because of (insert list of objections here). And if you don't get my help, IronPython will die a miserable death. Oh yes, and Microsoft is evil (insert list of sins)." Forgive me for pointing out the obvious, but sometimes we need to be reminded. First, no one can create software for free. Period. Somebody, somewhere, must pay for the resources and time required to create it. In this sense, there is no such thing as "Free Software". You might get it for free, but only at someone else's expense. I point this out because you created a wonderful piece of software and most generously gave it away. In so doing, you spawned a group of passionate enthusiasts who now feel as if they are co-owners of your creation, and are genuinely interested in seeing it grow and thrive. While it is wonderful that you now have a "community", it is important that note that this community does not own IronPython, and is not essential for either its success or demise. Only you are. Second, you made a decision to sell your software to the Microsoft Corporation (perhaps not in the literal sense, but at least figuratively as they have hired you for your time and programming talents). While this was not the only avenue for furthering your work on IronPython, it is certainly a viable choice with many obvious advantages. The point is that you made a choice, and as part of the passionate IronPython community I can respect that choice. IronPython was your property and you had every right to do with it as you saw fit. Third, your obligations with respect to IronPython are now to Microsoft, and not to the passionate IronPython community I spoke of earlier. This will cause you grief in the short run (as evidenced below), but should not be ignored entirely, as some of the suggestions are both insightful and useful, and may ultimately benefit both IronPython and your new employer. Fourth and finally, if you build it, they will come (apologies to K. Costner). With the successful development and growth of IronPython, all of the grumblings about the current course of IronPython will come to nothing. You have the talent, capability, and resources to create a truly first class product. I sincerely hope that you do. All my best, --Thane Plummer P.S. It's perfectly reasonable to expect people to pay for good software. > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users- > ironpython.com-bounces at lists.ironpython.com] On Behalf Of Andreas Kotes > Sent: Monday, March 28, 2005 4:56 PM > To: users-ironpython.com at lists.ironpython.com > Subject: Re: [IronPython] Ironpython 0.7 released! > > Hello again, > > * Jonathan LaCour [20050329 00:39]: > > So, to review my pie-in-the-sky wishes to guarantee IronPython success: > > 1. Switch to a similar, but respected license. > > - Bonus points for picking the same license as mono. > > 2. Ditch the gotdotnet forums. Make the mailing list "the way". > > 3. Don't require a passport to file bugs. > > 4. Have a public SVN or CVS repository. > > 5. Be open to accepting external patches. > > 6. Have at least one other "committer" (to help lighten the load on > you). > > - Bonus points if this person is outside Microsoft. > > - Extra bonus points if this person is a respected Mono hacker. > > > > Items 1, 3, and 5 are non-negotiable to me. If you don't do these at > least, I > > guarantee that the project will stagnate, and something like Boo will > become > > more widely accepted (especially by Open Source types). > > > > Anyway. I don't want to criticize you too much, as I think IronPython is > a great > > piece of work. I would just hate to see such a great opportunity be > missed! > > I could not agree more. Anything less will make IronPython 'nice', but > nothing more - at least not until Microsoft pushes it heavily, then it > will be another nice, forced, and despised steal by Microsoft. > > sorry for being this candid, but I think this needs to be clear. > > Regards, > > Count > > -- > Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) > mine! > All fixed set patterns are incapable of adaptability or pliability. > The truth is outside of all fixed patterns. > -- Bruce Lee (1940-1973, martial artist, actor, director, author) > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Tue Mar 29 03:41:59 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 28 Mar 2005 17:41:59 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: The lawyers that have briefed my dev groups over the years are waiting for such proof -- generally in the form of hard legal precedent. That involves lawsuits, money, angst, and probably some lost jobs. Consider MS's choice in it Team System designers, as well as XAML. Many people belly-ached over not having their favorite UML/XUL implementations used. MS responded: they looked, evaluated, and found them lacking. They therefore created a different representation. Always grandfathering in someone's favorite is a sure way to restrict advancement of the art. The mere fact that there are such a variety of ODI-approved licenses shows that many people have not felt confortable with any one of them. MS -- or any corporation -- is no different in that regard, and arguably have much more to lose than political control of any given project. Consider your signature line. I think it's somewhat apt in this case. ________________________________ From: count at nospam.flatline.de on behalf of Andreas Kotes Sent: Mon 3/28/2005 5:30 PM Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. -- Bruce Lee (1940-1973, martial artist, actor, director, author) From jonathan-lists at cleverdevil.org Tue Mar 29 03:42:34 2005 From: jonathan-lists at cleverdevil.org (Jonathan LaCour) Date: Mon, 28 Mar 2005 20:42:34 -0500 Subject: [IronPython] Thoughts on IronPython In-Reply-To: <20050329013124.6EFCC84D4A@che.dreamhost.com> References: <20050329013124.6EFCC84D4A@che.dreamhost.com> Message-ID: <16931a9389b29789ec2fce5ac4defff8@cleverdevil.org> > Forgive me for pointing out the obvious, but sometimes we need to be > reminded. > > First, no one can create software for free. Period. Somebody, > somewhere, > must pay for the resources and time required to create it. Congratulations, you have totally missed the point. This conversation has nothing to do with money. People's objections would be entirely the same with or without Microsoft in the picture. In fact, I am thrilled that Microsoft is in the picture. They created .NET, who better to help with an open source project for .NET? Most people's objections are very small. Jim has created an open source project and people with lots of experience with open source projects are simply giving him a little bit of advise to help make the project accessible and appealing for the largest audience. I would gladly pay Microsoft to integrate IronPython into Visual Studio, and I expect that now that Jim is working for them, they will probably do just that. Pay more attention -- the issues are small and easy to fix. Its not a holy war. -- Jonathan From count-ironpython at flatline.de Tue Mar 29 03:56:51 2005 From: count-ironpython at flatline.de (Andreas Kotes) Date: Tue, 29 Mar 2005 03:56:51 +0200 Subject: [IronPython] Thoughts on IronPython In-Reply-To: <20050329013124.6EFCC84D4A@che.dreamhost.com> References: <20050328235611.GS25172@aleph.priv.flatline.de> <20050329013124.6EFCC84D4A@che.dreamhost.com> Message-ID: <20050329015651.GV25172@aleph.priv.flatline.de> Hello, * Thane [20050329 03:36]: > I've attached below emails that seem to echo a lot of the sentiment coming > from the Open Source/Free Software community regarding IronPython. The > essence of these messages is generally: you're polarizing (intentionally, of course) > "You must do this, this, and this (insert list of demands/requests here), you -should- do this (and that), > or I'm not going to contribute to your project because of (insert list > of objections here). or the gross of the open source community will refrain from contributing for easily mendable psychological reasons, > And if you don't get my help, IronPython will die a miserable death. and if you don't get their help, IronPython will unlock (at least a little) of the huge potential it has. > Oh yes, and Microsoft is evil (insert list of sins)." > With the successful development and growth of IronPython, all of the > grumblings about the current course of IronPython will come to > nothing. .. and the legal encumberment carefully crafted for the benefit of specific parties will still remain, and the seed of evil will have taken foot at another place > You have the talent, capability, and resources to create a truly first class > product. I sincerely hope that you do. so do I, but I don't see it as a 'product' but rather as a valuable piece of a mosaic which does .NET the favour of allowing to benefit from the grand work of the horde of python designers and contributors which gave IronPython broad and capable shoulders to stand on. > P.S. It's perfectly reasonable to expect people to pay for good software. .. as well at it is perfectly reasonable to decide to work for the benefit of the whole (the world, the community, etc) as opposed to someones deep deep pockets. I totally agree that developing software should be payed for if you don't want/can't allow to make it for free - but I don't see an absolute need to bill (unintentional pun, sorry for that ..) for (then) existing software. Sharing the cost - ok. Multiplying from it - within reason. Exponentiating from it - not if I can help it. Consider giving IronPython to the world unencumbered as shared cost for developing Python et al themselves. Regards, Count -- Andreas Kotes - PGP 0x8F94C228 - The views expressed herein are (only) mine! All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. -- Bruce Lee (1940-1973, martial artist, actor, director, author) From luismg at gmx.net Tue Mar 29 04:07:19 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Mon, 28 Mar 2005 23:07:19 -0300 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <001301c53404$0b086420$1302a8c0@luis> I just read the last posts on this thread and I have to say that I'm really sorry for Jim. I understand many of the concerns expressed here regarding licensing issues, but the tone of some coments sound more like menaces than suggestions. First of all, Jim is working for Microsoft, and this is what's making possible the development of Ironpython right now. The fact that he works in Microsoft gives him acess to the internals of the CLR and put him in the best place for developing Ironpython. This is the best thing that could happen to Ironpython at this time. Second, Jim is the driving force behind it, and I don't see many other developers capable of taking his place at this moment. Third, if the "evil empire" tries to steal python from us in the near future by means of its legal tricks, you all can still make a fork and go on with it. Fourth, what reason do we have to distrust Jim? Didn't he already demonstrate what he can do for python? Isn't he the creator of Jython? Fifth, is it that hard to understand that he is probably having a hard time trying to please everybody (the community and MS lawyers)? Why do you all make things still harder for him? Besides, it seems perfectly reasonable that he pretends to lead Ironpython's development so firmly. As he already stated, he is learning a ton of new interesting features regarding features for dynamic languages in the CLR. Learning them, implementing them and teaching them to the community, all at the same time seems to be a rather daunting task... Why don't we just relax and give Jim some credit for what he's doing? I'm sure the end result will please everybody. Meanwhile, for all of you who want to try Boo, just go ahead! This is another excellent project with some special characteristics that make it unique. It doesn't have to compete with Ironpython, these are not religions, these are just programming languages, tools. Just my two cents... Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at microsoft.com Tue Mar 29 04:34:43 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Mon, 28 Mar 2005 18:34:43 -0800 Subject: [IronPython] Object ids and hash code Message-ID: <695D7C410F74A644B5335E47FB73E17E037D92DB@RED-MSG-52.redmond.corp.microsoft.com> Sriram Krishnan wrote: > > I saw that IronPython 0.7 uses > System.Runtime.CompilerServices.RuntimeHelpers to get the hash code of an > object (thereby removing the need for the Reflection.Emit/util dll hack in > 0.6). However, if I remember correctly, .NET hash codes are *not* > guaranteed > to be unique. Brad Abrams talks about it here > http://blogs.msdn.com/brada/archive/2003/09/30/50396.aspx. > > Doesn't this open up problems when 2 objects have the same id? Thanks for an excellent and tricky technical question. I'll answer this one tonight and take a crack at some of the other questions on the morrow. The previous hack and the current use of RuntimeHelpers to implement Python's id builtin both do the same thing and return the result of the default non-overridden Object.HashCode method called on the given object. So, the 0.7 code is absolutely better than 0.6 because it is simpler and doesn't have weird build process issues anymore while still doing as good a job of matching Python's id function. The open question remains as to whether or not this is good enough. Jython used Java's System.identityHashcode function to implement Python's id builtin from the very beginning. This function behaves very similarly to the RuntimeHelpers function that I'm using in IronPython. They both almost always generate a unique int for a given object but they are not 100% guaranteed to do so. I can't recall ever seeing a bug report from a Jython user indicating that this was a real issue for them. However, I can certainly imagine an odd corner case where this could produce an extremely hard to understand and fix bug. This is likely to be one of the detailed Python compatibility issues where we will spend some design time before getting to 1.0. This issue is coupled to the fact that IronPython, like Jython, uses a true garbage collector rather than a reference counting system. One aspect of these GC's is that they will move objects around in order to compact heap space and this means that an object's memory address can change over its lifetime. This makes it hard to precisely match Python's semantics for id. Note: This doesn't make it impossible to match the semantics of id. A simple implementation would be to use a Dictionary tied to the id function that kept track of every object passed to it and when it saw an object that wasn't in the Dictionary it would increment an int to the next value and then return that int. Obviously there'd be some performance and memory issues with this approach. The challenge with IronPython is very similar to that of Jython. To strike the right balance between perfect compatiblity with CPython (the name for the standard implementation of Python) and working as well as possible with the target platform. I suspect that the right answer here for IronPython will be the same as the Jython decision; however, I'd be interested in learning about existing Python programs that have a critical dependency on the semantics of id. I can tell you about one difference between IronPython and CPython that I'm sure won't be going away. IronPython will never guarantee the deterministic finalization that you can get in CPython. The classic example is this code: text = open("foo.txt", "r").read() In standard CPython you are guaranteed that the file object will be closed (assuming that the builtin open function was not overridden) because the moment the last reference to it goes away the destructor will be called and the file will be closed. IronPython (and Jython) does not offer this guarantee. FYI - There are tricks that can be played for this particular very special case of file objects that IronPython may decide to use, but the general case of finalization at the exact moment the last reference goes away won't be solved. I was asked this question during my PyCon talk and Guido van Rossum was kind enough to answer it for me. The community had already been through this discussion in earnest back in the early Jython days and in the end concluded that it was acceptable for a Python implementation to not use a reference count based GC. The winning argument was that this was an incredibly risky feature to depend on and that Python programmers on any platform could improve their code by not depending on the precise semantics of reference counting. Because we've already had this discussion once before in great depth it was easy to make this particular decision for IronPython. Thanks - Jim From jvm_cop at spamcop.net Tue Mar 29 04:49:39 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 28 Mar 2005 21:49:39 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <4248A7A6.20101@MyRealBox.com> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> <20050328235611.GS25172@aleph.priv.flatline.de> Message-ID: <4.3.2.7.2.20050328213809.061e7698@mail.comcast.net> At 07:56 PM 3/28/2005, Burning wrote >Having a problem with the license because of the name is as silly as having problems with the .NET Framework just because its under the ".NET" umbrella, in my personal opinion. It seems like many people who have issues with the license haven't quite read it yet. Why are there any incomprehensible statements about patents in the FAQ for the license? I do not see that you have answered the question I asked about the meaning of the phrase "that read on" that appears multiple times in the FAQ for the license. As far as I'm concerned, if I don't understand a phrase used in the official license FAQ, I "have issues" with the license. Doesn't item 6. of the license ("That the patent rights, if any, granted in this license only apply to the Software, not to any derivative works you make.") mean that if MS (or Jim personally) has licensed a patent, and has used the patented intellectual property in building IronPython, that I could possibly be sued by the owner of the patent were I to build a "derivative work" based on IronPython? What "patent rights, if any" are "granted in [the] license"? Wouldn't it be better if the license were more explicit about what those are? Do you think that the failure to list any such patent licenses that might apply guarantees that there aren't any? After all, MS could at any time choose to license anything, because they have (in effect) infinite money. J. Merrill / Analytical Software Corp From jvm_cop at spamcop.net Tue Mar 29 04:49:58 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 28 Mar 2005 21:49:58 -0500 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <4.3.2.7.2.20050328214952.052be180@wheresmymailserver.com> At 07:49 PM 3/28/2005, Sriram Krishnan wrote (in part) >What's the difference between signing up for a Passport to file bugs and >signing up in the Mozilla bugzilla to file bugs? I have to use a Passport to download from MSDN. If I then go to GotDotNet, it will either recognize my MSDN "identity" or not, using techniques that are not well documented, with little if any info available to me about how to control it. If I somehow turn off my MSDN Passport and get to use a different Passport when I access GotDotNet, then I go to a commercial web site that supports Passport, it will either recognize my MSDN "identity" or my GotDotNet "identity", or neither; maybe it will know about both. This is again done using techniques that are not well documented, with little if any info available to me about how to control it. If I sign in to Mozilla with an email address, they tell me that they won't use it for anything else. I tend to believe that. If you want to have a single identity on the net, Passport works for you. If I don't, it doesn't work as well for me as it does for you. J. Merrill / Analytical Software Corp From KarmaSlave at MyRealBox.com Tue Mar 29 05:10:39 2005 From: KarmaSlave at MyRealBox.com (Burning) Date: Mon, 28 Mar 2005 22:10:39 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <662dfd66e2a3e12b9d61770aab37ebb9@cleverdevil.org> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> <20050328235611.GS25172@aleph.priv.flatline.de> <4248A7A6.20101@MyRealBox.com> <662dfd66e2a3e12b9d61770aab37ebb9@cleverdevil.org> Message-ID: <4248C72F.4010908@MyRealBox.com> I am afraid we have arrived at a misunderstanding: I do not "miss" the point; I realize and understand it fully. However, I am not subject to the whims of 'the name is stupid, thus, the product is stupid' so I tend to try and reflect the technical aspects and their valued merits or disadvantages, as I am not a politician and care little for the whole mud-slinging about something as trivial as a name or brand. Thank you for your understanding, and I hope this clears things up. ;) > You miss the point. The license seems fairly reasonable, but the fact > that its called "Shared Source" causes a negative PERCEPTION. Saying > "people aught not think that way" doesn't solve the problem. Going to > any number of almost identical licenses that are OSI approved would > solve the perception problems without causing any issue from the > actual legal perspective. > > Its a simple matter of swaying public opinion. > > -- Jon > > From swaroopch at gmail.com Tue Mar 29 06:08:47 2005 From: swaroopch at gmail.com (Swaroop C H) Date: Tue, 29 Mar 2005 09:38:47 +0530 Subject: [IronPython] Matusow, Director of Shared Source explains IronPython's licensing Message-ID: <351e887105032820086ffa08cd@mail.gmail.com> http://blogs.msdn.com/jasonmatusow/archive/2005/03/28/402992.aspx Regards, -- Swaroop C H Blog: http://www.swaroopch.info Book: http://www.byteofpython.info From ryan4096 at bellsouth.net Tue Mar 29 06:32:57 2005 From: ryan4096 at bellsouth.net (Ryan Williams) Date: Mon, 28 Mar 2005 23:32:57 -0500 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <4.3.2.7.2.20050328213809.061e7698@mail.comcast.net> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> <1112049240.4248865845a56@webmail.barclay.textdrive.com> <20050328235611.GS25172@aleph.priv.flatline.de> <4.3.2.7.2.20050328213809.061e7698@mail.comcast.net> Message-ID: <1112070777.25311.7.camel@localhost.localdomain> Exactly. That's probably one of the reasons they didn't go with an OSI-approved license. That clause can easily be used to prevent forking, and to make sure that someone [the patent holder/licensee, MS] can retain control over the project and its direction. On Mon, 2005-03-28 at 21:49 -0500, J. Merrill wrote: > At 07:56 PM 3/28/2005, Burning wrote > >Having a problem with the license because of the name is as silly as having problems with the .NET Framework just because its under the ".NET" umbrella, in my personal opinion. It seems like many people who have issues with the license haven't quite read it yet. > > Why are there any incomprehensible statements about patents in the FAQ for the license? > > I do not see that you have answered the question I asked about the meaning of the phrase "that read on" that appears multiple times in the FAQ for the license. As far as I'm concerned, if I don't understand a phrase used in the official license FAQ, I "have issues" with the license. > > Doesn't item 6. of the license ("That the patent rights, if any, granted in this license only apply to the Software, not to any derivative works you make.") mean that if MS (or Jim personally) has licensed a patent, and has used the patented intellectual property in building IronPython, that I could possibly be sued by the owner of the patent were I to build a "derivative work" based on IronPython? > > What "patent rights, if any" are "granted in [the] license"? Wouldn't it be better if the license were more explicit about what those are? > > Do you think that the failure to list any such patent licenses that might apply guarantees that there aren't any? After all, MS could at any time choose to license anything, because they have (in effect) infinite money. > > J. Merrill / Analytical Software Corp > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sriramk at gmail.com Tue Mar 29 08:35:37 2005 From: sriramk at gmail.com (Sriram Krishnan) Date: Tue, 29 Mar 2005 12:05:37 +0530 Subject: [IronPython] Inheriting Python classes from .NET classes Message-ID: <4248f741.2a1d7b15.081a.0156@mx.gmail.com> I've been playing around with the 0.7 release for the last couple of days. I tried to write Don Box's Http.Sys ASP.NET web server (Google for cache:http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-03-30T07:38:4 5Z). He extends from MarshalByRefObject public class SubDomainCode : MarshalByRefObject {... When I try to do the same thing in a Python class by writing class SubDomainCode(MarshalByRefObject) I get a NotImplementedException. I've loaded the required assemblies properly. What am I doing wrong here? Or is inheriting .NET types not implemented yet in 0.7? Thanks, Sriram From innesm at gmail.com Tue Mar 29 13:44:27 2005 From: innesm at gmail.com (Innes MacKenzie) Date: Tue, 29 Mar 2005 12:44:27 +0100 Subject: [IronPython] Re: users-ironpython.com Digest, Vol 8, Issue 8 In-Reply-To: <20050329031154.ACAC484EA9@che.dreamhost.com> References: <20050329031154.ACAC484EA9@che.dreamhost.com> Message-ID: "J. Merrill" wrote: > I have to use a Passport to download from MSDN. If I then go to GotDotNet, it will either recognize my MSDN "identity" or not, using techniques that are not well documented, with little if any info available to me about how to control it. I did a little test, and the behaviour seems quite simple, if annoying. When I go to hotmail, Im automatically logged in using my personal passport (tied to the hotmail account) because I checked 'automatically sign me in'. When I go to the MSDN site, and press 'sign in' Im told that the passport isnt registered with MSDN, so I sign-out, and sign-in with the passport I have registered with MSDN. (I check 'automatically sign me in', again.) When I then go back to hotmail, Im told that 'an account has been reserved for me' - hotmail has tried to auto-login with the msdn passport. There is no sign-out button, so I have to go back to msdn to sign out :-\. Then, when I go to hotmail again, I log in, changing the msdn passport email address to my personal one in the login form. The same hassle would presumably happen each time you switch between sites that use passport. I initially tried this experiment so I could tell you to stop making such a fuss over nothing, but it is indeed a right pain in the arse, although disabling auto-sign-in might simplify things a little. Inflammatory PS: BTW none of this is a problem for people who use a single passport or are without a passport and would create one solely for IPy at GDN. Any objections from people in those categories I would see as the usual slashdotesque delusions of self-importance. Seems that a lot of nerds like to imagine themselves in an exciting hollywood thriller where evil corporations & shadowy government agencies amazingly give a bugger about their age, postcode etc. As a 99 year old woman from beverly hills (90210) I remain sanguine on the issue. ;) From lupus at ximian.com Tue Mar 29 15:16:19 2005 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 29 Mar 2005 15:16:19 +0200 Subject: [IronPython] IronPython compilation with mono Message-ID: <20050329131619.GS14394@debian.org> IronPython 0.7 compiles with the current mono from svn (not with the released 1.1.5, though the patch is minimal). I used the attached quick and dirty makefile: just put it in the toplevel dir and run make. You need to build mono with the 2.0 preview bits enabled (run ./autogen.sh --enable-preview=yes in the mono module). Note it doesn't overwrite the files in bin, but it places the new binaries in the current dir. Jim, any chance the binary can be given a more sane name like ironp, ironpy or ipython instead of IronPythonConsole.exe? Also it would be nice if the zip would extract in its own versioned directory like in 0.6. I only did very light testing: pystone runs and it's about 20 % faster than cpython 2.4 (and 35% faster than 2.3). It seems IronPython 0.7 is 2% faster at it than version 0.6 (always with mono from svn, I don't have .net to compare). Jim: is it correct that IP 0.7 doesn't run the pie-thon benchmark? It seems it looks for public object Invoke(object self, object arg1, object arg2, object arg3) in IronPython/Objects/PythonType.cs, but then there are also other issues. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better -------------- next part -------------- all: IronMath.dll IronPython.dll ironp.exe IronMath.dll: IronMath/*.cs gmcs -out:IronMath.dll -target:library IronMath/*.cs IronPython.dll: IronMath.dll IronPython/*.cs IronPython/*/*.cs gmcs -out:IronPython.dll -r:IronMath.dll -target:library IronPython/*.cs IronPython/*/*.cs ironp.exe: IronMath.dll IronPython.dll IronPythonConsole/*.cs gmcs -out:ironp.exe -r:IronPython.dll IronPythonConsole/*.cs clean: rm -f IronMath.dll IronPython.dll ironp.exe From chmouel at chmouel.com Tue Mar 29 16:03:42 2005 From: chmouel at chmouel.com (Chmouel Boudjnah) Date: Tue, 29 Mar 2005 14:03:42 +0000 (UTC) Subject: [IronPython] Re: IronPython compilation with mono References: <20050329131619.GS14394@debian.org> Message-ID: Paolo Molaro writes: > Jim, any chance the binary can be given a more sane name like > ironp, ironpy or ipython instead of IronPythonConsole.exe? FYI: ipython is already well know for : http://ipython.scipy.org/ -- Chmouel - http://www.chmouel.com/ From lupus at ximian.com Tue Mar 29 16:42:56 2005 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 29 Mar 2005 16:42:56 +0200 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E037954A6@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <20050329144256.GT14394@debian.org> On 03/28/05 Jim Hugunin wrote: > I'm in complete agreement that we've got work to do on the IronPython > community site. This feedback is great. > > I've had my first experiences using the forums this last week, and I'm > not particularly excited about them either. One thing that we're > investigating is NNTP access to the gotdotnet forums. If we can get Well, in that case it would be better to open a proper newsgroup in the microsoft.public.dotnet.* namespace. Just to reiterate, the gotdotnet pages for irnopython were down a couple of days ago, too, so it's not only slow and ugly, but also buggy. This mailing list is still the best option, IMHO. > I agree that the bug database could also use some improvement, but it > would be great if we could figure out how to make the current version > work for people today. I think people would rather spend their time testing and improving ironpython than beta or alpha testing the gotdotnet website:-) > Some people will see needing a .NET passport as > a hurdle to filing bug reports and any hurdles we add here are a It's worse when it's also required to just browse the database. > mistake. Nevertheless, have you tried to get a .NET passport? It's a > fairly simple process and it should work on any OS. While this is a > little cumbersome, I don't think that it's much different from most bug > trackers that will require a valid email address before accepting bug > reports. Do you have a technical reason that you don't want to/can't > get a passport to file bugs? Well, after reading the terms of services, I think the only way for most people to use it is to also break the terms of service which also means termination of its use. It says: "To set up an account, you _must_ provide information about yourself and _update_ this information as necessary in order to keep it current." And in the privacy statement it says it will collect the timezone info. Am I supposed to connect and update it while I travel? Of course the example is absurd, but so is an agreement I have to agree to that is (a lot) longer than the license to ironpython itself. It is just an unnecessary hurdle, IMHO: requiring a valid email address is instead fair and simple. At the end of the day, I think it all boils down to having IronPython as a viable project for both the win32 programmers and the free software community or not. The former are happy with whatever your throw at them (see the earlier mails about "just give me the binaries" - yes, this is a simplification). That community is big, so IronPython could live fine without any contribution from the free software world. But if that is the case, I'm probably not going to spend my time testing and supporting IronPython in mono and promoting its use. [Note for the people that are not used to frank discussions: I never met Jim personally but I have all the reasons to believe he's a nice person and I appreciate his contributions. I don't see, though, why this appreciation should be extended to the gotdotnet website and the policy decisions that I think are counterproductive to the IronPython project.] lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jimhug at microsoft.com Tue Mar 29 19:18:02 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Tue, 29 Mar 2005 09:18:02 -0800 Subject: [IronPython] IronPython compilation with mono Message-ID: <695D7C410F74A644B5335E47FB73E17E037D983A@RED-MSG-52.redmond.corp.microsoft.com> Paolo Molaro wrote: > IronPython 0.7 compiles with the current mono from svn Cool. It sounds like it would be a nice thing if we shipped a simple makefile in the top IronPython directory for people who don't have msbuild available. Sorry that we missed that suggestion when we went over these mail archives in preparation for the initial release. > Jim, any chance the binary can be given a more sane name like > ironp, ironpy or ipython instead of IronPythonConsole.exe? > Also it would be nice if the zip would extract in its own versioned > directory like in 0.6. I picked IronPythonConsole at the very start of the project knowing that it would be so bad that I'd have to change it eventually. As someone else pointed out, ipython is already in use. 'ironpy' is the most appealing of your list of options. Does anyone have a better suggestion? Do you have a problem with the .exe at the end of the name or just the length of IronPythonConsole? The packaging is a good suggestion as well. The tools that I use now to extract zip files will be default put the files in a directory with the name of the zip file, so the current design works fine on my box. I realize that isn't universal. One dilemma with extracting into a versioned directory is how often to change the name. Do you think the 0.7.1 should go into the same directory as 0.7 or not? > I only did very light testing: pystone runs and it's about 20 % > faster than cpython 2.4 (and 35% faster than 2.3). It seems > IronPython 0.7 is 2% faster at it than version 0.6 (always with mono > from svn, I don't have .net to compare). I'm glad to hear 0.7 is a little faster than 0.6 for you. I'd be curious to see numbers comparing mono 1.0 and 1.1 if you had them. There are no conscious attempts at performance optimization in 0.7. To save you the trouble of installing .NET, here are the numbers I got on my laptop: pystones/second (higher is better) 34K Python-2.3 38K Python-2.4 58K IronPython-0.7 on .NET 1.1 67K IronPython-0.7 on .NET 2.0beta1 The most interesting thing to me about these numbers is not the absolute difference, but the relative improvement. CPython from 2.3 to 2.4 got about 12% faster on pystone with a lot of Python specific development work. In going from .NET 1.1 to 2.0, IronPython got about 16% faster on the same benchmark with zero Python specific development. The ability to take advantage of these kinds of improvements in the underlying platform is a big part of what excites me about running on the CLI. My plans for getting to IronPython 1.0 don't include any significant work on performance optimization. I think that the performance is already good enough and the focus needs to be on CPython compatibility as well as really solid support for all of the CLI features. > Jim: is it correct that IP 0.7 doesn't run the pie-thon benchmark? > It seems it looks for > public object Invoke(object self, object arg1, object arg2, object > arg3) > in IronPython/Objects/PythonType.cs, but then there are also other issues. This is correct and embarrassing. I made some stupid changes in moving to 0.7 and wasn't running the right regression tests. In my defense, I've had one or two non-technical issues that were distracting me at the time. We'll work on getting pie-thon running again ASAP. Thanks - Jim From pythonmailing at web.de Tue Mar 29 20:06:01 2005 From: pythonmailing at web.de (Marek Kubica) Date: Tue, 29 Mar 2005 20:06:01 +0200 Subject: [IronPython] IronPython compilation with mono In-Reply-To: <695D7C410F74A644B5335E47FB73E17E037D983A@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E037D983A@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <20050329200601.000007ab@galileo> On Tue, 29 Mar 2005 09:18:02 -0800 "Jim Hugunin" wrote: > I picked IronPythonConsole at the very start of the project knowing > that it would be so bad that I'd have to change it eventually. As > someone else pointed out, ipython is already in use. 'ironpy' is the > most appealing of your list of options. Does anyone have a better > suggestion? ironpy is good, but I also like fepy or fepython :) > Do you have a problem with the .exe at the end of the name or just the > length of IronPythonConsole? To me it would be better having no .exe, but the bigger issue is the lenght of the IronPythonConsole. It could be symlinked to another name, but better simply provide a shorter name. And well, having a shorter name is better also on Windows, my system hat a real long %PATH% with all kinds of programs, so I would dislike typing IronPythonConsole instead of ironpy os something similar. greets, Marek From kfarmer at thuban.org Tue Mar 29 20:20:21 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 29 Mar 2005 10:20:21 -0800 Subject: [IronPython] IronPython compilation with mono Message-ID: fepy -- OK? fewer keystrokes, and google doesn't find "fepy.exe". It also has that science geek charm. ipy -- taken by spyware ip -- taken by spyware But then, I have some wonderfully long exe names here at work. I'd also as soon keep versions seperate, rather than nested. I've never considered a version number to be anything more than a label, since there isn't any universal way to distinguish the level of change from the version. That is, version numbers increment in a rather arbitrary manner: might as well just give them unique distribution. If the base libraries were stored in the GAC, one could use the standard config mechanisms for declaring which versions to use for side-by-side installations of IronPython. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Tue 3/29/2005 9:18 AM I picked IronPythonConsole at the very start of the project knowing that it would be so bad that I'd have to change it eventually. As someone else pointed out, ipython is already in use. 'ironpy' is the most appealing of your list of options. Does anyone have a better suggestion? Do you have a problem with the .exe at the end of the name or just the length of IronPythonConsole? The packaging is a good suggestion as well. The tools that I use now to extract zip files will be default put the files in a directory with the name of the zip file, so the current design works fine on my box. I realize that isn't universal. One dilemma with extracting into a versioned directory is how often to change the name. Do you think the 0.7.1 should go into the same directory as 0.7 or not? From jeffg at ActiveState.com Tue Mar 29 20:45:07 2005 From: jeffg at ActiveState.com (jeff griffiths) Date: Tue, 29 Mar 2005 10:45:07 -0800 Subject: [IronPython] IronPython compilation with mono In-Reply-To: <20050329200601.000007ab@galileo> References: <695D7C410F74A644B5335E47FB73E17E037D983A@RED-MSG-52.redmond.corp.microsoft.com> <20050329200601.000007ab@galileo> Message-ID: <4249A233.30209@activestate.com> Marek Kubica wrote: > On Tue, 29 Mar 2005 09:18:02 -0800 > "Jim Hugunin" wrote: > > >>I picked IronPythonConsole at the very start of the project knowing >>that it would be so bad that I'd have to change it eventually. As >>someone else pointed out, ipython is already in use. 'ironpy' is the >>most appealing of your list of options. Does anyone have a better >>suggestion? > > ironpy is good, but I also like fepy or fepython :) if this helps at all, the first thing I did on my Mac after getting 0.6 running last summer was to symlink /usr/bin/fepy to a shell script: #!/bin/bash mono /path/to/IronPythonConsole.exe ...or something. So to me, 'fepy' *is* IronPython. JeffG From lobrien at knowing.net Tue Mar 29 20:45:25 2005 From: lobrien at knowing.net (Larry O'Brien) Date: Tue, 29 Mar 2005 08:45:25 -1000 Subject: SPAM-LOW: RE: [IronPython] IronPython compilation with mono In-Reply-To: Message-ID: <20050329184601.EF85684D49@che.dreamhost.com> >>fepy -- OK? fewer keystrokes, and google doesn't find "fepy.exe". It >>also has that science geek charm. That must be why I like it! +1 From jimhug at microsoft.com Tue Mar 29 20:59:01 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Tue, 29 Mar 2005 10:59:01 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <695D7C410F74A644B5335E47FB73E17E037D99F0@RED-MSG-52.redmond.corp.microsoft.com> There has been a lot of feedback about the release site we've chosen and about the license used for this release. My first comment to everyone is that I like to get this frank and honest feedback. I want to build as large a community as possible around IronPython and it's helpful to understand where people's concerns lie. Please bear with me if replies to some of these questions take longer than replying to technical questions. It's not that I'm not reading and thinking about them, but they can be more difficult to answer. The feedback on the gotdotnet release site is the simplest. You're all basically right and our current setup has some serious flaws. I knew this before we made the 0.7 release. Rather than hold up the IronPython release to fix these issues with the site first, I thought it would be better if we got the release out there for people to use and then fixed the site. We're working on improving this. Some people can effectively work with things as they are and we're getting some valuable feedback from them. I hope and expect that we'll get more participation as we make the site experience better. The most serious questions are about the license itself. Many, if not all, of the license questions would be answered if we were using an existing OSI approved license. We certainly considered that option. At the end of the day our lawyers were more comfortable with the chosen license as it had been used in the past for Microsoft source releases. I agree that the proliferation of licenses is unfortunate; however, this is something that seems to be inevitable with large companies. IBM has at least three different licenses (IPL, CPL and EPL) that they wrote and decided to use for their OSS projects, so Microsoft isn't unique in having lawyers who believe that they can draft better licenses than other lawyers did in the past. I think that the terms of this license stand up very well on their own. However, we've clearly invited extra scrutiny by using a new license. Since I'm not an expert in these areas, I'd like to direct this initial discussion to Jason Matusow's blog (Swaroop already posted this): http://blogs.msdn.com/jasonmatusow/archive/2005/03/28/402992.aspx Let's see how that discussion goes and hopefully we can bring it back to this list with a better understanding of which issues are real and which are perceived. To address some of the specific feedback, I'm going to take Jonathan's list as a concise version of much of the questions to reply to in the spirit of the above. Jonathan LaCour wrote: > So, to review my pie-in-the-sky wishes to guarantee IronPython success: > 1. Switch to a similar, but respected license. This is a big discussion and I hope you can start it first with Jason and then bring it back here as mentioned above. > 2. Ditch the gotdotnet forums. Make the mailing list "the way". I'm not going to make the gotdotnet forums disappear overnight because there is a separate part of the IronPython community that might prefer those forums to a standard mailing list. However, I'm not going to make the mailing list go away either and the community gets to decide where the interesting discussion takes place. Right now most of the activity is here on the mailing list and if people continue to vote this way with their feet then you'll get your wish. > 3. Don't require a passport to file bugs. No passport to file bugs is easy. We'll send out instructions for how to do that by the end of the day. Of course, I suspect that you'd also like no passport to view the bug database. This is also good, but will probably take longer. > 4. Have a public SVN or CVS repository. This is an excellent suggestion but again not one that we can implement overnight. I know you'd specifically like SVN or CVS, but do you need those or would any public repository work so long as it had simple command-line access and was cross-platform? > 5. Be open to accepting external patches. I'm certainly open to this idea if I could be convinced that the value of the patches would be worth the large effort needed to accept them at this time. Given the company that I work for, I would have to spend a LOT of time with lawyers working out the right contribution policy in order to accept even small patches. This extreme level of legal caution is part of working for a large company. I don't believe that's the best way for me to spend my time right now in order to build the best IronPython 1.0. After 1.0, the value of building a strong external developer community goes up and I expect to revisit this question. As I said in my earlier email, I'd also like to figure out a way to encourage contributions in the short-term not to the IronPython core engine but in the space of porting CPython extension modules or building new IronPython-specific modules. Technically these are very appealing places to accept contributions because each module is a nice modular entity. Needless to say, there are a few other legal and infrastructure questions that I'm trying to answer before opening a new topic like this one. > 6. Have at least one other "committer" (to help lighten the load on > you). I do have another committer, Martin Maly, who is working very hard on the tree. He is the one who's already fixed most of the reported bugs and is rapidly growing in his expertise with the source tree. Martin also works for Microsoft, directly across the hall from me, so I realize I don't get any bonus points on this one. Martin will be the one to send mail later today about an interim solution for at least filing bugs without a passport. Thanks - Jim From danlash at gmail.com Tue Mar 29 21:51:24 2005 From: danlash at gmail.com (Dan Lash) Date: Tue, 29 Mar 2005 14:51:24 -0500 Subject: SPAM-LOW: RE: [IronPython] IronPython compilation with mono In-Reply-To: <20050329184601.EF85684D49@che.dreamhost.com> References: <20050329184601.EF85684D49@che.dreamhost.com> Message-ID: "fepy" has my vote; it's short yet concise. -Dan On Tue, 29 Mar 2005 08:45:25 -1000, Larry O'Brien wrote: > >>fepy -- OK? fewer keystrokes, and google doesn't find "fepy.exe". It > >>also has that science geek charm. > > That must be why I like it! +1 > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From martmaly at exchange.microsoft.com Tue Mar 29 22:52:25 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 29 Mar 2005 12:52:25 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701948632@df-chewy-msg.exchange.corp.microsoft.com> There are several ways to report bugs you find in IronPython. Because our priority when it comes to bugs is to find them, report them and fix them, the actual means of reporting is secondary. As we keep searching for ideal long term solution, our currently preferred way for you to report bugs is the GotDotNet website. Even though using it requires passport, it also gives you the opportunity to browse the bug database, avoid duplicates and track progress we are making on fixing the bugs. You can also report bugs by sending the email to this mailing list or to: "ironpy at microsoft.com" (the email address that is mentioned in the source file headers). Obviously, this approach doesn't give you access to all bugs reported and adds some burden on us to sort through the reports. For that reason, if you report bugs over email, please include [Bug Report] (or anything else in that sense) in the email subject to make it easier for us to identify them. Thanks Martin > > 3. Don't require a passport to file bugs. > No passport to file bugs is easy. We'll send out instructions for how > to do that by the end of the day. Of course, I suspect that you'd > also like no passport to view the bug database. This is also good, > but will probably take longer. From terry at triplett.org Wed Mar 30 00:27:02 2005 From: terry at triplett.org (Terry L. Triplett) Date: Tue, 29 Mar 2005 17:27:02 -0500 Subject: SPAM-LOW: RE: [IronPython] IronPython compilation with mono In-Reply-To: References: <20050329184601.EF85684D49@che.dreamhost.com> Message-ID: <4249D636.5070302@triplett.org> fepy +1 From martmaly at exchange.microsoft.com Wed Mar 30 01:40:16 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 29 Mar 2005 15:40:16 -0800 Subject: [IronPython] RE: Inheriting Python classes from .NET classes Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F70194871F@df-chewy-msg.exchange.corp.microsoft.com> You found a valid bug in IronPython. One of the reasons this doesn't work is that we currently don't support inheriting from .Net classes with no public constructors. That part is pretty easy to fix. However, there may be other roadblocks (beyond the one I found so far) to overcome to get your case working. The reason I think so is that MarshalByRefObject is a special class in the .Net framework and IronPython may not be ready to handle all its facets. We are working on it though. Thanks for the bug report! Martin > On Monday, March 28, 2005 10:36 PM > Sriram Krishnan Wrote: > > I've been playing around with the 0.7 release for the last couple of days. > I > tried to write Don Box's Http.Sys ASP.NET web server (Google for > cache:http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-03- > 30T07:38:4 > 5Z). > > He extends from MarshalByRefObject > > public class SubDomainCode : MarshalByRefObject > {... > > > When I try to do the same thing in a Python class by writing > > class SubDomainCode(MarshalByRefObject) > > I get a NotImplementedException. I've loaded the required assemblies > properly. What am I doing wrong here? Or is inheriting .NET types not > implemented yet in 0.7? > > Thanks, > Sriram From lupus at ximian.com Wed Mar 30 12:30:58 2005 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 30 Mar 2005 12:30:58 +0200 Subject: [IronPython] IronPython compilation with mono In-Reply-To: <695D7C410F74A644B5335E47FB73E17E037D983A@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E037D983A@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <20050330103057.GZ14394@debian.org> On 03/29/05 Jim Hugunin wrote: > Cool. It sounds like it would be a nice thing if we shipped a simple > makefile in the top IronPython directory for people who don't have Yep. > else pointed out, ipython is already in use. 'ironpy' is the most > appealing of your list of options. Does anyone have a better > suggestion? ironpy gets my vote, too. I don't like FePy myself: there is no py chemical element. You could spell it FePY, but, first, I don't like multi-case words for commands (especially command line unix ones) and second FePY doesn't exist as a molecule:-) > Do you have a problem with the .exe at the end of the name or just the > length of IronPythonConsole? The .exe is not an issue. Any sane distributor will ship a shell script with basically "mono ironpy.exe" in it and name it without the .exe. > The packaging is a good suggestion as well. The tools that I use now to > extract zip files will be default put the files in a directory with the > name of the zip file, so the current design works fine on my box. I Now, this begs the question: where the tools hacked to do that because too many windows people would not create a proper archive with all the files in a directory or the other way around? :-) > realize that isn't universal. One dilemma with extracting into a > versioned directory is how often to change the name. Do you think the > 0.7.1 should go into the same directory as 0.7 or not? The accepted way to do it is to name the directory as: project-version Since 0.7.1 is a different version the directory would be different as well. > I'm glad to hear 0.7 is a little faster than 0.6 for you. I'd be > curious to see numbers comparing mono 1.0 and 1.1 if you had them. Sure (using mono from svn, so about the same as 1.1.5 and an older mono close to 1.0.5): pystones/second: 34950 mono 1.0.x 35971 python 2.3 40322 python 2.4 49121 mono 1.1.x So it's a 40% improvement in this case when going from mono 1.0 to 1.1.x. The pie-thon bench gives some more interesting results: mono 1.0 b0 = 3.92477035522461 -- [4.13869476318359, 3.71084594726563] b1 = 0.596031188964844 -- [0.700836181640625, 0.491226196289063] b2 = 0.375785827636719 -- [0.369209289550781, 0.382362365722656] b3 = 1.314697265625 -- [1.31097412109375, 1.31842041015625] b4 = 1.41418838500977 -- [1.41653442382813, 1.41184234619141] b5 = 86.0883674621582 -- [86.6897125244141, 85.4870223999024] b6 = 2.75988006591797 -- [2.76504516601563, 2.75471496582031] mono svn b0 = 2.2257194519043 -- [2.46144104003906, 1.98999786376953] b1 = 0.433116912841797 -- [0.525177001953125, 0.341056823730469] b2 = 0.314487457275391 -- [0.311737060546875, 0.317237854003906] b3 = 0.912036895751953 -- [0.901985168457031, 0.922088623046875] b4 = 0.782825469970703 -- [0.75592041015625, 0.809730529785156] b5 = 3.01733779907227 -- [3.10484313964844, 2.92983245849609] b6 = 1.00485610961914 -- [0.968063354492188, 1.04164886474609] Now, if you exclude b5 (as you can see we didn't bother improving exception throwing performance in 1.0: it turns out it's needed also when running nemerle and Java code) we have an overall 80% improvement. More speedups are expected from the changes we plan to do to the runrime and jit in the next few months before mono 1.2. > pystones/second (higher is better) > 34K Python-2.3 > 38K Python-2.4 > 58K IronPython-0.7 on .NET 1.1 > 67K IronPython-0.7 on .NET 2.0beta1 I assume you mean 0.6, since 0.7 doesn't run on 1.1. > the same benchmark with zero Python specific development. The ability > to take advantage of these kinds of improvements in the underlying > platform is a big part of what excites me about running on the CLI. Yep, it's the reason I advocated people target IL code for dynamic langauges before I even knew about ironpython:-) > My plans for getting to IronPython 1.0 don't include any significant > work on performance optimization. I think that the performance is > already good enough and the focus needs to be on CPython compatibility > as well as really solid support for all of the CLI features. Some (even limited) support for specialization is needed to get the real speed boosts, anyway, IMHO. But of course having ironpython run a wider range of code than it currently does is a better choice to spend time on. > This is correct and embarrassing. I made some stupid changes in moving > to 0.7 and wasn't running the right regression tests. In my defense, > I've had one or two non-technical issues that were distracting me at the > time. We'll work on getting pie-thon running again ASAP. Thanks. Being able to run the standard python tests would be good, too, to have a grasp of where ironpython is wrt cpython compatibility. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Wed Mar 30 12:51:55 2005 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 30 Mar 2005 12:51:55 +0200 Subject: [IronPython] Ironpython 0.7 released! In-Reply-To: <695D7C410F74A644B5335E47FB73E17E037D99F0@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E037D99F0@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: <20050330105155.GA14394@debian.org> On 03/29/05 Jim Hugunin wrote: > > 2. Ditch the gotdotnet forums. Make the mailing list "the way". > I'm not going to make the gotdotnet forums disappear overnight because > there is a separate part of the IronPython community that might prefer > those forums to a standard mailing list. However, I'm not going to make > the mailing list go away either and the community gets to decide where > the interesting discussion takes place. Right now most of the activity > is here on the mailing list and if people continue to vote this way with > their feet then you'll get your wish. Mentioning this list prominetly in the gotdotnet pages would help to ensure the list is know to people that approached ironpython only recently. > > 4. Have a public SVN or CVS repository. > This is an excellent suggestion but again not one that we can implement > overnight. I know you'd specifically like SVN or CVS, but do you need > those or would any public repository work so long as it had simple > command-line access and was cross-platform? It should be accessible with free tools, svn or cvs are just the most common. > > 5. Be open to accepting external patches. > I'm certainly open to this idea if I could be convinced that the value > of the patches would be worth the large effort needed to accept them at Well, nobody is going to start contributing any significant patch unless you change the policy so people won't be able to convince you (which can be done only with working code). > this time. Given the company that I work for, I would have to spend a > LOT of time with lawyers working out the right contribution policy in > order to accept even small patches. This extreme level of legal caution > is part of working for a large company. I don't believe that's the best > way for me to spend my time right now in order to build the best > IronPython 1.0. After 1.0, the value of building a strong external > developer community goes up and I expect to revisit this question. I understand the legal issues involved. If the license was clarified wrt derived works it would be easier to have someone maintain a tree with external contributions that tracked your changes closesly, so the official tree maintained at MS would not need to be concerned with the issues your legal department has and the other people could contribute. Anyway, I expect most people to remain in a wait and see state until the license issues are solved or clarified. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From martmaly at exchange.microsoft.com Thu Mar 31 01:16:54 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Wed, 30 Mar 2005 15:16:54 -0800 Subject: [IronPython] Ironpython 0.7 released! Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701948AE8@df-chewy-msg.exchange.corp.microsoft.com> Paolo, thanks for your suggestion concerning the mailing list reference. We have posted the address to this mailing list on our GotDotNet workspace homepage. Martin > On March 30, 2005 2:52 AM, Paolo Molaro Wrote: > > > On 03/29/05 Jim Hugunin wrote: > > > 2. Ditch the gotdotnet forums. Make the mailing list "the way". > > I'm not going to make the gotdotnet forums disappear overnight because > > there is a separate part of the IronPython community that might prefer > > those forums to a standard mailing list. However, I'm not going to make > > the mailing list go away either and the community gets to decide where > > the interesting discussion takes place. Right now most of the activity > > is here on the mailing list and if people continue to vote this way with > > their feet then you'll get your wish. > > Mentioning this list prominetly in the gotdotnet pages would help > to ensure the list is know to people that approached ironpython > only recently. From iain.cartwright at atari.com Thu Mar 31 06:27:25 2005 From: iain.cartwright at atari.com (Cartwright, Iain) Date: Thu, 31 Mar 2005 14:27:25 +1000 Subject: [IronPython] VS 2005/#Develop/MonoDevelop plugins Message-ID: For dev's coming from a Windows/.NET environment IDE plug-ins are in my opinion a real drawcard. It would really aid the progress and adoption of IronPython if these are made available as soon as possible. I am guessing that this is beyond the scope of Jim and Martin's tasks. Perhaps this would make a good ironpy community project? VS 2005 I have looked briefly at the MS VSIP SDK (http://msdn.microsoft.com/vstudio/extend/) - It appears to be a lot of work to get full language support + integrated help + ironpy window. #Develop The Boo folks have working code that might be useful as a basis for a #develop plug-in. MonoDevelop Appears to use the same/similar plug-in format to #Develop. It would of course be best to have MS do the VS 2005 plug-in and release it as (shared source) example code for the VSIP program maybe? iain From jimhug at microsoft.com Thu Mar 31 23:49:10 2005 From: jimhug at microsoft.com (Jim Hugunin) Date: Thu, 31 Mar 2005 13:49:10 -0800 Subject: [IronPython] Renaming IronPythonConsole Message-ID: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com> Thanks for the feedback on names for IronPythonConsole. I notice that there were zero votes for keeping the name as is . The two names that had votes in favor of them were fepy and ironpy. There were a few more of you in favor of fepy than ironpy for that science geek charm; however, I didn't notice a strong outpouring of feelings either way. I'd prefer to go with ironpy for the 0.7.1 release and see what the response is. This name is far from set in stone and comments and suggestions are always welcome. Thanks - Jim From mailinglist.account at gmail.com Thu Mar 31 23:57:14 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Thu, 31 Mar 2005 23:57:14 +0200 Subject: [IronPython] Renaming IronPythonConsole In-Reply-To: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com> References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com> Message-ID: Jim, Sorry I didn't get my vote in before you close the ballot.. But I do what to register my vote for ipython Btw, that's what I have named the console already and it is natural for me to continue to type python with just a leading i.... Give it a try, I think you may like it.. Anthony On Thu, 31 Mar 2005 13:49:10 -0800, Jim Hugunin wrote: > Thanks for the feedback on names for IronPythonConsole. I notice that > there were zero votes for keeping the name as is . > > The two names that had votes in favor of them were fepy and ironpy. > There were a few more of you in favor of fepy than ironpy for that > science geek charm; however, I didn't notice a strong outpouring of > feelings either way. I'd prefer to go with ironpy for the 0.7.1 release > and see what the response is. This name is far from set in stone and > comments and suggestions are always welcome. > > Thanks - Jim > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From miguel at ximian.com Fri Mar 25 02:54:28 2005 From: miguel at ximian.com (Miguel de Icaza) Date: Fri, 25 Mar 2005 01:54:28 -0000 Subject: [IronPython] Ironpython 0.7 released! [mono?] In-Reply-To: <4243012E.3020809@activestate.com> References: <695D7C410F74A644B5335E47FB73E17E024639B1@RED-MSG-52.redmond.corp.microsoft.com> <200503240145.19166.terry@triplett.org> <20050324105712.GA66885@thailand.botanicus.net> <4243012E.3020809@activestate.com> Message-ID: <1111715130.3551.148.camel@linux.site> Hello, > > http://www.microsoft.com/downloads/details.aspx?FamilyID=B7ADC595-717C-4EF7-817B-BDEFD6947019&displaylang=en > > Has anyone tried this with Mono, on OS X or Linux? IronPython will work with Mono if you use the SVN version; You need at least version 42243. We were only missing one method to run IronPython; Still, no regression test suite, but everything else seems ok.