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 Behnel added the comment:
I tried several times to debug it myself, but I don't understand the exception
cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and friends, new in Py3).
If someone can get me set up to debug them, I can give it another shot. I
assume there are a coup
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
New submission from Stefan Behnel :
The xml.etree.ElementTree package in the Python 3.x standard library breaks
compatibility with existing ET 1.2 code. The serialiser returns a unicode
string when no encoding is passed. Previously, the serialiser was guaranteed to
return a byte string. By
Stefan Behnel added the comment:
I agree that the lxml API is somewhat clumsy here. I just mentioned it to show
that there are already ways to do it in a backwards compatible way, so this
change does two things: it breaks existing code, and it does so in a way that
is incompatible with other
Stefan Behnel added the comment:
It has been brought up several times that ET is special in the stdlib in that
it is an externally maintained package. Correct me if I'm wrong, but the rules
seem to be: features come outside, adaptation to Py3 can happen inside. What we
are talking about
Stefan Behnel added the comment:
Antoine, in the same comment, you say that it was not backported to Py2 in
order to prevent breaking existing code, and then you ask if it's difficult to
support in lxml. ;-)
Supporting the same behaviour in lxml would either mean that it breaks exi
Stefan Behnel added the comment:
Sorry, Antoine, but you can't possibly mean what you say here. The culprit in
question is clearly one of the best hidden features of the new Py3 ET API. The
only existing reference to it that I can find is the SVN commit comment when it
was applied. H
Stefan Behnel added the comment:
Then I would call that a clear sign that no-one actually stumbled over this
feature in Py3 before I did, well hidden as it was. Still time to fix it.
--
___
Python tracker
<http://bugs.python.org/issue8
Stefan Behnel added the comment:
Hi Guido, your comment was long overdue in this discussion.
Guido van Rossum, 12.03.2010 01:35:
> My thinking was that since an XML document looks like text, it should
> probably be considered text, at least by default. (There may have
> been some
Stefan Behnel added the comment:
One more thing: given that many web-frameworks are still not available for Py3
at this time, and that there are still tons of third-party libraries missing on
that platform, I would be surprised if there was any ElementTree based XML/HTML
processing code
Stefan Behnel added the comment:
"'None' has always been the documented default for the encoding parameter"
What I meant here was that "help(ET.tostring)" will show you that as the
default. Also, in the docs, the signature is "tostring(tree, encoding=None)&q
New submission from Stefan Behnel :
Python 3.2a0 (py3k:78205M, Feb 16 2010, 17:32:08)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> e = None
[50279 refs]
>>> e
[50279 refs]
>>>
Stefan Behnel added the comment:
I knew that the variable was supposed to go out of scope when leaving the
except block, but I wasn't aware that this was supposed to be done using (the
equivalent of) a 'del'. Were the side-effects of deleting variables defined
outside of
Stefan Behnel added the comment:
That's a funny idea. I like that. +1
--
___
Python tracker
<http://bugs.python.org/issue8047>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
> Supporting unicode for lxml.etree compatibility is fine with me, but I
> think it might make sense to support the string "unicode" as well (as
> a pseudo-encoding -- it's pretty clear to me that nobody will ever
> define a real c
Stefan Praszalowicz added the comment:
I just got surprised by this, and I agree that updating the doc would be nice,
because as of now, it states quite explicitly that "the Queue and JoinableQueue
types are multi-producer, multi-consumer FIFO queues".
--
nosy: +Ste
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
Stefan Krah added the comment:
Sorry, the random node id generation in uuid.py is correct. The least
significant bit of the first octet (which is set to 1) is the first
one transmitted on the network, then the "low 47 random bits" follow.
I assumed that the least significant bit of
Changes by Stefan Krah :
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue3581>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
For the record:
In 2.7-alpha you do not even get to press [Restart Shell], since IDLE is
not responding during the calculation.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue8
New submission from Stefan Krah :
Got this test failure on Windows/qemu:
==
FAIL: test_stopasync (__main__.PlaySoundTest)
--
Traceback (most recent call last
Stefan Krah added the comment:
Searching for the failure reveals that sporadically this has appeared on the
buildbots, so I plan to apply the patch soon if there aren't any
protests.
--
assignee: -> skrah
components: +Tests
keywords: +patch
priority: -> normal
stage
Stefan Krah added the comment:
The changes in main.c in r79881 don't look right:
strtok() is used on the string returned by getenv(), which must not
be modified.
Also (and this admittedly cosmetic), perhaps use a static buffer like
wchar_t warning[128] or use a single allocation befor
Stefan Krah added the comment:
Applied test_uuid3.patch to trunk (r79954), release26-maint (r79959),
py3k (r79960) and release31-maint (r79961).
No buildbot failures so far, so I'm closing this.
--
stage: commit review -> committed/rejected
status: open -> closed
versions:
Stefan Krah added the comment:
Fixed in issue 3581. Thanks for the report and the comments!
--
assignee: -> skrah
dependencies: +failures in test_uuid
keywords: +patch
resolution: -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -&
Stefan Krah added the comment:
Issue fixed by test_uuid3.patch from issue 3581 in trunk (r79954),
release26-maint (r79959), py3k (r79960) and release31-maint (r79961).
--
assignee: -> skrah
keywords: -needs review
resolution: -> accepted
stage: patch review -> committed
Stefan Krah added the comment:
This has been fixed in issue 7903.
--
assignee: -> skrah
keywords: +patch
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> Configure script incorrect for reasonably
Stefan Krah added the comment:
There are two cases:
1) stdin and stdout go to a tty:
my_fgets() from Parser/myreadline.c does not handle the case
where fgets() reads some characters followed by an EOF. One
way to deal with this is to consider a sequence like 1234EOF
an empty line.
This is
Stefan Krah added the comment:
Committed in r8, r80001, r80002 and r80003.
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
This type of failure appears again in current builds:
http://www.python.org/dev/buildbot/builders/x86 gentoo
3.x/builds/2160/steps/test/logs/stdio
--
nosy: +skrah
versions: +Python 3.2, Python 3.3
___
Python tracker
Stefan Krah added the comment:
This bugreport http://bugs.gentoo.org/28193 indeed suggests that
the failure occurs on systems without nptl.
Would it be possible for someone with an affected system to run
the test program from the bug report
Stefan Krah added the comment:
You can use http://gnuwin32.sourceforge.net/packages/diffutils.htm or
cygwin or msys.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue8
Stefan Krah added the comment:
The requirement to remember the "-u" option is a benefit for the user.
If he ever wants to use a standard diff, he doesn't have to relearn
things.
I don't agree that diff.py should be a custom tool. It's unfortunate
that it already dev
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue8355>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Valgrind can be installed by:
cd /usr/ports/devel/valgrind && make install
Then you can do (curses_test.py is your short test program):
1) valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python
curses_test.py
2) valgrind --supp
Stefan Krah added the comment:
One oddity: In Mark's test case, the error only shows if readline
is imported _before_ curses. The other way around it's fine.
On FreeBSD 8.0 amd64, with the _default_ libcurses, the Valgrind output
for py3k looks like this:
[...]
==31089== Invali
Stefan Krah added the comment:
I take that back. With the curses from /usr/ports/devel/ncurses,
Mark's test case is fine, but
./python Lib/test/regrtest.py -uall test_curses
fails again.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Alas, after installing curses from /usr/ports/devel/ncurses I did not
recompile Modules/_curses_panel.c.
So, after a proper build
./python Lib/test/regrtest.py -uall test_curses
shows no errors.
--
___
Python
Stefan Krah added the comment:
It seems that FreeBSD has problems with the fact that readline.so is
linked with -lreadline and -lncursesw (why?).
With issue7384.patch I get no more errors using either Mark's test case
or test_curses.py.
--
Added file: http://bugs.python.org/file
Stefan Krah added the comment:
Antoine is right: On a fast machine (3.16GHz) test_io.py takes 810s
on debian-arm/qemu. All tests pass, so perhaps the limit is just too
restrictive on slow machines.
--
nosy: +skrah
___
Python tracker
<h
Stefan Krah added the comment:
I ran the whole test suite on
http://people.debian.org/~aurel32/qemu/arm/debian_lenny_arm_small.qcow2
and there were no hanging processes. test_tokenize also takes around
10min on a fast machine (12s without -uall).
Probably the timeout has to be increased
Stefan Krah added the comment:
To clarify a couple of things:
On some systems (Redhat?) readline is not linked against ncurses in order to
give the user the possibility to choose. This is why setup.py
has to select an ncurses version.
However, things can go wrong if readline is already
Stefan Krah added the comment:
test_itimer_virtual assumes that a process must get 0.3s of virtual
time within 5s of real time. This is not true:
I can easily make the test fail even on a fast machine by doing
as root (do it n times for n cores):
nice -n -19 sh -c 'echo "1234^12345
Stefan Krah added the comment:
Mark, I also think there is no reliable witness function that checks
the amount of virtual time used.
I guess it's best to increase the timeout and just print a diagnostic
if the test "fails".
--
keywords: +patch
Added file: http://
Stefan Krah added the comment:
Right, the skip should be left in place.
--
Added file: http://bugs.python.org/file16988/issue8424-2.patch
___
Python tracker
<http://bugs.python.org/issue8
Stefan Krah added the comment:
Committed fix (with the freebsd6 skips intact) in r80238, r80239, r80240
and r80241.
David, is it intentional that py3k doesn't have the freebsd6 fixes?
--
assignee: -> skrah
resolution: -> accepted
status: open
Stefan Krah added the comment:
Mark, sorry, let me know if I should revert anything.
I took the stdout over from some similar print statements that
once were in test_uuid (I agree that stderr would seem more
natural).
[http://svn.python.org/view/python/trunk/Lib/test/test_uuid.py?r1=50896&am
Stefan Krah added the comment:
The Tiger buildbot triggers the message in build #31:
test_signal
test_itimer_virtual: timeout: likely cause: machine too slow or load too high.
But build #23 is ok.
--
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
Confirmed on FreeBSD-6.4/py3k. Threading causes the problem, the skip
works here, too.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue8
Stefan Krah added the comment:
Jeroen, thanks for the idea. I asked Thomas Dickey and he said that
one should not load both libncurses.so and libncursesw.so.
I think this means that if libreadline.so is already linked against
libncurses.so, we are stuck with libncurses.so for the curses module
Stefan Krah added the comment:
Mark, thanks for reviewing the patch. In the new patch, I added a skip
for OS X.
Buildbot testing looks good. In particular, one FreeBSD bot passes
test_curses now (the other one is hanging in multiprocessing).
For most bots nothing changes. The solaris bot has
Stefan Krah added the comment:
Yes, readline uses only the termcap part of ncurses. I think that
--with-termlib is the correct option, see:
http://www.mail-archive.com/util-linux...@vger.kernel.org/msg00273.html
--
___
Python tracker
<h
Stefan Krah added the comment:
Actually this means that we should also look for -ltinfo in the ldd
check (A Redhat buildbot would be nice).
--
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
The buildbots are generally happy with the change. However, on OpenBSD
test_itimer_prof fails seemingly unrelated to machine load.
I'm not so familiar with the signal module, but how can the signal
handlers in the tests be guaranteed to work? For example, i
Stefan Krah added the comment:
I included the test for libtinfo in the latest patch. The patch is tested
on Fedora and correctly links the curses module with -lncursesw.
This means that the ldd method works on all buildbots, OpenBSD, OpenSolaris
and Fedora.
--
Added file: http
Stefan Krah added the comment:
I'm not against sorting things out in configure.in, but I'm not quite
sure that it will be more portable than ldd:
On FreeBSD (the problem system!) I can't get this to work:
[ste...@freebsd-i386 ~]$ echo 'int main() { readline(); }
Stefan Krah added the comment:
Sigh. xxx.c == test_readline.c in the previous comment.
--
___
Python tracker
<http://bugs.python.org/issue7384>
___
___
Python-bug
Stefan Krah added the comment:
Can you check if the latest patch for issue 7384 fixes the problem?
The patch is against py3k, but it comes down to this:
1) Build the readline module _only_ with -lreadline (instead of
-lreadline -lncursesw)
2) Build the curses and curses_panel modules
Stefan Krah added the comment:
Roumen Petrov wrote:
> Yes , I understand .
> For the protocol did gcc on FreeBSD warn if library order is -lncursesw
> -lreadline ?
No.
> P.S. Issue with readline library linked to termcap compatible library on
> system that distribut
Stefan Krah added the comment:
(1) Perhaps I missed the relevant part in the spec, so I had to check
what decNumber does: In the default context, clamp is 0, in the extended
contexts, it is 1. So Python's ExtendedContext should indeed set _clamp
to 1.
(2) I agree about the importance o
Stefan Krah added the comment:
I knew it was somewhere: In the test case description, clamp=0 is
specified as the default:
http://speleotrove.com/decimal/dtfile.html#syntax
--
___
Python tracker
<http://bugs.python.org/issue8
Stefan Krah added the comment:
Jeroen Ruigrok van der Werven wrote:
> Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this
> issue and he asked:
>
> "Basically, this is caused by
>
> a) our readline.so is linked against ncurses.so (via -ltermcap w
Stefan Krah added the comment:
I'd prefer to drop the ExtendedContext completely. Reasons are:
1) _clamp, prec, emin and emax aren't set to IEEE754 values.
2) The use of 'extended' is decNumber specific (see
http://speleotrove.com/decimal/dncont.html ). In IEEE754
Stefan Krah added the comment:
Mark,
I'm very short of time today, so I hope I don't miss anything that you
wrote.
The model of decNumber (and libmpdec) is to accumulate any status
(flags) that occurs in a function, regardless of whether a signal
is trapped or not.
Only at functio
Stefan Krah added the comment:
> Were you thinking of any deviations in particular?
More or less a commentary on what is listed here:
http://speleotrove.com/decimal/dascope.html
==> Restrictions
I only have a draft of IEEE754, but for instance I can't find a power
or rem
601 - 700 of 4949 matches
Mail list logo
