On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote:
Author: andrew.kuchling
Date: Thu Nov 9 14:51:14 2006
New Revision: 52692
[Patch #1514544 by David Watson] use fsync() to ensure data is really on disk
Should I backport this change to 2.5.1? Con: The patch adds two new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 9, 2006, at 9:01 AM, A.M. Kuchling wrote:
Should I backport this change to 2.5.1? Con: The patch adds two new
internal functions, _sync_flush() and _sync_close(), so it's an
internal API change. Pro: it's a patch that should reduce
Anthony So we'd now have 3 places to update when things change
Anthony (setup.py, PCbuild area, SCons)?
Four. You forgot Modules/Setup...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
On Thu Nov 9 07:45:30 CET 2006, Anthony Baxter wrote:
On Thursday 09 November 2006 16:30, Martin v. Löwis wrote:
Patch #841454 takes a stab at cross-compilation
(for MingW32 on a Linux system, in this case),
and proposes to use SCons instead of setup.py
to compile extension modules.
On Thu, Nov 09, 2006 at 04:42:48PM +0100, David Boddie wrote:
On Thu Nov 9 07:45:30 CET 2006, Anthony Baxter wrote:
On Thursday 09 November 2006 16:30, Martin v. Löwis wrote:
Patch #841454 takes a stab at cross-compilation
(for MingW32 on a Linux system, in this case),
and proposes
A.M. Kuchling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote:
Author: andrew.kuchling
Date: Thu Nov 9 14:51:14 2006
New Revision: 52692
[Patch #1514544 by David Watson] use fsync() to ensure data is really on
Anthony Baxter schrieb:
So we'd now have 3 places to update when things change (setup.py, PCbuild
area, SCons)? How does this deal with the problems that autoconf has with
cross-compilation? It would seem to me that just fixing the extension module
building is a tiny part of the problem...
Martin In any case, the patch being contributed uses SCons. If people
Martin think this is unmaintainable, this is a reason to reject the
Martin patch.
Could SCons replace distutils?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Nov 09, 2006 at 01:15:15PM -0600, [EMAIL PROTECTED] wrote:
Martin In any case, the patch being contributed uses SCons. If people
Martin think this is unmaintainable, this is a reason to reject the
Martin patch.
Could SCons replace distutils?
If SCons replaced Distutils
Chris Lambacher schrieb:
I think a better question is what about Distutils hinders cross-compiler
scenarios and how to we fix those deficiencies?
It's primarily the lack of contributions. Somebody would have to define
a cross-compilation scenario (where use Cygwin on Linux is one that
might be
Could SCons replace distutils?
Chris If SCons replaced Distutils would SCons have to become part of
Chris Python? Is SCons ready for that? What do you do about the
Chris existing body 3rd party extensions that are already using
Chris Distutils?
Sorry, my question was
David Boddie schrieb:
It seems that Martin's patch solves some problems I encountered more cleanly
(in certain respects) than the solutions I came up with. Here are some
issues I encountered (from memory):
Just let me point out that it is not my patch:
http://python.org/sf/841454
was
[EMAIL PROTECTED] schrieb:
Someone (I don't know who) submitted a patch to use SCons for building
modules in cross-compilation contexts. Either the author tried to shoehorn
this into distutils and failed or never tried (maybe because using SCons for
such takss is much easier - who knows?). I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:
Martin In any case, the patch being contributed uses SCons. If
people
Martin think this is unmaintainable, this is a reason to
reject the
Martin patch.
Could SCons replace
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:
Martin In any case, the patch being contributed uses SCons. If
people
Martin think this is unmaintainable, this is a reason to
reject the
Martin
On Friday 10 November 2006 01:01, A.M. Kuchling wrote:
On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote:
Author: andrew.kuchling
Date: Thu Nov 9 14:51:14 2006
New Revision: 52692
[Patch #1514544 by David Watson] use fsync() to ensure data is really on
disk
Should I
On Fri, Nov 10, 2006 at 11:56:25AM +1100, Anthony Baxter wrote:
Looking at the patch, the functions are pretty clearly internal
implementation
details. I'm happy for it to go into release25-maint (particularly because
the consequences of the bug are so dire).
OK, I'll backport it; thanks!
On Friday 10 November 2006 13:45, A.M. Kuchling wrote:
OK, I'll backport it; thanks!
(It's not fixing a frequent data-loss problem -- the patch just
assures that when flush() or close() returns, data is more likely to
have been written to disk and be safe after a subsequent system
crash.)
It is not required. If you are careful, you can implement a pairing
heap with a structure combining a dictionary and list.
That's interesting. Can you give an overview of how you can do that? I
can't really picture it. You can support all the pairing heap
operations with the same complexity
Talin wrote:
/ I don't know how you define simple. In order to be able to have
// separate GILs you have to remove *all* sharing of objects between
// interpreters. And all other data structures, too. It would probably
// kill performance too, because currently obmalloc relies on the GIL.
/
20 matches
Mail list logo
