[ python-Bugs-1451341 ] msgfmt.py: fuzzy messages not correctly found
Bugs item #1451341, was opened at 2006-03-16 16:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hanno Schlichting (hannosch)
Assigned to: Nobody/Anonymous (nobody)
Summary: msgfmt.py: fuzzy messages not correctly found
Initial Comment:
In the msgfmt.py script which is installed in
%PYTHON_HOME%\Tools\i18n (on Windows) on line 129 to
131 it says:
# Record a fuzzy mark
if l[:2] == '#,' and l.find('fuzzy'):
fuzzy = 1
this should be:
# Record a fuzzy mark
if l[:2] == '#,' and l.find('fuzzy') > -1:
fuzzy = 1
or all lines beginning with '#,' will be treated as
fuzzy. Only change is the "> -1".
This applies to all versions of Python. It has been
brought to my attention by Andrey Lebedev who found
this in a product which uses a slightly modified msgfmt.py.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444408 ] subprocess test cases fail with noexec-mounted /tmp
Bugs item #108, was opened at 2006-03-06 21:48 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Peter à strand (astrand) Summary: subprocess test cases fail with noexec-mounted /tmp Initial Comment: Hi, on my Linux box two subprocess tests always fail (see below for a log output). The reason is those two tests try to execute files created with tempfile.mkstemp(), which generates files in /tmp. And my /tmp directory forbids to execute files, it is mounted with the "noexec" option. What I expected from the tests is to either find a temporary directory where execution is allowed (eg. the directory where sys.executable lies), or simply skip those tests. Test output: [...] == ERROR: test_args_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 490, in test_args_string p = subprocess.Popen(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied == ERROR: test_call_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 532, in test_call_string rc = subprocess.call(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied -- >Comment By: Wummel (calvin) Date: 2006-03-16 17:20 Message: Logged In: YES user_id=9205 I attached a patch that creates temp files in the directory of sys.executable. This directory is guaranteed to have executable permissions, and should also have write permissions (since sys.executable should have been generated from a previous make run). With the patch the test case runs ok. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451466 ] reading very large files
Bugs item #1451466, was opened at 2006-03-16 18:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files
Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)
this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.
Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either
for li in file:
do something
or
while li!='':
li=file.readline()
I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)
As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
file2.write(li)
li=file1.readline()
produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.
The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.
Everything was run from the command line.
the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:
which is 'first line'+'1rst word of next line'
PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 18:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1451588 ] bisect should support a custom comparison function
Feature Requests item #1451588, was opened at 2006-03-16 14:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1451588&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan S. Joseph (jsjoseph) Assigned to: Nobody/Anonymous (nobody) Summary: bisect should support a custom comparison function Initial Comment: The 'bisect' module provides functions for finding the proper insertion point of an item in a sorted list. The sort() function for lists supports passing in a custom comparison function, however none of the functions in bisect() support this. The method used by bisect to find the proper insertion point is not documented, but I guess the module relies on a natural ordering for the items, or on the items of the list implementing __cmp__. I suggest adding a 5th argument, with keyword 'cmp', to the functions in the 'bisect' module that would allow supplying a custom comparison function, as for 'sort'. bisect_left(list, item[, lo[, hi]][,cmp]) bisect_right( list, item[, lo[, hi]][,cmp]) bisect(...) insort_left(list, item[, lo[, hi]][,cmp]) insort_right( list, item[, lo[, hi]][,cmp]) insort(...) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1451588&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451641 ] segfault in optimize_code()
Bugs item #1451641, was opened at 2006-03-16 20:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451641&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kristján Valur (krisvale)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in optimize_code()
Initial Comment:
The function optimize_code() is called, for example
when unpickling code objects. However, with corrupt
data it can cause segfaults.
This is because of code such as:
tgt = GETJUMPTGT(codestr, (i+1))
if (codestr[tgt])
continue;
tgt can in this case easily be some nonsense and
cause access violation when used as an index into
codestr. This behaviour has been observed.
My particular patch is this:
#define CHECK_I(i) do {if ((i)<0 || (i)>=codelen)
goto exitError;}while(0)
#define CHECKARG(i) do {CHECK_I(i+1); CHECK_I(i+2);}
while(0)
#define CHECKJUMPTGT(i) do{CHECKARG(i); CHECK_I(i);}
while(0)
then, adding tests such as
CHECKJUMPTGT(j);
before code that looks like
tgt = GETJUMPTGT(j);
and
CHECK_I(tgt);
before
codestr[tgt] = foo;
Also, this function needs to be able to raise an
exception. jcompile() must be able to deal with this
case.
Finally, this is also an issue in 2.3 (actually, I
discovered it there, but a quick look seems to
indicate it being a problem in 2.4 too.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451641&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451717 ] OS/X on i386 framework build
Bugs item #1451717, was opened at 2006-03-17 09:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: OS/X on i386 framework build Initial Comment: in Makefile.pre (374) it hard codes the architecture to 'ppc' which isn't correct for the new x86 boxes. this needs to be i386 for the framework install to actually build on the new macs. regards Ian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451717 ] OS/X on i386 framework build
Bugs item #1451717, was opened at 2006-03-17 09:22 Message generated for change (Comment added) made by webperf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: OS/X on i386 framework build Initial Comment: in Makefile.pre (374) it hard codes the architecture to 'ppc' which isn't correct for the new x86 boxes. this needs to be i386 for the framework install to actually build on the new macs. regards Ian -- >Comment By: Ian Holsman (webperf) Date: 2006-03-17 09:34 Message: Logged In: YES user_id=5209 also.. in plat-mac/applesingle.py the fields AS_HEADER_FORMAT and AS_ENTRY_FORMAT need a '>' infront of the definitions AS_HEADER_FORMAT=">LL16sh" AS_ENTRY_FORMAT=">lll" (this is what the system-packaged python has. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451641 ] segfault in optimize_code()
Bugs item #1451641, was opened at 2006-03-16 20:43
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451641&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kristján Valur (krisvale)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in optimize_code()
Initial Comment:
The function optimize_code() is called, for example
when unpickling code objects. However, with corrupt
data it can cause segfaults.
This is because of code such as:
tgt = GETJUMPTGT(codestr, (i+1))
if (codestr[tgt])
continue;
tgt can in this case easily be some nonsense and
cause access violation when used as an index into
codestr. This behaviour has been observed.
My particular patch is this:
#define CHECK_I(i) do {if ((i)<0 || (i)>=codelen)
goto exitError;}while(0)
#define CHECKARG(i) do {CHECK_I(i+1); CHECK_I(i+2);}
while(0)
#define CHECKJUMPTGT(i) do{CHECKARG(i); CHECK_I(i);}
while(0)
then, adding tests such as
CHECKJUMPTGT(j);
before code that looks like
tgt = GETJUMPTGT(j);
and
CHECK_I(tgt);
before
codestr[tgt] = foo;
Also, this function needs to be able to raise an
exception. jcompile() must be able to deal with this
case.
Finally, this is also an issue in 2.3 (actually, I
discovered it there, but a quick look seems to
indicate it being a problem in 2.4 too.
--
>Comment By: Michael Hudson (mwh)
Date: 2006-03-16 23:14
Message:
Logged In: YES
user_id=6656
I don't *think* optimize_code is called for unmarshalled code objects any more
(i.e. in 2.4 and 2.5/SVN HEAD). But I could be wrong.
If not, and so optimize_code is only called with code freshly generated from
the
compiler, this isn't really an issue, is it?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451641&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451641 ] segfault in optimize_code()
Bugs item #1451641, was opened at 2006-03-16 15:43
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451641&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Kristján Valur (krisvale)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in optimize_code()
Initial Comment:
The function optimize_code() is called, for example
when unpickling code objects. However, with corrupt
data it can cause segfaults.
This is because of code such as:
tgt = GETJUMPTGT(codestr, (i+1))
if (codestr[tgt])
continue;
tgt can in this case easily be some nonsense and
cause access violation when used as an index into
codestr. This behaviour has been observed.
My particular patch is this:
#define CHECK_I(i) do {if ((i)<0 || (i)>=codelen)
goto exitError;}while(0)
#define CHECKARG(i) do {CHECK_I(i+1); CHECK_I(i+2);}
while(0)
#define CHECKJUMPTGT(i) do{CHECKARG(i); CHECK_I(i);}
while(0)
then, adding tests such as
CHECKJUMPTGT(j);
before code that looks like
tgt = GETJUMPTGT(j);
and
CHECK_I(tgt);
before
codestr[tgt] = foo;
Also, this function needs to be able to raise an
exception. jcompile() must be able to deal with this
case.
Finally, this is also an issue in 2.3 (actually, I
discovered it there, but a quick look seems to
indicate it being a problem in 2.4 too.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-16 18:27
Message:
Logged In: YES
user_id=80475
For 2.4, Michael is correct and the optimizer only applied
to internally generated code.
Also, FWIW, in Py2.5, I'm planning to move the optimizer
to appear before the assembler instead of after -- this
will both speed it up and simplify it.
Also, discussions on python-dev have noted that there are
a number of ways to make bad things happen if you execute
corrupt byte-code. IIRC, there is a proposal for a Java
style byte-code verifier to be put in place someday.
--
Comment By: Michael Hudson (mwh)
Date: 2006-03-16 18:14
Message:
Logged In: YES
user_id=6656
I don't *think* optimize_code is called for unmarshalled code objects any more
(i.e. in 2.4 and 2.5/SVN HEAD). But I could be wrong.
If not, and so optimize_code is only called with code freshly generated from
the
compiler, this isn't really an issue, is it?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451641&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447607 ] make frameworkinstall fails on Intel Macs
Bugs item #1447607, was opened at 2006-03-10 23:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447607&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michael Mondragon (mammon_) Assigned to: Nobody/Anonymous (nobody) Summary: make frameworkinstall fails on Intel Macs Initial Comment: make frameworkinstall fails on Intel Macs due to an endian error. Hardware: Intel Duo iMac 20" OS Version: OS X 10.4.6 Error: -- File "/Users/Shared/Downloads/Python-2.4.2/Lib/plat-mac/applesingle.py", line 58, in __init__ raise Error, "Unknown AppleSingle magic number 0x%8.8x" % (magic,) applesingle.Error: Unknown AppleSingle magic number 0x00160500 make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 Looking in the file at line 31: AS_MAGIC=0x00051600 ...it seems fairly obvious that byte order is reverse. Looks like the file is in big-endian format, not ntaive format. Fix: vi Lib/plat-mac/applesingle.py Line 28: Replace AS_HEADER_FORMAT="LL16sh" with AS_HEADER_FORMAT=">LL16sh" Line 35: Replace AS_ENTRY_FORMAT="lll" with AS_ENTRY_FORMAT=">lll" -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-17 06:37 Message: Logged In: YES user_id=849994 Duplicate of #1451717. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447607&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
