I had the same problem, but it downloaded fine after several retries. Mark
On Wed, 2006-09-06 at 11:10 -0700, Keith J. Farmer wrote: > I saw that. After logging in, I was able to successfully download. I don't > know if it was a timing issue or a login issue. > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Tim Riley > Sent: Wed 9/6/2006 6:32 AM > To: Discussion of IronPython > Subject: Re: [IronPython] [ANN] IronPython 1.0 released today! > > > 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] <mailto:[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
