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 same
2010/12/29 David Cournapeau courn...@gmail.com
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
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
parent.
2010/12/29 Georg Brandl g.bra...@gmx.net
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
On Wed, Dec 29, 2010 at 10:53, Amaury Forgeot d'Arc amaur...@gmail.com 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
___
Am 29.12.2010 10:53, schrieb Amaury Forgeot d'Arc:
2010/12/29 Georg Brandl g.bra...@gmx.net
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
2010/12/29 Georg Brandl g.bra...@gmx.net:
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,
Am 29.12.2010 11:09, schrieb Amaury Forgeot d'Arc:
2010/12/29 Georg Brandl g.bra...@gmx.net:
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
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
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-Dev
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2010/12/29 David Cournapeau courn...@gmail.com
The easiest way I found to emulate git cherry-pick (which does exactly
what you want) with hg is to use import/export commands:
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 for
2010/12/29 Georg Brandl g.bra...@gmx.net:
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
2010/12/29 David Cournapeau courn...@gmail.com:
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2010/12/29 David Cournapeau courn...@gmail.com
The easiest way I found to emulate git cherry-pick (which does exactly
what you want) with hg is to use import/export
Am 29.12.2010 15:17, schrieb Amaury Forgeot d'Arc:
2010/12/29 Georg Brandl g.bra...@gmx.net:
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
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 is
2010/12/29 Georg Brandl g.bra...@gmx.net:
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
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
On Wed, 29 Dec 2010 23:12:28 +0900, Stephen J. Turnbull step...@xemacs.org
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
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 consequence,
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 whole
On Wed, Dec 29, 2010 at 10:28 AM, Martin v. Löwis mar...@v.loewis.de 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
On Wed, Dec 29, 2010 at 8:17 AM, Victor Stinner
victor.stin...@haypocalc.com 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
Am 29.12.2010 18:54, schrieb Jesse Noller:
On Wed, Dec 29, 2010 at 10:28 AM, Martin v. Löwis mar...@v.loewis.de
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
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller jnol...@gmail.com 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
In python-list thread Does Python 3.1 accept \r\n in compile()?
jmfauth notes that
compile('print(999)\r\n', 'in', '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
On Dec 29, 2010, at 2:14 PM, R. David Murray wrote:
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller jnol...@gmail.com 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 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 mine and
2010/12/29 Terry Reedy tjre...@udel.edu:
In python-list thread Does Python 3.1 accept \r\n in compile()?
jmfauth notes that
compile('print(999)\r\n', 'in', '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
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', 'in', '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
On Wed, 29 Dec 2010 14:14:03 -0500
R. David Murray rdmur...@bitdance.com wrote:
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller jnol...@gmail.com wrote:
The concurrent.futures tests should (like the multiprocessing test
suite) detect the lack of support and skip the tests on the broken
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)
code objectmodule at 0xb353e8, file blah, line 1
I made a mistake in testing. Issue closed. Sorry for the noise.
--
Terry Jan Reedy
On Wed, Dec 29, 2010 at 1:34 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 29.12.2010 18:54, schrieb Jesse Noller:
On Wed, Dec 29, 2010 at 10:28 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
I would like to know if it should be considered as a release blocker.
Georg Brandl said yes on
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()
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 the
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 functionality
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
On Dec 29, 2010, at 3:49 PM, Martin v. Löwis mar...@v.loewis.de 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
Am 29.12.2010 22:34, schrieb Jesse Noller:
On Dec 29, 2010, at 3:49 PM, Martin v. Löwis mar...@v.loewis.de 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
On Dec 29, 2010, at 4:54 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 29.12.2010 22:34, schrieb Jesse Noller:
On Dec 29, 2010, at 3:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If the functionality is not supported then users get an import error
(within multiprocessing).
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 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 that a
On Wed, 29 Dec 2010 23:24:32 +0100
Martin v. Löwis mar...@v.loewis.de 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
Martin v. Löwis mar...@v.loewis.de 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
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 29 Dec 2010 23:24:32 +0100
Martin v. Löwis mar...@v.loewis.de 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
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 SemLock
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
On Dec 29, 2010, at 5:46 PM, Nick Coghlan wrote:
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 29 Dec 2010 23:24:32 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now,
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: 3
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
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
On Thu, 30 Dec 2010 14:42:48 +0900, Stephen J. Turnbull step...@xemacs.org
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
52 matches
Mail list logo
