Bazaar on IronPython

[Martin (gzlist)]

For anyone who is interested, I have done a little work getting the
DVCS bazaar working on IronPython 2.0 and 2.6 - please see this
message and attached patch:
<https://lists.canonical.com/archives/bazaar/2009q2/060028.html>

I've yet to have a chance to go through the codeplex bugtracker and
match up the issues I ran across against existing tickets or file new
ones, but I do intend to get to that.

Also, thanks to Jeff Hardy for his zlib emulation library. He has
already released a new version incorporating the testcases I sent,
with the issues fixed. I think the module, or something along the same
lines, should be included in the base release.

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

[Dino Viehland]

Good work, it's very cool to see this - if you see an existing bug or
open a new please make sure to mention that it effects Bazaar and we'll
treat it with a higher priority.  In general that goes for any large
body of existing Python code.

-----Original Message-----
From: users-bounces@... [mailto:users-bounces@...] On Behalf Of Martin (gzlist)
Sent: Monday, June 29, 2009 3:29 PM
To: users@...
Subject: [IronPython] Bazaar on IronPython

For anyone who is interested, I have done a little work getting the
DVCS bazaar working on IronPython 2.0 and 2.6 - please see this
message and attached patch:
<https://lists.canonical.com/archives/bazaar/2009q2/060028.html>

I've yet to have a chance to go through the codeplex bugtracker and
match up the issues I ran across against existing tickets or file new
ones, but I do intend to get to that.

Also, thanks to Jeff Hardy for his zlib emulation library. He has
already released a new version incorporating the testcases I sent,
with the issues fixed. I think the module, or something along the same
lines, should be included in the base release.

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

[Seo Sanghyeon-3]

2009/6/30 Martin (gzlist) <gzlist@...>:
> For anyone who is interested, I have done a little work getting the
> DVCS bazaar working on IronPython 2.0 and 2.6 - please see this
> message and attached patch:
> <https://lists.canonical.com/archives/bazaar/2009q2/060028.html>

You seem to use xmllib to get ElementTree working. If you need
pyexpat for IronPython, you can use my implementation:

http://fepy.svn.sourceforge.net/svnroot/fepy/trunk/lib/pyexpat.py

Just drop it in sys.path.

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

[Martin (gzlist)]

On 30/06/2009, Dino Viehland <dinov@...> wrote:
> Good work, it's very cool to see this - if you see an existing bug or
> open a new please make sure to mention that it effects Bazaar and we'll
> treat it with a higher priority.  In general that goes for any large
> body of existing Python code.

Okay, I've written testcases for each of the changes I needed to make
to get Bazaar to run that were due to IronPython bugs. Have just had a
quick look at the IronPython source online and could submit patches
for a few of the issues.

However I don't see any information on the site about how you want
fixes provided, and messages likes this:
<http://lists.ironpython.com/pipermail/users-ironpython.com/2009-April/010114.html>
seem to imply that not only can you not take submissions, but you
can't even look at them? Perhaps an entry in the faq addressing this
would make things clearer.

Don't want to make your lives harder, so for the moment will just say
what and where:

* Even non re.RE_Pattern objects shouldn't confuse warnings filtering
(Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)

* Require the zlib module [workitem:2590] (other missing or broken
modules not as crucial)

* Making sys._getframe equal to None by default in 2.6 beta 1 lead to
a happier logging module but a sadder doctest module.

* The third argument to file should work as a keyword as well as
positionally [workitem:23347]

* The abspath function should not throw even for invalid windows
paths. Or, if it's going to throw, it shouldn't spell 'pecified'
without the 'S'. Fixed post-2.6 beta 1 by the workaround in
nt._getfullpathname? (going by the code in
IronPython_Main/Src/IronPython.Modules/nt.cs)

* Removing a read-only file should raise an error with errno set to
EACCES [workitem:23348] also related to [workitem:13702]

* Removing a open file should raise an error with errno set to EACCES
[workitem:23349] also related to [workitem:13702]

* A buffer object should be directly writable to a cStringIO object
[workitem:23350]

