Antoine Pitrou added the comment:
Thank you! I've committed the patch in r86493.
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.2
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file19627/default_verify_paths.patch
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Pushed in 2c5c6d3f399b, thanks.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Woops, sorry, wrong issue.
--
resolution: fixed ->
stage: committed/rejected -> patch review
status: closed -> open
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Pushed in 2c5c6d3f399b, thanks.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Pushed in 92088733aade and 8dd7a860a2fa, thanks.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Uh, after translation I get a SystemError when trying to run the Mako bench
under the current py3k SVN:
$ PYTHONPATH=lib/mako/ /home/antoine/py3k/py3k/python ./performance/bm_mako.py
-n 25
Traceback (most recent call last):
File "./performance/bm_ma
Antoine Pitrou added the comment:
> This is on Snow Leopard 64 bit, 02b70cb59701 (r88451) -> Python 3.3a0.
> Is there a switch i must trigger? Just pulled 24 changesets,
> recompiling and trying again with r88460.
Have you tried "./python -m test -
Antoine Pitrou added the comment:
Can you try to identify which revision introduced the issue?
--
nosy: +haypo, ned.deily, pitrou
priority: normal -> critical
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Just stepping ... with c8d1f99f25eb/r88476:
Right, that's what we should investigate :)
Could try to diagnose the crash?
--
___
Python tracker
<http://bugs.python.org
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue11285>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Ok, so it boils down to:
>>> pickle.loads(b'\x80\x02}q\x00U\x00q\x01h\x01s.')
{'': ''}
>>> pickle.loads(b'\x80\x02}q\x00U\x00q\x01h\x01s.', encoding='latin1')
Traceback (most recent call last)
Antoine Pitrou added the comment:
This is because of the buffer pointer passed to the codecs machinery being NULL
when the empty string is being decoded.
Quick patch follows (needs a test). Also, it is not clear whether it is allowed
to store a NULL pointer in the "buf" member of a
Antoine Pitrou added the comment:
> .. even with a self-compiled 1.2.3, INT_MAX/1000 ... nothing.
> The problem is not crc32(), but the buffer itself:
>
>if (pbuf.len > 1024*5) {
> unsigned char *buf = pbuf.buf;
> Py_ssize_t len = pbuf.len;
>
Antoine Pitrou added the comment:
Out of curiosity, could you try the following patch?
Index: Lib/test/test_zlib.py
===
--- Lib/test/test_zlib.py (révision 88500)
+++ Lib/test/test_zlib.py (copie de travail)
@@ -70,7
Antoine Pitrou added the comment:
Here is a patch with tests.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20842/null_ptr_buffer.patch
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Antoine, your msg129093 patch of test_zlib.py does it (with and
> without fprintf(3)s). CRC ok etc., it just works.
Indeed, and it also seems to work on the buildbot. I will commit the
patch soon. Thanks for your help!
> (Seems mmap(2) has a pro
Antoine Pitrou added the comment:
Committed in r88511 (3.3) and r88514 (3.2).
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Jesus, perhaps you can address Amaury's comments by uploading a new patch?
--
assignee: amaury.forgeotdarc ->
stage: commit review -> needs patch
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
This is nice, but IMO there is some information lacking, e.g.:
- when an underlying mapping is mutated, does the ChainMap get updated too?
- does it work with arbitrary mappings or only with dicts or dicts subclasses?
I think new_child() isn't very usefu
Antoine Pitrou added the comment:
("too specialized", sorry)
--
___
Python tracker
<http://bugs.python.org/issue11297>
___
___
Python-bugs-list mailing
Antoine Pitrou added the comment:
> > I am not sure PyUnicode_Decode() should treat NULL as an empty string.
>
> Definitely not. That would hide programming errors.
Well, this could break some third-party code.
--
title: Some "trivial" python 2.x pickles fails t
Antoine Pitrou added the comment:
> Antoine Pitrou wrote:
> >
> > Antoine Pitrou added the comment:
> >
> >>> I am not sure PyUnicode_Decode() should treat NULL as an empty string.
> >>
> >> Definitely not. That would hide programming error
Antoine Pitrou added the comment:
> PyUnicode_Decode() et al. are conversion functions and these
> require valid content to work on. Passing in a NULL pointer
> does not fit that specification and so allowing for this
> would hide programming errors.
"Valid content" doesn
Antoine Pitrou added the comment:
For the record:
> e.g. 'cd Lib/test; ../../python.exe -m test -v -uall test_iter' works
> just perfect.
You don't need to "cd". Just "./python -m test (etc.)".
See http://docs.python.org/de
Changes by Antoine Pitrou :
--
resolution: -> works for me
___
Python tracker
<http://bugs.python.org/issue11285>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
> > So, IMO, practicality beats purity here. Especially since it is bound to
> > land in a bugfix release (3.2.1), which users don't expect to produce
> > regressions in their own code.
>
> Nope. Your suggestion would be a
Antoine Pitrou added the comment:
> > Nope. Your suggestion would be a new feature and those are not
> > allowed in patch level releases.
>
> What new feature are you talking about? I think you misunderstood the
> actual issue: NULL as an empty string *worked* in 3.1
Antoine Pitrou added the comment:
This new failure is perhaps related:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/572/steps/test/logs/stdio
==
FAIL: test_module
Antoine Pitrou added the comment:
> Please go with Alexander's solution of fixing the higher level code
> rather than silently trying to introduce a new feature in
> PyUnicode_Decode() that hides programming errors.
I'm sorry, I'm perfectly fine with my own patch, so s
Antoine Pitrou added the comment:
Oops, I hadn't seen Alexander's patch. Sorry.
--
___
Python tracker
<http://bugs.python.org/issue11286>
___
___
Antoine Pitrou added the comment:
So, about Alexander's patch:
- it lacks a test
- it doesn't solve the issue with PyUnicode_Decode's confusing error message
when a NULL is passed ("ValueError: operation forbidden on released memoryview
object"); if we want to disall
Antoine Pitrou added the comment:
> It may be better to modify _Unpickler_Read() so that it returns
> self->input_buffer (or even self->input_buffer + self->next_read_idx)
> for zero n.
I agree this would be better for readability and maintainability.
> On the othe
Antoine Pitrou added the comment:
It would probably be ok to fallback on read() when read1() isn't implemented.
read1() is supposed to be implemented by all BufferedIO-compliant classes, but
in all honesty I don't think it's very useful in practice. It's supposed to be
an
Antoine Pitrou added the comment:
I've committed the part of the patch which disallows a NULL data pointer with
PyMemoryView_FromBuffer in r88550 and r88551.
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> > I've committed the part of the patch which disallows a NULL data pointer
> > with PyMemoryView_FromBuffer in r88550 and r88551.
>
> Is it possible to create such buffer in Python (other than by
> exploiting a bug or writing a ro
Antoine Pitrou added the comment:
> It seems appropriate to consult python-dev on this. I thought
> ValueError was for values that are valid Python objects but out of
> acceptable range of the function. Errors that can only be triggered
> in C code normally handled with either
Antoine Pitrou added the comment:
Thanks for the new patch. Looking again, I wonder if there's a reason the
original regexp was so complicated. ldconfig output here has lines such as:
libBrokenLocale.so.1 (libc6,x86-64, OS ABI: Linux 2.6.9) =>
/lib64/libBrokenLoc
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue11314>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I think your analysis is wrong. These mmap() calls are for anonymous memory,
most likely they are emitted by the libc's malloc() to get some memory from the
kernel. In other words they will be blazingly fast.
I would suggest you try to dig deeper
Antoine Pitrou added the comment:
Le vendredi 25 février 2011 à 13:58 +, Palm Kevin a écrit :
> Palm Kevin added the comment:
>
> Please find here a small C app embedding python that shows how to
> reproduce the problem (It turned out that the problem is caused by the
Changes by Antoine Pitrou :
--
nosy: +barry, tarek
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue11320>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
> But in the two scenarios I mentioned (monitoring and Web services such
> as CGI, neither of which is particularly rare), this is going to make
> quite a lot of difference
That's why I asked for absolute numbers for the overhead difference.
Antoine Pitrou added the comment:
Okay, thanks to Charles-François' measurements, we can deduce that each
subprocess launch is at most 0.3ms of user CPU time and 1.2ms of system CPU
time. IMO that's not a real problem.
--
___
Python trac
Antoine Pitrou added the comment:
Can you explain why this is a problem in Python?
Can't lib/python3.2/config-3.2m/Makefile simply be provided by virtualenv (by
copying it, I guess)?
--
nosy: +pitrou
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
Committed in r88607 (3.3).
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
This patch has tests and is also able to constant-fold tuples larger than 256
elements.
--
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Forgot to attach new patch, sorry.
--
Added file: http://bugs.python.org/file20897/constfold2.patch
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Committed in r88610 (3.3), r88611 (3.2) and r88612 (2.7).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I corrected the patches (they were breaking the property of inheriting daemon
by default) and committed them in r88618. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
Antoine Pitrou added the comment:
The patch needs updating for latest 3.x.
--
assignee: loewis ->
nosy: +giampaolo.rodola, pitrou
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> What's wrong with Marc's commit? He's using the standard names.
That's a pretty useless commit and it will make applying patches and backports
more tedious, for no obvious benefit.
Of course that concern will be removed if Marc-And
Antoine Pitrou added the comment:
Éric, the weak dicts are implemented in pure Python while built-in dicts are in
C. That can make quite a difference.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Committed in r88622 (3.3) and r88623 (3.2). The 2.7 implementation is too
different for the patch to apply, so if you want to fix it too, feel free to
upload a patch. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/re
Antoine Pitrou added the comment:
I have committed the patch in r88624. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
New submission from Antoine Pitrou :
$ make
gcc -pthread -g -O0 -Wall -Wstrict-prototypes-I. -IInclude -I./Include
-DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ‘posix_sendfile’:
./Modules/posixmodule.c:6025: attention
Antoine Pitrou added the comment:
Committed in r88625. Thank you!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
==
ERROR: test_set_get_priority (test.test_os.ProgramPriorityTests)
--
Traceback (most recent call last):
File
"
Antoine Pitrou added the comment:
Perhaps (probably?) related to the crash in
http://www.python.org/dev/buildbot/all/builders/PPC64%20Ubuntu%203.x/builds/655
./Modules/posixmodule.c:5909: warning: implicit declaration of function
‘sendfile’
--
priority: normal -> h
Antoine Pitrou added the comment:
Ok, one issue is that connect_ex() isn't implemented for SSL sockets, so it
defers to the normal implementation instead, which is wrong.
But your still is wrong too. connect_ex() returns an error, meaning the socket
isn't connected and you must r
Antoine Pitrou added the comment:
> The select call after the connect_ex waits until the connection is
> done, for the first write event is fired then, so the socket is
> connected afterwards.
You are right. Here is a patch for py3k implementing connect_ex() and solving
the issue
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file20900/ssl_connect.patch
___
Python tracker
<http://bugs.python.org/issue11326>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file20901/ssl_connect.patch
___
Python tracker
<http://bugs.python.org/issue11326>
___
___
Python-bug
Antoine Pitrou added the comment:
> For other spellings like "utf8" or "latin1", I wonder if it would be
> useful to emit a warning/suggestion to use the standard spelling.
No, it would be an useless annoyance.
--
___
Antoine Pitrou added the comment:
> If we ever decide to get rid of codec aliases in the core
"If".
--
___
Python tracker
<http://bugs.pytho
Antoine Pitrou added the comment:
Can you backport to 3.2?
--
___
Python tracker
<http://bugs.python.org/issue10228>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Fixed in r88626, and it *did* fix the buildbot crash!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Fixed in r88626, and it *did* fix the buildbot crash!
--
___
Python tracker
<http://bugs.python.org/issue11325>
___
___
Pytho
Antoine Pitrou added the comment:
Indeed.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10784>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
Removed message: http://bugs.python.org/msg129503
___
Python tracker
<http://bugs.python.org/issue11325>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11328>
___
___
Python-bugs-
Antoine Pitrou added the comment:
I'm not sure why you use PyTuple_Size() and PyTuple_GetItem().
You should be able to do a first call to PyArg_ParseTuple() (using the "S"
specifier to mandate a bytes object), and call PyErr_Clear() and fallback to
the second PyArg_ParseTuple
Antoine Pitrou added the comment:
Now backported as part of issue 941346.
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> AIX shared library fix
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
Not sure that silencing errors from quit() is the right thing. Is there any
reason?
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Ok, I think you're right.
I've committed the patch to 3.3 in r88639 after having added a minimal test. Is
there a full name I should credit?
Thank you for contributing!
--
assignee: theller ->
resolution: -> fixed
stage: patch rev
Antoine Pitrou added the comment:
Reopening and reverted the commit in r88640. The patch changes behaviour by
turning the previous unrooted filename ('libc.so.6') into a full path
('/lib64/libc.so.6'). This breaks builds where multiple versions of a library
are avail
Antoine Pitrou added the comment:
Given the way the new GIL works, I'm afraid it's not really possible to support
this (it needs some thread-state to be available).
Note that there is no reason, AFAIK, why you would want to call
PyEval_InitThreads() before Py_
Changes by Antoine Pitrou :
--
assignee: docs@python -> vinay.sajip
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue11330>
___
___
Python-
Changes by Antoine Pitrou :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue11327>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
assignee: -> vinay.sajip
nosy: +brett.cannon, vinay.sajip
stage: -> patch review
type: -> behavior
versions: +Python 3.3
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
New patch including a check for PyObject_GetBuffer()'s return value, the
missing declaration of HAVE_SETHOSTNAME in pyconfig.h.in, and a test for giving
a bytes values to the function.
--
Added file: http://bugs.python.org/file20909/sethostna
Antoine Pitrou added the comment:
It still fails under AMD64 OpenIndiana:
==
ERROR: test_offset_overflow (test.test_os.TestSendfile)
--
Traceback (most recent
Antoine Pitrou added the comment:
> What about Doc/whatsnew/3.3.rst?
This is filled by Raymond (or other people) when the release nears.
No need to care about it in regular commits.
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Ok, so the root cause is that sendfile() under Solaris can fail with EINVAL
when the offset is past the end of file (but only on 64-bit builds, strangely
:-)). Here is a patch, tested under Linux, 32-bit OpenSolaris and 64-bit
OpenSolaris. It also uses a
Antoine Pitrou added the comment:
> It seems we have a failure on Leopard:
I think the issue is you request a 4096 transfer near the end of file, but
there aren't that many bytes remaining. Apparently OS X then doesn't transfer
anything and returns 0. Hint:
>>> 1
Antoine Pitrou added the comment:
Should be fixed in r88647.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> The patch looks good.
>
> Just to be clear, on my system running "autoreconf" adds the correct
> stuff to pyconfig.h.in
Ah, strange. I used "autoconf" and it didn't...
> Isn't it best to leave it up t
Changes by Antoine Pitrou :
--
assignee: ronaldoussoren ->
nosy: +asksol, jnoller
___
Python tracker
<http://bugs.python.org/issue11334>
___
___
Python-
Changes by Antoine Pitrou :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue11334>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Committed in r88652 (3.3) and r88655 (3.2). Unfortunately, Paul's buildbot
seems a bit stuck in a previous build...
(I didn't commit to 2.7 since things look fine there)
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejec
Antoine Pitrou added the comment:
Thank you for the suggestion. We are actually starting our official transition
to hg, which makes things a bit unstable.
The final URL (http://hg.python.org/cpython/) is currently a test repo, while
the "usable for work right now" (http://code.pyt
Antoine Pitrou added the comment:
Errno 75 is EOVERFLOW here (Linux), which doesn't seem to be mentioned in
sendfile's man page.
Can you describe your system? (CPU architecture, bitness, endianness,
glibc/kernel version, etc.)
--
assignee: -> giampaolo.rodola
nosy: +gia
Antoine Pitrou added the comment:
> rev 88657
> Arch Linux 2.6.37 x86_64 with glibc2.6
> 64-bit, little endian
You are not running under a VM or something?
--
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I've committed the patch + some tests in r88664 (3.3), r88665 (3.2) and r88666
(2.7). Thanks for reporting this!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions
Antoine Pitrou added the comment:
Here is an excerpt:
libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.9) => /lib64/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.6.9) => /lib/libc.so.6
The "OS ABI" thing is not always there:
libdrm.so.2 (libc6,x86-64) => /
Antoine Pitrou added the comment:
Well, on the other hand, it *is* a common need.
(and I don't think mimicking the shell is a design principle for Python)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Ok, great !
The hg builders are temporary - or, rather, the SVN builders will get removed
once the transition is over.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Changes by Antoine Pitrou :
--
nosy: +barry, dmalcolm
___
Python tracker
<http://bugs.python.org/issue11347>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Likely explanation is http://bugs.python.org/issue10882#msg129555.
--
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Your patch is not cleaned up. There are strange things like:
+ret ^= ret;
(while would you xor an off_t?)
and
+do {off_t x = (*buf)[i].len;
+(*iov)[i].iov_len = x;
+ret += x;
+} while (0
2301 - 2400 of 16792 matches
Mail list logo
