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 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 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 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
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
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 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
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
New submission from Stefan Krah :
The arraymodule depends on "structmember.h". Patch attached.
--
components: Build
files: arraymodule_deps.diff
keywords: patch
messages: 154556
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: a
Stefan Krah added the comment:
There is a comment in setup.py that suggests that *all* Python headers
should be added to the dependencies (?):
# Python header files
headers = [sysconfig.get_config_h_filename()]
headers += glob(os.path.join(sysconfig.get_path('platinclude&#x
Stefan Krah added the comment:
In Python2.6 all headers from Include/ were added:
# Python header files
headers = glob("Include/*.h") + ["pyconfig.h"]
--
___
Python tracker
<http://bug
Stefan Krah added the comment:
Dependency support added: 1be93dd179df
Last good version (all Include/*.h): 9705ef3fdb22
Current behavior (only pyconfig.h): fa69e891edf4
To answer your question: Neither of the last two revisions builds
in an out-of-source directory.
Raising the priority to
Stefan Krah added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file24676/issue14152.diff
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file24673/arraymodule_deps.diff
___
Python tracker
<http://bugs.python.org/issue14152>
___
___
Python-bug
Changes by Stefan Krah :
--
stage: -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue14152>
___
_
Stefan Krah added the comment:
I'm busy adding the C-API changes to the docs. Regarding the stable ABI:
The general mood was to *keep* the removal of the buffer interface
for some time, did I get that right?
In that case this removal (especially of the Py_buffer struct) should
be docum
Stefan Krah added the comment:
??ric Araujo wrote:
> > To answer your question: Neither of the last two revisions builds
> > in an out-of-source directory.
> My question was more whether the last known good revision did :)
That's what I meant. "last two revisions"
Stefan Krah added the comment:
> From the PEP: "The buffer interface (type Py_buffer, type slots bf_getbuffer
> and bf_releasebuffer, etc) has been omitted from the ABI, since the stability
> of the Py_buffer structure is not clear at this time. Inclusion in the ABI
> can
Stefan Krah added the comment:
I'm trying to understand what you want to be able to write. Do you
perhaps have a short example? Also, to get the bigger picture: Is
this related to your strview proposal?
http://mail.python.org/pipermail/python-ideas/2011-December/012993
Stefan Krah added the comment:
Since this issue targeted 2.7 and 3.2:
In a brief discussion on python-dev it was decided that the 3.3 fixes
from #10181 won't be backported for a number of reasons, see:
http://mail.python.org/pipermail/python-dev/2012-February/116872
Stefan Krah added the comment:
Since this issue targeted 2.7 and 3.2:
In a brief discussion on python-dev it was decided that the 3.3 fixes
from #10181 won't be backported for a number of reasons, see:
http://mail.python.org/pipermail/python-dev/2012-February/116872
New submission from Stefan Krah :
Supporting chained objects that redirect getbuffer requests to a single
exporter rather than re-exporting the buffer is a matter of removing an
assert, but it needs tests and documentation updates.
--
assignee: skrah
messages: 154826
nosy: ncoghlan
Stefan Krah added the comment:
> # generated on buildbot.rubenkerkhof.com, which had, according to Ruben
> # Fedora's package "openssl-1.0.1-0.1.beta2.fc17.x86_64"
I think openssl needs to be compiled with -DPURIFY to avoid this.
--
Stefan Krah added the comment:
I didn't ask for review since in the production code only the assert()
line is removed. There are a couple of new tests and I have a private
version of test_buffer that runs most tests with an ndarray chain
using either redirection or re-exporting. As exp
New submission from Stefan Krah :
Nick's comment from #10181:
"It occurs to me that one thing that *could* be backported to early versions
are some of the documentation improvements on how to correctly handle the
lifecycle of fields in Py_buffer. That gets messy though because
Stefan Krah added the comment:
I'm abusing the issue to settle all concerns that came up on python-dev:
The tests added in the latest commit show that it's indeed no
problem if an atypical static exporter sets view.obj to NULL.
--
New submission from Stefan Krah :
bytearray_getbuffer() checks for view==NULL. But this has never been
allowed:
PEP: "The second argument is the address to a bufferinfo structure.
Both arguments must never be NULL."
DOCS (3.2): "view must point to an existing Py_b
Stefan Krah added the comment:
array_buffer_getbuf does a similar thing:
if (view==NULL) goto finish;
finish:
self->ob_exports++; // ???
return 0
Where does this view==NULL thing come from?
--
___
Python tracker
&l
Changes by Stefan Krah :
--
dependencies: +bytearray_getbuffer: unnecessary code
___
Python tracker
<http://bugs.python.org/issue13860>
___
___
Python-bugs-list m
Stefan Krah added the comment:
I seems to be a feature to get a "lock" on an exporter
without the exporter filling in a buffer. It was there
from the beginning:
http://svn.python.org/view/python/branches/release30-maint/Objects/bytearrayobject.c?r1=56849&r2=57181
Last use tha
Stefan Krah added the comment:
> Then I'm abusing this ticket to say: thanks for verifying this.
I would still like to sweep this fact under the rug. :)
Could you have a look at the documentation patch and see if it's clearer?
--
keywords: +patch
Added file: http://bu
Stefan Krah added the comment:
OK, for me the view->obj issues are done. The new tests indicate
that we can silently keep backwards compatibility for view->obj==NULL,
but I suppressed that fact in the documentation because it's already
complicated enough.
Perhaps we might want to de
Changes by Stefan Krah :
--
dependencies: -bytearray_getbuffer: unnecessary code
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> adapt sphinx-quickstart for windows
___
Python tr
Changes by Stefan Krah :
--
superseder: adapt sphinx-quickstart for windows -> bytearray_getbuffer:
unnecessary code
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Jim, thanks for taking a look at this.
Jim Jewett wrote:
> (1) I think this module would benefit greatly from a map explaining
> what each file does, and perhaps from some reorganization.
Just MAP.txt in the top level directory? Amaury suggested
Stefan Krah added the comment:
STINNER Victor wrote:
> How can I help to integrate this module into CPython?
It would be fantastic if you could take a look at _decimal.c, for example
to find some incompatibilities between _decimal.c and decimal.py.
mpdecimal.c could also always profit f
Stefan Krah added the comment:
Jim Jewett wrote:
> Whether you need *additional* subdirectories within _cdecimal to
> subcategorize the .c and .h files, I'm not sure -- because I didn't
> get in deep enough to know what they should be. If the categorization
> let pe
Stefan Krah added the comment:
Benjamin Peterson wrote:
> The scripts for generating code would preferably go in a Tools/decimal
> directory.
Hmm, do you mean the gen*.py scripts? The output is generated by decimal.py
and used for testing libmpdec. While the syntax resembles that
Stefan Krah added the comment:
Benjamin Peterson wrote:
> Speaking of inline, the "inline" keyword will have to go because it's not C89.
Do you happen to know a free compiler that builds Python but does not
understand "inline"? I'm asking because without tes
Stefan Krah added the comment:
Case Van Horsen wrote:
> cdecimal 2.3 does not support the __ceil__ and __floor__
Thanks. I'll look into that.
> cdecimal.Decimal instances do not emulate the various single-underscore
> methods of a decimal.Decimal instance. In gmpy2, I use _in
Stefan Krah added the comment:
Antoine Pitrou wrote:
> You could use Py_LOCAL_INLINE, but most compilers should inline small
> functions automatically, AFAIK.
At the time I wrote it I benchmarked everything. I'm pretty sure
that gcc did not inline larger functions like mpd_qresize
Stefan Krah added the comment:
Jim Jewett wrote:
> implementation details. Are there are clear distinctions (type
> info/python bindings/basic arithmetic/advanced
> algorithms/internal-use-only/???)
I failed to mention that libmpdec also has complete documentation. Perhaps
that c
901 - 1000 of 3396 matches
Mail list logo