* Opening an existing file with the O_CREAT should succeed
[workitem:19310] (problem at FileModeFromFlags in
IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
Likewise, the O_TRUNC flag is not being correctly combined in there.

* The mbcs codec for decoding windows 'ansi' strings should exist
[workitem:23351]

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

[Martin (gzlist)]

On 01/07/2009, Seo Sanghyeon <sanxiyn@...> wrote:
>
> You seem to use xmllib to get ElementTree working. If you need
> pyexpat for IronPython, you can use my implementation:

Yes, and I'm aware of Jeff's subprocess module as well. Was just
trying to keep the number of extra things someone needed to download
to try out the patch to a minimum. That said, I do wonder if
implementing the ElementTree with System.Xml makes more sense than
emulating expat, bzr complains about speed unless cElementTree is
installed for instance.

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

[Dino Viehland]

Martin wrote:

> However I don't see any information on the site about how you want
> fixes provided, and messages likes this:
> <http://lists.ironpython.com/pipermail/users-ironpython.com/2009-
> April/010114.html>
> seem to imply that not only can you not take submissions, but you
> can't even look at them? Perhaps an entry in the faq addressing this
> would make things clearer.

Yeah, unfortunately we can't accept changes back.  :(  Adding an entry
to the FAQ on this sounds like a good idea.  In the mean time good bug
reports like this are a tremendous help.

> Don't want to make your lives harder, so for the moment will just say
> what and where:
>
> * Even non re.RE_Pattern objects shouldn't confuse warnings filtering
> (Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)

Are you just saying that we have a bug in our re implementation which is
breaking warning filtering?

>
> * Require the zlib module [workitem:2590] (other missing or broken
> modules not as crucial)

Hopefully Jeff Hardy's zlib fills the gap here as we don't have any
immediate plans to implement this (the underlying .NET implementation
simply isn't sufficient to build upon).

>
> * Making sys._getframe equal to None by default in 2.6 beta 1 lead to
> a happier logging module but a sadder doctest module.

Yeah, we actually want to patch the std lib for handling _getframe more
consistently.  We're working w/ our lawyers to make sure we can submit
the changes back to CPython though.

>
> * The third argument to file should work as a keyword as well as
> positionally [workitem:23347]
>
> * The abspath function should not throw even for invalid windows
> paths. Or, if it's going to throw, it shouldn't spell 'pecified'
> without the 'S'. Fixed post-2.6 beta 1 by the workaround in
> nt._getfullpathname? (going by the code in
> IronPython_Main/Src/IronPython.Modules/nt.cs)
>
> * Removing a read-only file should raise an error with errno set to
> EACCES [workitem:23348] also related to [workitem:13702]
>
> * Removing a open file should raise an error with errno set to EACCES
> [workitem:23349] also related to [workitem:13702]
>
> * A buffer object should be directly writable to a cStringIO object
> [workitem:23350]
>
> * Opening an existing file with the O_CREAT should succeed
> [workitem:19310] (problem at FileModeFromFlags in
> IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
> analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
> Likewise, the O_TRUNC flag is not being correctly combined in there.

These should all be simple to fix - 19310 is the only one that has me
a little bit worried but hopefully it's not the issue I'm thinking of.
I'll probably dig into these early next week.

> * The mbcs codec for decoding windows 'ansi' strings should exist
> [workitem:23351]

I recently got started on some mbcs support so maybe this will be the
reason to finish that off.
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Martin (gzlist)]

On 02/07/2009, Dino Viehland <dinov@...> wrote:
>
>> * Even non re.RE_Pattern objects shouldn't confuse warnings filtering
>> (Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)
>
> Are you just saying that we have a bug in our re implementation which is
> breaking warning filtering?

No, it's far more obscure than that. Bazaar replaces re.compile with a
function that returns objects that behave like pattern objects but are
really wrappers. It's not exactly a common use case I think you should
be rushing to support. :)

>> * Making sys._getframe equal to None by default in 2.6 beta 1 lead to
>> a happier logging module but a sadder doctest module.
>
> Yeah, we actually want to patch the std lib for handling _getframe more
> consistently.  We're working w/ our lawyers to make sure we can submit
> the changes back to CPython though.

That sounds like the most sensible option by far.

>> * Opening an existing file with the O_CREAT should succeed
>> [workitem:19310] (problem at FileModeFromFlags in
>> IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
>> analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
>> Likewise, the O_TRUNC flag is not being correctly combined in there.

Whoops, OPEN_ALWAYS is actually OpenOrCreate in dot net speak.

> These should all be simple to fix - 19310 is the only one that has me
> a little bit worried but hopefully it's not the issue I'm thinking of.
> I'll probably dig into these early next week.

It may not be possible to get perfect emulation of the C way of
opening files with System.IO but fixing the flags looks right on the
surface.

Thanks for looking over all these little issues.

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

[Dino Viehland]

Martin wrote:

> * Even non re.RE_Pattern objects shouldn't confuse warnings filtering
> (Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)
>
> * Require the zlib module [workitem:2590] (other missing or broken
> modules not as crucial)
>
> * Making sys._getframe equal to None by default in 2.6 beta 1 lead to
> a happier logging module but a sadder doctest module.
>
> * The third argument to file should work as a keyword as well as
> positionally [workitem:23347]
>
> * The abspath function should not throw even for invalid windows
> paths. Or, if it's going to throw, it shouldn't spell 'pecified'
> without the 'S'. Fixed post-2.6 beta 1 by the workaround in
> nt._getfullpathname? (going by the code in
> IronPython_Main/Src/IronPython.Modules/nt.cs)
>
> * Removing a read-only file should raise an error with errno set to
> EACCES [workitem:23348] also related to [workitem:13702]
>
> * Removing a open file should raise an error with errno set to EACCES
> [workitem:23349] also related to [workitem:13702]
>
> * A buffer object should be directly writable to a cStringIO object
> [workitem:23350]
>
> * Opening an existing file with the O_CREAT should succeed
> [workitem:19310] (problem at FileModeFromFlags in
> IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
> analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
> Likewise, the O_TRUNC flag is not being correctly combined in there.
>
> * The mbcs codec for decoding windows 'ansi' strings should exist
> [workitem:23351]

With this morning's source push all of these should be fixed now except
For the zlib and re.RE_Pattern issues.
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com