I got it once, but tried again and it went away.
On 9/6/06, Tim Riley <[EMAIL PROTECTED]> wrote: > I keep getting an error from codeplex when I try to download 1.0.bin. Am I > the only one? > > > On 9/5/06, Jim Hugunin < [EMAIL PROTECTED]> wrote: > > I'm extremely happy to announce that we have released IronPython 1.0 > today! > > http://www.codeplex.com/IronPython > > > > I started work on IronPython almost 3 years ago. My initial motivation > for the project was to understand all of the reports that I read on the web > claiming that the Common Language Runtime (CLR) was a terrible platform for > Python and other dynamic languages. I was surprised to read these reports > because I knew that the JVM was an acceptable platform for these languages. > About 9 years ago I'd built an implementation of Python that ran on the JVM > originally called JPython and later shortened to Jython. This > implementation ran a little slower than the native C-based implementation of > Python (CPython), but it was easily fast enough and stable enough for > production use - testified to by the large number of Java projects that > incorporate Jython today. > > > > I wanted to understand how Microsoft could have screwed up so badly that > the CLR was a worse platform for dynamic languages than the JVM. My plan > was to take a couple of weeks to build a prototype implementation of Python > on the CLR and then to use that work to write a short pithy article called, > "Why the CLR is a terrible platform for dynamic languages". My plans > quickly changed as I worked on the prototype, because I found that Python > could run extremely well on the CLR - in many cases noticeably faster than > the C-based implementation. For the standard pystone benchmark, IronPython > on the CLR was about 1.7x faster than the C-based implementation. > > > > The more time I spent working on IronPython and with the CLR, the more > excited I became about its potential to finally deliver on the vision of a > single common platform for a broad range of languages. At that same time, I > was invited to come out to Microsoft to present IronPython and to talk with > members of the CLR team about technical issues that I was running into. I > had a great time that day working through these issues with a group of > really smart people who all had a deep understanding of virtual machines and > language implementation. After much reflection, I decided to join the CLR > team at Microsoft where I could work with the platform to make it an even > better target for dynamic languages and be able to have interesting > technical discussions like that every day. > > > > The first few months at Microsoft were a challenge as I learned what was > involved in working at a large company. However, once the initial hurdle > was over I started experiencing the things that motivated me to come here in > the first place. The team working on dynamic languages in general and > IronPython in particular began to grow and I got to have those great > technical discussions again about both how to make IronPython as good as it > could be and how to make the CLR an even better platform. We began to take > advantage of the great new features for dynamic languages already shipping > in .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new > generics system that was seamlessly integrated with the existing reflection > infrastructure. > > > > We were also able to release IronPython publicly from Microsoft with a > BSD-style license. In the agile spirit of the project, we put out a new > release of IronPython once every three weeks (on average) over the course of > the project. This helped us connect well with our daring early adopters and > receive and incorporate their feedback to make IronPython better. We've had > countless excellent discussions on the mailing list on everything from > supporting value types to calling overloaded methods. Without the drive and > input of our users, IronPython would be a much weaker project. > > > > IronPython is about bringing together two worlds. The key value in > IronPython is that it is both a true implementation of Python and is > seamlessly integrated with the .NET platform. Most features were easy and > natural choices where the language and the platform fit together with almost > no work. However, there were challenges from the obvious cases like > exception type hierarchies to the somewhat esoteric challenges concerning > different methods on strings. We spent long days and sometimes weeks looking > for the best answers to these challenging problems and in the end I think > that we have stayed true to both Python and .NET. > > > > To drive our Python compatibility, we run a large portion of the standard > Python regression test suite in addition to a large custom test suite we > added that runs IronPython and CPython side-by-side to test for identical > behavior whenever possible. Despite all of this work, there will still be > differences between IronPython 1.0 and CPython. The most obvious difference > is that IronPython is missing a number of standard C-based extension modules > so things like "import bsddb" will fail. We maintain a detailed list of > differences between the two implementations and aim to reduce the size of > this list in every release. > > > > IronPython has also striven for deep integration with the CLR. For the > implementation this is a great thing as it lets us take advantage of > highly-tuned components developed for other languages such as the > just-in-time compiler, garbage collector, debugging support, reflection, > dynamic loading and more. This integration is also valuable to IronPython > developers as it lets them easily use any and all libraries built for .NET > from their Python code. > > > > This is the 1.0 release of IronPython. It's more complete and well tested > than any other 1.0 product I have personally released in my career. > However, like any other software product it's not perfect. You can search > for known issues and let us know about any new ones that you find in our > public bug database. We're continuing to work on IronPython and we want > your input on how to make 1.1 and future releases even better. > > > > It's been an exciting journey for me to see IronPython go from a rough > prototype playing around with some ideas to a solid 1.0 release. This never > could have happened without all the people who've contributed to this > project along the way. My thanks go out to all the users who braved our > early releases and passed along their problems and suggestions. My thanks > also go out to the amazing group of people here at Microsoft who've come to > join this project and drive it to this quality 1.0 release. > > > > Shipping IronPython 1.0 isn't the end of the road, but rather the > beginning. Not only will we continue to drive IronPython forward but we're > also looking at the bigger picture to make all dynamic languages deeply > integrated with the .NET platform and with technologies and products built > on top of it. I'm excited about how far we've come, but even more excited > by what the future holds! > > > > Thanks - Jim Hugunin (for the IronPython Team) > > _______________________________________________ > > users mailing list > > [email protected] > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
