Re: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython

[Andrew Schaeffer]

This may be a stretch here but how about Pymento?

>From pimento -- a pepper in the chili family that are grown and used 
>throughout the world because of their many flavors and flexible uses.


Drew Schaeffer

NorthPoint Solutions, LLC

130 West 42nd Street

New York, NY  10036

T: 212-819-1700

F: 212-398-5533



http://www.northps.com


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Monday, October 15, 2007 7:17 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Announcement: Project to get some 
CPython C extensions running under IronPython

Giles Thomas wrote:
> [snip..]
> That looks like a pretty popular choice generally - quite a few people have 
> posted off-list saying the same.  I'll get in touch with the NumPy developers.
>
> One further question for this list, before I create a repository and mailing 
> list elsewhere for the project - what should the project be called?  The best 
> one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
> you get the picture) and I'd be really grateful if someone could come up with 
> a less appalling pun...
>
>

Aipysurus - a genus of sea snake with the letters 'py' in its name?

http://en.wikipedia.org/wiki/Aipysurus

The "Aipysurus laevis" is also known as the golden sea snake!

:-)

Michael

> Cheers,
>
> Giles
>

___
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] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython

[Michael Foord]

Giles Thomas wrote:
> [snip..]
> That looks like a pretty popular choice generally - quite a few people have 
> posted off-list saying the same.  I'll get in touch with the NumPy developers.
>
> One further question for this list, before I create a repository and mailing 
> list elsewhere for the project - what should the project be called?  The best 
> one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
> you get the picture) and I'd be really grateful if someone could come up with 
> a less appalling pun...
>
>   

Aipysurus - a genus of sea snake with the letters 'py' in its name?

http://en.wikipedia.org/wiki/Aipysurus

The "Aipysurus laevis" is also known as the golden sea snake!

:-)

Michael

> Cheers,
>
> Giles
>   

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

Re: [IronPython] Can anybody reproduce this issue under ipy 2.0 a5 (expr if cond else expr)?

[Dave Fugate]

Thanks for reporting this!  I've filed the bug report here - 
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13320.

Dave

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vizcayno 
Tamparantan
Sent: Monday, October 15, 2007 2:12 PM
To: users@lists.ironpython.com
Subject: [IronPython] Can anybody reproduce this issue under ipy 2.0 a5 (expr 
if cond else expr)?

For ipy 2.0 alpha 5, try this:
h = 'hello'
b = 'bye'
print h if h=='hello' else b
print h if h=="hello" else "bye"

Results are:
>>> h = 'hello'
>>> b = 'bye'
>>> print h if h=='hello' else b
hello
>>> print h if h=="hello" else "bye"
Traceback (most recent call last):
ValueError: Types must match
Parameter name: ifTrue

In Cpython 2.5 and ipy 2.0 a4 I don't have this problem.
Regards.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Can anybody reproduce this issue under ipy 2.0 a5 (expr if cond else expr)?

[Vizcayno Tamparantan]

For ipy 2.0 alpha 5, try this:
h = 'hello'
b = 'bye'
print h if h=='hello' else b
print h if h=="hello" else "bye"

Results are:
>>> h = 'hello'
>>> b = 'bye'
>>> print h if h=='hello' else b
hello
>>> print h if h=="hello" else "bye"
Traceback (most recent call last):
ValueError: Types must match
Parameter name: ifTrue

In Cpython 2.5 and ipy 2.0 a4 I don't have this problem.
Regards.

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

Re: [IronPython] [python] Re: Announcement: Project to get some CPythonCextensions running under IronPython

[Michael Foord]

> Personally, I like the name "C Extensions for IronPython".  It's descriptive.
>
>   

CexFIP

Cex for IronPython ??

:-)

Michael


> Joe
> ___
> 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
>
>   

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

Re: [IronPython] Announcement: Project to get some CPythonCextensions running under IronPython

[Keith J. Farmer]

I prefer Joe's suggestion, personally.
 
But, for completeness:
 
C Extensions for Microsoft .NET Dynamic Language Runtime [version?] with the 
Python Standard Library -- [Mono | Microsoft .NET | Cross-Platform] Edition



From: [EMAIL PROTECTED] on behalf of Joe Mason
Sent: Mon 10/15/2007 10:57 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcement: Project to get some CPythonCextensions 
running under IronPython



On 10/15/07, Andy Shah <[EMAIL PROTECTED]> wrote:
> I am a nobody in this world... but to extend sidnei's second choice.. and the 
> fact that we are extending *C* extensions... how about "CxyPython"

Personally, I like the name "C Extensions for IronPython".  It's descriptive.

