Stefan Krah added the comment:
Upgrading to critical, since I just verified that C extensions in
general don't build on FreeBSD due to this issue.
Sorry for bringing this up on the release day, it's a coincidence that
I discovered it today...
--
priority: normal -
Stefan Krah added the comment:
Checked python-3.1.2.msi with f-prot, no viruses. Checked download
with firefox (which claims to do a short virus scan), no results.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
Thinking about it, declaring PyMODINIT_FUNC as void would be a huge
step backwards. Using PyMODINIT_FUNC is the correct way of doing things.
The current situation punishes developers who actually read the docs.
If a C module stops working because of the change
Stefan Krah added the comment:
Right, Debian's solution is quite reasonable. Closing as wont_fix.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
r86848: backported r85422, as required by the changes in r85358.
Antoine, there are some remaining {LDFLAGS}, two in the Darwin sections,
one in the OpenBSD section.
I think all of those should be removed as well. Do you agree?
--
nosy: +pitrou
Stefan Krah added the comment:
> PyUnicode_EncodeDecimal() is either unnecessary or should be exposed
> as a codec.
I'm depending on PyUnicode_EncodeDecimal in cdecimal. In fact, it saved
me quite a bit of trouble. I wouldn't be surprised if other extension
writer
Stefan Krah added the comment:
[Antoine]
> I didn't want to mess with these things too much. I guess you can try
> and we'll see.
You're right, it's better not to touch the Darwin stuff.
The 2.7 buildbots are green (including the FreeBSD ones!). I also
tested
Stefan Krah added the comment:
> (Anyone knows whether Arabic numbers are written right to left or left
> to right? What is the proper decimal point character?)
Thousands separator: U+066C
Decimal point: U+066B
١٢٣٬١٢٣٫١٢ should be: 123,123.12
Wikipedia says that digits are arran
Stefan Krah added the comment:
> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
Hmm, looks like a bug? I think U+066B is correct.
--
___
Python tracker
<ht
Stefan Krah added the comment:
Without the patch, you see the warning if test_build_ext is run in
verbose mode. With the patch, the warning disappears.
--
___
Python tracker
<http://bugs.python.org/issue9
Stefan Krah added the comment:
Alexander Belopolsky wrote:
> On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
> wrote:
> ..
> > * Please change the API _PyUnicode_NormalizeDecimal() to
> > PyUnicode_ConvertToASCIIDecimal() - that's closer to what
> > i
New submission from Stefan Krah :
I'm not sure if this is a documentation issue or a bug. If watchexp=0,
quantize() also allows any number of digits:
>>> x = Decimal("6885998238912213556789006667970467609814")
>>> y = Decimal("1e2")
>>> x.q
Stefan Krah added the comment:
NaNs, however, are decapitated:
>>> x = Decimal("NaN5357671565858315212612021522416387828577")
>>> y = 0
>>> x.quantize(y, watchexp=0)
Decimal('NaN8315212612021522416387828577')
--
__
Stefan Krah added the comment:
Before anyone does any further testing:
Tarek, can this go into distutils 2.7/3.2 (after 3.2 has been released)?
Due to the popularity of this issue I think it might be worthwhile to
make an exception and ignore the distutils freeze
Stefan Krah added the comment:
[Alexander]
if sys.getenv('PYTHONSEGVHANDLER'):
import segvhandler
segvhandler.enable()
+1
If this doesn't find support, I'd name sys.setsegfaultenabled()
sys.setsegvhandlerenabled() or sys.enable_segvhandler().
---
Stefan Krah added the comment:
STINNER Victor wrote:
> Note: To avoid the signal-safe requirement, another solution is to use
> sigsetjmp()+siglongjmp().
FWIW, there is a caveat in the OpenBSD man page concerning the use of
siglongjmp():
http://www.openbsd.org/cgi-bin/man.cgi
New submission from Stefan Krah :
When CFLAGS are set, distutils drops -fno-strict-aliasing (among other
flags):
$ python2.7 setup.py build
...
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC -I./src -I/usr/local/include
-I/usr/local/include
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue9880>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
I narrowed this issue down to -ftree-vectorize, which is part of
-O3.
--
___
Python tracker
<http://bugs.python.org/issue9
Stefan Krah added the comment:
If OrderedDict is used, the test case quickly uses 8GB of memory. With
this change (I'm not suggesting this as a fix!), the timings are normal:
Index: Lib/ConfigParser.py
===
--- Lib/ConfigPars
Stefan Krah added the comment:
This seems to be a duplicate of #7424.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> segmentation fault in listextend during install
___
Py
Stefan Krah added the comment:
See also:
http://gnats.netbsd.org/42627
--
nosy: +H.Xu, haypo, loewis, skrah
___
Python tracker
<http://bugs.python.org/issue7
New submission from Stefan Krah :
Hi,
to_integral() should behave like quantize() for negative exponents:
"Otherwise (the operand has a negative exponent) the result is the
same as using the quantize operation using the given operand as the
left-hand-operand, 1E+0 as the right-hand-op
New submission from Stefan Krah :
Another exciting corner case in plus/minus:
"The operations are evaluated using the same rules as add and subtract;
the operations plus(a) and minus(a) (where a and b refer to any numbers)
are calculated as the operations add(’0’, a) and subtract(’
Stefan Krah added the comment:
Éric, the Debian patch looks good to me and it solves my build problem.
The only question I have is why EXTRA_CFLAGS still go behind CFLAGS
and cannot be overridden via the environment.
But as it is, the patch is an improvement. I'm attaching the version
fo
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Why is OPT duplicated in get_config_vars(...)?
I missed that, thanks.
> Why do OPT and BASECFLAGS environ vars override their Makefile values
> instead of accumulating with them?
I think it would go too far to append in three p
Stefan Krah added the comment:
EXTRA_CFLAGS were removed in r38848. Is it necessary to configure
OPT, BASECFLAGS and EXTRA_CFLAGS via the environment? I think it
might be sufficient to take CFLAGS from the Makefile and append
the environment CFLAGS.
Chris, would the new minimal patch solve
Stefan Krah added the comment:
For the record, I prefer Python's behavior. The quantize() definition
does not work well for arbitrary precision input and leads to situations
like:
Precision: 1
Maxexponent: 1
Minexponent: -1
tointegral 101 -> 101
tointegral 101.0
Stefan Krah added the comment:
The patch and the test cases look good, but the implicit context must
be looked up earlier now (see the altered patch).
I just realize that there aren't any regression tests for this sort
of situation, since for the main tests we are only testing the co
Stefan Krah added the comment:
Chris Lambacher wrote:
> I was cross-compiling to a target architecture that does not support
> the -march option so I would not be able to provide a different one
> as override.
Just out of curiosity: You are cross-compiling a C-extension? How can
yo
New submission from Stefan Krah :
Due to an integer overflow in unicode_hash, the python interpreter
crashes if built with -ftrapv:
./configure --with-pydebug CFLAGS="-ftrapv"
Starting program: /home/stefan/svn/py3k/python
[Thread debugging using libthread_db enabled]
Progra
Stefan Krah added the comment:
Ok, this is known, see #1621. Closing.
--
resolution: -> duplicate
status: open -> closed
superseder: -> Do not assume signed integer overflow behavior
___
Python tracker
<http://bugs.python.or
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue1621>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Could you try the same in Python 2.7 ?
It's the same, just in stringobject.c. Many hash functions have this issue.
> The overflow is intended (after all, it's
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue2531>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
This is what Valgrind complains about:
==4750== 3,456 (1,440 direct, 2,016 indirect) bytes in 30 blocks are definitely
lost in loss record 3,302 of 3,430
==4750==at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==by 0x41B7B5: PyMem_Malloc (object.c
Stefan Krah added the comment:
Mark, thanks for the explanation! - You can generate suppressions for the
Misc/valgrind-python.supp file, but you have to know exactly which errors can
be ignored.
Going through the Valgrind output again, it looks like most of it is about what
you already
Stefan Krah added the comment:
With the latest dtoa.c, your non-caching pow5mult and a quick hack for Balloc
and Bfree I get zero (dtoa.c related) Valgrind errors.
So the attached memory_debugger.diff is pretty much all what's needed for
Valgrind.
--
Added file:
Stefan Krah added the comment:
All outstanding issues mentioned here have been solved in Rev. 77696:
(1) New ANSI path for unknown 64bit platforms (ia64 and Alpha build
without problems now).
(2) Unified tests for decimal and cdecimal.
(3) Documentation for cdecimal.
Other
Stefan Krah added the comment:
(6) Yes, I think that is logical. In cdecimal, I accept integers for all unary
methods except is_canonical and number_class.
--
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
I'm new to this thread, so I hope I didn't miss anything that has been
said already. I don't fully understand why TypeError cannot be raised
in 2.x. The 2.6 documentation for tp_richcompare says:
"If you want to implement a type for which o
Stefan Krah added the comment:
If none of you is working on it right now, I'll produce a new patch.
Mark, how about this:
def __add__(self, other, context=None, raiseit=False):
"""Returns self + other.
-INF + INF (or the reverse) cause Inv
Stefan Krah added the comment:
Juan: Sure, take your time. :) I just wanted to know if you were still busy
with it.
--
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
Marc-Andre,
on 64-bit Ubuntu, this method ...
BASECFLAGS=-m32 LDFLAGS=-m32 ./configure
... results in a gcc segfault:
gcc -pthread -m32 -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython3.2.a
Stefan Krah added the comment:
The builds are almost identical, so I attach a diff of the build output.
For both builds, I used a fresh Python-3.1.1 directory. This looks
suspicious:
-checking whether va_list is an array... yes
+checking whether va_list is an array... no
For completeness
Changes by Stefan Krah :
Removed file:
http://bugs.python.org/file16023/basecflags-vs-patch-3.1.1-builddiff.txt
___
Python tracker
<http://bugs.python.org/issue1628
Changes by Stefan Krah :
Added file:
http://bugs.python.org/file16024/basecflags-vs-patch-3.1.1-builddiff.txt
___
Python tracker
<http://bugs.python.org/issue1628
Stefan Krah added the comment:
(1) I can get around the configure problem by patching configure.in,
meaning that va_list is detected correctly now. Perhaps BASECFLAGS
should be used by default for the compile tests?
(2) Now I run into the problem that distutils somehow ignores the
Stefan Krah added the comment:
I also think that the added docstrings are not really necessary.
Another thing: I forgot to mention 'canonical' in the list of functions
that should only accept Decimals. As with the other two (number_class
and is_canonical), this is a matter of taste.
Stefan Krah added the comment:
Yes, indeed 'canonical' can be justified to take an integer, if we interpret
the spec as:
'canonical' takes an operand and returns the preferred _decimal_
encoding of that operand.
But then 'is_canonical' should return false
New submission from Stefan Krah :
As discussed privately, the following test cases should raise TypeError
(currently ValueError):
self.assertRaises(TypeError, Decimal, (0., (4, 3, 4, 9, 1), 2) )
self.assertRaises(TypeError, Decimal, (Decimal(1), (4, 3, 4, 9, 1), 2))
self.assertRaises(TypeError
Stefan Krah added the comment:
I wonder if this is technically a bug. The stream is not opened for reading and
yet you do an fread. I quickly glanced through the
C-Standard and I did not find an _explicit_ paragraph that this is
undefined behavior, but personally I'd expect it
Stefan Krah added the comment:
Bug or not, this can be handled since fread sets EBADF on Windows.
--
keywords: +patch
Added file: http://bugs.python.org/file16071/fileread-errno.patch
___
Python tracker
<http://bugs.python.org/issue5
Stefan Krah added the comment:
I see that a complete errno based solution would get messy. To avoid
interfering with EAGAIN special cases, this would be needed:
#if defined(EBADF)
#define ERRNO_EBADF(x) ((x) == EBADF)
#else
#define ERRNO_EBADF(x) 0
#endif
Then, additional checks would need to
Stefan Krah added the comment:
An errno+ferror approach works except for two cases:
(1) MS fgets() does not consider reading from a write-only stream
an error. While annoying, I think this is standard conforming.
(2) OpenSolaris sets errno unreliably after getc.
I do not know how
Changes by Stefan Krah :
Added file: http://bugs.python.org/file16104/errno-ebadf-tests.patch
___
Python tracker
<http://bugs.python.org/issue5677>
___
___
Python-bug
Stefan Krah added the comment:
The new patch takes over the logic from fileio.c. Tested on Linux, Windows
x86/x64 and OpenSolaris.
--
Added file: http://bugs.python.org/file16115/add-readable-writable.patch
___
Python tracker
<h
Stefan Krah added the comment:
I tested bsd3.diff on OpenBSD-4.4/py3k and it works fine. ncurses
doesn't build and I get a libssl assertion failure in test_ftplib,
but without the patch I can't build py3k at all.
This is a significant improvement, so +1 for applying
Stefan Krah added the comment:
Thanks Antoine, I fixed both issues.
--
Added file: http://bugs.python.org/file16140/add-readable-writable2.patch
___
Python tracker
<http://bugs.python.org/issue5
Stefan Krah added the comment:
Ok, I'll fix that. Perhaps I should also remove the comment in err_mode(). I
wonder if the ValueError in fileio.c is intentional:
>>> import io
>>> f = io.open("testfile", "w")
>>> f.write("xxx")
3
&
Changes by Stefan Krah :
Added file: http://bugs.python.org/file16141/add-readable-writable3.patch
___
Python tracker
<http://bugs.python.org/issue5677>
___
___
Python-bug
New submission from Stefan Krah :
I think that certain FileIO methods should raise IOError instead of
ValueError when a file operation is attempted with the wrong mode.
The methods of IOBase are documented to raise IOError in these situations.
>>> import io
>>> f = io.o
Stefan Krah added the comment:
Thanks for reporting. This looks like a duplicate of issue3920.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
I can reproduce it almost always under these conditions:
System: Ubuntu Intrepid 64-bit, running on the actual hardware.
CPU: Core 2 Duo.
Load: At least one core maxed out by another process.
On an empty machine I haven't reproduced it yet.
--
Stefan Krah added the comment:
Confirm that 2.5 is the only troublesome version, but also when compiled from
source (Ubuntu 64-bit, 2.5.5).
--
nosy: +skrah
versions: +Python 2.5 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
As an aside, I would not use atof(). Better use something like:
char *end;
f = strtod(input, &end);
if (*end != '\0') {
PyErr_Format(PyExc_ValueError, "Could not convert: %s", end);
return NULL;
}
I've two questions:
1)
Stefan Krah added the comment:
I have a patch that fixes this specific issue. Probably there are similar
issues in other places, e.g. when LC_TIME and LC_CTYPE differ.
I suspect that this is related:
http://bugs.python.org/issue5905
--
keywords: +patch
Added file: http
Stefan Krah added the comment:
In my testing of issue 3920 I missed that the original approach also
fixed the ncurses.h problem, so it should be preferred over bsd3.diff.
I attach a patch that reverts the recent commit and extends the
xopen_source=no up to version 4.9. I've tested it o
Stefan Krah added the comment:
On OpenBSD the ncurses.h header has been broken for quite some time,
see e.g. http://bugs.python.org/issue1244610. The problem is that
when _XOPEN_SOURCE_EXTENDED is defined, wchar_t is defined twice.
I can confirm that it is still broken on 4.6, but it appears
Stefan Krah added the comment:
This is fixed in trunk by the configure.in patch. I've tested trunk on 4.4
and 4.7.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
It is a stack overflow, which can be prevented by setting
#define Py_DEFAULT_RECURSION_LIMIT 150
in Python/ceval.c.
Then the program behaves in the same way as on Linux (i.e. it swallows
the RuntimeError somewhere). Recommend closing.
--
nosy: +skrah
Stefan Krah added the comment:
It looks good (I agree on number_class), but I'd change these:
- Add raiseit=True to context.copy_decimal()
- Remove wrong comment from context.is_infinite()
- Add _convert_other(a, raiseit=True) to context.logical_invert()
- More whitespa
Stefan Krah added the comment:
I found the problem. On a loaded machine, an attempt is made to
get the pid of the worker before the process has properly started.
There are several places where a sleep could be inserted. Perhaps
Process.start() should wait until the child's pid is not
Stefan Krah added the comment:
I think it would be nice to update the documentation if this isn't
resolved yet. The patch adds a warning that FIFO behavior is not
guaranteed.
--
keywords: +patch
nosy: +skrah
Added file: http://bugs.python.org/file16276/warn_fifo.
Stefan Krah added the comment:
This is documented, so I'd recommend to close this issue.
http://docs.python.org/3.1/c-api/intro.html#include-files
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
This is a very loosely related issue, but I think it fits in here.
To be consistent with the documentation, the three argument power
should use the ideal exponent:
>>> c = getcontext()
>>> c.prec = 400
>>> Decimal('1E400') % D
Stefan Krah added the comment:
I've tried to pinpoint exactly what I don't like about the current
behavior, and the main reason is that it violates my mental model
of how the functions in the specification generally behave:
1) Functions take arbitrary precision input.
2) Functi
Stefan Krah added the comment:
I couldn't find other issues where #1 and #2 are addressed. This
is from py3k:
#1:
>>> format(float('nan'), '+08.4')
'+nan'
[70141 refs]
>>> format(Decimal('nan'), '+08.4')
'+
Stefan Krah added the comment:
[The tracker apparently set the status to 'open' without my intervention.]
To sum up what I said earlier about #1 and #2, I think that the C standard
and gcc's warning behavior support the
Stefan Krah added the comment:
instigate_team, you said earlier that you have no warnings if you change
the include sequence according to the documentation. Unless you provide
a concrete example where the position dependent include of Python.h
makes building _impossible_ (as opposed to being a
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue8188>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
Mark, this looks great, thanks.
--
___
Python tracker
<http://bugs.python.org/issue7279>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Mark, very nice concept! - I'm just starting to review the patch, but I
think the unsigned longs in_Py_HashDouble() and long_hash() should be
uint64_t on a 64-bit OS.
For instance, now on Windows 64-bit:
>>> hash(2**61
Stefan Krah added the comment:
Actually the current long_hash() is affected as well. On Windows 64-bit:
>>> hash(2**31)
-2147483648
>>> hash(2**32)
1
--
___
Python tracker
<http://bugs
Stefan Krah added the comment:
I've finished reviewing the patch and I think it's quite ready to be
applied.
The documentation in stdtypes.rst says that P = 2**61-1 on 64-bit
machines. This should be changed to reflect the fact that actually
sizeof long is the deciding factor. I atta
New submission from Stefan Krah :
Mark, are you ok with silencing these conversion warnings?
--
components: Build
files: longobject_vs_warnings_py3k.patch
keywords: patch
messages: 102482
nosy: mark.dickinson, skrah
severity: normal
status: open
title: longobject.c: silence warnings
Changes by Stefan Krah :
Added file: http://bugs.python.org/file16787/longobject_vs_warnings_trunk.patch
___
Python tracker
<http://bugs.python.org/issue8328>
___
___
New submission from Stefan Krah :
On Windows/amd64, I get loads of pickling errors in test_multiprocessing.
Type 1 error:
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 347, in
main
sel
Stefan Krah added the comment:
Committed in trunk (r79885), py3k (r79886) and release31-maint (r79891).
Thanks for the review!
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Stefan Krah added the comment:
It was introduced in r79623, and the attached patch makes the problem
go away. I would be happy to apply it, but I perhaps you and Michael
could analyze if there are unwanted dependencies between multiprocessing
and unittest.
--
nosy: +michael.foord
Changes by Stefan Krah :
--
keywords: +patch
Added file: http://bugs.python.org/file16805/issue8333.patch
___
Python tracker
<http://bugs.python.org/issue8
Stefan Krah added the comment:
Confirmed on Windows 7 under qemu with a fresh trunk checkout.
--
nosy: +skrah
priority: low -> high
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/iss
Stefan Krah added the comment:
According to http://standards.ieee.org/regauth/groupmac/tutorial.html ,
the assertions in check_node are weeding out perfectly valid addresses:
>>> node = 0x525400123456
>>> universal_local_bit = (node >> 40L) & 2
>>> univers
Stefan Krah added the comment:
The multicast bit is the least significant bit of the first octet.
Could you check if the patch for http://bugs.python.org/issue3581
fixes your problem?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
Still fails with trunk on OpenBSD. The error is more ctypes related
though: _uuid_generate_time isn't set.
==
ERROR: test_unixdll_getnode (__main__.Tes
Stefan Krah added the comment:
The new patch test_uuid.patch fixes issue 7650, issue 1481 and this one.
I've applied it to py3k-cdecimal in r79905 and test_uuid is passed
on all buildbots (I did not test on ARM and one FreeBSD bot is still hanging in
test_subprocess).
Additionally, the
Stefan Krah added the comment:
With test_uuid.patch from issue 3581 (related) no warnings can be seen on the
buildbots.
--
___
Python tracker
<http://bugs.python.org/issue1
Stefan Krah added the comment:
5. uuid.getnode() can fall back to creating a random 48 bit number and
so can _windll_getnode() (by using UuidCreateSequential). Therefore,
in unlucky cases 0x can be generated and the assert in
check_node() will fail.
check_node() is
Stefan Krah added the comment:
I do not understand the semantics of uuid.getnode(). Per the docs
it's supposed to return a hardware address. This would reasonably
make it a UUID version 1.
But then the random fallback should be a 47 bit number as per
http://www.ietf.org/rfc/rfc4122.txt se
Stefan Krah added the comment:
I reread http://www.ietf.org/rfc/rfc4122.txt and I'm pretty sure that
if getnode() is supposed to return a hardware address, one of the
following should be used:
1) If ifconfig etc. returns successfully, we are fine.
2) If uuid_generate_time
401 - 500 of 3396 matches
Mail list logo
