Am 30.12.2010 04:45, schrieb Brian Quinlan:
On Dec 29, 2010, at 2:55 PM, Victor Stinner wrote:
Le mercredi 29 décembre 2010 à 21:49 +0100, Martin v. Löwis a écrit :
Of course, one may wonder why test_first_completed manages
to create 41 SemLock objects, when all it tries to do is two future
Wiadomość napisana przez Martin v. Löwis w dniu 2010-12-30, o godz. 10:16:
Am 30.12.2010 04:45, schrieb Brian Quinlan:
So skipping the test is probably the way to go.
I'm still -1 on that proposal.
I agree with Martin, explanation follows.
In general, I'm trying to think as the user:
On Thu, 30 Dec 2010 16:04:16 +0100
Łukasz Langa luk...@langa.pl wrote:
Some answers Philip gave already. Knowing all these things would let us
decide whether switching the module off on systems that don't meet the
requirements is okay and can we get away with just documenting how to make it
Am 30.12.2010 16:40, schrieb Antoine Pitrou:
On Thu, 30 Dec 2010 16:04:16 +0100
Łukasz Langa luk...@langa.pl wrote:
Some answers Philip gave already. Knowing all these things would let us
decide whether switching the module off on systems that don't meet the
requirements is okay and can we
I'm not sure concurrent.futures is the culprit, rather than
multiprocessing itself (or perhaps even some core Python functionality).
Actually, the threading-based part of concurrent.futures probably works
fine.
Well, the culprit really is FreeBSD. However, concurrent.futures
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process should fail. Unfortunately,
it's imported from __init__.py, so either we change the API to move
the
R. David Murray writes:
I thought Amaury was saying it was harder than svnmerge, not harder
than patching by hand (ie: that it *was* patching by hand, including
.rej files and the lack of tracking). I also heard Georg say that this
should be fixable, and that he's partly fixed the
1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
2. Why is the semaphore limit so low in the first place?
I don't know - (Free)BSD is in the tradition of disliking
SysV inventions, and POSIX inventions unless
Am 30.12.2010 18:54, schrieb Stephen J. Turnbull:
R. David Murray writes:
I thought Amaury was saying it was harder than svnmerge, not harder
than patching by hand (ie: that it *was* patching by hand, including
.rej files and the lack of tracking). I also heard Georg say that this
On Fri, 31 Dec 2010 02:54:26 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
I don't see why the tracking issue is any different than it would be
for svn. If you're actually merging, either a dummy merge (what git
Martin already said most of what I would have in response to your
post.
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
a merge tool? I for one immensely like Mercurial’s merge and utterly
dislike
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
2010/12/30 Antoine Pitrou solip...@pitrou.net:
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems
Le jeudi 30 décembre 2010 à 14:24 -0600, Benjamin Peterson a écrit :
2010/12/30 Antoine Pitrou solip...@pitrou.net:
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different
Martin v. Löwis wrote:
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process should fail.
If I understand correctly, it is possible to adjust BSD so that this
On Thu, 30 Dec 2010 12:36:47 -0800
Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process
Am 30.12.2010 19:31, schrieb Martin v. Löwis:
But using the adapted workflow simply requires learning new names for
old operations. Annoying, but it will make a fair number of core devs
quite happy.
I think the new workflow will simply result in (even) less care for the
maintenance
Am 30.12.2010 19:17, schrieb Martin v. Löwis:
1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
2. Why is the semaphore limit so low in the first place?
I don't know - (Free)BSD is in the tradition of
Also, it's not really necessary for everyone to merge every change from
maintenance to trunk: a) they can do multiple commits on the same
subject and merge once, and b) if the change is small and no problems can
be expected from merging, merging can also be done by others, just like
the mass
Am 30.12.2010 20:57, schrieb Éric Araujo:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
a merge tool?
Neither nor.
Am 30.12.2010 21:36, schrieb Ethan Furman:
Martin v. Löwis wrote:
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process should fail.
If I understand
Am 30.12.2010 22:38, schrieb Martin v. Löwis:
Also, it's not really necessary for everyone to merge every change from
maintenance to trunk: a) they can do multiple commits on the same
subject and merge once, and b) if the change is small and no problems can
be expected from merging, merging
BTW - can anyone contribute data points from other *BSDs?
I don't have an installation of OpenBSD, but...
In FreeBSD, POSIX semaphores are implemented in sys/kern/uipc_sem.c.
In
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/
that file doesn't exist. Also, in FreeBSD's limits.h,
On 12/30/2010 4:44 PM, Georg Brandl wrote:
But you can't use Mercurial's merge functionality for that, right?
You have to use some kind of transplant/cherry-picking to merge from the
3.3 branch to the 3.2 branch, right?
Oh, I wrote the above assuming 3.2-3.3 merging. For the other direction
According to the consensus (and loosely following the Google spreadsheet
I created for that purpose), I have removed the Demo directory from py3k.
Most demos have been deleted; some have been moved into Tools or into the
docs as an example. If I removed something you think should have stayed,
2010/12/30 Terry Reedy tjre...@udel.edu:
On 12/30/2010 4:44 PM, Georg Brandl wrote:
But you can't use Mercurial's merge functionality for that, right?
You have to use some kind of transplant/cherry-picking to merge from the
3.3 branch to the 3.2 branch, right?
Oh, I wrote the above assuming
Martin v. Löwis mar...@v.loewis.de writes:
1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
Yeah, my recollection about 7.3 appears to have been remembering when
the kernel module was included by default as
2010/12/28 Lukas Lueg lukas.l...@googlemail.com
Consider the following code:
def foobar(x):
for i in range(5):
x[i] = i
The bytecode in python 2.7 is the following:
2 0 SETUP_LOOP 30 (to 33)
3 LOAD_GLOBAL 0 (range)
2010/12/29 Martin v. Löwis mar...@v.loewis.de
Am 28.12.2010 18:08, schrieb Lukas Lueg:
Also, the
load_fast in lne 22 to reference x could be taken out of the loop as x
will always point to the same object
That's not true; a debugger may change the value of x.
Regards,
Martin
OK,
29 matches
Mail list logo