Joe
___
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] Announcement: Project to get some CPython Cextensions running under IronPython

[Joe Mason]

On 10/15/07, Andy Shah <[EMAIL PROTECTED]> wrote:
> I am a nobody in this world... but to extend sidnei's second choice.. and the 
> fact that we are extending *C* extensions... how about "CxyPython"

Personally, I like the name "C Extensions for IronPython".  It's descriptive.

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

Re: [IronPython] Announcement: Project to get some CPython Cextensions running under IronPython

[Andy Shah]

I am a nobody in this world... but to extend sidnei's second choice.. and the 
fact that we are extending *C* extensions... how about "CxyPython"
 
1) We are talkin of eXtending C (Cx)
2) Makes it sexy... (Cxy)
 
Kind Regards,
Anand Praivn Shah.



From: [EMAIL PROTECTED] on behalf of Sidnei da Silva
Sent: Mon 10/15/2007 9:35 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcement: Project to get some CPython Cextensions 
running under IronPython



On 10/15/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
> One further question for this list, before I create a repository and mailing 
> list elsewhere for the project - what should the project be called?  The best 
> one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
> you get the picture) and I'd be really grateful if someone could come up with 
> a less appalling pun...

Ah, naming. My preferred subject. ;)

Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or
'crude', and yet have a cool name. Is 'Python' required to be part of
the name?

The first cool name that came to my mind was 'Monera'. It is a cool
name because it refers (mostly) to prokaryotic organisms (organisms
without a nucleus). It also resembles a bit 'Mono', which might be an
useful association (Monera -> Mono, ah, so this is some thing related
to .NET!).

Another idea would be 'OxyPython', since it's the combination of
Oxygen + Iron is that forms Rust. :)

--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
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] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

Hmmm, we didn't really want to get the feeling of oldness or rottenness 
- it was just side-effect of a terrible pun on C/sea.  If the pun not 
only is really bad but also falls flat, then it's definitely a bad name ;-)


OxyPython sounds much cooler; but Python's definitely not required as 
part of the name. 



Sidnei da Silva wrote:

On 10/15/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
  

One further question for this list, before I create a repository and mailing list 
elsewhere for the project - what should the project be called?  The best one we've come 
up with in-house is "RustPython" (IronPython, *C* extensions, you get the 
picture) and I'd be really grateful if someone could come up with a less appalling pun...



Ah, naming. My preferred subject. ;)

Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or
'crude', and yet have a cool name. Is 'Python' required to be part of
the name?

The first cool name that came to my mind was 'Monera'. It is a cool
name because it refers (mostly) to prokaryotic organisms (organisms
without a nucleus). It also resembles a bit 'Mono', which might be an
useful association (Monera -> Mono, ah, so this is some thing related
to .NET!).

Another idea would be 'OxyPython', since it's the combination of
Oxygen + Iron is that forms Rust. :)

  


--
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/ 


17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.

Registered address: 843 Finchley Road, London NW11 8NA, UK

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

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Sidnei da Silva]

On 10/15/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
> One further question for this list, before I create a repository and mailing 
> list elsewhere for the project - what should the project be called?  The best 
> one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
> you get the picture) and I'd be really grateful if someone could come up with 
> a less appalling pun...

Ah, naming. My preferred subject. ;)

Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or
'crude', and yet have a cool name. Is 'Python' required to be part of
the name?

The first cool name that came to my mind was 'Monera'. It is a cool
name because it refers (mostly) to prokaryotic organisms (organisms
without a nucleus). It also resembles a bit 'Mono', which might be an
useful association (Monera -> Mono, ah, so this is some thing related
to .NET!).

Another idea would be 'OxyPython', since it's the combination of
Oxygen + Iron is that forms Rust. :)

-- 
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Michael Foord]

Matt Clinton wrote:
>
> NumPy is largely about speed, and going through extra interop layers 
> can really bite into that (my $0.02).
>

The reason that Numpy is much faster is because most of the work happens 
inside the C code, so a minor performance hit on the way in and out 
isn't necessarily a problem.

> I think the suggestion for a smaller module to start with was about 
> learning about compatibility with a more manageable chunk of code than 
> the many, many lines of deep number-crunching that NumPy has 
> accumulated, but maybe a few sections of compatibility there (i.e. 
> limited part of the API) would be a similarly tractable goal?
>
Possibly.
>
> Wrapping the plain-C in COM would be a good way to test implementation 
> compatibility,
>
I'm not sure that COM is the way to go (because it does seem to insert 
an extra layer into the equation) - but it is certainly on the table.

> if your plan is to ported raw C to C++,
>
That wasn't at all the *original* plan. :-)

