Jean Brouwers added the comment:
I haven't retested that yet, but I will as soon as can.
/Jean Bouwers
On May 26, 2013, at 7:57 AM, Mark Lawrence wrote:
>
> Mark Lawrence added the comment:
>
> is this still a problem with 2.7 or 3.x?
>
>
Jean Brouwers added the comment:
Mark L,
No, I do not intend to take this issue further. Rather the opposite, it should
probably be paired down based on the recent comments. Specifically, use
PyOS_double_to_string, remove support for long double and perhaps more.
Also, the patches I
Jean Brouwers added the comment:
It would be sufficient to support size_t/ssize_t in native mode for my usage.
The workaround I have been using is in this recipe
<http://code.activestate.com/recipes/546530/>
in the function calcsize. That maps the 'z' and 'Z'
Changes by Jean Brouwers :
Removed file: http://bugs.python.org/file18006/unnamed
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailin
Jean Brouwers added the comment:
Yes I am and I will get back to you on this after check my (old) notes.
/Jean
On Wed, Jul 14, 2010 at 12:08 PM, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> Jean, if you're still around:
>
> Do you still have in
Jean Brouwers added the comment:
The test also passes on Python 2.6.2 on MacOS X 10.4.11 Tiger (Intel):
% ./python.exe
Python 2.6.2 (r262:71600, Apr 15 2009, 21:47:16)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or
Jean Brouwers added the comment:
This test passes with Python 3.1rc2 on MacOS X 10.4.11 Tiger (Intel).
% ./python.exe
Python 3.1rc2 (r31rc2:73411, Jun 14 2009, 09:27:12)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credi
Jean Brouwers added the comment:
This test still fails and is the only failure with Python 3.1rc2 on MacOS
X 10.4.11 Tiger (Intel).
--
___
Python tracker
<http://bugs.python.org/issue4
Jean Brouwers added the comment:
Correct. With new Lib/asyncore.py file rev 73183 all 23 tests in the
original test_asynchat.py pass in Python 3.1rc1 built from source on
MacOS X 10.4.11 Tiger (Intel).
% ./python.exe Lib/test/test_asynchat.py
test_close_when_done (__main__.TestAsynchat
Jean Brouwers added the comment:
Well, with fresh build of Python 3.1rc1 on MacOS X 10.4.11 Tiger (Intel)
test_asynchat.py rev 73183 still seems to
fail, perhaps differently. Here is 3 different results. First, rev 73183:
% ./python.exe Lib/test/test_asynchat73183.py
test_close_when_done
Jean Brouwers added the comment:
Fixed a couple of typos in the README and _profile_hires.c files of the
attached profile_module2.tgz tar ball.
--
Added file: http://bugs.python.org/file14156/profile_module2.tgz
___
Python tracker
<h
Changes by Jean Brouwers :
Removed file: http://bugs.python.org/file14131/profile_module.tgz
___
Python tracker
<http://bugs.python.org/issue2919>
___
___
Python-bug
Jean Brouwers added the comment:
I just added another comment about the high-resolution timer in
<http://bugs.python.org/issue2281>.
--
___
Python tracker
<http://bugs.python.org/
Jean Brouwers added the comment:
Another thought on the hires timer to make the hires time and hires time
units available as 2 other functions in the time module.
For example, function time.ticks() returns the hires time stamp as an
int. Function time.ticks2secs(t) converts a given number
Jean Brouwers added the comment:
Attached is *an* attempt to combine the old profile/cProfile modules into a
single
one called profile. Only the C and Python source and test files are included,
not
any documentation files. More details are in the README file, copied below.
Hopefully
Changes by Jean Brouwers :
Removed file: http://bugs.python.org/file14006/hpTime.c
___
Python tracker
<http://bugs.python.org/issue2281>
___
___
Python-bugs-list mailin
Changes by Jean Brouwers :
Removed file: http://bugs.python.org/file14004/hires_lsprof4.tgz
___
Python tracker
<http://bugs.python.org/issue2281>
___
___
Python-bug
Jean Brouwers added the comment:
Another test build and result has been added to the hpTime.c comment.
--
Added file: http://bugs.python.org/file14012/hpTime.c
___
Python tracker
<http://bugs.python.org/issue2
Jean Brouwers added the comment:
Both the hires_lsprof4.tgz and hpTime.c files have been updated with a
change in the PowerPC asm code.
The previous implementation used a loop: label and that may cause
duplicate symbols when compiled at optimization levels of -O3 and above
with older GNU C
Jean Brouwers added the comment:
Here a small, standalone test program of the hires timer code from
_lsprof4.c.
The results from 10 different builds are included in the comment.
--
Added file: http://bugs.python.org/file14006/hpTime.c
___
Python
Jean Brouwers added the comment:
There were two problems with _lsprof4.c. Attached is the corrected file
and the forward diff with _lsprof.c rev 6670.
--
Added file: http://bugs.python.org/file14004/hires_lsprof4.tgz
___
Python tracker
<h
Changes by Jean Brouwers :
Removed file: http://bugs.python.org/file14001/hires_lsprof4.tgz
___
Python tracker
<http://bugs.python.org/issue2281>
___
___
Python-bug
Jean Brouwers added the comment:
Attached is yet another version of the Modules/_lsprof.c source, called
_lsprof4.c.
This one adds support for the hires timer on 32- and 64-bit Intel and
PowerPC processors iff compiled with GNU C.
With _lsprof4.c, the high precision profile is available on
Jean Brouwers added the comment:
Attached is another version of the Modules/_lsprof.c source file.
This _lsprof3.c uses the hires time base on Mac OS X, Solaris and HP-UX
(plus MS Windows like before) and does not require any asm code.
Also, there are no changes other than the very top of
Jean Brouwers added the comment:
Possible, I do not know and had never seen this before.
Also, I just installed the latest (free) version 13.0.3 (Intel Build
165) of Stuffit Expander and the problem does *not* occur.
But the older Stuffit 11.0.2 (Intel Build 627) still creates 2 files for
Jean Brouwers added the comment:
Here are the answers to your questions.
% python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more informat
Jean Brouwers added the comment:
Another attempt to attach the image.
--
Added file: http://bugs.python.org/file13979/Issue5956.jpg
___
Python tracker
<http://bugs.python.org/issue5
Jean Brouwers added the comment:
Indeed, this is Python 3.1b1 built from source on MacOS X 10.4.1 Tiger
(Intel).
MacOS considers some of these win*.exe files directories. See the
attached picture and below.
% ls -l Python-3.1b1/Lib/distutils/command/win*
-rw-r--r-- 1 jean jean 61440
Jean Brouwers added the comment:
Indeed, the unmodified test_asynchat.py now passes in Python 3.1b1. The
readwrite function in asyncore looks like this now:
def readwrite(obj, flags):
try:
if flags & (select.POLLHUP | select.POLLERR | select.POLL
Jean Brouwers added the comment:
Understood.
On Thu, May 7, 2009 at 5:18 PM, Josiah Carlson wrote:
>
> Josiah Carlson added the comment:
>
> As an aside, I was testing against trunk, not 3.1b1 .
>
> --
>
> ___
&
Jean Brouwers added the comment:
I reran the test_synchat.py test after patching to the Lib/asyncore.py
and Lib/test/test-asynchat.py files of Python-3.1b1 on MacOS X 10.4.11
(Intel).
The test now hangs in
...
test_string_producer (__main__.TestAsynchat) ... ok
test_close_when_done (__main__
New submission from Jean Brouwers :
% make test
test_distutils
test test_distutils failed -- Traceback (most recent call last):
File "../Python-3.1b1/Lib/distutils/tests/test_bdist_wininst.py", line
23, in test_get_exe_bytes
exe_file = cmd.get_exe_bytes()
File "../P
Jean Brouwers added the comment:
Here is a (new?) failure of test_asynchat with Python 3.1b1 on MacOS X
10.4.11 (Intel).
% make test
test test_asynchat produced unexpected output:
**
*** lines 2-16 of actual output
Jean Brouwers added the comment:
Typo. That should be ..., os.O_RDWR)
--
___
Python tracker
<http://bugs.python.org/issue5870>
___
___
Python-bugs-list mailin
New submission from Jean Brouwers :
The subprocess module exposes the PIPE and STDOUT constants to be used
for the stdin, stdout or stderr keyword arguments.
Often, stderr needs to be redirected to /dev/null (on posix). It would
nice if another constant was available for that purpose, e.g
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file:
http://bugs.python.org/file12308/Python-2.6.1-64bit-Solaris10-math_patch.log
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
It looks like the patch did fix the problems. Attached are the results
for 32- and 64-bit Python 2.6.1 with and without the patch, all built with
SUN's compilers on Solaris 10 (Opteron).
The math log tests failed with the 3
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The results from this script
import os, sys
print('Python %s' % sys.version.split()[0])
print('env[LANG]: %s' % os.environ.get('LANG', ''))
print('default encoding: %s' % sy
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The test was originally run with
% echo $LANG
tcsh: LANG: Undefined variable.
The same failure occurs with LANG set to C
% env LANG=C ../Python-3.0rc3/python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest)
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
There is one test failure with Python 3.0rc3 built on MacOS X 10.4.11
(Intel). Test test_cmd_line fails in the very last test as follows:
% python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok
test_op
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
--
versions: +Python 2.7 -Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
--
versions: +Python 2.7 -Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
--
versions: +Python 2.7 -Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3 -Python 2.7
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3 -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3 -Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
Soyez heureux avec votre taille et de rendre votre partenaire heureux et
satisfait.
Alors que VPXL elargissement chirurgie est couteux et parfois dangereux,
pilules pourrait facilement etre oublie de prendre et d'autres produ
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
The test_urllib2_localnet fails on MacOS X 10.4.11 (Intel) with Python 2.6b2
(and 3.0b2), see
below.
The same test also failed for Python 2.6b1 but was not reported as a test
failure.
% ./python.exe
Python 2.6b2 (r26b2:65082,
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The /lib/libm.so.* files on my Solaris 10 (Opteron) box are equally old:
> ll /lib/libm.so*
lrwxrwxrwx 1 root root 9 Sep 7 2006 /lib/libm.so -> libm.so.2*
-rwxr-xr-x 1 root bin 13536 Jan 22 2005 /lib/libm.so.1
-rwxr
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10818/config64.log.gz
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Can't find that particular message. Attached is the entire log of one of
the SUN C builds of Python 2.6b1.
Added file: http://bugs.python.org/file10817/config.log.gz
___
Python tracker <[E
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Below is the reply from SUN. It was indeed a bug which has been fixed already.
I have not yet applied the patches to my SUN compilers and tried again.
/Jean
Begin forwarded message:
From: Sun Microsystems <[EMAIL PROTECTED]>
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
There is another, perhaps related issue on Solaris. The compiler warns
that function finite is implicitly defined.
Commenting out this line in pyconfig.h as
/* #define HAVE_FINITE 1 */
make that warning go away. If there is no fu
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Without changing the cmath_log code, another workaround is to compile
Python with optimization level -xO2 or less for 64-bit using Sun C.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
File but showing -xO0 thru -xO5 results.
Added file: http://bugs.python.org/file10775/SunC-64bit-xO5-bug.c
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10774/SunC-64bit-xO5-bug.c
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10762/c_quot.c
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is a test case which does demonstrate the problem. See the top
of that file. I will post this at the SUN C Forum.
Added file: http://bugs.python.org/file10774/SunC-64bit-xO5-bug.c
___
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
I have not yet been able to duplicate the problem in a smaller test
case, but I did stumble into a fix. Changing the following statement in
the cmath_log function from
if (PyTuple_GET_SIZE(args) == 2)
x = c_
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
What about this case? Should cmath not produce the same result as math:
>>> math.log(float('-inf'))
Traceback (most recent call last):
File "", line 1, in
ValueError: math domain error
>>> cmath
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
For comparison, 64-bit -xO5 Python build:
Python 2.6b1 (r26b1:64398, Jun 28 2008, 12:50:06) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> i
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Yep, that one works. As before, using ./configure --without-gcc ...
BASECFLAGS= -xlibmieee
CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
# Both CPPFLAGS and LDFLAGS need to contain the shell's value for
setup
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Trying to isolate and duplicate the problem with c_quot isn't quite
working. See the attached c_quot.c file and the results at the end.
Added file: http://bugs.python.org/file10762/c_quot.c
___
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
This is pretty bizarre, take a look at the following, 64-bit Pyhon 2.6b1
-xO5.
Python 2.6b1 (r26b1:64398, Jun 28 2008, 12:50:06) [C] on sunos5
Type "help", "copyright", "credits" or "licen
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
I applied your patch to freshly updated configure and configure.in files
and ran ./configure --without-gcc on Solaris.
The resulting Makefile has empty BASECFLAGS and LDFLAGS. Here is the
snippet:
# Compiler optio
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Sorry, my previous post was wrong. The LDSHARED symbol did NOT include -
xlibmieee. Only the BASECFLAGS and the LDFLAGS.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Forgot to mention, both 64-bit builds above includes -xlibmieee in the
BASECFLAGS and LDFLAGS ./configure symbols (not LDSHARED!).
The complete .configure command line was (with OPT adjusted accordingly):
env CCSHARED="-KPIC&qu
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The SUN compiler versions
> cc -V
cc: Sun C 5.8 2005/10/13
usage: cc [ options] files. Use 'cc -flags' for details
> CC -V
CC: Sun C++ 5.8 2005/10/13
Both define the following symbols:
#define __SUNPRO_C 0x58
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here are the 64-bit results. First with -xO5:
Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:57:27) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> i
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
For 32-bit, see the latest posts at <http://bugs.python.org/issue3167>.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The 32-but results are the same when built with -xO5.
Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:43:53) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more inf
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Keep in mind also, these Python builds are compiled with the SUN
compilers, i.e. the ./configure command line includes --without-gcc.
If we do change the CC- and LINKFLAGS, those changes should only apply
in that particular case.
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The patch <http://bugs.python.org/file10754/issue3167.patch> does not
work. The -xlibmieee flag is included in the cc command lines, like
cc -c -xtarget=native -xlibmieee -DNDEBUG -xO5 -I.
However, the resulting build
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
3 different Python 2.6b1 builds:
1) 64-bit Python 2.6b1 on Solaris 10 built with SUN C (no -xlibmieee):
Python 2.6b1 (r26b1:64398, Jun 19 2008, 20:27:39) [C] on sunos5
Type "help", "copyright", "credits&quo
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The 64-bit version did the right thing, all along. The 32-bit result is
correct only when compiled with option -xlibmieee.
But the latter sets errno value to EDOM and that should be 0, rather
remain unmo
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Sorry, the flag *does* make a difference. Ignoring errno, the results for
32- and 64-bit do match.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Unless I am doing something wrong, that flag does not fix the problem.
#include
#include
#include
int main(int argc, char *argv[])
{
errno = 0;
printf("%f %d\n", log(-HUGE_VAL), errno);
errno = 0;
print
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Mark,
Take a look at the SUN forum, there is a (long) answer.
<http://forum.java.sun.com/thread.jspa?threadID=5308106&tstart=0>
/Jean
On Tue, Jun 24, 2008 at 3:37 PM, Jean Brouwers <[EMAIL PROTECTED]> wrote:
>
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Right on! With errno = 0; in between both calls:
-Inf 33
Inf 0
/Jean
On Tue, Jun 24, 2008 at 1:17 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> O
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is another patch for PyString_FromFormat* adding support for 'l' and
'z' type specifications for the '%x' format and an optional '#' to prepend
'0x' to the hex result. In additio
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is a simple test case, demonstrating the issue.
#include
#include
#include
int main(int argc, char *argv[])
{
printf("%f %d\n", log(-HUGE_VAL), errno);
printf("%f %d\n", log( HUGE_VAL), errno);
}
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10705/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The tests for PyString_FromFormat are in file Modules/_testcapimodule.c.
Attached is yet another update of the patch, this one also includes 3
tests for the new %f format specification added to file
Modules/_testcapimodule.c.
Adde
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10703/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Another rev of the patch now including updates to 2 documentation files:
Doc/c-api/exceptions.rst and Doc/c-api/string.rst. As before the patch is
relative to the source of Python 2.6b1.
Where should test cases for the new formats
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10703/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10702/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is another patch for file Objects/stringobject.c(relative to
Python 2.6b1) which supports the double %f and long double %LF formats.
However, %Lf is included only if symbol LDBL_DIG is defined in header
file on the unde
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is that in from 32- and 64-bit Python 2.6b1:
> ./python (32-bit)
Python 2.6b1 (r26b1:64398, Jun 20 2008, 09:20:49) [C] on sunos5
Type "help", "copyright", "credits" or "license" for mor
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
Test test_macos is reported as an "unexpected skip" on linux2 by Python
2.6b1 make test.
35 tests skipped:
...
test_macos test_macostools ...
...
2 skips unexpected on linux2:
test_tcl test_macos
$ uname -a
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10697/stringobject_format_f.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10696/stringobject_format_f.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is a patch attempting to provide support for %f with precision in
PyString_FromFormat* based on file Objects/stringobject.c of Python 2.6b1.
Note, only %f is support but %lf is not and silently ignored.
--
keywords:
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
There is on cmath test failure with 64-bit Python 2.6b1 and 3.0b1 on
Solaris 10. The failure does not occur in the 32-bit builds.
All builds are compiled with Sun's C compiler using the same options
(except -xtarget=native
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
There are 2 math test failures with 32-bit Python 2.6b1 and 3.0b1 on
Solaris 10 both built with Sun's C compiler. The failures do *not*
occur for the 64-bit builds. The same compiler options are used for all
these bui
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10687/struct_size_t.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Please ignore the first patch. Use the rev2 patch which includes an
update for test file Lib/test/test_struct.py as well.
Added file: http://bugs.python.org/file10690/struct_size_t.rev2.patch
___
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
Attached is a (simplistic) patch for the struct module to support C types
ssize_t and size_t with format characters 'z' resp. 'Z'.
The patch updates Python 2.6b1 files Modules/_struct.c and
Doc/library/struct.rs
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
If the struct changes are made, add also 2 formats for C types ssize_t and
size_t, perhaps 'z' resp. 'Z'. In particular since on platforms
sizeof(size_t) != sizeof(long).
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
One more comment on SEM_VALUE_MAX for Solaris. _POSIX_SEM_VALUE_MAX is
defined in on Solaris and that header file must be included.
Better might be to use _SEM_VALUE_MAX which is defined in and
that header files needs to be inclu
1 - 100 of 199 matches
Mail list logo
