Antoine Pitrou added the comment:
Should be fixed now.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11688>
___
___
Python-bugs-lis
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4329/steps/test/logs/stdio
==
FAIL: test_collect_generations (test.test_gc.GCTests
Antoine Pitrou added the comment:
Looks fixed now.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> Here's an implementation of read1() that satisfies that condition, along with
> some relevant unit tests.
Something looks fishy: what happens if size is -1 and EOFError is not
raised?
--
___
Python tra
Antoine Pitrou added the comment:
Patch now committed, thank you!
Since the patch adds a new API (GzipFile.read1()), I think it's better not to
backport it.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: behavior ->
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4334/steps/test/logs/stdio
==
FAIL: test_dump_tracebacks_later (test.test_faulthandler.FaultHandlerTests
New submission from Antoine Pitrou :
This sometimes happens on the buildbots:
test test_multiprocessing failed -- Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py",
line 1191, in test_pool_worke
Antoine Pitrou added the comment:
Should be fixed now.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
The new FreeBSD buildbot had a sporadic SIGKILL in
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1/steps/test/logs/stdio
(apparently, faulthandler didn't dump a traceback)
By the way, we can be fairly certain now tha
Antoine Pitrou added the comment:
By the way, at this point I think we could simply skip the test on BSDs and OS
X. The tested functionality is cross-platform, so testing under a limited set
of systems should be ok.
--
___
Python tracker
<h
Antoine Pitrou added the comment:
Rather than hardwiring `self.addCleanup(lambda: setattr(self, '_diffThreshold',
2**16))`, you should retrieve the previous value.
--
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Why on Earth would you want to serialize a hashlib object?
It makes as much sense as serializing, say, a JSONEncoder.
--
nosy: +gregory.p.smith, pitrou
___
Python tracker
<http://bugs.python.org/issue11
Changes by Antoine Pitrou :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11767>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Why not add fast paths to the generic functions if that's what you're
> concerned about?
>
> It's unexpected for the user of the functions and breaks years of
> tradition. What if someone calls PyList_Append on a custom type th
Antoine Pitrou added the comment:
> 1. It's an external API. We *don't control* most of the potentially
> broken code, so saying "just fix the call sites" effectively solves
> nothing and leaves classes like OrderedDict at risk of subtle silent
> corruption w
Antoine Pitrou added the comment:
There is no Cygwin buildbot, this is a regular Windows buildbot (despite the
path in the traceback).
That said, spawning processes is quite slow under Windows anyway (much slower
than under Linux). So we could up the countdown
Antoine Pitrou added the comment:
Hopefully fixed now, thanks for your diagnosis!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: -Python 3.1
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%202.7/builds/519/steps/test/logs/stdio
==
FAIL: test_notify_all (test.test_multiprocessing.WithProcessesTestCondition
Changes by Antoine Pitrou :
--
assignee: -> giampaolo.rodola
nosy: +giampaolo.rodola
stage: -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> Having "Christophe Simonis" in the nosy list is precluding NOSY
> changes. I guess the space is causing problems. Should we forbid
> spaces in usernames (maybe provided by OpenID, who knows)???
Please report this in the meta-tracke
Changes by Antoine Pitrou :
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue11800>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
The question is: what's the point? Having an individual test timeout is not
more "correct" than having a timeout for a test file. Both are arbitrary.
Therefore, I'd prefer we choose the simplest solution and this patch brings
complica
Antoine Pitrou added the comment:
> Buildbots use currently a global timeout of 1 hour. I tried timeouts
> of 5, 15 and 30 minutes for a file, and I always got false positive.
> Using a timeout of 15 minutes per function, I don't expect any false
> positive anymore.
Still I do
Antoine Pitrou added the comment:
Le jeudi 07 avril 2011 à 23:08 +, STINNER Victor a écrit :
> STINNER Victor added the comment:
>
> > Still I don't see the point. Is a 60 minutes timeout too long?
>
> If regrtest timeout is too close to the buildbot timeou
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11804>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I did a similar test on Windows: test_io takes ~19.1 sec with and
> without timeout.
You may want to test with test_argparse.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Well, buildbots run tests with "-uall", so the "largefile" resource gets
enabled.
--
nosy: +pitrou
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
It has been fixed in 2.7.x, not 2.6.x (which is in security fixes-only mode).
Can you try with 2.7.1?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Confirmed. In the meantime, you can connect manually using
socket.create_connection():
>>> import ssl, socket
>>> conn = socket.create_connection(("2001:888:2003:1004:c2ff:eeff:fe00:133",
>>>
Changes by Antoine Pitrou :
--
components: +Library (Lib)
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue11811>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> Actually, python 2.6 is the default version in pkgsrc
> (http://www.netbsd.org/docs/software/packages.html), and the reason
> why i'm pulling up this bug is that python 2.6 failure on SunOS brings
> down more than 3000 packages :/ Neverth
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2920/steps/test/logs/stdio
test test_telnetlib failed -- Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_telnetl
Changes by Antoine Pitrou :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11810>
___
___
Python-bugs-
New submission from Antoine Pitrou :
There's the following code in pool.py, line 494 and following:
debug('joining task handler')
task_handler.join()
debug('joining result handler')
task_handler.join()
It seems the last line should
New submission from Antoine Pitrou :
Queue.get(block=True) cannot raise EmptyError, meaning there's some dead code
that we can remove.
--
components: Library (Lib)
files: cfsimplify.patch
keywords: patch
messages: 133435
nosy: bquinlan, pitrou
priority: normal
severity: normal
Antoine Pitrou added the comment:
A further optimization would be to use a SimpleQueue (from
multiprocessing.queues) for the result_queue in the ProcessPoolExecutor. A
SimpleQueue is much more light-weight than a normal Queue, which has a bunch of
additional locks and a dedicated thread
Antoine Pitrou added the comment:
> I know this is closed etc... but Plone (the CMS I use) is tied to
> various versions of Python, in particular 2.6 at this time. Having it
> not build on Open[Solaris/Indiana] means I can't install current
> versions of Plone/Zope on th
Changes by Antoine Pitrou :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue11810>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
title: smptlib should support SSL contexts -> smtplib should support SSL
contexts
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Duplicate of issue11821.
--
nosy: +pitrou
resolution: -> duplicate
status: open -> closed
superseder: -> smtplib should provide a means to validate a remote server ssl
certificate(s)
___
Python track
Antoine Pitrou added the comment:
Oops, I meant issue8809.
--
superseder: smtplib should provide a means to validate a remote server ssl
certificate(s) -> smtplib should support SSL contexts
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Is anybody working on this issue? If not, I think it looks like it
> might be a nice one for me to tackle. I'll go ahead unless there are
> any objections.
Nobody is working on it AFAIK. Feel free to
Changes by Antoine Pitrou :
--
keywords: +easy
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue11823>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
Nice! See also issue11814.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8428>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Should be fixed now, thank you Charles-François.
As for the TestCondition failure, there's a separate issue11790 open.
(Victor, please don't file many bugs in a single issue!)
--
resolution: -> fixed
stage: -> committed/rejec
Antoine Pitrou added the comment:
Fixed. The _terminate() issue has been fixed separately in issue8428.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
components: +Windows
nosy: +brian.curtin, tim.golden
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue5
Changes by Antoine Pitrou :
--
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue5162>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
I think it should be enabled with an optional argument. Otherwise in some cases
you'll get lots of additional output while you're only interested in the
top-level code.
--
nosy: +pitrou
___
Python trac
Antoine Pitrou added the comment:
> If you disassemble a function, you typically want to see all the code
> in that function.
That depends on the function. If you do event-driven programming (say,
Twisted deferreds with addCallback()), you don't necessarily want to see
the disasse
New submission from Antoine Pitrou :
multiprocessing.queues.SimpleQueue is undocumented and doesn't appear in
multiprocessing.__all__.
--
assignee: docs@python
components: Documentation, Library (Lib)
keywords: easy
messages: 133586
nosy: docs@python, pitrou
priority: normal
sev
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> Another solution would be to rewrite the test to not use mmap() at all:
>
> @precisionbigmemtest(size=_4G + 4, memuse=1)
> def test_big_buffer(self, size):
> if size < _4G + 4:
> self.skipTest("not e
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file21659/sometext.txt
___
Python tracker
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue8326>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I don't think it's in the business of the C API docs to explain Python-visible
semantics, or the difference between "==" and "is". I would just rephrase the
original paragraph, removing the last sentence joke:
“Since integ
Antoine Pitrou added the comment:
> 1. Find a more reliable host to test with?
Well, if you find a more reliable host than "localhost", why not ;-)
--
___
Python tracker
<http://bugs.pytho
New submission from Antoine Pitrou :
In Python 3.x, parsing JSON numbers involve calling PyLong_FromUnicode or
PyFloat_FromString with an unicode object. These functions are quite costly
because they call PyUnicode_TransformDecimalToASCII(). But JSON numbers are
always pure ASCII. This patch
Antoine Pitrou added the comment:
Cleaned up patch.
--
Added file: http://bugs.python.org/file21686/jsonnumbers2.patch
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
> Here is a patch: Antoine, would you like to review it?
>
> --
> keywords: +patch
> nosy: +pitrou
> Added file: http://bugs.python.org/file21636/rlock_release_save.patch
Well, it looks ok to me. Is the a
Antoine Pitrou added the comment:
Indeed, it just seems that the sleep period is sometimes too low. Will commit a
patch.
--
___
Python tracker
<http://bugs.python.org/issue11
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Agreed with your analysis. The problem is that the signal module doesn't expose
pthread_sigmask. We could grab Jean-Paul's implementation from
http://bazaar.launchpad.net/~exarkun/python-signalfd/trunk/view/head:/signalfd/_signalfd.c
(although I&
Antoine Pitrou added the comment:
> To sum up, python is returning memory, but your libc is not.
> You can force it using malloc_trim, see the attached patch (I'm not at
> all suggesting its inclusion, it's just an illustration).
That's an interesting thing, perhaps yo
Antoine Pitrou added the comment:
> The signal handler calls Py_AddPendingCall() which blocks on acquiring
> "pending_lock".
It blocks in taking the mutex, not on waiting for the condition variable.
Otherwise it wouldn't block (microseconds = 0).
I think the s
New submission from Antoine Pitrou :
PEP 11 calls for removing support for the following systems in 3.3:
Name: Systems using Mach C Threads
Unsupported in: Python 3.2
Code removed in: Python 3.3
Name: SunOS lightweight processes (LWP)
Unsupported
New submission from Antoine Pitrou :
Happened on a buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2957/steps/test/logs/stdio
test test_concurrent_futures failed -- Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-win
Antoine Pitrou added the comment:
> Antoine: if I understand correctly your patch, if we have a pending
> signal, all next signals will be simply ignored.
I don't think so, please re-read.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Well, since it is a bugfix, you should apply it to all versions.
--
___
Python tracker
<http://bugs.python.org/issue11
Changes by Antoine Pitrou :
--
nosy: +gps
___
Python tracker
<http://bugs.python.org/issue11870>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> threading_info.patch:
> - Add thread._info() function -> dict with 'name' and
> 'use_semaphores' (pthread only) keys
Most of these names will be removed in 3.3:
http://bugs.python.org/issue11863
--
__
Antoine Pitrou added the comment:
> Yeah, I know. My patch should be updated if #11863 is fixed before this issue.
>
> Updated patch:
> - add 'pthread_version' key to threading._info()
> - test_os uses threading._info() to check if we are using linuxthr
Antoine Pitrou added the comment:
> Python/thread.c contains a reference to a missing file:
>
> #ifdef PLAN9_THREADS
> #include "thread_plan9.h"
> #endif
>
> But I don't see where PLAN9_THREADS is defined.
>
> remove_threads.patch removes these 3 l
Changes by Antoine Pitrou :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11882>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I also renamed 'name' key to 'thread', so 'thread' is the name of the
> *thread* implementation, and 'lock' is the name of the *lock*
> implementation.
Not that I want to bikeshed, but I think 'name'
Antoine Pitrou added the comment:
Agreed with Ronald. If Apple thinks fsync() shouldn't flush the hardware cache,
there's no reason for us to override that.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Thanks for the patch. A couple of comments:
- it would be nice to have some tests, but of course there are no tests for
SMTP_SSL currently. If you are motivated, perhaps you could investigate into
adding some.
- there are some tab characters in your patch
New submission from Antoine Pitrou :
smtplib uses a wrapper class "SSLFakeFile" in order to call readline() on an
SSL socket. But modern SSL sockets have makefile(), so using that wrapper class
really shouldn't necessary (of course, it must be investigated whether that's
t
Antoine Pitrou added the comment:
> - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> PyFloat_GetInfo() and PyLong_GetInfo())
I don't think we want that API to be public, so it should be
_PyThread_GetInfo().
> - Always compile thread.c, but add #ifd
Antoine Pitrou added the comment:
Sorry for the delay, I had forgotten about this issue. Thank you for the patch!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I committed a modified patch. Hopefully the buildbots won't break this time :)
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> pending
___
Python tracker
<http:
Antoine Pitrou added the comment:
Where have you seen that Python is calling mprotect()? There's no sign of it in
the whole source tree.
--
nosy: +neologix, pitrou
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> /usr/bin/iotop is a Python script and according to that log message
> grsecurity detected a call to mprotect().
Well, does Python itself run ok? That Python script could use
third-party extension modules which issue the offending mprotect(
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue11258>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue11882>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
After wrestling with startup issues on the OS X buildbots, here is a new patch,
tested on several different UNIX platforms.
--
Added file: http://bugs.python.org/file21765/embedtest2.patch
___
Python tracker
<h
Antoine Pitrou added the comment:
Unless someone objects, I would like to commit that latest patch, since at
least it enables the start of a regression suite for Python embedding.
(it also allowed me to notice how crufty and incredibly obscure the getpath.c
mechanisms are
Antoine Pitrou added the comment:
I agree with Amaury that it would be better in Modules. In my experience, code
that is in PC/ is a pain to discover.
A couple of nits about the patch:
- the functions in the PyMethodDef array could be sorted alphabetically
- the defint() macro isn't nece
Antoine Pitrou added the comment:
PS: I don't think there's a problem with the "_windows" name, as long as
wxPython doesn't depend on a *toplevel* module named "_windows".
--
___
Python tracker
Antoine Pitrou added the comment:
For the record, I tried Alexander's tests on the buildbots and it failed on OS
X Leopard:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%20custom/builds/12/steps/test/logs/stdio
but succeeded on OS X Tiger:
http://www.python.org/dev/bui
Antoine Pitrou added the comment:
What do you call "sandbox" ?
Also, would be nice if you investigated a bit more about the causes. From the
traceback, it looks like the child process is stuck inside exec().
--
___
Python trac
Antoine Pitrou added the comment:
> 19d9f0a177de causes that test_ctypes hangs when test suite is run in
> Gentoo sandbox. Please reopen this issue.
I'd prefer having a separate issue (which you already opened :-)).
The fact that all buildbots work fine after the change suggests to
Changes by Antoine Pitrou :
--
resolution: duplicate ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue11915>
___
___
Python-bugs-
Antoine Pitrou added the comment:
The MALLOC_MMAP_THRESHOLD improvement is less visible here:
$ MALLOC_MMAP_THRESHOLD_=1024 ../opt/python issue11849_test.py
*** Python 3.3.0 alpha
--- USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
0 antoine 7703 0.0 0.1 57756
Antoine Pitrou added the comment:
> By the way, I noticed that dictionnaries are never allocated through
> pymalloc, since a new dictionnary takes more than 256B...
On 64-bit builds indeed. pymalloc could be improved to handle allocations up to
512B. Want to try and write a
Changes by Antoine Pitrou :
--
assignee: -> ronaldoussoren
components: +Library (Lib), Macintosh -Extension Modules
nosy: +ned.deily, ronaldoussoren
stage: -> patch review
versions: -Python 3.4
___
Python tracker
<http://bugs.p
Antoine Pitrou added the comment:
+1 to Victor's proposal ("expected bytes, bytearray or buffer compatible
object").
--
nosy: +pitrou
___
Python tracker
<http://bugs.pyt
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.2/builds/215/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1223/steps/test/logs/stdio
Antoine Pitrou added the comment:
> > The MALLOC_MMAP_THRESHOLD improvement is less visible here:
> >
>
> Are you running on 64-bit ?
Yes.
> If yes, it could be that you're exhausting M_MMAP_MAX (malloc falls
> back to brk when there are too many mmap ma
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
2701 - 2800 of 16792 matches
Mail list logo