> so that the DLR/CLR can get some hooks in and go-quicka:
>
> the COM-wrapped CPy extensions may be faster to develop, if not 
> performing as quickly,
>
> and if your C++ ports behave the same, you have pretty good confidence.
>
> Along the way, they’ll help point out what’s the framework and what’s 
> your code, especially if you can run the same test-cases through 
> straight CPy.
>
> Wrapping all the way back through Mono seems an odd goal – isn’t IPy 
> compatible enough with CPy in source that your business apps would be 
> light to port back to Cpy-land, if you’re on Posix already anyway?
>

No - our application is currently a .NET only (not Mono) application, 
with a heavy dependency on .NET for the user interface layer. So back 
porting the whole app. to CPython is not on the cards (for business 
reasons as well - getting the finance sector to install new technology 
is difficult, so a .NET based application will more easily be accepted 
by companies than a CPython one).

> For some purposes, it really makes sense, but a NumPy implementation 
> for IPy for Mono?
>
We are not talking particularly about a new implementation, but finding 
a way of getting the current implementation to work.

> Seem to me that going that deep this soon will make you a valuable 
> contributor to low-level compatibility testing… but I don’t have the 
> whole picture of where you’re going.
>
> If you’re going to alloy FePy, would that make a type of SteelPython? 
> – a happier compound than Rust!
>
RustPython is one of the possible names (what happens when you introduce 
Iron to the Sea... Moray would be another one - a kind of Python that 
lives in the sea... better names solicited...) :-)

Michael
http://www.manning.com/foord

> Cheers,
>
> -- Matt
>
> 
>
> *From:* [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Giles Thomas
> *Sent:* Monday, October 15, 2007 9:17 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Announcement: Project to get some CPython 
> C extensions running under IronPython
>
> Davy,
>
> What would the issues be with NumPy - just the size of the API that 
> would have to be wrapped? I must admin that my biggest concern with 
> this would be getting everything running under Mono...
>
>
> Cheers,
>
> Giles
>
>
> Davy Mitchell wrote:
>
> On 10/12/07, Giles Thomas <[EMAIL PROTECTED]>  
> wrote:
>   
>> Python and .NET, but also the existing CPython C extensions.
>> 
>  
> Hi Giles,
>  
> Sounds like a good idea and the approaches mentioned seemed solid.
>  
> One strategy I was considering for a port of my Mood News site to
> Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM
> object using the win32 stuff and getting it into .Net via the COM
> interop support.
>  
> Maybe not practical for Numpy :-) Does have the advantage of not
> having to modify the original lib...
>  
> Cheers,
> Davy
>  
>   
>
>
>
> -- 
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> [EMAIL PROTECTED] 
> +44 (0) 20 7253 6372
>  
> We're hiring! http://www.resolversystems.com/jobs/ 
>  
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79 
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
> 
>
> ___
> 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] Announcement: Project to get some CPython C extensions running under IronPython

[Matt Clinton]

NumPy is largely about speed, and going through extra interop layers can
really bite into that (my $0.02).

 

I think the suggestion for a smaller module to start with was about
learning about compatibility with a more manageable chunk of code than
the many, many lines of deep number-crunching that NumPy has
accumulated, but maybe a few sections of compatibility there (i.e.
limited part of the API) would be a similarly tractable goal?

 

Wrapping the plain-C in COM would be a good way to test implementation
compatibility, 

if your plan is to ported raw C to C++, so that the DLR/CLR can get some
hooks in and go-quicka:

the COM-wrapped CPy extensions may be faster to develop, if not
performing as quickly, 

and if your C++ ports behave the same, you have pretty good confidence.

Along the way, they'll help point out what's the framework and what's
your code, especially if you can run the same test-cases through
straight CPy.

 

Wrapping all the way back through Mono seems an odd goal - isn't IPy
compatible enough with CPy in source that your business apps would be
light to port back to Cpy-land, if you're on Posix already anyway? 

For some purposes, it really makes sense, but a NumPy implementation for
IPy for Mono?  

Seem to me that going that deep this soon will make you a valuable
contributor to low-level compatibility testing... but I don't have the
whole picture of where you're going.

 

If you're going to alloy FePy, would that make a type of SteelPython? -
a happier compound than Rust!

 

Cheers,

-- Matt

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas
Sent: Monday, October 15, 2007 9:17 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcement: Project to get some CPython C
extensions running under IronPython

 

Davy,

What would the issues be with NumPy - just the size of the API that
would have to be wrapped?  I must admin that my biggest concern with
this would be getting everything running under Mono...


Cheers,

Giles


Davy Mitchell wrote: 

On 10/12/07, Giles Thomas <[EMAIL PROTECTED]>
  wrote:
  

