FW: regarding the Python Developer posting...
Dan, anyone can mail to python-dev@python.org. Everyone else, this appears to be a followup on the Mac OSX compiler error. Dan, I replied to that on comp.lang.python; if you have bugs to report (platform-specific or otherwise) against the current CVS tree, SourceForge is the best place to do it. Since the 1.6 release is history, it's too late to change anything there. -----Original Message----- From: Dan Wolfe [mailto:dkwolfe@pacbell.net] Sent: Saturday, September 23, 2000 5:35 PM To: tim_one@email.msn.com Subject: regarding the Python Developer posting... Howdy Tim, I can't send to the development list so your gonna have to suffer... ;-) With regards to: http://www.python.org/pipermail/python-dev/2000-September/016188.html
cc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c -o unicodectype.o unicodectyc cc: Internal compiler error: program cpp-precomp got fatal signal 11make[1]: *** [unicodectype.o] Error 1 make: *** [Objects] Error 2 dhcppc4:~/Python-1.6] root#
I believe it's a bug in the cpp pre-comp as it also appears under 2.0. I've been able to work around it by passing -traditional-cpp to the compiler and it doesn't complain... ;-) I'll take it up with Stan Steb (the compiler guy) when I go into work on Monday. Now if I can just figure out the test_sre.py, I'll be happy. (eg it compiles and runs but is still not passing all the regression tests). - Dan
Tim Peters wrote:
Dan, anyone can mail to python-dev@python.org.
Everyone else, this appears to be a followup on the Mac OSX compiler error.
Dan, I replied to that on comp.lang.python; if you have bugs to report (platform-specific or otherwise) against the current CVS tree, SourceForge is the best place to do it. Since the 1.6 release is history, it's too late to change anything there.
-----Original Message----- From: Dan Wolfe [mailto:dkwolfe@pacbell.net] Sent: Saturday, September 23, 2000 5:35 PM To: tim_one@email.msn.com Subject: regarding the Python Developer posting...
Howdy Tim,
I can't send to the development list so your gonna have to suffer... ;-)
With regards to:
http://www.python.org/pipermail/python-dev/2000-September/016188.html
cc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c -o unicodectype.o unicodectyc cc: Internal compiler error: program cpp-precomp got fatal signal 11make[1]: *** [unicodectype.o] Error 1 make: *** [Objects] Error 2 dhcppc4:~/Python-1.6] root#
I believe it's a bug in the cpp pre-comp as it also appears under 2.0. I've been able to work around it by passing -traditional-cpp to the compiler and it doesn't complain... ;-) I'll take it up with Stan Steb (the compiler guy) when I go into work on Monday.
You could try to enable the macro at the top of unicodectype.c: #if defined(macintosh) || defined(MS_WIN64) /*XXX This was required to avoid a compiler error for an early Win64 * cross-compiler that was used for the port to Win64. When the platform is * released the MS_WIN64 inclusion here should no longer be necessary. */ /* This probably needs to be defined for some other compilers too. It breaks the ** 5000-label switch statement up into switches with around 1000 cases each. */ #define BREAK_SWITCH_UP return 1; } switch (ch) { #else #define BREAK_SWITCH_UP /* nothing */ #endif If it does compile with the work-around enabled, please give us a set of defines which identify the compiler and platform so we can enable it per default for your setup.
Now if I can just figure out the test_sre.py, I'll be happy. (eg it compiles and runs but is still not passing all the regression tests).
Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
in response to a OS X compiler problem, mal wrote:
You could try to enable the macro at the top of unicodectype.c:
#if defined(macintosh) || defined(MS_WIN64) /*XXX This was required to avoid a compiler error for an early Win64 * cross-compiler that was used for the port to Win64. When the platform is * released the MS_WIN64 inclusion here should no longer be necessary. */ /* This probably needs to be defined for some other compilers too. It breaks the ** 5000-label switch statement up into switches with around 1000 cases each. */ #define BREAK_SWITCH_UP return 1; } switch (ch) { #else #define BREAK_SWITCH_UP /* nothing */ #endif
If it does compile with the work-around enabled, please give us a set of defines which identify the compiler and platform so we can enable it per default for your setup.
I have a 500k "negative patch" sitting on my machine which removes most of unicodectype.c, replacing it with a small data table (based on the same unidb work as yesterdays unicodedatabase patch). out </F> # dump all known unicode data import unicodedata for i in range(65536): char = unichr(i) data = ( # ctype predicates char.isalnum(), char.isalpha(), char.isdecimal(), char.isdigit(), char.islower(), char.isnumeric(), char.isspace(), char.istitle(), char.isupper(), # ctype mappings char.lower(), char.upper(), char.title(), # properties unicodedata.digit(char, None), unicodedata.numeric(char, None), unicodedata.decimal(char, None), unicodedata.category(char), unicodedata.bidirectional(char), unicodedata.decomposition(char), unicodedata.mirrored(char), unicodedata.combining(char) )
oops. mailer problem; here's the rest of the mail:
I have a 500k "negative patch" sitting on my machine which removes most of unicodectype.c, replacing it with a small data table (based on the same unidb work as yesterdays unicodedatabase patch).
(this shaves another another 400-500k off the source distribution, and 10-20k in the binaries...) I've verified that all ctype-related methods eturn the same result as before the patch, for all characters in the unicode set (see the attached script). should I check it in? </F>
Fredrik Lundh wrote:
oops. mailer problem; here's the rest of the mail:
I have a 500k "negative patch" sitting on my machine which removes most of unicodectype.c, replacing it with a small data table (based on the same unidb work as yesterdays unicodedatabase patch).
(this shaves another another 400-500k off the source distribution, and 10-20k in the binaries...)
I've verified that all ctype-related methods eturn the same result as before the patch, for all characters in the unicode set (see the attached script).
should I check it in?
Any chance of taking a look at it first ? (BTW, what happened to the usual post to SF, review, then checkin cycle ?) The C type checks are a little performance sensitive since they are used on a char by char basis in the C implementation of .upper(), etc. -- do the new methods give the same performance ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
[M.-A. Lemburg, on /F's Unicode patches]
Any chance of taking a look at it first ? (BTW, what happened to the usual post to SF, review, then checkin cycle ?)
I encouraged /F *not* to submit a patch for the unicodedatabase.c change. He knows what he's doing, experts in an area are allowed (see PEP200) to skip the patch business, and we're trying to make quick progress before 2.0b2 ships. This change may be more controversial, though:
The C type checks are a little performance sensitive since they are used on a char by char basis in the C implementation of .upper(), etc. -- do the new methods give the same performance ?
Don't know. Although it's hard to imagine we have any Unicode apps out there now that will notice one way or the other <wink>.
mal wrote:
Any chance of taking a look at it first ?
same as unicodedatabase.c, just other data.
(BTW, what happened to the usual post to SF, review, then checkin cycle ?)
two problems: SF cannot handle patches larger than 500k. and we're in ship mode...
The C type checks are a little performance sensitive since they are used on a char by char basis in the C implementation of .upper(), etc. -- do the new methods give the same performance ?
well, they're about 40% faster on my box. ymmv, of course. </F>
mal wrote:
Any chance of taking a look at it first ?
same as unicodedatabase.c, just other data.
(BTW, what happened to the usual post to SF, review, then checkin cycle ?)
two problems: SF cannot handle patches larger than 500k. and we're in ship mode...
The C type checks are a little performance sensitive since they are used on a char by char basis in the C implementation of .upper(), etc. -- do the new methods give the same performance ?
well, they're about 40% faster on my box. ymmv, of course.
Fredrik, why don't you make your patch available for review by Marc-Andre -- after all he "owns" this code (is the original author). If Marc-Andre agrees, and Jeremy has enough time to finish the release on time, I have no problem with checking it in. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Fredrik, why don't you make your patch available for review by Marc-Andre -- after all he "owns" this code (is the original author).
hey, *I* wrote the original string type, didn't I? ;-) anyway, the new unicodectype.c file is here: http://sourceforge.net/patch/download.php?id=101652 (the patch is 500k, the new file 14k) the new data file is here: http://sourceforge.net/patch/download.php?id=101653 the new generator script is already in the repository (Tools/unicode/makeunicodedata.py) </F>
Fredrik Lundh wrote:
mal wrote:
The C type checks are a little performance sensitive since they are used on a char by char basis in the C implementation of .upper(), etc. -- do the new methods give the same performance ?
well, they're about 40% faster on my box. ymmv, of course.
Hmm, I get a 1% performance downgrade on Linux using pgcc, but in the end its a win anyways :-) What remains are the nits I posted to SF. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (4)
-
Fredrik Lundh
-
Guido van Rossum
-
M.-A. Lemburg
-
Tim Peters