2010/12/29 "Martin v. Löwis"
> 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, but
2010/12/28 Lukas Lueg
> 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)
> 6 LOAD_CONST
"Martin v. Löwis" 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 opposed to need
2010/12/30 Terry Reedy :
> 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
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,
plea
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
> 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,
_POSIX_SE
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, m
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 unde
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 n
> 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 m
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 traditi
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
> maintena
On Thu, 30 Dec 2010 12:36:47 -0800
Ethan Furman 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 should
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
w
Le jeudi 30 décembre 2010 à 14:24 -0600, Benjamin Peterson a écrit :
> 2010/12/30 Antoine Pitrou :
> > On Thu, 30 Dec 2010 20:57:11 +0100
> > Éric Araujo wrote:
> >> Hi,
> >>
> >> One thing confuses me in this thread: Do the problems come from merging
> >> across different versions (i.e. different
2010/12/30 Antoine Pitrou :
> On Thu, 30 Dec 2010 20:57:11 +0100
> Éric Araujo 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 peo
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo 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
> a merge tool
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 S
On Fri, 31 Dec 2010 02:54:26 +0900, "Stephen J. Turnbull"
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.
> For cherypicki
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 t
> 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 t
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 tra
> 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 execut
> > 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
Am 30.12.2010 16:40, schrieb Antoine Pitrou:
> On Thu, 30 Dec 2010 16:04:16 +0100
> Łukasz Langa 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 a
On Thu, 30 Dec 2010 16:04:16 +0100
Łukasz Langa 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
> work.
I
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
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
29 matches
Mail list logo
