[IronPython] users Digest, Vol 26, Issue 6
David Taylor
davidandrewtaylor at hotmail.com
Wed Sep 6 02:41:13 CEST 2006
Jim and Team,
I have tracked this project since you started, happily reading the mailing
list awaiting V1.0.
Here is a big congratulations and thank you!
David
-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of
users-request at lists.ironpython.com
Sent: Tuesday, 5 September 2006 10:05 PM
To: users at lists.ironpython.com
Subject: users Digest, Vol 26, Issue 6
Send users mailing list submissions to
users at lists.ironpython.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
or, via email, send a message with subject or body 'help' to
users-request at lists.ironpython.com
You can reach the person managing the list at
users-owner at lists.ironpython.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of users digest..."
Today's Topics:
1. Re: ipy support in msxsl:script blocks (Dino Viehland)
2. [ANN] IronPython 1.0 released today! (Jim Hugunin)
3. Re: IronPython RC2 RPM + YaST + YUM (M. David Peterson)
4. locale issues (Jonathan Jacobs)
5. Re: [ANN] IronPython 1.0 released today! (M. David Peterson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 5 Sep 2006 10:53:15 -0700
From: Dino Viehland <dinov at exchange.microsoft.com>
Subject: Re: [IronPython] ipy support in msxsl:script blocks
To: Discussion of IronPython <users at lists.ironpython.com>
Message-ID:
<7AD436E4270DD54A94238001769C2227383C457D58 at DF-GRTDANE-MSG.exchange.corp.mic
rosoft.com>
Content-Type: text/plain; charset="us-ascii"
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: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] 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
------------------------------
Message: 2
Date: Tue, 5 Sep 2006 13:27:12 -0700
From: Jim Hugunin <Jim.Hugunin at microsoft.com>
Subject: [IronPython] [ANN] IronPython 1.0 released today!
To: "users at lists.ironpython.com" <users at lists.ironpython.com>
Cc: "python-list at python.org" <python-list at python.org>
Message-ID:
<B5F2A8845315C94E838A0901C3A036B92D99513D2B at DF-GRTDANE-MSG.exchange.corp.mic
rosoft.com>
Content-Type: text/plain; charset="iso-8859-1"
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)
------------------------------
Message: 3
Date: Tue, 5 Sep 2006 14:34:18 -0600
From: "M. David Peterson" <xmlhacker at gmail.com>
Subject: Re: [IronPython] IronPython RC2 RPM + YaST + YUM
To: "Discussion of IronPython" <users at lists.ironpython.com>
Message-ID:
<eab75e160609051334w75d54814p986a954a37c31d50 at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Seo,
I know VERY little when it comes to the world of Unix, but at first look,
after installation there does seem to be the standard site.py contained in
/usr/lib/IronPython/Lib which is the same empty file (except for the
Microsoft copyright information) contained in the standard distro via
CodePlex.
With this in mind, two things immediately jump out at me as possibilities,
NOTE: For ease of reference via URI#line number I checked the file into the
extensibleforge repository which can be viewed via the Trac interface @
http://dev.extensibleforge.net/browser/build/IronPython.spec
>From http://dev.extensibleforge.net/browser/build/IronPython.spec#L124,
cat <<EOF >> ${DESTDIR}/usr/lib/IronPython/Lib/site.py
1) If not mistaken, when using cat, a single < (e.g. "cat <EOF ...") will
create a new file if it doesn't exist or replace the existing file if it
does, where as a double < (e.g. "cat <<EOF ...") will create a new file if
it doesn't exist, and append from stdin to the existing file if it does.
While doubtful, would changing the existing double < to a single < help in
any way?
2) Regardless of the above, if the site.py file already exists in the Lib
directory that is copied into the RPM, and the copy process takes place
after the above cat process, the newly created site.py file would (I'm
guessing) be copied over the top of by the existing site.py from the
standard distro.
I've verified that if you append the same lines from the spec file [
http://dev.extensibleforge.net/browser/build/IronPython.spec#L124 ->
http://dev.extensibleforge.net/browser/build/IronPython.spec#L132] to the
end of /usr/lib/IronPython/Lib/site.py, you can then access the existing
*.py modules as expected.
In this sense, the solutions seems to be one of the following,
a) Just add the desired lines to the site.py that is wrapped into the RPM.
b) If not already (as alluded to already, my knowledge of the Unix command
line tools and even more so, the RPM build process is severely limited) run
the cat process after the copy process takes place.
Thoughts?
On 9/4/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
>
> 2006/9/4, M. David Peterson <xmlhacker at gmail.com>:
> > Looking through the various release notes and download pages for
> > Mono
> > 1.1.17.1 I noticed the Mono folks have now packaged RC2 of
> > IronPython
> into
> > an RPM.
> >
> http://www.go-mono.com/download/noarch/ironpython/1.0-RC2/IronPython-1
> .0_RC2-0.novell.noarch.rpm
>
> Good catch!
>
> In case others are curious how this was done, here's a link to RPM
> spec
> file:
> http://www.go-mono.com/download/noarch/ironpython/1.0-RC2/IronPython.s
> pec
>
> Does anyone have an idea re: "Doesn't work... site.py doesn't seem to
> get loaded...?" cmment in the spec file?
>
> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
/pipermail/users-ironpython.com/attachments/20060905/b86d5f22/attachment.htm
------------------------------
Message: 4
Date: Tue, 05 Sep 2006 22:49:08 +0200
From: Jonathan Jacobs <korpse-ironpython at kaydash.za.net>
Subject: [IronPython] locale issues
To: IronPython List <users-ironpython.com at lists.ironpython.com>
Message-ID: <44FDE2C4.7080009 at kaydash.za.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
A few locale issues I've run across:
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32 Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'cp1252'
>>> locale.getlocale()
(None, None)
>>> import _locale
>>> _locale._getdefaultlocale()
('en_ZA', 'cp1252')
IronPython 1.0.2408 on .NET 2.0.50727.42 Copyright (c) Microsoft
Corporation. All rights reserved.
>>> import locale
>>> locale.getpreferredencoding()
''
>>> locale.getlocale()
Traceback (most recent call last):
File , line 0, in <stdin>##19
File c:\program files\python24\lib\locale.py, line 365, in getlocale
File c:\program files\python24\lib\locale.py, line 278, in
_parse_localename
ValueError: unknown locale: en_ZA
>>> import _locale
>>> _locale._getdefaultlocale()
('en-ZA', '')
Looks like ipy and cpython are not on the same wavelength.
--
Jonathan
When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
-- Rinzai, ninth century Zen master
------------------------------
Message: 5
Date: Tue, 5 Sep 2006 15:05:12 -0600
From: "M. David Peterson" <xmlhacker at gmail.com>
Subject: Re: [IronPython] [ANN] IronPython 1.0 released today!
To: "Discussion of IronPython" <users at lists.ironpython.com>
Cc: "python-list at python.org" <python-list at python.org>
Message-ID:
<eab75e160609051405x66b8b8d3h1123ba19e30dd01a at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Congratulations, Jim! Truly and amazing vision you and your development
staff have brought into fruition :)
>From my recent post to the O'Reilly Windows DevCenter,
ref:
http://www.oreillynet.com/windows/blog/2006/09/jim_huguninmsft_announce_iron
p.html
Congratulations are in order to Jim Hugunin, Dino Viehland, Microsoft, the
> core IronPython development
> team<http://www.codeplex.com/Project/ProjectPeople.aspx?ProjectName=Ir
> onPython>, and two all of the community members that have been
> involved in the development of such a remarkable product which is
> represented by the final release of IronPython
> 1.0<http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython>
> .
>
> To each of you listed above and to everyone involved with making this
> happen, a HUGE thank you! Truly an amazing accomplishment.
>
On 9/5/06, Jim Hugunin <Jim.Hugunin at microsoft.com> wrote:
>
> I'm extremely happy to announce that we have released IronPython 1.0today!
> 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
> users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
/pipermail/users-ironpython.com/attachments/20060905/63766eea/attachment.htm
l
------------------------------
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
End of users Digest, Vol 26, Issue 6
************************************
More information about the Ironpython-users
mailing list