Antoine Pitrou added the comment:
[...]
> _PyObject_Call403 99,02
[...]
> affinity off:
> Functions Causing Most Work
> Name Samples %
[...]
> _PyObject_Call1.936 99,23
[...]
> _threadstartex1.934 99,13
>
> When we run on both cores, w
Antoine Pitrou added the comment:
> The counter is "stall cycles".
> During the 10 second run on my 2.4Ghz cpu, we had instruction cache
> miss stalls for 2 billion cycles (2000 samples of 100 cycles per
> sample). That does account for around 10% of the availible
Antoine Pitrou added the comment:
The patch adds a new feature, which makes it unsuitable for 2.6. I guess it
could be applied to the 2.7 trunk, although a beta is being released and I'm
not sure new features are really welcome afterwards. This one is really small
and non-controve
Antoine Pitrou added the comment:
Ok, I trust you on the investigation.
> Could this go into trunk, since the tests actually fail needlessly
> on qemu setups?
Yes, but after the beta:
http://mail.python.org/pipermail/python-dev/2010-April/099132.html
--
assignee: -> skrah
r
Antoine Pitrou added the comment:
Ok, I raised the "errno 0" issue on the openssl mailing-list, and I had a nice
response by Darryl Miles here:
http://www.mail-archive.com/openssl-us...@openssl.org/msg60710.html
The bottom line is that any "socket error" return from u
Antoine Pitrou added the comment:
My analysis of SSL_shutdown() was missing something: timeout sockets are really
non-blocking sockets in disguise. I guess it's never too late to notice.
OpenSSL doesn't know about the timeout, so we have to do it ourselves.
Ironically, the infrast
Changes by Antoine Pitrou :
--
nosy: +akuchling, exarkun
___
Python tracker
<http://bugs.python.org/issue2643>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Py_ASSIGN could be a better name, but given the enthusiasm generated by this
proposal, I think we might just as well close the issue.
--
___
Python tracker
<http://bugs.python.org/issue3
Antoine Pitrou added the comment:
Ok, I think the wrapper approach is a good one. Now remains to decide whether
it should stay private to socketserver or be exposed as a generic method (for
example in the "os" module as proposed).
By the way, adding a patch would be nice, too. I&
Antoine Pitrou added the comment:
Ok, I think the wrapper approach is a good one. Now remains to decide whether
it should stay private to socketserver or be exposed as a generic method (for
example in the "os" module as proposed).
By the way, adding a test would be nice, too. I
Changes by Antoine Pitrou :
--
___
Python tracker
<http://bugs.python.org/issue7978>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Antoine Pitrou added the comment:
The docstring looks right to me. "mode=0777" doesn't mean it takes a keyword
argument, only that this argument has a default value.
You might want to fix posixmodule to accept keyword arguments, but it should
probably be done for all functions
Antoine Pitrou added the comment:
You're right that silencing IO errors is bad. Patch welcome.
--
nosy: +amaury.forgeotdarc, pitrou
priority: low -> normal
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
nosy: +exarkun
___
Python tracker
<http://bugs.python.org/issue8354>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +nnorwitz, tim_one
___
Python tracker
<http://bugs.python.org/issue3581>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
assignee: -> janssen
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue7927>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
assignee: -> janssen
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue7943>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
Is it a dup of issue1785?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue7425>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> Wouldn't it be nicer if mode was a property?
Good point. I guess it would indeed...
--
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
After some investigation, the error does occur because of the aforementioned
changelog entry (SSLv2 weak ciphers are now disabled by default). To check it I
just added the following line to newPySSLObject():
SSL_CTX_set_cipher_list(self->ctx, &
Antoine Pitrou added the comment:
The tests don't look good to me. You should use p.communicate() rather than
p.stdout.read(). Also, check the error return code and raise an error if it's
non-zero.
--
nosy: +pitrou
___
Python trac
Antoine Pitrou added the comment:
> Should the patch go into the maintenance branches as well (after the
> beta is out)?
Yes, I think it would be nice (though not mandatory).
--
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
> List of ciphers is application dependent and configure script can't
> limit users(applications) .
I was obviously talking about a runtime argument to ssl.wrap_socket().
--
___
Python tra
Antoine Pitrou added the comment:
It turns out isatty() returns True for fds created by openpty(), which helps
quite a bit: we can silence EIO for ttys while keeping it for non-ttys, where a
low-level I/O (hardware) error should be raised properly.
Here is a patch for trunk
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16859/io-openpty.patch
___
Python tracker
<http://bugs.python.org/issue5380>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file16861/io-openpty.patch
___
Python tracker
<http://bugs.python.org/issue5380>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
After triggering the buildbots, it seems that reading from the master fd
after the slave fd has been closed is rather OS-dependent. The FreeBSDs
return an empty string. I wonder whether this use case (reading from the
master after the slave is closed) should
Antoine Pitrou added the comment:
Regardless of the decision, a new patch.
--
Added file: http://bugs.python.org/file16863/io-openpty.patch
___
Python tracker
<http://bugs.python.org/issue5
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16861/io-openpty.patch
___
Python tracker
<http://bugs.python.org/issue5380>
___
___
Python-bug
Antoine Pitrou added the comment:
Worse, the test timed out (probably froze) on the Solaris buildbot:
http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/649/steps/test/logs/stdio
--
___
Python tracker
<h
Antoine Pitrou added the comment:
> SHA1 hashing (C)
>
> threads= 1: 1275 iterations/s. balance
> threads= 2: 1267 ( 99%)0.7238
> threads= 3: 1271 ( 99%)0.2405
> threads= 4: 1270 ( 99%)0.1508
>
> Using the forced "do_yield" helps
Antoine Pitrou added the comment:
Why do you think PyObject_CallObject() is the culprit?
There could be any number of reasons for a memory leak:
- cyclic references needing to be cleared (have you tried calling
PyGC_Collect()?)
- reference leak(s) in your own internal logic
- inefficiencies in
Antoine Pitrou added the comment:
> Antoine (2): The need to have do_yield is a symptom of the brokenness
> of the GIL.
Of course it is. But the point of the benchmark is to give valid results
even with the old broken GIL.
I could remove do_yield and still have it give valid result
Antoine Pitrou added the comment:
Thanks for the detailed analysis, Charles-François.
> Finally, I think that the documentation should be rephrased:
Yes, I think so.
> Furthermore, under Linux 2.6 and NPTL, getpid() returns the main thread
> PID even from another thread.
Yes, thos
Antoine Pitrou added the comment:
To just run the test_ftplib tests, you can use:
$ ./python -m test.regrtest -v -uall test_ftplib
(Other tests involving SSL sockets are test_ssl, test_smtpnet,
test_imaplib and test_poplib)
> 1) Some thing that concern me, the "unwrap()" philos
Changes by Antoine Pitrou :
--
nosy: +haypo, loewis
priority: -> high
stage: -> patch review
versions: -Python 2.5, Python 3.3
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +haypo, loewis
priority: -> normal
stage: -> patch review
versions: -Python 3.3
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
Thanks Martin. I see no leak here either (Linux with Python 2.6 and 2.7).
--
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
> Thinking back about this, I wonder whether "FTPS" could be a better name to
> use instead of "FTP_TLS".
> It's shorter, easier to remember, and also makes more sense since also SSL
> can be used, not only TLS.
What
Antoine Pitrou added the comment:
I think parsing should be a bit more careful. For example, what happens when
you give 'http://dead:beef::]/foo/' as input (note the missing opening bracket)?
--
nosy: +pitrou
___
Python trac
Antoine Pitrou added the comment:
By the way, updating the RFC list as done in
python-urlparse-rfc2732-rfc-list.patch is also a good idea.
--
___
Python tracker
<http://bugs.python.org/issue2
Antoine Pitrou added the comment:
> Isn’t “http://dead:beef::]/foo/“ and invalid URI?
That's the point, it shouldn't parse as a valid one IMO.
--
title: RFC2732 support for urlparse (e.g. http:// -> RFC2732 support for
urlparse
Antoine Pitrou added the comment:
This doesn't look like a bug. You must install a locale before it gets
available to Python.
Furthermore, according to the original traceback (
http://launchpadlibrarian.net/43012745/quickshot-latin.log ), the locale module
isn't eve
Antoine Pitrou added the comment:
Actually, my diagnosis was wrong. The locale module contains a list of locale
aliases and some of the Serbian ones are missing. A recent locale.alias file
from X11 is more complete.
--
nosy: +lemburg
priority: -> normal
resolution: inva
Antoine Pitrou added the comment:
> However, these cases seem to be different.
I think it can be used to find out the current language setting of the
user, and trigger a third-party translation system (other than e.g.
gettext).
--
___
Pyt
Antoine Pitrou added the comment:
When the table is updated in trunk, can it be backported to 2.6?
It does change a couple of mappings (example here is from sr_CS.* to sr_RS.*).
--
___
Python tracker
<http://bugs.python.org/issue8
New submission from Antoine Pitrou :
test_distutils fails in py3k when run with -j (e.g.
"python -m test.regrtest -j1 -v test_distutils")
==
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildE
Antoine Pitrou added the comment:
Ok, the fix (updated tables) has been committed in trunk (r79977) and py3k
(r79978). I suppose Ubuntu can backport the patch if they want their Python to
be in sync with their own locales.
(even better, distributions should include the regeneration of locale
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue2987>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Could you tell me which X11 version you used ? I've modified the
> generation script to also output the added aliases and would like
> to list them as well.
It's the file supplied on my Mandriva system, from
libx11-1.2.2
Antoine Pitrou added the comment:
It's probably caused by optimizations in the peepholer indeed.
--
nosy: +pitrou, rhettinger
priority: -> low
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Should we call it libpython3.py, in order to distinguish it from the 2.x
version?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
It should be ported to py3k, the sparc buildbots still fail there.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8
Changes by Antoine Pitrou :
--
status: closed -> pending
___
Python tracker
<http://bugs.python.org/issue8314>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Probably not. I guess an implicit str() is done on the argument given to
write():
>>> s = StringIO()
>>> s.write((1,2))
>>> s.write(3)
>>> s.getvalue()
'(1, 2)3'
--
nosy: +pitrou
priority: -> norma
Changes by Antoine Pitrou :
--
title: cStringIO and StringIO don't behave the same way -> StringIO.write()
takes any argument and converts it to a string
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> Do you really think that Python users shouldn't use tools written in
> Python if they are available?
Sure, they can. For example, they can use Mercurial and type "hg diff".
Or even TortoiseHg and do it all from a GUI.
---
Antoine Pitrou added the comment:
Updated patch against current py3k.
About the timeout limit, an useful point of comparison is select(), which
doesn't try to loop either: it just throws OverflowError if the specified
timeout value is too large to be represented in a timeval s
Antoine Pitrou added the comment:
I suggest simply skipping the "offending" test on linuxthread platforms.
(perhaps as simple as checking for sys.platform == "linux2" and signal.SIGRTMIN
== 35)
--
___
Python tracker
<
Antoine Pitrou added the comment:
> Seems like I have to remind that everybody can still paint their
> bikeshed in classic colors with "-c" option, but if you all prefer
> unified colors, why do you resist on painting them in these by
> default? Custom color options add
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue8355>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Kristjan,
> Maybe the state of this discussion is my fault for not being clear enough.
It's quite a bit simpler. The first 2.7 beta has been released and
there's IMO no way such patches will be accepted. It doesn't seem to be
a pressing
Antoine Pitrou added the comment:
Thank you! Checked in in r80071.
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
It looks rather like a bug to me, and should be forbidden.
--
nosy: +pitrou
priority: -> normal
stage: -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.2
___
Python tracker
<http://bugs.p
Antoine Pitrou added the comment:
I'm with Martin, better to target 3.2 IMO.
Does signalfd really bring something compared to set_wakeup_fd()?
The one big difference I can see is that set_wakeup_fd() doesn't transmit the
signal number, but this could be fixed if desired (instead of s
Antoine Pitrou added the comment:
> if _POSIX_SEMAPHORES is defined, thread_pthread.h is designed to use
> the (fair) semaphore. If it is not present, or
> HAVE_BROKEN_POSIX_SEMAPHORES defined, the semaphore is supposed to be
> emulated using a condition variable.
> Now, I don&#
Antoine Pitrou added the comment:
> However, I just asked a colleague with a os X to compile python 2.7
> and _POSIX_SEMAPHORES isn't defined, and so, it is running using the
> emulation. Why, I wonder? Isn't it defined in unistd.h?
Perhaps a bad combination of defines.
Antoine Pitrou added the comment:
2.7 is in (mostly) feature freeze mode, so I'm retargetting this to 3.2.
(yes, this issue is very old; sorry)
I will try to include it (or a variant thereof; the non-blocking + timeout
combination doesn't make much sense, so I plan to forbid it) t
Antoine Pitrou added the comment:
> Yes, we put #error in both places (defining and undefining
> USE_SEMAPHORES). The colleague in question is Christian Tismer, he is
> unlikely to have gotten it wrong.
Ok, so can you or Christian open an issue about it? We should try to fix
it.
&g
Antoine Pitrou added the comment:
> You do realize, that if we enable the USE_SEMAPHORE, we get the GIL
> behaviour as seen on windows and with my ROUNDROBIN_GIL
> implementation, right?
I haven't studied this argument, but I don't see how that contradicts
anything. The m
Antoine Pitrou added the comment:
> Googling a bit gave me this:
> http://lists.apple.com/archives/darwin-kernel/2005/Dec/msg00022.html
> It would appear that mac os X was at least lacking full posix semaphore
> support in 2005.
Hmm. OS X
Antoine Pitrou added the comment:
I don't understand why you claim your patched version is fair. As far as I can
tell, if you have three threads A, B and C all routinely trying to take this
lock, your implementation can perfectly well bounce between A and B without
ever giving the lock
Antoine Pitrou added the comment:
> What do you think about my solution (convert the traceback to ASCII to
> avoid the encoding issue)?
It's fine for me. Perhaps you should add a comment to explain why this is
necessary.
--
___
Pyt
Antoine Pitrou added the comment:
After thinking a bit about it, we're in quasi-feature freeze now for 2.x and it
doesn't sound reasonable to add options to unwrap(); we would need to write
tests to exercise these options and their behaviour. Also, they aren't strictly
ne
Antoine Pitrou added the comment:
A set_ciphers() method turns out to be highly impractical, since the underlying
SSL objects are created lazily when we actually connect the socket.
Therefore, I have instead opted for a new "ciphers" argument to the SSL
constructor(s). Patc
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16952/ciphers.patch
___
Python tracker
<http://bugs.python.org/issue8322>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file16953/ciphers.patch
___
Python tracker
<http://bugs.python.org/issue8322>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
New patch updating docs.
--
Added file: http://bugs.python.org/file16954/ciphers2.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Antoine Pitrou :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue8322>
___
___
Python-bugs-list mailing list
Un
Changes by Antoine Pitrou :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue8429>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I don't know about test_tokenize, but test_io is quite heavy and a couple of
individual tests launch many threads. On a slow CPU with little RAM, the test
could simply be still running (swapping?) after 1800s...
--
nosy: +doko, p
Changes by Antoine Pitrou :
--
assignee: -> barry
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue8430>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
I agree that we can consider dropping the static buffer and always using
PyMem_MALLOC().
It looks a bit strange for this bug to happen, though. Does Ubuntu use a small
stack size?
--
nosy: +pitrou, tim_one
Antoine Pitrou added the comment:
Oh, and the record of the original patch conversation (when this optimization
was added) can be found here:
http://mail.python.org/pipermail/patches/2001-January/003500.html
--
priority: normal -> high
versions: +Python 2.7, Python 3.1, Python
Antoine Pitrou added the comment:
A small benchmark shows no difference in startup time when disabling the stack
buffer. (this is on Linux: of course, the problem might be that the glibc is
heavily optimized)
The benchmark was a simple:
$ time ./python -E -c "import logging, pydoc, xmlr
Antoine Pitrou added the comment:
Committed in r80151 (trunk), r80154 (py3k).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> If everyone agrees on "error: [Errno 0] Error" being a legitimate alias
> for a "connection closed event" condition then I'd say the test server
> looks good, even if I think that expecting a ssl.SSLError derived
> exce
Antoine Pitrou added the comment:
After a bit of investigation, this issue seems to be exactly why
test_httpservers sometimes hangs.
The patch looks complicated to me, though; I don't think we really have to
support the multiple shutdowns case.
--
nosy: +pitrou
priority: ->
Antoine Pitrou added the comment:
Here is a simpler patch. It also fixes the wrong use of a lock instead of an
event in test_httpservers. With this patch, test_httpservers runs forever
without freezing.
--
Added file: http://bugs.python.org/file16964/shutdown.patch
Antoine Pitrou added the comment:
Modified patch committed in r80157 (py3k). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
> Probably the timeout has to be increased drastically or -uall should
> be dropped.
We should probably increase the timeout on this particular set of
buildbots. -uall has no influence on the duration of e.g. t
Changes by Antoine Pitrou :
--
components: +Tests
priority: -> normal
stage: -> patch review
type: -> behavior
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Certainly a bug indeed.
--
components: +IO -Unicode
nosy: +pitrou
priority: -> high
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> Any new features in 2.7 require approval from the release manager now.
Not only, but they also need someone to provide a patch :)
Removing any surrogateescape use from the io module would be comparatively much
easier.
--
nosy: +benjamin.peter
Antoine Pitrou added the comment:
> the ARMv4 buildbot is a 500Mhz Xscale, with a SATA disk attached, 256MB
> RAM. It can't go faster :-/
Have you checked running the test suite manually (possibly with the -v option
for more progress information), to check whether these were genu
Changes by Antoine Pitrou :
--
components: +Tests
nosy: +barry, brett.cannon
priority: -> normal
stage: -> needs patch
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Here is a fix + test.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file16974/surrogateescape.patch
___
Python tracker
<http://bugs.python.org/iss
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16974/surrogateescape.patch
___
Python tracker
<http://bugs.python.org/issue8438>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file16975/surrogateescape.patch
___
Python tracker
<http://bugs.python.org/issue8438>
___
___
Python-bug
Antoine Pitrou added the comment:
New patch fixing Windows compatibility.
--
Added file: http://bugs.python.org/file16977/surrogateescape.patch
___
Python tracker
<http://bugs.python.org/issue8
4801 - 4900 of 16792 matches
Mail list logo
