[IronPython] Empty CodeMethodReturnStatement causes exception...

[Nathan Baulch]

I'm completely new to Python, so please forgive my ignorance.
I thought a good way to learn would be to target it with my code
generation tool that uses CodeDom. However I'm getting an exception
when my code contains empty return statements
(CodeMethodReturnStatement) for methods that return void.

Is this a bug or does it not make sense to return void in Python?
Is there a way around this without breaking other languages?

Cheers,
Nathan
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython is Referenced on SlashDot

[Martin Maly]

In case you missed it, there is an IronPython discussion on
SlashDot:

 

http://developers.slashdot.org/developers/06/09/06/2134234.shtml

 

Martin






___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] ipy support in msxsl:script blocks

[M. David Peterson]

Excellent!  Thanks for the advice, Dino!  I will add this to my priority list and update accordingly.
 
In a (somewhat) related note, I have been pulling together a quick demo that incorporates IronPython, LINQ, and XSLT 2.0 extensions functions to provide what I believe will prove to be an extremely lethal combination as this demo develops.  The first part is complete, though a bit rough around the edges.

 
This builds directly from  from a few weeks back.  The post was an XSLT 2.0 answer to Steve Eichert's "Solving Scoble's problems ..."  post from a few weeks back.  However, this time around I have extended Steve's original code base  to implement a slight more dynamic approach to the filter settings such that you can add, subtract, multiply, and/or divide the filter settings using an external XML file.
 
I have quite a bit more to add to this, including the mentioned extension functions for XSLT 2.0.  More updates throughout today and tomorrow, the result of which will become a new post when complete. However, I'll avoid flooding the list with each update, and instead point you to the timeline RSS <
http://dev.pypod.net/timeline?ticket=on&changeset=on&milestone=on&wiki=on&wiki=on&max=50&daysback=90&format=rss
> feed if you have interest in keeping up with the changes. 
 
With this in mind, if any of you have some ideas you would like to throw my direction, or furthermore would like to view/play with the code base, you can do so via the PyPod.Net Click-Once app, or checkout the code base from SVN directly.

 
The svn repo is located @ http://src.pypod.net/trunk
 
You can view the code base via the Trac interface @ http://dev.pypod.net/browser/trunk
 
And, as already mentioned in a separate thread, the PyPod.Net app is located @,
 
http://pypod.net/console/index.html
 
To run the (BIG TIME HACK) test,
 
>>> import linqtest
 
(note: Dependent upon your system, you may get a "SystemError: Unable to connect to the remote server" error at first of which you will then more than likely be asked for permission for the IP Console to access the internet)

 
As pointed out, the above is a quick and dirty hack just to test and make sure it works properly.  I am in the middle of building a more efficient caching mechanism such that the XML data for processing can be accessed once, cached locally, and then used for each subsequent test run unless a flag is set to access the live stream again.  WIth this in mind, please be aware that the XML data file that is currently set to be accessed dynamically with each new run is ~17megs, so it will take a bit before you see the result of the filtering printed to the console.

 
I'll update with extended details when it seems appropriate to do so.
 
Until then, please let me know of any ideas any of you would like to see developed as part of this code base.  Sample code is all fine and dandy, but I would rather write something that would be immediatelly useful and reusable to a broader base of folks than would be your typical sample app if at all possible.

 
Best regards,
 
On 9/6/06, Dino Viehland <[EMAIL PROTECTED]> wrote:




The best thing you could do for Saxon.NET right now is to support ICustomTypeDescriptor in addition to supporting Reflection.  The one downside is that ICustomTypeDescriptor isn't as comprehensive as 
Reflection.Emit – for example it doesn't support calling methods.  But it does support getting properties.  So you'll want to back that up w/ Reflection, and hopefully in time there'll be a solution which will encompass all of these.

 

From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of M. David PetersonSent:
 Tuesday, September 05, 2006 2:27 PMTo: Discussion of IronPythonSubject: Re: [IronPython] ipy support in msxsl:script blocks

 
btw, the newly released docs in regards to develping extension functions for Saxon on .NET are located @ 
http://www.saxonica.com/documentation/extensibility/dotnetextensions.html 

On 9/5/06, M. David Peterson <[EMAIL PROTECTED]> wrote:

