On Thu, 30 Dec 2010 14:42:48 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > We merge bug fixes to 2.7 on a routine basis. It is the rule rather
> > than the exception, by a long shot.
>
> For bugfixes, of course it's routine. I understand that. My point
> was that the
R. David Murray writes:
> We merge bug fixes to 2.7 on a routine basis. It is the rule rather
> than the exception, by a long shot.
For bugfixes, of course it's routine. I understand that. My point
was that the case Amaury fears, where the (new) VCS makes things
harder than patching or porti
On Dec 29, 2010, at 12:49 PM, Martin v. Löwis wrote:
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's understanding is correct,
and
the test is creating more than supported.
Hmm. The tests do the absolute minimum stuff that exerci
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
calls.
More numbers (on Linux):
- Queue:
On Dec 29, 2010, at 5:46 PM, Nick Coghlan wrote:
> On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou wrote:
>> On Wed, 29 Dec 2010 23:24:32 +0100
>> "Martin v. Löwis" wrote:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now, but making a migration
On 12/29/2010 5:44 PM, David Bolen wrote:
Or, I'll make the same offer I think I made in the multiprocessing
case, which is I can build a kernel on the buildbot with a higher
limit, if that's needed just to ensure test completion. Yes, it would
also mean that users would need to do the same (or
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
> calls.
More numbers (on Linux):
- Queue: 3 SemLock
- Condition: 4 SemLock
- Event: 5 SemL
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou wrote:
> On Wed, 29 Dec 2010 23:24:32 +0100
> "Martin v. Löwis" wrote:
>> > I don't have a good suggestion (or a computer with a keyboard
>> > anywhere near me) right now, but making a migration/fallback to SYSV
>> > style semaphores a release block
"Martin v. Löwis" writes:
>> I don't have a good suggestion (or a computer with a keyboard
>> anywhere near me) right now, but making a migration/fallback to SYSV
>> style semaphores a release blocker seems like a mistake to me.
>
> And indeed, I don't propose to make that a release blocker. Inst
On Wed, 29 Dec 2010 23:24:32 +0100
"Martin v. Löwis" wrote:
> > I don't have a good suggestion (or a computer with a keyboard
> > anywhere near me) right now, but making a migration/fallback to SYSV
> > style semaphores a release blocker seems like a mistake to me.
>
> And indeed, I don't propose
On Dec 29, 2010, at 5:24 PM, Martin v. Löwis wrote:
>> I don't have a good suggestion (or a computer with a keyboard
>> anywhere near me) right now, but making a migration/fallback to SYSV
>> style semaphores a release blocker seems like a mistake to me.
>
> And indeed, I don't propose to make t
> I don't have a good suggestion (or a computer with a keyboard
> anywhere near me) right now, but making a migration/fallback to SYSV
> style semaphores a release blocker seems like a mistake to me.
And indeed, I don't propose to make that a release blocker. Instead,
I propose to disable support
On Dec 29, 2010, at 4:54 PM, "Martin v. Löwis" wrote:
> Am 29.12.2010 22:34, schrieb Jesse Noller:
>>
>>
>> On Dec 29, 2010, at 3:49 PM, "Martin v. Löwis" wrote:
>>
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's unders
Am 29.12.2010 22:34, schrieb Jesse Noller:
>
>
> On Dec 29, 2010, at 3:49 PM, "Martin v. Löwis" wrote:
>
>>> If the functionality is not supported then users get an import error
>>> (within multiprocessing). However, RDM's understanding is correct, and
>>> the test is creating more than support
On Dec 29, 2010, at 3:49 PM, "Martin v. Löwis" wrote:
>> If the functionality is not supported then users get an import error
>> (within multiprocessing). However, RDM's understanding is correct, and
>> the test is creating more than supported.
>
> Hmm. The tests do the absolute minimum stuff
> If the functionality is not supported then users get an import error
> (within multiprocessing). However, RDM's understanding is correct, and
> the test is creating more than supported.
Hmm. The tests do the absolute minimum stuff that exercises the code;
doing anything less, and they would be u
>>> The multiprocessing test suite already skips the tests which use the
>>> (broken) functionality on BSD correctly. This logic needs to be added
>>> to the concurrent.futures library.
>> Also, what specific test are you referring to?
Can you kindly point me to the test that skips if broken funct
>> If you can make the above change, the question then is what API
>> multiprocessing semaphores should be built upon. It seems that you
>> are saying that they should use SysV IPC, and only fall back to
>> POSIX IPC if SysV IPC doesn't work/exist (are there any platforms
>> where this would be
Le mercredi 29 décembre 2010 à 21:04 +0100, Antoine Pitrou a écrit :
> Doesn't it suggest a possible resource leak somewhere?
I already checked that: all locks are destroyed correctly on each test.
- test_all_completed_some_already_completed() uses 51 SemLock objects
- test_first_completed() us
On Wed, Dec 29, 2010 at 1:34 PM, "Martin v. Löwis" wrote:
> Am 29.12.2010 18:54, schrieb Jesse Noller:
>> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis"
>> wrote:
> I would like to know if it should be considered as a release blocker.
> Georg Brandl said yes on IRC.
Under
On 12/29/2010 2:53 PM, Benjamin Peterson wrote:
Type "help", "copyright", "credits" or "license" for more information.
compile("print(999)\r\n", "blah", "exec")
at 0xb353e8, file "blah", line 1>
I made a mistake in testing. Issue closed. Sorry for the noise.
--
Terry Jan Reedy
__
On Wed, 29 Dec 2010 14:14:03 -0500
"R. David Murray" wrote:
> On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller wrote:
> > The concurrent.futures tests should (like the multiprocessing test
> > suite) detect the lack of support and skip the tests on the broken
> > platforms. I'm sort of surprised
On 12/29/2010 2:31 PM, Terry Reedy wrote:
In python-list thread "Does Python 3.1 accept \r\n in compile()?"
jmfauth notes that
compile('print(999)\r\n', '', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.
I started to respond that this is part of Py3
2010/12/29 Terry Reedy :
> In python-list thread "Does Python 3.1 accept \r\n in compile()?"
> jmfauth notes that
> compile('print(999)\r\n', '', 'exec')
> works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
> SyntaxError.
>
> I started to respond that this is part of Py3 cleanu
On Dec 29, 2010, at 10:43 AM, Martin v. Löwis wrote:
>> Hi all, What Victor says above is correct, although I wasn't aware
>> that POSIX IPC under FreeBSD 7.2 was still having problems. Prior to
>> 7.2 it was broken but 7.2 worked OK in my limited testing. In any
>> case, the sysv_ipc module is m
On Dec 29, 2010, at 2:14 PM, R. David Murray wrote:
> On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller wrote:
>> The concurrent.futures tests should (like the multiprocessing test
>> suite) detect the lack of support and skip the tests on the broken
>> platforms. I'm sort of surprised FreeBSD su
In python-list thread "Does Python 3.1 accept \r\n in compile()?"
jmfauth notes that
compile('print(999)\r\n', '', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.
I started to respond that this is part of Py3 cleanup with newlines
converted on input a
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller wrote:
> The concurrent.futures tests should (like the multiprocessing test
> suite) detect the lack of support and skip the tests on the broken
> platforms. I'm sort of surprised FreeBSD support is still broken in
> this way though (echoed by Phili
Am 29.12.2010 18:54, schrieb Jesse Noller:
> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis"
> wrote:
I would like to know if it should be considered as a release blocker.
Georg Brandl said yes on IRC.
>>>
>>> Under the condition that it is within reason to fix it before the
>>> rel
On Wed, Dec 29, 2010 at 8:17 AM, Victor Stinner
wrote:
> Hi,
>
> FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
> a concurrent.futures failure. The problem is that
> test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
> whereas POSIX semaphores support i
On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis" wrote:
>>> I would like to know if it should be considered as a release blocker.
>>> Georg Brandl said yes on IRC.
>>
>> Under the condition that it is within reason to fix it before the
>> release.
>
> What *should* be possible is to disable bui
> Hi all, What Victor says above is correct, although I wasn't aware
> that POSIX IPC under FreeBSD 7.2 was still having problems. Prior to
> 7.2 it was broken but 7.2 worked OK in my limited testing. In any
> case, the sysv_ipc module is mine and it's mature and you're welcome
> to pillage it in w
>> I would like to know if it should be considered as a release blocker.
>> Georg Brandl said yes on IRC.
>
> Under the condition that it is within reason to fix it before the
> release.
What *should* be possible is to disable building
SemLock/multiprocessing.synchronize on FreeBSD. As a conseque
On Wed, 29 Dec 2010 23:12:28 +0900, "Stephen J. Turnbull"
wrote:
> worked for me the one time I tried it, IIRC. Now I use patch queues,
> and avoid cherry-picking as much as possible. (Avoiding cherry-pick
> is not going to be possible for 3.x <-> 2.x porting, of course, but in
> many cases the
On Dec 29, 2010, at 8:17 AM, Victor Stinner wrote:
> Hi,
>
> FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
> a concurrent.futures failure. The problem is that
> test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
> whereas POSIX semaphores support in
2010/12/29 Georg Brandl :
>>> A change can of course also be transplanted after the fact. It requires
>>> another
>>> merge, but usually a trivial one.
>>
>> No, it's not trivial with hg: this is the very subject of the thread!
>
> I don't understand: if you make the same change in two branches,
Am 29.12.2010 14:17, schrieb Victor Stinner:
> Hi,
>
> FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
> a concurrent.futures failure. The problem is that
> test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
> whereas POSIX semaphores support in FreeBSD
Am 29.12.2010 15:17, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl :
You need to think about which category your change is
right now too, when deciding what to backport/svnmerge.
>>>
>>> No, today this decision can take place after the development,
>>> some tickets got reopened
2010/12/29 David Cournapeau :
> On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
> wrote:
>> 2010/12/29 David Cournapeau
>>>
>>> The easiest way I found to emulate git cherry-pick (which does exactly
>>> what you want) with hg is to use import/export commands:
>>> http://mercurial.selenic.co
2010/12/29 Georg Brandl :
>>> You need to think about which category your change is
>>> right now too, when deciding what to backport/svnmerge.
>>
>> No, today this decision can take place after the development,
>> some tickets got reopened because a backport was needed.
>
> A change can of course
Amaury Forgeot d'Arc writes:
> Which precise steps do you take [to cherrypick with export/import]?
hg export -r $CHERRY .tmp.patch
xemacs .tmp.patch
;; Move to end of log message, type "Cherry-picked from: ", then
;; C-u M-! hg id -i -r $CHERRY RET C-x C-s C-x C-c>
hg import .tmp.patch
worked f
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
wrote:
> 2010/12/29 David Cournapeau
>>
>> The easiest way I found to emulate git cherry-pick (which does exactly
>> what you want) with hg is to use import/export commands:
>> http://mercurial.selenic.com/wiki/CommunicatingChanges
>>
>> It is
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
___
Python-De
Hi,
FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
a concurrent.futures failure. The problem is that
test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
whereas POSIX semaphores support in FreeBSD is recent and limited. We
have to use SysV semaphores (ft
Am 29.12.2010 11:09, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl :
>>> What worries me more is the requirement to find the correct branch before I
>>> can
>>> even edit the file. How would you, Georg, deal with doc patches
>>> (typos, bad markup)?
>>
>> Finding the correct branch is no
2010/12/29 Georg Brandl :
>> What worries me more is the requirement to find the correct branch before I
>> can
>> even edit the file. How would you, Georg, deal with doc patches
>> (typos, bad markup)?
>
> Finding the correct branch is not really hard. Bugfixes go to maintenance,
> features to t
Am 29.12.2010 10:53, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl
>>
>> Am 29.12.2010 09:02, schrieb Amaury Forgeot d'Arc:
>>
>> > - even if there was one, there is the problem of changes specifically made
>> > for 2.7
>> > that make no sense in py3k. You'd have to perform a "dummy mer
On Wed, Dec 29, 2010 at 10:53, Amaury Forgeot d'Arc wrote:
> And http://hg.python.org/cpython/ probably needs an initial "dummy merge"
> on every branch.
Yes, the present delays are all about getting that right.
Cheers,
Dirkjan
___
Python-Dev mailing
2010/12/29 Georg Brandl
>
> Am 29.12.2010 09:02, schrieb Amaury Forgeot d'Arc:
>
> > - even if there was one, there is the problem of changes specifically made
> > for 2.7
> > that make no sense in py3k. You'd have to perform a "dummy merge" to py3k
> > which has the disadvantage of cluttering th
Am 29.12.2010 09:02, schrieb Amaury Forgeot d'Arc:
> I've read all this, and this method does not work, for several reasons:
>
> - py3k / 2.7 / 3.1 cannot be ordered, there is no "earliest possible parent"..
> we usually consider py3k as a child of both 2.7 and 3.1, and there is no
> common
> pa
2010/12/29 David Cournapeau
> The easiest way I found to emulate git cherry-pick (which does exactly
> what you want) with hg is to use import/export commands:
> http://mercurial.selenic.com/wiki/CommunicatingChanges
>
> It is indeed quite a pain to use in my experience, because you cannot
> easi
Am 29.12.2010 01:13, schrieb Amaury Forgeot d'Arc:
> Hello,
>
> The PyPy project recently switched from svn to mercurial. Since this day I
> have some
> difficulties to perform simple tasks, and my questions did not receive
> satisfying answers.
>
> I was sure the Python project would have the s
52 matches
Mail list logo
