Changes by David Watson :
Added file: http://bugs.python.org/file16885/af_unix-pep383-doc.diff
___
Python tracker
<http://bugs.python.org/issue8373>
___
___
Python-bug
David Coconut added the comment:
Issue 3770 is not relevant because this code works in Python 2.6 on both
machines (x86 and x86-64). These machines run plenty of other concurrent
processes also, which would imply to me that sem_open() does work.
I could be completely wrong as I'm no e
David Watson added the comment:
Attaching the C test programs I forgot to attach yesterday -
sorry about that. I've also tried these programs, and the
patches, on FreeBSD 5.3 (an old version from late 2004). I found
that it accepted unterminated addresses as well, and unlike Linux
it di
Changes by David Watson :
Added file: http://bugs.python.org/file16899/accept.c
___
Python tracker
<http://bugs.python.org/issue8372>
___
___
Python-bugs-list mailin
David Planella added the comment:
It would be nice that %-formatting had the same functionality as in C when it
comes to discarding unnamed arguments, but from the comments I understand that
being deprecated no changes in functionality are contemplated.
However, before recommending using
David Beazley added the comment:
What bothers me most about this discussion is that the Windows implementation
(legacy GIL) is being held up as an example of what we should be doing on
posix. Yet, if I go run the same thread tests that I presented in my GIL talks
on a multicore Windows
David Beazley added the comment:
I hope everyone realizes that all of this bike-shedding about emulated
semaphores versus "real" semaphores is mostly a non-issue. For one thing, go
look at how a "real" semaphore is implemented by reading the source code to
pthreads
David Beazley added the comment:
I'm sorry, but even in the presence of fair locking, I still don't like this
patch. The main problem is that it confuses fair locking with fair CPU
use---something that this patch does not and can not achieve on any platform.
The main probl
David Beazley added the comment:
I've attached a test "fair.py" that gives an example of the fair CPU scheduling
issue. In this test, there are two threads, one of which has fast-running
ticks, one of which has slow-running ticks.
Here is their sequential performance (O
David Bolen added the comment:
Looks like some initial configuration glitches - the buildbot needed a little
convincing to go to the DNS server for gethostbyname(). Should be working now.
--
___
Python tracker
<http://bugs.python.org/issue8
David Beazley added the comment:
I'm not trying to be a pain here, but do you have any explanation as to why,
with fair scheduling, the observed execution time of multiple CPU-bound threads
is substantially worse than with unfair scheduling?
>From your own benchmarks, consider thi
David Beazley added the comment:
One other comment. Running the modified fair.py file on my Linux system using
Python compiled with semaphores shows they they are *definitely* not fair.
Here's the relevant part of your test:
Treaded, balanced execution, with quickstop:
fast C: 1.5808
David Beazley added the comment:
I'm definitely sure that semaphores were being used in my test---I stuck a
print statement inside the code that creates locks just to make sure it was
using the semaphore version :-).
Unfortunately, at this point I think most of this discussion is aca
David Beazley added the comment:
As a followup, since I'm not sure anyone actually here actually tried a fair
GIL on Linux, I incorporated your suggested fairness patch to the
condition-variable version of the GIL (using this pseudocode you wrote as a
guide):
with gil.cond:
David Beazley added the comment:
Here are the results of running the fair.py test on a Mac OS-X system using a
"fair" GIL implementation (modified condition variable):
[ Fair GIL, Dual-Core, OS-X ]
Sequential execution
slow: 5.490943 (0 left)
fast: 0.369257 (0 left)
Threaded exec
David Bolen added the comment:
I believe it's XCode 2.4.1.
I know the script worked fine prior to the change that clears the environment,
and commenting out just that piece of the latest trunk copy continues to work.
To be honest, I'm not sure how the build even finds gcc-4.0 (e.
David Bolen added the comment:
The buildbot user's shell is also bash, so not entirely sure yet why it's
behaving differently in my environment. I had completely forgotten about bash
having a default path.
I do agree that explicitly setting a minimal path is a
New submission from David Bolen :
The attached suggested patch changes build-installer to pass along the same
Python executable that it itself is running under to the documentation
Makefile. This fixes an issue on OSX where pruning the PATH reverts to the
system python (2.3.5) which is too
New submission from David Bolen :
The attached suggested patch fixes a small bug where if you execute the
build-installer script without an explicit path (e.g., "python
build-installer.py") the setIcon compilation will fail since dirname(__file__)
is an empty string, so it ends up l
David Beazley added the comment:
I know that multicore processors are all the rage right now, but one thing that
concerns me about this patch is its effect on single-core systems. If you
apply this on a single-CPU, are threads just going to sit there and thrash as
they rapidly context
David Bolen added the comment:
For what it's worth, I added a few debugging statements to a local trunk
checkout, and it looks like the port is getting lost somewhere along the way to
setup the proxy... So the refused error is accurate and because it's trying the
default port 80.
New submission from David Beazley :
The attached patch makes two simple refinements to the new GIL implemented in
Python 3.2. Each is briefly described below.
1. Changed mechanism for thread time expiration
In the current implementation, threads perform a timed-wait on a condition
variable
David Beazley added the comment:
Can't decide whether this should be attached to Issue 7946 or not.
I will also post it there. (Feel free to close this issue if you want to keep
7946 alive).
--
___
Python tracker
<http://bugs.python.org/i
David Beazley added the comment:
The attached patch makes two simple refinements to the new GIL implemented in
Python 3.2. Each is briefly described below.
1. Changed mechanism for thread time expiration
In the current implementation, threads perform a timed-wait on a condition
variable
David Beazley added the comment:
One comment on that patch I just submitted. Basically, it's an attempt to make
an extremely simple tweak to the GIL that fixes most of the problems discussed
here in an extremely simple manner. I don't have any special religious
attachment to
David Beazley added the comment:
Here is the result of running the writes.py test with the patch I submitted.
This is on OS-X.
bash-3.2$ ./python.exe writes.py
t1 2.83990693092 0
t2 3.27937912941 0
t1 5.54346394539 1
t2 6.68237304688 1
t1 8.9648039341 2
t2 9.60041999817 2
t1 12.1856160164 3
David Beazley added the comment:
Greg,
I like the idea of the monitor suspending if no thread owns the GIL. Let me
work on that. Good point on embedded systems.
Antoine,
Yes, the gil monitor is completely independent and simply ticks along every 5
ms. A worst case scenario is that an
Changes by David Beazley :
Removed file: http://bugs.python.org/file17084/dabeaz_gil.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
David Beazley added the comment:
I've updated the GIL patch to reflect concerns about the monitor thread running
forever. This version has a suspension mechanism where the monitor goes to
sleep if nothing is going on for awhile. It gets resumed if threads try to
acquire the GIL
David Beazley added the comment:
I've also attached a new file schedtest.py that illustrates a subtle difference
between having the GIL monitor thread and not having the monitor.
Without the monitor, every thread is responsible for its own scheduling. If
you have a lot of threads ru
Changes by David Beazley :
Removed file: http://bugs.python.org/file17094/dabeaz_gil.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
David Beazley added the comment:
New version of patch that will probably fix Windows-XP problems. Was doing
something stupid in the monitor (not sure how it worked on Unix).
--
Added file: http://bugs.python.org/file17102/dabeaz_gil.patch
Changes by David Beazley :
Removed file: http://bugs.python.org/file17102/dabeaz_gil.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
David Beazley added the comment:
Added extra pointer check to avoid possible segfault.
--
Added file: http://bugs.python.org/file17104/dabeaz_gil.patch
___
Python tracker
<http://bugs.python.org/issue7
David Beazley added the comment:
That second access of gil_last_holder->cpu_bound is safe because that block of
code is never entered unless some other thread currently holds the GIL. If a
thread holds the GIL, then gil_last_holder is guaranteed to have a valid va
David Beazley added the comment:
I stand corrected. However, I'm going to have to think of a completely
different approach for carrying out that functionality as I don't know how the
take_gil() function is able to determine whether gil_last_holder has been
deleted or not.
Changes by David Beazley :
Removed file: http://bugs.python.org/file17104/dabeaz_gil.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
David Beazley added the comment:
One more attempt at fixing tricky segfaults. Glad someone had some eagle eyes
on this :-).
--
Added file: http://bugs.python.org/file17106/dabeaz_gil.patch
___
Python tracker
<http://bugs.python.org/issue7
David Beazley added the comment:
Wow, that is a *really* intriguing performance result with radically different
behavior than Unix. Do you have any ideas of what might be causing it?
--
___
Python tracker
<http://bugs.python.org/issue7
New submission from David Ripton:
Python 3.0a2, Gentoo Linux, x86
"make altinstall" installs idle, pydoc, and smtpd.py
This can partially break the previous Python install, which is counter
to the idea of altinstall being safe to use in parallel with an existing
install of a differe
David Ripton added the comment:
Here's a patch, against the 3.0a2 tarball.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1590>
__
___
Python-bugs-
David Ripton added the comment:
Same patch appears to work fine against the 2.5.1 tarball.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1590>
__
___
Pyth
Changes by David Ripton:
Added file: http://bugs.python.org/file8931/altinstall.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1590>
__
___
Python-bugs-
David Gardner added the comment:
the output of symtest.py looks like:
(13, 'Permission denied')
[Errno 13] Permission denied
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
New submission from David Gardner:
the docs for os.symlink at: http://docs.python.org/lib/os-file-dir.html
don't mention if the function raises an exception if there was a file
permission failure.
--
components: Documentation
files: symtest.py
messages: 59762
nosy: dgardner
sev
New submission from David Goodger:
I ran across this bug in some legacy production code when numbers got high:
>>> '%i' % 2e9
'20'
>>> '%i' % 3e9
Traceback (most recent call last):
File "", line 1, in ?
TypeError: int argumen
David Binger added the comment:
Bill's patch does appear to fix the ssl-related problem.
imaplib is still broken in py3k, though, due
to bytes/str issues.
--
nosy: +dbinger
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
David Binger added the comment:
On Jan 31, 2008, at 12:42 PM, Bill Janssen wrote:
>
> Bill Janssen added the comment:
>
> But that's issue 1210, which is still open. David, do you want to
> submit a patch for 1210?
I see that you are correct that 1210 is the bytes/str iss
David Ripton added the comment:
Just noticed that this is a partial duplicate of issue 1540386.
--
versions: +Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
David Chrsitian added the comment:
I don't see any change to the return value of new_buffersize that could
alleviate this problem - the problem being that because linux is
extremely efficient at reading bytes from /dev/zero, some other code
incosistencies are exposed.
The problem that is
David Christian added the comment:
Raise OverflowError if unbounded read() exceeds PY_SSIZE_T_MAX bytes.
Added file: http://bugs.python.org/file9511/issue1174606.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Changes by David Christian:
Added file: http://bugs.python.org/file9512/issue1174606.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1174606>
_
___
David Kwast added the comment:
On OSX 10.5 this behavior is confirmed (Python2.5 and 2.6a). This fix
appears to be a good fix for python 2.6a.
(Python 2.6a with patch applied)
Python 2.6a0 (trunk:60977M, Feb 23 2008, 19:24:52)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "
David Ripton added the comment:
The "if pid not in self.active_children: continue" check that was added
in r61106 appears to fix the bug, so I'm happy. Thanks.
__
Tracker <[EMAIL PROTECTED]>
<http://b
New submission from David Harel <[EMAIL PROTECTED]>:
Using Linux (Gentoo), when closing the socket of an smtp connection
using tls (you can use the example at:
http://snippets.dzone.com/posts/show/757).
Attached code example with my e-mail data. (I don't mind).
Also tested on Debian
David Harel <[EMAIL PROTECTED]> added the comment:
Found a problem in my python installation where SSL was unintentionally
disabled.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
David Harel <[EMAIL PROTECTED]> added the comment:
Yep. Close it.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2272>
__
___
Python-bugs-list mailing
New submission from David Ripton <[EMAIL PROTECTED]>:
distutils.sdist.add_defaults adds the Python modules and scripts and C
extensions found in setup.py to the MANIFEST. It does *not* add
data_files mentioned in setup.py to the MANIFEST.
This is non-orthogonal and confusing, because it
New submission from David Binger <[EMAIL PROTECTED]>:
This is with the current revision of py3k: 61353.
parser.suite('"\u1234"') fails with a TypeError.
Changing the argument format from "s" to "s#" works around this problem.
I added a unit test
New submission from David Binger <[EMAIL PROTECTED]>:
(at revision 61376)
It looks like this docstring needs to be updated.
--
assignee: georg.brandl
components: Documentation
messages: 63521
nosy: dbinger, georg.brandl
severity: minor
status: open
title: list.sort.__doc__ say
David Binger <[EMAIL PROTECTED]> added the comment:
Hi Bruno,
Are you testing py3k? This is what I see:
Python 3.0a3+ (py3k:61352M, Mar 12 2008, 13:11:35)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "licens
New submission from David Wolever <[EMAIL PROTECTED]>:
This patch makes it easier to run tests in the 2to3 suite.
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3tester.patch
keywords: patch
messages: 63740
nosy: David Wolever, collinwinter
se
David Wolever <[EMAIL PROTECTED]> added the comment:
I'll take this one (and the next few dealing with itertools)
------
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from David Wolever <[EMAIL PROTECTED]>:
ssh-rsa
B3NzaC1yc2EBIwAAAIEAvyZUU3zNsAoETLN8kDgTmm6qPeWMqUno3KkxcayPSVzT
U2pBLlMet/LVtLpHwqARTo4d5/g9vmjwPluQO7LgyIsH88GlJYRgPwV08rpzBTDR+/
0ZQWt82J7loB1z6mhxMS+YS0Oe2UOEXxYTCKfwwyTXDKVRk8wjlneyI9JZfB8=
[EMAIL PRO
David Stanek <[EMAIL PROTECTED]> added the comment:
I am uploading a new diff that includes the original fix from Hagai
along with some tests.
--
keywords: +patch
nosy: +dstanek
Added file: http://bugs.python.org/file9704/braced_override.diff
__
T
David Wolever <[EMAIL PROTECTED]> added the comment:
To clarify, 2to3 shouldn't wrap map, filter, zip in list() if they are
imported from future_builtins.
------
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
David Wolever <[EMAIL PROTECTED]> added the comment:
The 2to3 stuff relating to map is added in r61479.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2171>
__
David Wolever <[EMAIL PROTECTED]> added the comment:
Fixed in r61466.
--
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2363>
__
_
David Wolever <[EMAIL PROTECTED]> added the comment:
Fixed in r61466.
--
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2362>
__
_
David Wolever <[EMAIL PROTECTED]> added the comment:
Fixed in r61466.
--
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2361>
__
_
David Wolever <[EMAIL PROTECTED]> added the comment:
Fixed in r61466.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2360>
__
___
Python-bugs-list mailing
Changes by David Wolever <[EMAIL PROTECTED]>:
--
nosy: -brett.cannon, collinwinter, georg.brandl
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by David Wolever <[EMAIL PROTECTED]>:
--
nosy: -brett.cannon, collinwinter
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by David Wolever <[EMAIL PROTECTED]>:
--
nosy: -brett.cannon, collinwinter
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by David Wolever <[EMAIL PROTECTED]>:
--
nosy: -brett.cannon, collinwinter
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
David Wolever <[EMAIL PROTECTED]> added the comment:
Filter has been fixed in r61546.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2171>
__
___
Python
David Wolever <[EMAIL PROTECTED]> added the comment:
Added to future_builtins in r61587.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2171>
__
___
Python
David Wolever <[EMAIL PROTECTED]> added the comment:
Ok, checked in the last piece -- fixer for filter -- in r61598.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
David Wolever <[EMAIL PROTECTED]> added the comment:
Added in r61626.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2414>
__
_
Changes by David Wolever <[EMAIL PROTECTED]>:
--
assignee: collinwinter -> David Wolever
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
David Wolever <[EMAIL PROTECTED]> added the comment:
I've updated the fixer (checkin to come shortly), but 2to3 gets upset when
you it comes across print statements with kwargs (eg: print("spam", end="
")), so the tests will be co
David Wolever <[EMAIL PROTECTED]> added the comment:
As of r61635, the fix_print fixer has been fixed and tests have been added
(which will ``assert False`` when 2to3 is fixed so it can handle
``print(**kwargs)``).
--
assignee: David Wolever -> col
David Wolever <[EMAIL PROTECTED]> added the comment:
itertools.imap is being translated directly to map... But I bet this is
another one of those ordering problems -- itertools.imap is converted to
the map, then the map is converted to list(map(...)) because fix_map
doesn't know t
Changes by David Wolever <[EMAIL PROTECTED]>:
--
assignee: collinwinter -> David Wolever
nosy: +David Wolever
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
David Wolever <[EMAIL PROTECTED]> added the comment:
Ok, I've added explicit ordering to fixers in r61654, fixing this issue.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bu
David Wolever <[EMAIL PROTECTED]> added the comment:
Ok, fixed in r61664.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from David Wolever <[EMAIL PROTECTED]>:
It takes me 10 seconds to run 2to3 on the example file.
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 64152
nosy: David Wolever, collinwinter
severity: normal
status: open
title: 2to3 is
David Wolever <[EMAIL PROTECTED]> added the comment:
Martin and I talked about this, and I'm going to try loading the first
node of each tree generated by the PATTERNs into a dictionary, then when
the tree is walked, only fixers which could potentially match the current
node a
David Wolever <[EMAIL PROTECTED]> added the comment:
A patch so that, on each node, only fixers who's head node could match
this node are executed. It's still hacky and ugly, but a decent POC.
--
keywords: +patch
Added file: http://bugs.python.org/file9791/fixer_head_
New submission from David Stanek <[EMAIL PROTECTED]>:
I was having an issue building extension with a fresh checkout of
revision 61699. distutils was using the UnixCCompiler. This is not able
to find thec correct libraries to link against. I made a few changes in
this patch:
* distuti
Changes by David Stanek <[EMAIL PROTECTED]>:
--
type: -> compile error
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2445>
__
___
Python-b
David Stanek <[EMAIL PROTECTED]> added the comment:
As Christian suggested I removed the unrelated svn:ignore changes.
Added file: http://bugs.python.org/file9804/cygwin-smaller.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by David Stanek <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9803/cygwin.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2445>
__
David Wolever <[EMAIL PROTECTED]> added the comment:
Ok, I've fixed this in r61755.
I _think_ it does the right thing, but it might be good if someone else
checks out the test cases to make sure.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
David Wolever <[EMAIL PROTECTED]> added the comment:
Ah, nuts -- I had a test case for this, but it was testing with 'from
itertools import izip, imap'... But not the single node >_<
It has been fixed, and appropriate test has been added, in r61824.
On 23-Mar-08, at 4:
Changes by David Wolever <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2468>
__
___
David Wolever <[EMAIL PROTECTED]> added the comment:
Ah, yea -- in my rush to catch my train I must have neglected to look at
the _results_ of running test.py... I have updated the patch so the fixers
will work.
Added file: http://bugs.python.org/file9853/fixer_head_node_lookup_
David Wolever <[EMAIL PROTECTED]> added the comment:
Can you write a test case proving this?
At the moment, the second thing that the transform function in
fix_import.py does is return if the import doesn't look like a local
import (see probably_a_local_import in fix_import).
At
David Wolever <[EMAIL PROTECTED]> added the comment:
Ah, yes -- that may be the fault of the confusingly named
'check_both'. The "both" means "both when the module in question
exists and when it does not". If you've got a better name, please
David Remahl <[EMAIL PROTECTED]> added the comment:
The following test cases still cause bus errors with the patch applied:
import imageop; imageop.rgb82rgb('A'*(2**30), 32768, 32768)
import imageop; imageop.grey2rgb('A'*(2**30), 32768, 32768)
501 - 600 of 5932 matches
Mail list logo