Worth noting, from my post earlier today (
http://www.oreillynet.com/xml/blog/2006/09/mhksaxon_saxon_88basic_and_sch_1.html ) regarding the release of Saxon on .NET 8.8,* in the .NET product, extension functions written in C# or other .NET
 languages can now be invoked
While the same is more than likely true in regards to the ability to access extension functions written in Python, this is one area I can help with more so than anything else as this was a significant area of study and development I put into 
Saxon.NET before handing over the reigns to Dr. Kay in February.   In addition, with his guidance, I've since continued forward in working on various areas of research and development.  With this in mind, in regards to,




 
We'll need to work w/ so

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Yasir Alvi]

Hi Keith.  They've been tested with the July CTP and not against any 
newer .NET 3 bits so we can only guarantee workability on the July bits.

Thanks
Yasir

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer
Sent: Wednesday, September 06, 2006 12:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] [ANN] IronPython 1.0 released today!

Should we expect the samples to work with the RC of .NET 3, or are they limited 
to July CTP?

-
Keith J. Farmer // [EMAIL PROTECTED]


___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] ipy support in msxsl:script blocks

[Dino Viehland]

The best thing you could do for Saxon.NET right now is to
support ICustomTypeDescriptor in addition to supporting Reflection.  The
one downside is that ICustomTypeDescriptor isn’t as comprehensive as
Reflection.Emit – for example it doesn’t support calling
methods.  But it does support getting properties.  So you’ll
want to back that up w/ Reflection, and hopefully in time there’ll be a solution
which will encompass all of these.

 



From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of M. David Peterson
Sent: Tuesday, September 05, 2006 2:27 PM
To: Discussion of IronPython
Subject: Re: [IronPython] ipy support in msxsl:script blocks



 

btw, the newly released docs in
regards to develping extension functions for Saxon on .NET are located @ http://www.saxonica.com/documentation/extensibility/dotnetextensions.html




On 9/5/06, M. David Peterson
<[EMAIL PROTECTED]> wrote:



Worth noting, from my post
earlier today (http://www.oreillynet.com/xml/blog/2006/09/mhksaxon_saxon_88basic_and_sch_1.html
) regarding the release of Saxon on .NET 8.8,

* in the .NET product, extension functions written in C# or other .NET
 languages can now be invoked


While the same is more than likely true in regards to the ability to access
extension functions written in Python, this is one area I can help with more so
than anything else as this was a significant area of study and development I
put into Saxon.NET before handing over the reigns to Dr. Kay in February.
  In addition, with his guidance, I've since continued forward in working
on various areas of research and development.  With this in mind, in
regards to,







 

We'll need to work w/ some other teams within the company to
make sure we can get the right amount of support in the right places to make
this all come together.  Thanks for bringing this to our attention.



 





While for obvious reasons I can't help with the internal
System.Xml.Xsl code base, I can help with the Saxon.NET code base.  If I
can be of help, please let me know :) 











On 9/5/06, Dino Viehland <
[EMAIL PROTECTED]> wrote:

The answer to this appears to be no - The XSL processor uses
Reflection to try and discover the method to be called.  In
IronPython reflection won't tell you what methods are available.  We
do support the ICustomTypeDescriptor interface which is another way to get this
information (which enables scripting WPF), but unfortunately XSL isn't falling
back to that. 

We'll need to work w/ some other teams within the company to make sure we can
get the right amount of support in the right places to make this all come
together.  Thanks for bringing this to our attention.  I'm
not going to open a bug on this (because it's not necessarily an IP issue) but
I believe we will be tracking this one (and similar issues) closely. 


From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Jesse Wiles 
Sent: Tuesday, September 05, 2006 8:00 AM
To: Discussion of IronPython
Subject: [IronPython] ipy support in msxsl:script blocks

Hi,

Can I script XSL extension objects using Iron Python?

Jesse Wiles 
___
users mailing list
users@lists.ironpython.com

http://lists.ironpython.com/listinfo.cgi/users-ironpython.com











-- 
/M:D

M. David Peterson
http://mdavid.name
| http://www.oreillynet.com/pub/au/2354









-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354







___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Dino Viehland]

You're not the only one - there seems to be intermittent issues on CodePlex 
(they also released a new version yesterday).  It does seem to come and go so 
closing down your browser and trying again works.  We're pinging the CodePlex 
team to try and get the issue resolved.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 6:43 AM
To: Discussion of IronPython
Subject: Re: [IronPython] [ANN] IronPython 1.0 released today!

