"Joe Smith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote: >>> >> I'm wondering if the recusion limit on my build is getting set too >>> >> low >>> >> somehow. >>> > >>> > Can you find out what it is? sys.getrecursionlimit(). >>> >>> Hmm... It is a limit of 1000. >>> That is probably large enough, no? >> >> Yes, that's what it is for me. >> >>> Anyway, from some basic testing it looks like marshal is always throwing >>> that error when marshal.load() is called. >>> However, marshal.loads() works fine. >>> >>> Might this be another encoding related error? >> >> Perhaps. Or something else. Do try to investigate. >> > > What I have found is that (on CYGWIN) all of marshal seems to work fine > except for marshal.load(). > marshal.dump()'s output can be read by 2.5's marshal.load() without > problem. > 3k's marshal.load() will not > load the data from 3k's marshal.dump or 2.5's marshal.dump() > > It turns out to be a fault due to an uninitialized value on a RFILE. > Specifically, the following patch (part of marshal_load in marshal.c fixes > things. > > -----BEGIN PATCH----- > Index: Python/marshal.c > =================================================================== > --- Python/marshal.c (revision 56620) > +++ Python/marshal.c (working copy) > @@ -1181,6 +1181,7 @@ > return NULL; > } > rf.strings = PyList_New(0); > + rf.depth=0; > result = read_object(&rf); > Py_DECREF(rf.strings); > Py_DECREF(data); > -----END PATCH----- > > I'll submit the patch to sourceforge if needed, although the fact that all > the other loading methods > do set rf.depth=0 (including PyMarshal_ReadObjectFromFile) indicates to me > that this is definately the correct patch. > Looks like that line was accidentally forgoten.
With that patch, things on CYGWIN are getting close to matching the other platforms. There are still some problems with the 'Python' directory for example. This is because of a change in the internals of Cygwin. Cygwin does have "managed mounts" which allow for case sensitivity. Compiling Python inside a managed mount eliminates those issues. So it is not a terribly big deal. If I patch io.py to default to "utf-8" rather than using the filesystem encoding (ascii), that fixes a few more things. (test_coding.py and test_minidom.py) Then there are only 2 test failures remaining that are not listed on the wiki. One of them is a very minor issue in test_platform.py. The other is a more complicated problem with test_mailbox.py First the test_platform problem. sys.executable lacks the ".exe" suffix. In order for libc_ver to work it would need to be passed the exe suffix. The cygwin specific hack in the test_platform.py does not work if when using a managed mount because a managed mount is case sensitive, so isdir(executable) returns false. (Using libc_ver with no arguments also fails for the same basic reason. (although there is no cygwin hack in that case.)) That said, using libc_ver on cygwin would not be meaningful because cygwin uses newlib instead of libc/glibc. The mailbox.py problem seems troubling, I'm getting exceptions of type "IOError: [Errno 13] Permission denied" on "./@test" (aka. test_support.TESTFN) . This is true for all tests after TestMbox's run of test_add(). All of TestMailDir works fine. TestMbox's test_add() works fine, but all the remaining tests that use "./@test" fail. Sounds like something is not getting cleaned up correctly. That said no "@test" file or directory is left behind after the end of the test. (For whats its worth, Cygwin's python 2.5 (as installed on my system) fails 2 of the tests in it's version of test_mailbox.py, both with "IOError: [Errno 13] Permission denied"). _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
