[ python-Bugs-763708 ] Failures in test_macostools for
--enable-unicode=ucs4
SourceForge.net
noreply at sourceforge.net
Sun Dec 19 01:21:26 CET 2004
Bugs item #763708, was opened at 2003-07-01 08:54
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470
Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 4
Submitted By: Brett Cannon (bcannon)
Assigned to: Jack Jansen (jackjansen)
Summary: Failures in test_macostools for --enable-unicode=ucs4
Initial Comment:
Here are the test results:
test_copy (__main__.TestMacostools) ... ok
test_mkalias (__main__.TestMacostools) ... ERROR
test_mkalias_relative (__main__.TestMacostools) ... ERROR
test_touched (__main__.TestMacostools) ... ok
=====================================
=================================
ERROR: test_mkalias (__main__.TestMacostools)
--------------------------------------------------------------------
--
Traceback (most recent call last):
File "Lib/test/test_macostools.py", line 69, in test_mkalias
macostools.mkalias(test_support.TESTFN, TESTFN2)
File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/
macostools.py", line 46, in mkalias
File.FSGetResourceForkName())
Error: (-1402, 'Fork name parameter is bad')
=====================================
=================================
ERROR: test_mkalias_relative (__main__.TestMacostools)
--------------------------------------------------------------------
--
Traceback (most recent call last):
File "Lib/test/test_macostools.py", line 78, in
test_mkalias_relative
macostools.mkalias(test_support.TESTFN, TESTFN2,
sys.prefix)
File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/
macostools.py", line 46, in mkalias
File.FSGetResourceForkName())
Error: (-1402, 'Fork name parameter is bad')
----------------------------------------------------------------------
>Comment By: Jack Jansen (jackjansen)
Date: 2004-12-19 01:21
Message:
Logged In: YES
user_id=45365
I'd like to keep this bug open, because the underlying problem is serious:
the Python interfaces to the MacOSX APIs assume that the binary
representation of "python unicode" is identical to the binary
representation of "macosx unicode". This needs to be fixed at some
point, but such a fix requires major surgery (especially if we want things
to be efficient for the normal case, where the assumption indeed holds).
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-12-18 22:40
Message:
Logged In: YES
user_id=357491
This test still fails in 2.4 and so far in 2.5 . Does this still deserve a
"later" resolution?
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 23:27
Message:
Logged In: YES
user_id=357491
Sorry, Jack. I didn't know that this was a Unicode issue. Oh well,
at least the cause has been narrowed down.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-07-22 21:35
Message:
Logged In: YES
user_id=45365
Boo, hiss! :-)
You're using --enable-unicode=ucs4 and you didn't tell me that
when there's a unicode problem:-)
My guess is that I'm somewhere grabbing the pointer from the
Python unicode object and passing that straight to the Apple
routines, which will fail miserably because they expect ucs2 (or
utf16, or whatever it's called). Actually, I wouldn't be surprised if
there are more places where I do that. Yes, looking at the data
returned this looks like a very likely scenario.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 20:42
Message:
Logged In: YES
user_id=357491
The Carbon.File.FSGetResourceForkName() returns
u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f
0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5
334bfff\Uf4200000' . That can't be printed because of a
conversion to ASCII error. If I remember correctly this is what
was returning the string "ERROR" (or however it was formatted).
There is also the ``Error: (-1402, 'Fork name parameter is bad'``
from the failed tests.
And here is the info you wanted, Jack:
1. My build has the settings --with-pydebug --prefix=$HOME/
cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight
build.
2. I think so. I also have an OS 9 partition that came with my
iBook that I never touch.
3. Nope, no stray TESTFN files. The only file I have in my CVS
directory that is not in the repository is Lib/plat-mac/
errors.rsrc.df.rsrc .
Hope that helps.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-07-22 17:22
Message:
Logged In: YES
user_id=45365
Brett, please try the following:
>>> import Carbon.File
>>> Carbon.File.FSGetResourceForkName()
u'RESOURCE_FORK'
>>>
You mention it prints ERROR for you, I'd like to see exactly what it
prints (u"ERROR"? "ERROR"? ERROR?).
And a bit more information I need to try and duplicate the
problem:
1. Are you using a framework build or a straight build?
2. Is your /Users/drifty directory in yoor root partition?
3. Could you check that there are no test_support.TESTFN or
test_support.TESTFN + '2' turds on your system?
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 08:48
Message:
Logged In: YES
user_id=357491
Tested and still fails with a CVS update on 2003-07-21.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-07-20 02:30
Message:
Logged In: YES
user_id=45365
This seems to be fixed in 2.3c1. Could you please test?
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-07-09 20:03
Message:
Logged In: YES
user_id=357491
OK, so the problem seems to be coming from Mac/Modules/file/
_Filemodule.c and the File_FSGetResourceForkName function
(printing the result just prints "ERROR"). The online docs for
FSGetResourceForkName (which is pretty much all that is called in
that function) can be found at http://developer.apple.com/
documentation/Carbon/Reference/File_Manager/file_manager/
function_group_20.html#//apple_ref/c/func/
FSGetResourceForkName .
Now it looks like the error is an OS X error and has nothing to do
with Python. The error (-1402) means that the fork name is
syntactically invalid. I don't see how this can mean anything,
though, since FSGetResourceForkName's only argument is a
pointer to store the result of the call into.
The only thing I can think of that might be causing this error from
Python's side is that a resource fork does not exist when the call is
made. But this is just a guess so I could be wrong.
Jack, I am going to be gone from July 13 until July 21, so if you
need any debugging info from me before 2.3 final goes out I am
afraid it will have to happen soon.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-07-01 22:42
Message:
Logged In: YES
user_id=357491
OK, Jack, here is your info:
- 10.2.6
- Python 2.3b2+ straight from CVS (only way to code =)
- HFS+ I believe (Finder says my HD is Mac OS Extended)
Ran the test from my CVS tree with my installed version of Python
2.3b2+ (I can't do anything the standard way). I just ran it with
the installed copy from the installed test directory and got the
errors. I also just ran it with the compiled copy but not installed
Python executable in my CVS tree and once again got the error.
I noticed this came up, for me at least, when I was checking a
patch for posixpath.py (which was applied to CVS). I checked the
code, though, and didn't find a problem where anything changed to
posixpath.py would affect it.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2003-07-01 13:47
Message:
Logged In: YES
user_id=45365
Brett, I've seen this bug once in a while, but whenever I try to
hunt it it disappears. Could you give me the following info:
- OSX exact version
- Python exact version, plus where you got it from (binary install,
source tarball install, CVS)
- Type of filesystem (HFS+, UFS, NFS, something else)
Also, if you're building from source, did you run the tests from the
build tree or from the installed tree? Could you try the other one
too?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470
More information about the Python-bugs-list
mailing list