Hi,
I did get it downloaded yesterday and up and running today.
Jeff



 "Tim Riley"
 <[EMAIL PROTECTED]
 >  To
 Sent by:  "Discussion of IronPython"
 [EMAIL PROTECTED] 
 ts.ironpython.com  cc

   Subject
 09/06/2006 08:32  Re: [IronPython] [ANN] IronPython
 AM1.0 released today!


 Please respond to
   Discussion of
IronPython
 <[EMAIL PROTECTED]
python.com>






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 t

[IronPython] Change in behaviour

[Jörgen Stenarson]

Hi,

congratulations on the 1.0 release!

Today after downloading the 1.0 release and trying it with my 
experimental readline code I got a crash when trying to get a reference 
to the PythonCommandLine object. The minimum code example that shows 
this behaviour:


in file prov.py:

import clr
clr.AddReference("ipy.exe")
import IronPythonConsole
print IronPythonConsole.PythonCommandLine.MyConsole


which gives the following result using IronPython-1.0

C:\IronPython-1.0>ipy -i prov.py
Traceback (most recent call last):
   File C:\IronPython-1.0\prov.py, line 4, in Initialize
AttributeError: 'module' object has no attribute 'PythonCommandLine'
 >>> dir(IronPythonConsole)
['BasicConsole', 'IConsole', 'Style', 'SuperConsole', '__builtins__', 
'__dict__', '__name__']
 >>>

With IronPython-RC1 I get the following:

C:\IronPython-1.0-RC1>ipy -i prov.py
IronPythonConsole.BasicConsole
 >>> dir(IronPythonConsole)
['BasicConsole', 'IConsole', 'PythonCommandLine', 'Style', 
'SuperConsole', '__builtins__', '__dict__', '__name__']
 >>>


Is there a new way to get to the commandline object now or some other 
fix I can do?

/Jörgen
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Keith J. Farmer]

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]  > 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

[IronPython] [ANN] HOWTO Screencast: Install IronPython

[mattgriffith-ironpython]

I created a 5 minute screencast that shows how to install IronPython.
You can view it here:

http://mattgriffith.net/PermaLink.aspx?guid=0b9de84a-d84e-484c-b06f-8ff75ab70b9f

I used RC1 in the screencast but the same procedure works for IronPython 1.0.

Matt Griffith
http://mattgriffith.net
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] [ANN] IronPython 1.0 released today!

[jcollett]

Hi,
I did get it downloaded yesterday and up and running today.
Jeff


   
 "Tim Riley"   
 <[EMAIL PROTECTED] 
 >  To 
 Sent by:  "Discussion of IronPython"  
 [EMAIL PROTECTED] 
 ts.ironpython.com  cc 
   
   Subject 
 09/06/2006 08:32  Re: [IronPython] [ANN] IronPython   
 AM1.0 released today! 
   
   
 Please respond to 
   Discussion of   
IronPython 
 <[EMAIL PROTECTED] 
python.com>
   
   




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 pr

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Charlie Moad]

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 

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Tim Riley]

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/IronPythonI 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 ai

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Stanislas Pinte]

On behalf of http://www.ertmssolutions.com, thanks a lot again!

Stan.

Giles Thomas a ?crit :
> On behalf of all of us at Resolver, congratulations!  Many thanks to 
> everyone on the IP team for making such a great product.
> 
> All the best for future releases.
> 
> 
> Giles
> 


-- 
-
   Stanislas Pinte e-mail: [EMAIL PROTECTED]
   ERTMS Solutions   http://www.ertmssolutions.com
   Rue de l'Autonomie, 1 Tel:+ 322 - 522.06.63
   1070Bruxelles  Fax:   + 322 - 522.09.30
-
   Skype (http://www.skype.com) id:  stanpinte
-

___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Giles Thomas]

On behalf of all of us at Resolver, congratulations!  Many thanks to 
everyone on the IP team for making such a great product.

All the best for future releases.


Giles

-- 
Giles Thomas
Resolver Systems
[EMAIL PROTECTED]




Jim Hugunin 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.

Re: [IronPython] [ANN] IronPython 1.0 released today!

[Keith J. Farmer]

Should we expect the samples to work with the RC of .NET 3, or are they limited 
to July CTP?

-
Keith J. Farmer // [EMAIL PROTECTED]


___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] CodePlex dump is discontinued

[Sanghyeon Seo]

With recent updates to CodePlex, it is now possible to download any
revisions, even very old ones, from the project start. Previously,
only recent revisions were listed.

So there's few reasons to continue my CodePlex dump service. Therefore
it's discontinued now:
http://sparcs.kaist.ac.kr/~tinuviel/codeplex/

Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com