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
Stefan Krah added the comment:
I think this is a duplicate of issue 7546.
--
nosy: +skrah
type: behavior -> feature request
___
Python tracker
<http://bugs.python.org/iss
Stefan Krah added the comment:
I agree that the spec is not unambiguous, but consider the Overflow and
Underflow passages here:
http://speleotrove.com/decimal/daexcep.html
==> Overflow
==> In all cases, Inexact and Rounded will also be raised.
"Raise" here of course m
Stefan Krah added the comment:
Just to save you some time investigating, it broke the build because
of missing parentheses in setup.py:
if sys.platform == 'darwin' and dir.startswith('/System') or
dir.startswith('/usr')
--
nosy: +skrah
Changes by Stefan Krah :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue1481>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue6419>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
Victor, I think one more skip is required in test_socketserver.
--
nosy: +skrah
resolution: fixed ->
status: closed -> open
Added file:
http://bugs.python.org/file17317/nothreads-socketserver-shutdown
Stefan Krah added the comment:
The same patch was applied to the Python port by OpenBSD developer Damien
Miller:
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_kqueue_py
Mark, would it be ok in this situation to apply the patch even though
personally
Stefan Krah added the comment:
Luckily, the OpenBSD failures are caused by issues in libpthread. This
means that some skips could be added (as for FreeBSD), but I'll open
a separate issue for that.
Thanks for the comments on the patch. I add two new patches that
incorporate the s
Changes by Stefan Krah :
Added file: http://bugs.python.org/file17335/issue8424-trunk-skiptest.patch
___
Python tracker
<http://bugs.python.org/issue8424>
___
___
Pytho
New submission from Stefan Krah :
When the system python does not have the Lib/test directory, the
compat tests are failing.
==
ERROR: test_attribute_name_interning (test.test_xpickle.CPicklePython26Compat
Stefan Krah added the comment:
The EINTR issue should be fixed in trunk (issue1628205). Have you by
any chance run the test suite on trunk in the meantime?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue3
Stefan Krah added the comment:
The compat tests check that pickling in the newly compiled Python
version is compatible with pickling in installed Python versions.
The installed versions may or may not have a test directory. For
example, the 2.6 port in OpenBSD does not have the test directory
New submission from Stefan Krah :
[Added OpenBSD Python port maintainers to the nosy list.]
I've identified a number of tests that all pass when Python is compiled
without threads, but fail otherwise. The failures are probably caused
by libpthread issues in OpenBSD, as described in this
Stefan Krah added the comment:
With _pydecimal the memory also grows very slowly (I didn't have the patience
to wait for MemoryError).
I'm pretty sure decNumber also does the same, it's just easier to implement
and does not slow down division for small numbers.
libmpde
Stefan Krah added the comment:
MAX_PREC is chosen so that 5*MAX_PREC does not overflow 32-bit or 64-bit signed
integers. This eliminates many overflow checks for the exponent.
Updating the exponent is (perhaps surprisingly) quite performance sensitive,
that's why the 32-bit build doe
Stefan Krah added the comment:
The feature would be nice to have; however, if you choose the precision to
match the amount of available RAM things work (I have 8GB here, one word in the
coefficient has 19 digits for the 4 bit version):
>>> from decimal import *
>>&
Stefan Krah added the comment:
> This isn't purely academic. The `decimal` docs, at the end:
Yes, that is a good point. I think for libmpdec I'll just do a trial divmod if
prec > BIGNUM_THRESHOLD.
> Perhaps the only thing to be done is to add words to t
New submission from Stefan Krah :
As mentioned in the PR, I don't see sufficient evidence that backticks are
legacy. So I'll close this.
--
assignee: -> skrah
nosy: +skrah
resolution: -> rejected
stage: patch review -> resolved
sta
Stefan Krah added the comment:
The change looks reasonable, but unfortunately this is a long-standing
behavior that originates from before the Python-3.3 memoryview rewrite.
It is also present in 2.7 (the previous implementation) and documented
in 3.3:
https://docs.python.org/3/library
Change by Stefan Krah :
--
nosy: skrah
priority: normal
severity: normal
status: open
title: Azure Pipelines PR broken
___
Python tracker
<https://bugs.python.org/issue39
New submission from Stefan Krah :
There is no status report, no details link and manually committing is
prohibited:
https://github.com/python/cpython/pull/18569
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
Closing and reopening the PR helped.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
Re-opening this issue, Azure fails too often:
https://github.com/python/cpython/pull/18577
https://dev.azure.com/Python/cpython/_build/results?buildId=58220&view=logs&j=c83831cd-3752-5cc7-2f01-8276
Change by Stefan Krah :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue39701>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +17951
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18581
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Fortunately libmpdec raises MemoryError almost instantaneously, so the PR
retries
the affected operations with estimated upper bounds for exact results without
slowing down the common case.
The docs still need updating because people will still wonder why 1
Stefan Krah added the comment:
BTW, this PR implements the invariant:
"If there exists an exact result at a lower precision, this
result should also be returned at MAX_PREC (without MemoryError)".
So non-integer powers are left out, since _decimal has no notion
of exact non-inte
New submission from Stefan Krah :
The automated code coverage on GitHub is quite inaccurate and needlessly flags
PRs as red.
I'd prefer to make this opt-in.
--
messages: 362367
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable code cov
Stefan Krah added the comment:
New changeset 90930e65455f60216f09d175586139242dbba260 by Stefan Krah in branch
'master':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
https://github.com/python/cpython/commit/90930e65455f60216f09d175586139
Stefan Krah added the comment:
New changeset c6f95543b4832c3f0170179da39bcf99b40a7aa8 by Miss Islington (bot)
in branch '3.7':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
(#18585)
https://github.com/python/cpyt
Stefan Krah added the comment:
New changeset b6271025c640c228505dc9f194362a0c2ab81c61 by Miss Islington (bot)
in branch '3.8':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
(#18584)
https://github.com/python/cpyt
Stefan Krah added the comment:
I'd definitely disable the automatic comment and prefer that the build
happens on buildbot.python.org rather than affecting the GitHub build
status.
--
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
Vedran, msg362365 is meant to say:
"This PR implements $SOMEWHAT_MATHEMATICAL_SPEC except for inexact power."
Had I put the caveat inside the statement as well, the message would have been:
"Thi
Stefan Krah added the comment:
"So non-integer powers are left out" in isolation would indeed be
wrong, but actual sentence is unambiguously qualified with:
"... since _decimal has no notion of exact non-integer powers yet.",
which clearly states that exact non-inte
Change by Stefan Krah :
--
pull_requests: +17961
pull_request: https://github.com/python/cpython/pull/18594
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
Updated docs:
https://github.com/python/cpython/pull/18594
The PR uses some of Tim's suggestions while also explaining how to
calculate the amount of memory used in a single large decimal.
Hopefully it isn't too much i
Stefan Krah added the comment:
They are allowed failures but the build is still marked in red:
https://github.com/python/cpython/pull/18567
So if you look at the front page you have to click through red results
only to find that the reason is code coverage
Stefan Krah added the comment:
New changeset a025d4ca99fb4c652465368e0b4eb03cf4b316b9 by Stefan Krah in branch
'master':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic (#18594)
https://github.com/python/cpython/commit/a025d4ca99fb4c652465368e0b4eb0
Stefan Krah added the comment:
New changeset 00e45877e33d32bb61aa13a2033e3bba370bda4d by Miss Islington (bot)
in branch '3.7':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic
(GH-18594) (#18596)
https://github.com/python/cpyt
Stefan Krah added the comment:
New changeset d6965ff026f35498e554bc964ef2be8f4d80eb7f by Miss Islington (bot)
in branch '3.8':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic
(GH-18594) (#18597)
https://github.com/python/cpyt
Stefan Krah added the comment:
libmpdec and the docs are done, the question remains what to do with
decimal.py.
It has the same behavior, but I don't think users are running
decimal.py with very large precisions.
Anyway, unassigning myself in case anyone else wants to work on a
Change by Stefan Krah :
--
stage: patch review -> resolved
___
Python tracker
<https://bugs.python.org/issue39576>
___
___
Python-bugs-list mailing list
Un
Change by Stefan Krah :
--
pull_requests: +17981
pull_request: https://github.com/python/cpython/pull/18616
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset b76518d43fb82ed9e5d27025d18c90a23d525c90 by Stefan Krah in branch
'master':
bpo-39576: Clarify the word size for the 32-bit build. (#18616)
https://github.com/python/cpython/commit/b76518d43fb82ed9e5d27025d18c90
Stefan Krah added the comment:
New changeset 24c570bbb82a7cb70576c253a73390accfa7ed78 by Miss Islington (bot)
in branch '3.7':
bpo-39576: Clarify the word size for the 32-bit build. (GH-18616) (#18617)
https://github.com/python/cpython/commit/24c570bbb82a7cb70576c253a73390
Stefan Krah added the comment:
New changeset c6ecd9c14081a787959e13df33e250102a658154 by Miss Islington (bot)
in branch '3.8':
bpo-39576: Clarify the word size for the 32-bit build. (GH-18616) (#18618)
https://github.com/python/cpython/commit/c6ecd9c14081a787959e13df33e250
Stefan Krah added the comment:
For me even a mail with a single line would be too much. I can filter that in
my mail client but not on GitHub.
Speaking about that, I also don't want to get mail from Bevedere stating that
I, in fact, have signed a CLA any time I open
Stefan Krah added the comment:
Before I look at the example code: Can you also reproduce this with
Python 3.6? The threading code in _decimal was changed to a ContextVar
in 3.7.
There's a high chance though that the problem is in the c++ module.
--
nosy: +
Stefan Krah added the comment:
I've briefly looked at the zip archive. Without going much into
the C++ module as a whole, this should not be done:
gil_unlocker.UnlockGILAndSleep()
self.val = decimal.Decimal(1) / decimal.Decimal(7)
gil_unlocker.UnlockGILAndSleep()
If you w
Change by Stefan Krah :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39776>
___
___
Stefan Krah added the comment:
I built your example with 3.6:
git clone https://github.com/pybind/pybind11
wget https://bugs.python.org/file48923/decimal_crash.zip
unzip decimal_crash.zip
git checkout v3.6.7
./configure --with-pydebug
make
g++ -std=c++11 -pthread -Wno-unused-result -Wsign
Stefan Krah added the comment:
This is 3.6.7, compiled --with-pydebug:
$ ./main
Aborted (core dumped)
(gdb) bt
#0 0x7f9974077428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x7f997407902a in __GI_abort () at abort.c:89
#2 0x0056e2d1 in
501 - 600 of 3396 matches
Mail list logo