Python and .NET, but also the existing CPython C extensions.


 
Hi Giles,
 
Sounds like a good idea and the approaches mentioned seemed solid.
 
One strategy I was considering for a port of my Mood News site to
Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM
object using the win32 stuff and getting it into .Net via the COM
interop support.
 
Maybe not practical for Numpy :-) Does have the advantage of not
having to modify the original lib...
 
Cheers,
Davy
 
  





-- 
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
 
We're hiring! http://www.resolversystems.com/jobs/ 
 
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

Davy,

What would the issues be with NumPy - just the size of the API that 
would have to be wrapped?  I must admin that my biggest concern with 
this would be getting everything running under Mono...



Cheers,

Giles


Davy Mitchell wrote:

On 10/12/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
  

Python and .NET, but also the existing CPython C extensions.



Hi Giles,

Sounds like a good idea and the approaches mentioned seemed solid.

One strategy I was considering for a port of my Mood News site to
Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM
object using the win32 stuff and getting it into .Net via the COM
interop support.

Maybe not practical for Numpy :-) Does have the advantage of not
having to modify the original lib...

Cheers,
Davy

  


--
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/ 


17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.

Registered address: 843 Finchley Road, London NW11 8NA, UK

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

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

Curt Hagenlocher wrote:
 > My two cents would be this: using Managed C++, try for source 
compatibility first. 

Binary compatibility would be a great thing in the long term - after 
all, we don't want to run the risk of branching the target library's 
codebase! - but my gut feeling is that you're right, Curt: it would be 
much easier, at least as an exploratory first stage, to target source 
compatibility only.  So perhaps we should start off in that direction.

Does anyone know how this would impact the potential for Mono compatibility?

Keith J. Farmer wrote:
 > NumPy would be cool :)

That looks like a pretty popular choice generally - quite a few people have 
posted off-list saying the same.  I'll get in touch with the NumPy developers.

One further question for this list, before I create a repository and mailing 
list elsewhere for the project - what should the project be called?  The best 
one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
you get the picture) and I'd be really grateful if someone could come up with a 
less appalling pun...


Cheers,

Giles
-- 
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/ 

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

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

[IronPython] [ANN] IronPython Community Edition r7

[Sanghyeon Seo]

This is the seventh release of IronPython Community Edition (IPCE).

Download from SourceForge:
http://sourceforge.net/projects/fepy

FePy project aims to provide enhancements and add-ons for IronPython.
http://fepy.sourceforge.net/

This work was in part supported by Mozilla Corporation.

FePy project got a blog!
http://fepy.blogspot.com/

FePy blog documents two developments not included in this release.
Files under trunk/pyprof/, which tries to implement sys.setprofile
with Mono profiler API. (Thanks to Miguel de Icaza and Paolo Molaro
for help.) Files under bench/, which benchmarks simple IronPython
programs to measure progress of Mono runtime.

This release comes with both IronPython 1.1 and IronPython 2.0 Alpha
5. IronPython 1.x is stable on Mono. IronPython 2.x isn't. For
example, importing string module will crash runtime for Mono 1.2.5.
(But os module works fine, which is much more complex. It's a bit of
hit and miss.)

This release is built with Mono 1.2.5.1. The minimum Mono version
needed to compile and run for IronPython 1.x is 1.2.3. For IronPython
2.x it's 1.2.5. Mono 1.2.5 and 1.2.5.1 are same except for ASP.NET
bugfixes. DLR-based languages won't work with Mono versions before
1.2.5. Please check your Mono version before reporting any problems.

Changes in this release follow. Contributions are credited in parentheses.

IronPython

IronPython 2.0 Alpha 5.

Libraries

dbapi module handles DBNull correctly. (Carsten Haese)
pyexpat module handles DTD. (Shozo Arai)

Bundles

Following modules are now included: decimal, modulefinder, pkgutil, smtplib.
pystone benchmark. (It's under Lib/test.)

irclib, which works great. Try this example as a sanity test.
https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/example/irc_test.py

Patches

Patches are documented here.
http://fepy.sourceforge.net/patches.html

New in this release:

For 1.x
patch-ironpython-option-s

For 2.x
patch-{325478,328022,333647} # Numbers refer to Mono bugs
patch-console
patch-cs0177
patch-debug-define
patch-initialize-builtins

Build system

Use NAnt to build IronPython 2.x.
Use quilt to manage patches.
Patches to build all IronPython 2 Alpha releases.
- AssemblyVersion.cs was missing in Alpha 3. (Miguel de Icaza)
Include both IronPython 1.x and 2.x, but share the library using site.py.

Misc

Ms-PL is now included in licenses.

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