New submission from Stefan Krah :
In non-debug mode the read_null test fails with clang-3.0:
==
FAIL: test_disable (test.test_faulthandler.FaultHandlerTests
Stefan Krah added the comment:
STINNER Victor wrote:
> Can you try x = (int *)1; instead of x = NULL; ?
This works. - I must say that I find this new behavior of clang slightly
dangerous...
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
I've added some comments on Rietveld. This time, I pasted the email
addresses manually into the CC field, apparently without success
(I didn't receive mail).
Regarding the use of _testbuffer in the docs: I agree that it's strange,
on the other hand
Stefan Krah added the comment:
Yes, volatile works, too. That's probably the best solution.
--
___
Python tracker
<http://bugs.python.org/issue13874>
___
___
Stefan Krah added the comment:
Well, to be completely unambiguous. This works:
diff -r d2cf8a34ddf9 Modules/faulthandler.c
--- a/Modules/faulthandler.cThu Jan 26 00:15:07 2012 -0800
+++ b/Modules/faulthandler.cFri Jan 27 23:16:27 2012 +0100
@@ -943,7 +943,7 @@
static PyObject
Stefan Krah added the comment:
Jes??s Cea Avi??n wrote:
> That makes "x" and "y" volatile.
Well yes, but is that a problem?
--
___
Python tracker
<http://
Stefan Krah added the comment:
I've been busy fixing the memoryview.h issues first. Could you take a
look at:
http://hg.python.org/features/pep-3118/file/f020716704d4/Include/memoryobject.h
Changes:
a) Make all functions and the two buffer access macros part
of the limited API
Stefan Krah added the comment:
Nick Coghlan wrote:
> Radical suggestion: make it public as collections.simple_ndarray?
Heh, that's a nice one. :)
While I think that the code in _testbuffer.c is sound and very well tested,
the API is low-level and optimized for testing all sorts o
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > Nick Coghlan wrote:
> > > Radical suggestion: make it public as collections.simple_ndarray?
> >
> > Heh, that's a nice one. :)
>
> Well, the question is: does it have a point? Is this ndarr
Stefan Krah added the comment:
Antoine Pitrou wrote:
> >a) Make all functions and the two buffer access macros part
> > of the limited API again.
>
> Hmm, I don't think buffer access macros should be part of the limited
> API. If they are truely important
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > I thought the whole Py_buffer API was only temporarily removed from the
> > limited API until the issues were sorted out:
> >
> > http://bugs.python.org/issue10181#msg125462
>
> I'm talking about the
Stefan Krah added the comment:
Yes, it's really superseded by #10181 now. I'm closing as 'duplicate',
since technically it'll be fixed once the patch for #10181 is committed.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (an
Stefan Krah added the comment:
STINNER Victor wrote:
> Does my commit fix the issue?
Yes, perfectly.
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Congratulations: You (again) have found a fundamental error in TAOCP.
Example (Third Edition, page 233):
"The following definitions seem to be appropriate for base b, excess q,
floating point numbers ..."
--
no
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13837>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24381/a5c4a96dc981.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
I've uploaded a new patch that should address the remaining issues:
o In the documentation _testbuffer has been replaced by
m.cast() + the now multi-dimensional m.tolist().
o I restored the state of the limited API. If we want
to in
Stefan Krah added the comment:
Georg Brandl wrote:
> Wow, does that mean he can cash in a Knuth check?
Two already: One for the insight that "i-th" is the only true spelling,
and now this one.
--
___
Python tracker
<http:/
Stefan Krah added the comment:
I've upgraded the Fedora buildbot to Fedora-16. The specific glibc
workaround should not be necessary any more.
So the test will now fail again on all systems that a) have the bug
and b) the tr_Tr l
Stefan Krah added the comment:
Here's a terse shell script that IMO even moderately experienced admins
will prefer to the current version.
I'm not sure if the devguide is the right place for this, since
non-devs are very welcome to set up buildbots.
--
nosy: +pitrou
Added
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24399/buildslave_install.txt
___
Python tracker
<http://bugs.python.org/issue13124>
___
___
Python-bug
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file24398/buildslave_install.txt
___
Python tracker
<http://bugs.python.org/issue13124>
___
___
Python-bug
Stefan Krah added the comment:
Antoine Pitrou wrote:
> I'm sure some admins will prefer using their system's packages (I think
> buildbot is packaged for Debian/Ubuntu, I see it in Mageia's packages,
> not sure about Fedora).
Yes, certainly. I had a bad experience usi
Stefan Krah added the comment:
Eric Araujo wrote:
> docutils is the first package that???s found in my user site-packages;
> can you tell if your Crypto package is in that same location?
The package is here:
/usr/local/lib/python3.3/site-packages/Crypto/SelfTest/Protocol/test_AllOrNoth
Stefan Krah added the comment:
Eric Snow wrote:
> Incidentally, the second patch is a bit cleaner than the first.
Yes, indeed it is. :) To prevent a misunderstanding: In my last mail I was
talking about the "Build Slaves and Security" additions to:
http://wiki.python.org/
Stefan Krah added the comment:
I'm tagging this as a duplicate of #13843, since I expect more activity
on the newer issue.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> Python doesn't compile
Stefan Krah added the comment:
See also #6617 (which I marked as a duplicate).
--
nosy: +amaury.forgeotdarc, skrah, thoratsandip
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
I can run the tests on win64, but it I think it would be nice to
have a patch with exactly the same logic as the gcc-asm version
(Mark already mentioned _MCW_PC | _MCW_RC).
Another thing: _WIN32 might be defined on MinGW, but I'm not sure.
If that's th
Stefan Krah added the comment:
Closing, since it's fixed in #10181.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -&
Stefan Krah added the comment:
Fixed in #10181.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> Problems with Py_buffer m
Stefan Krah added the comment:
I ran the demo in the pep-3118 repo, and it is fixed (see #10181):
$ ./bufrel
Accessing buffer directly...
Accessing buffer through a memory view...
Done.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (and
elsewhere
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10211>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Eli Bendersky, 10.02.2012 15:52:
> * The current contents of xml/etree/ElementTree.py will move to
> xml/etree/pyElementTree.py
IIRC, there is a well specified way how accelerator modules should be used
by Python modules. I recall a lengthy discuss
Stefan Behnel added the comment:
Eli Bendersky, 10.02.2012 16:43:
>>> I don't see a compelling enough reason to break imports in existing code by
>>> removing the cElementTree module, so we should not do that.
>
> Agreed. Perhaps it should just be deprecated?
Giv
Stefan Krah added the comment:
Kristján, I ran the benchmarks from http://bugs.python.org/issue10227#msg143731
in the current cpython and pep-3118 repos. In both cases the differences between
Linux and Windows are far less pronounced than they used to be. All benchmarks
were run with the x64
Stefan Behnel added the comment:
Eli Bendersky, 11.02.2012 09:08:
> The more I think about it, the more the bootstrap code in _elementtree.c
> annoys me. It's the only instance of calling PyRun_String in Modules/ !
>
> It's hackish and causes ugly import problems. If t
Stefan Krah added the comment:
Great. I removed the dependency since it's fixed in both cpython
and pep-3118.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
stage: -> committed/rejected
status: open -
Stefan Krah added the comment:
I'm using ps_AF for testing:
$ ./localeconv_wchar ps_AF
size of wchar_t: 32 bits
decimal_point byte string: "\xd9\xab" (2 bytes)
decimal_point wide string: L"\u066b" (1 characters)
thousands_sep byte string: "\xd9\xac" (2
Stefan Behnel added the comment:
Both lxml and ElementTree have tutorials:
http://effbot.org/zone/element.htm
http://lxml.de/tutorial.html
Here is another tutorial that may server as a source for an intro:
http://infohost.nmt.edu/tcc/help/pubs/pylxml/web/index.html
And the general ET
Stefan Behnel added the comment:
Oh, and here are the ReST sources of the lxml docs:
https://github.com/lxml/lxml/tree/master/doc/
Specifically the tutorial:
https://raw.github.com/lxml/lxml/master/doc/tutorial.txt
and the parsing part:
https://raw.github.com/lxml/lxml/master/doc
Stefan Krah added the comment:
Yes, the leak does not seem to be in posix_read() itself. Sadly
enough, the number of leaks in test_multiprocessing has grown to
five in e9d01c5c92ed (the four additional ones were definitely not
present when I reported this).
==3047== 32 bytes in 1 blocks are
Stefan Krah added the comment:
Stefan Krah wrote:
> enough, the number of leaks in test_multiprocessing has grown to
> five in e9d01c5c92ed (the four additional ones were definitely not
To be sure, e9d01c5c92ed is completely innocent. I just tested
with that re
Stefan Krah added the comment:
STINNER Victor wrote:
> decimal.Decimal.__truediv__() has an optional context argument, whereas
> _decimal defines PyNumberMethods.
Regarding the special methods: decimal.py uses the optional context arguments
for convenience so that these methods can
Stefan Krah added the comment:
I walked into the Roundup trap again:
>>> Decimal(9).quantize(1, "?!?!?")
Decimal('9')
--
___
Python tracker
<
Stefan Krah added the comment:
Yes, that's basically what I did, but using the latest revision I cannot
reproduce the parsetok leak either.
The atexit leak is an old friend (#11826), so I think we can close
this one for now.
--
resolution: -> out of date
stage: nee
Stefan Krah added the comment:
Charles-Fran??ois Natali wrote:
> However, I have a stupid question: are those logs for the main
> process, or for child processes ?
Valgrind was run with --trace-children=no. However, the option is a bit
tricky, since it only affects tracing of sub-pro
Stefan Krah added the comment:
It just happened again on the new FreeBSD-9.0 bot:
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1845/steps/test/logs/stdio
==
FAIL: test_package___file__
New submission from Stefan Krah :
I tried to reproduce the failure from #14080 using this:
./python -m test -uall -v -F test_imp
After around 500 iterations the test fails:
==
ERROR: test_find_module_encoding
Changes by Stefan Krah :
--
type: behavior -> resource usage
___
Python tracker
<http://bugs.python.org/issue14084>
___
___
Python-bugs-list mailing list
Un
New submission from Stefan Krah :
The FreeBSD-9.0 bot shows a couple of warnings because some comparisons
in PyUnicode_WRITE are always true:
Objects/unicodeobject.c:2598: warning: comparison is always true due to limited
range of data type
Objects/unicodeobject.c:2598: warning: comparison is
Stefan Krah added the comment:
Your suggestion eliminates many warnings, but not all. FreeBSD
is still stuck with gcc-4.2, so perhaps this is a good compromise.
Getting rid of the remaining warnings might require a more bloated
solution.
These are the remaining warnings:
Objects
Stefan Krah added the comment:
It looks like in the FreeBSD (patched?) gcc version -Wtype-limits is part
of -Wall. I can reproduce the same warnings on Ubuntu with:
./configure --with-pydebug CFLAGS=-Wtype-limits
So I'm not so sure anymore if this is worth a patch at all. I could
Stefan Krah added the comment:
OK, on FreeBSD the failure occurs reliably when test_sqlite and
test_imp are chained, perhaps because of the import failure
of sqlite3:
[stefan@freebsd-amd64 ~/hg/cpython]$ ./python -m test -uall test_sqlite test_imp
[1/2] test_sqlite
test_sqlite skipped -- No
Stefan Krah added the comment:
No, this is sys.path after sys.path.insert(0, os.curdir):
['.', '', '/usr/local/lib/python33.zip', '/usr/home/stefan/hg/cpython/Lib',
'/usr/home/stefan/hg/cpython/Lib/plat-freebsd9',
'/usr/home/stefan/hg/
Stefan Krah added the comment:
Here's a minimal test case for now. It only fails if called as -m test:
$ ./python Lib/test/test_dot.py # OK
$ ./python Lib/test/regrtest.py test_dot # OK
[1/1] test_dot
Warning -- sys.path was modified by test_dot
$ ./python -m test test_dot
Stefan Krah added the comment:
Antoine, what is your gcc version? The test case I posted fails
with Debian/gcc-4.3.2 and Ubuntu/gcc-4.4.3. The two affected
buildbots have gcc-4.2.x.
But the test case passes on Fedora/gcc-4.6.
--
___
Python tracker
New submission from Stefan Behnel :
Following up on recent mailing list threads on pypy-dev and python-dev, this is
a request for adding a public C-API to read and write the sys.exc_info()
fields, currently stored in tstate->exc_*.
While not of major interest for CPython itself, this C-
Stefan Behnel added the comment:
I wonder if these functions should have an error return value, i.e. return -1
on failure. They'd "never" fail in CPython, but other implementations may want
to report failures, in case their internal implementation is more involved.
OTOH, d
Stefan Behnel added the comment:
Writing up a test case, I noticed that it makes sense to let PyErr_SetExcInfo()
steal the references. This matches the main use case of saving and restoring
the fields. For the getter, it's still best to return new references in order
to support the use
Changes by Stefan Behnel :
--
keywords: +patch
Added file: http://bugs.python.org/file24613/exc_info_capi.patch
___
Python tracker
<http://bugs.python.org/issue14
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24615/40917e4b51aa.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Over the last two months I've done a full review of all files except
_decimal.c and mpdecimal.c.
I now have additional ACL2 proofs for a couple of functions in basearith.c
(some are partial proofs), a full proof for the special case (d = 10**19)
of Gra
Stefan Krah added the comment:
The ps_AF locale fails with an assert after the latest commit:
Python 3.3.0a0 (default:f89e2f4cda88+, Feb 24 2012, 01:14:50)
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more in
Stefan Krah added the comment:
STINNER Victor wrote:
> Your comment is incorrect, it was already failing before my commit ;-)
> Example at changeset 548a023c8230:
Ah, sorry about that. I was lazy and tested against 585d3664da89 (which is a
couple of weeks old).
That version didn'
Stefan Krah added the comment:
The current interpretation in the PEP-3118 repo is that a request
without PyBUF_FORMAT means "implicit cast to unsigned bytes".
This makes the behavior of PyObject_AsWriteBuffer() correct, so I'm
closing this.
--
resolution: -> in
Stefan Krah added the comment:
Thanks, Nick. I'll try to get it done this weekend.
I've uploaded Misc/NEWS and Doc/whatsnew/3.3.rst (my apologies to Antoine
for plagiarizing the first sentence, I found it hard to come up with a
better version).
I wasn't sure whether to pu
New submission from Stefan Krah :
These two tests fail on Windows 7:
==
FAIL: test_copymode_follow_symlinks (test.test_shutil.TestShutil
Changes by Stefan Krah :
--
nosy: +eric.araujo, tarek
___
Python tracker
<http://bugs.python.org/issue14108>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
This failure occurs on the Windows 7 buildbot:
[302/364] test_lib2to3
---
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\lib2to3\tests\test_main.py
2012-02-13 21:57:29.273004000 -0500
+++ @ 2012-02-24 11:59:54.408966500 -0500
@@ -42,7
Stefan Krah added the comment:
Oops, this is just undesirable output. Is there any chance to fix
this?
--
title: test_lib2to3: failure on Windows 7 -> test_lib2to3: output that looks
like a failure on Windows 7
___
Python tracker
&l
New submission from Stefan Krah :
On FreeBSD, if the user is a member of the group 'wheel', these
tests fail:
==
FAIL: test_setegid (test.test_os.PosixU
New submission from Stefan Behnel :
In the context of better interfacing of PyPy with Cython, it appears that
simple looking things like PyTuple_GET_ITEM() are often rather involved in
PyPy's C-API implementation. However, since functions/macros like these are
used very frequently, thi
Stefan Krah added the comment:
I've trouble debugging this: Is the new version of importlib already
being used? I'm stepping through the offending pep3147 import, which
should correspond to this line in test_dot.py:
m = __import__('pep3147')
Until here Pyt
Stefan Krah added the comment:
OK, I stepped in parallel through the non-failing and the failing
versions. The first divergence is when _path_mtime is compared.
The comparison in the good version returns 'False', the one in the
bad version returns 'True':
Good version (Fe
Stefan Krah added the comment:
So I think the good version proceeds to refresh the _path_cache:
<_FileFinder(_relaxed_path_cache={'pep3147'}, packages=[('.py', ), ('.pyc', )], _path_mtime=, modules=[('.cpython-33m.so', ),
('.abi3.s
Stefan Krah added the comment:
And indeed, with this patch ...
diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -777,6 +777,8 @@
mtime = _os.stat(self.path).st_mtime
except
Stefan Krah added the comment:
Antoine Pitrou wrote:
> This might be what triggers the issue, but it's not the cause. Even with
> a bad mtime, the __file__ should still be the right one, so there must
> be something else.
It definitely triggers the issue because the problem
Stefan Krah added the comment:
What happens is that if self._fill_cache() is called, cache_module='pep3147'
and cache={'pep3147'}. Then 'cache_module in cache' is true and the function
returns:
loader('pep3147', './pep3147/__init__.py')
New submission from Stefan Krah :
The following tests fail on Windows in refleak mode. I used
24ca28cc9c9c as a reference point. Build is x64. Summary:
test_concurrent_futures, test_datetime, test_multiprocessing, test_strftime and
test_time are leaking.
C:\Users\stefan\hg\master\PCbuild
Stefan Behnel added the comment:
Note that Element is also a factory function in lxml.etree, and people have
been living with this quite happily. I don't see a reason to change either
side. There is a dedicated function iselement(obj) for exactly the purpose
of testing if something
Stefan Krah added the comment:
Nick Coghlan wrote:
> PEP section makes sense - I plan to mark PEP 3118 as Final once you commit
> this (or you can do that yourself, for that matter).
Array features are complete except for multi-dimensional indexing and slicing.
I think it would be nice
Stefan Krah added the comment:
I think this issue is now superseded by #10181 and #3132.
--
nosy: +skrah
resolution: -> duplicate
stage: test needed -> committed/rejected
status: open -> pending
superseder: -> Problems with Py_buffer management in memoryobject.c (an
Changes by Stefan Krah :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue2394>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Behnel added the comment:
For the record, the relevant mailing list discussion can be found here:
http://thread.gmane.org/gmane.comp.python.devel/129429/focus=129794
--
___
Python tracker
<http://bugs.python.org/issue14
Changes by Stefan Krah :
--
assignee: skrah
nosy: ncoghlan, pitrou, pv, skrah, teoliphant
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview: add multi-dimensional indexing and slicing
type: enhancement
___
Python
New submission from Stefan Krah :
The PEP-3118 authors originally planned to have support for multi-dimensional
indexing and slicing in memoryview.
Since memoryview now already has the capabilities of multi-dimensional
list representations and comparisons, this would be a nice addition
to the
Changes by Stefan Krah :
--
components: +Interpreter Core
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue14130>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Strange, I can't reproduce this on Windows 7 with exactly the same
command line:
python_d -Wd -E -bb ../lib/test/regrtest.py -uall -rwW -n -r --randseed=8022149
--
nosy: +skrah
___
Python tracker
Changes by Stefan Krah :
--
nosy: +db3l
___
Python tracker
<http://bugs.python.org/issue14131>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
> So the test needs to be fixed to call importlib.invalidate_caches()
> after creating the module.
That works. With issue14080.diff I can run the failing combination
without problems:
$ ./python -m test test_sqlite test_imp
[1/2] test_sqlite
test_sqlite s
Stefan Krah added the comment:
It looks like test_locale from test_format.py changes the locale on Windows:
>>> import time
>>> >>> magic_date = (1999,
Stefan Krah added the comment:
Attached a fix that is tested on Windows.
--
keywords: +patch
Added file: http://bugs.python.org/file24649/issue14113.diff
___
Python tracker
<http://bugs.python.org/issue14
Stefan Krah added the comment:
> ... it seems that getlocale() doesn't accept LC_ALL as its argument:
The current situation is not ideal. getlocale() is documented to fail
("category may be one of the LC_* values except LC_ALL"), but it only
fails if there's a semicolon
Stefan Krah added the comment:
I think there's another problem on Windows even after the fix:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4463
==
FAIL: test_package___f
New submission from Stefan Krah :
Seen on a Windows buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4223/steps/test/logs/stdio
Fatal Python error: Segmentation fault
Current thread 0x07e4:
File "D:\Buildslave\3.x.moore-windows\build\lib\ssl.py&q
Stefan Krah added the comment:
Nice! This also fixes the leak in test_concurrent_futures. The
time-related test failures probably also have a single source.
I ran the whole test suite on x64 with no (new) failures.
--
___
Python tracker
<h
Stefan Krah added the comment:
sbt, thanks again! I chose a different approach because on non-Windows
the unused 'error' label produced compiler warnings.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Test suite is OK also on 3.2. Closing.
--
components: +Tests
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah :
This came up in #14113. getlocale(LC_ALL) is documented to fail, at
least that's how I read this:
"category may be one of the LC_* values except LC_ALL."
But in fact getlocale(LC_ALL) works if there is no semicolon in the
locale name:
>&
Stefan Krah added the comment:
I've created #14142 for the getlocale(LC_ALL) situation. The main issue
is fixed, Nadeem's changes result in better error messages, so I think we
can close this.
Perhaps the assertEqual changes should be backported to 3.2 and 2.7
to keep the fil
1301 - 1400 of 4949 matches
Mail list logo
