[PATCH] revlog, setup: Adds IronPython compatibility changes

[Matt Mackall]

On Fri, 2011-05-06 at 13:13 -0400, Zachary Gramana wrote:
> On 5/6/2011 1:45 AM, Matt Mackall wrote:
> > On Thu, 2011-05-05 at 11:50 -0400, Zachary Gramana wrote:
> >> # HG changeset patch
> >> # User Zachary Gramana<zgramana at pottsconsultinggroup.com>
> >> # Date 1304609612 14400
> >> # Node ID d096e2af7865730d8f93d123481991c777e6fd64
> >> # Parent  bedad898a28a3e6a25afff650a68e47c347ec1db
> >> revlog, setup: Adds IronPython compatibility changes
> >>
> >> diff -r bedad898a28a -r d096e2af7865 mercurial/revlog.py
> >> --- a/mercurial/revlog.py    Thu May 05 11:33:02 2011 -0400
> >> +++ b/mercurial/revlog.py    Thu May 05 11:33:32 2011 -0400
> >> @@ -54,6 +54,18 @@
> >>    def offset_type(offset, type):
> >>        return long(long(offset)<<  16 | type)
> >>
> >> +def ensurestr(text):
> >> +    """take either a buffer of a string, and return a string.
> >> +
> >> +    IronPython treats all strings as unicode strings.  Large
> >> +    strings are passed as buffers.  Currently, _sha.update and
> >> +    zlib.compress don't like buffers, so we ensure they get strings.
> >> +    """
> >> +    if type(text) == buffer:
> >> +        return str(text)
> >> +    else:
> >> +        return text
> >> +
> >>    nullhash = _sha(nullid)
> >
> > Seems you missed my comment here about util.fakebuffer.
> 
> I'm not ashamed to say I'm new to Python, and Hg, and I've been taking 
> some time to digest your comment. Plus, I'm not fully confident that I 
> correctly understood your suggestion. I didn't want that to be a 
> blocking operation, though.

Well it's definitely blocking in the sense that I can either take all of
a patch or none of a patch. Given that your setup.py code is unrelated
to the buffering question, you should send that separately.

> I think IronPython peculiarities may be making the issue a bit more 
> complicated.  Some of the modules, like socket, are built into the 
> executable (there is not even a socket.py in the distribution).  As a 
> result, socket operations may not be aware of monkey patches.  My 
> operating theory is that a socket read(), which is handled by compiled 
> C# code, is returning a buffer. If this is true, then it would require 
> changing IronPython source code.

Yes, that would present an issue and would definitely constitute an
IronPython bug.

It should be fairly straightforward to test this by pasting some example
code from the socket module docs.

-- 
Mathematics is the supreme nostalgia of our time.