> Actually, I think it is slightly. IIUC, the AMD64 build currently assumes
> it can execute x86 executables in various places. To fix this, the build
> process for each of the platforms would be slightly different.
Why does that need fixing? The AMD64 build *can* execute x86 binaries,
whether
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 2, 2008, at 6:00 PM, Barry Warsaw wrote:
>
> This is a reminder that I am going to start building the next alpha
> releases for Python 2.6 and 3.0 now. Please, no checkins unless you
> get approval from me, and until you hear that the freez
On Wed, Apr 2, 2008 at 8:36 PM, <[EMAIL PROTECTED]> wrote:
> Ralf> anyone care to take a look at:
> Ralf> http://bugs.python.org/issue2014
> Ralf> It's about xmlrpclib not being able to send datetime objects with
> Ralf> dates before 1900.
>
> It's actually not xmlrpclib which has
Ralf> anyone care to take a look at:
Ralf> http://bugs.python.org/issue2014
Ralf> It's about xmlrpclib not being able to send datetime objects with
Ralf> dates before 1900.
It's actually not xmlrpclib which has the limitation, but
datetime.strftime(). That's a known limitation. H
> I think this is fine; we don't really have a notion of compiling for a
> native platform, nor is the build machine's architecture factored into
> the equation.
Actually, I think it is slightly. IIUC, the AMD64 build currently assumes
it can execute x86 executables in various places. To fix thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a reminder that I am going to start building the next alpha
releases for Python 2.6 and 3.0 now. Please, no checkins unless you
get approval from me, and until you hear that the freeze is lifted.
I am now on freenode #python-dev, IM, and
Martin v. Löwis wrote:
>> Is using a fixed TESTFN just an old approach that predates the existence
>> of a robust tempfile module in the standard library?
>
> No. I believe the rationale for TESTFN is to provide a fixed name,
> precisely so that the test suite doesn't leave tons of garbage around
On Wed, Apr 2, 2008 at 7:16 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Christian Heimes [mailto:[EMAIL PROTECTED]:
> > Trent Nelson schrieb:
> > > I think holding a developer accountable for merging or blocking to
> > py3k when they commit to trunk is a great idea. Who better to pass
> > judge
On Wed, Apr 2, 2008 at 10:12 PM, Pree Raj <[EMAIL PROTECTED]> wrote:
> Hi,
> I have an application that used python on linux.
> I want to port it to run on ThreadX.
> Can you tell me if this can be possible.
> If yes, how can I get started.
I managed to get Python to work under eCos, which is also
Hi,
I have an application that used python on linux.
I want to port it to run on ThreadX.
Can you tell me if this can be possible.
If yes, how can I get started.
Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Trent Nelson wrote:
>>> That'll kill the first python_d.exe instance it finds matching the
>>> given path; given that our buildbots run trunk/release25-maint/py3k
>>> in parallel
>> That's actually not a given: we currently *don't* run multiple builds
>> simultaneously on the same slave.
>
> I tho
> > That'll kill the first python_d.exe instance it finds matching the
> > given path; given that our buildbots run trunk/release25-maint/py3k
> > in parallel
>
> That's actually not a given: we currently *don't* run multiple builds
> simultaneously on the same slave.
I thought the slave lock only
> Personally, I've never really understood the purpose of
> test_support.TESTFN. Whenever I've needed a temporary file for a test, I
> just use the tempfile module (e.g. test_cmd_line_script, test_runpy).
> Tests using that module don't care if the old files take 'a while' to
> get deleted on W
On Wed, Apr 2, 2008 at 3:17 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Guido van Rossum python.org> writes:
> > Your solution (a counter) seems fine except I think perhaps the
> > close() call should not raise IOError -- instead, it should set a flag
> > so that the thread that makes the
> That'll kill the first python_d.exe instance it finds matching the
> given path; given that our buildbots run trunk/release25-maint/py3k
> in parallel
That's actually not a given: we currently *don't* run multiple builds
simultaneously on the same slave.
> Unless anyone advises otherwise, I'll
Looking into some of the recent Windows buildbot failures, I see things like
this:
sqlite3 : error PRJ0008 : Could not delete file
'c:\buildbot\trunk.heller-windows-amd64\build\PCbuild\amd64\sqlite3_d.dll'.
build-amd64.bat doesn't go through the kill_python.c hoopla, so I figure the
above erro
Christian Heimes [mailto:[EMAIL PROTECTED]:
> Trent Nelson schrieb:
> > I think holding a developer accountable for merging or blocking to
> py3k when they commit to trunk is a great idea. Who better to pass
> judgement on such an activity than the person closest to it?
>
> Blocking a revision mak
On Wed, Apr 2, 2008 at 11:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis schrieb:
> > Can you please explain why this is an important problem?
> > Dates before 1900 have all passed long ago, so they shouldn't
> > occur that often in real applications.
>
In the application wh
Guido van Rossum python.org> writes:
> Your solution (a counter) seems fine except I think perhaps the
> close() call should not raise IOError -- instead, it should set a flag
> so that the thread that makes the counter go to zero can close the
> thread (after all the file got closed while it was
Tim Golden wrote:
> Gregory P. Smith wrote:
>> On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>>
>>> Tim Golden wrote:
>
>>>
>>> import os, sys
>>> import win32file
>>>
>>> FILENAME = "test"
>>>
>>> def rename_and_remove (filename):
>>> os.rename (filename, filename + ".d
Martin v. Löwis schrieb:
> Can you please explain why this is an important problem?
> Dates before 1900 have all passed long ago, so they shouldn't
> occur that often in real applications.
Does xmlrpc support dates for 1900? For historic dates the Julian Day
Number family (MJD or JDN) or Rata Die
Nick Coghlan wrote:
> Tim Golden wrote:
>> I admit: this did occur to me on the train this am. While I
>> try to think of a robust way to handle this, other people have
>> proposed variations on pid-based / tempdir based filenames instead
>> of the same name for each test. In principle this sounds
Tim Golden wrote:
> I admit: this did occur to me on the train this am. While I
> try to think of a robust way to handle this, other people have
> proposed variations on pid-based / tempdir based filenames instead
> of the same name for each test. In principle this sounds good to me,
> but I'm not
On Wed, Apr 2, 2008 at 9:58 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> > > In the py3k branch I've assigned the audio resource to the winsound
> > > tests. Only regrtest.py -uall or -uaudio runs the winsound test.
> > Reason:
> > > the test sound was freaking out my poor cat. :/
> >
> > I f
Trent Nelson schrieb:
> I think holding a developer accountable for merging or blocking to py3k when
> they commit to trunk is a great idea. Who better to pass judgement on such
> an activity than the person closest to it?
Blocking a revision makes my job as The Merger easier.
I'm not so sure
Gregory P. Smith wrote:
> On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>
>> Tim Golden wrote:
>>
>> import os, sys
>> import win32file
>>
>> FILENAME = "test"
>>
>> def rename_and_remove (filename):
>> os.rename (filename, filename + ".deleted")
>> os.remove (filenam
> > In the py3k branch I've assigned the audio resource to the winsound
> > tests. Only regrtest.py -uall or -uaudio runs the winsound test.
> Reason:
> > the test sound was freaking out my poor cat. :/
>
> I feel with your cat ;-).
> This would not help on the buildbot since it runs 'rt.bat -d -q
> Further, I
> assert that there are a greater number of build tools which do not support
> cross-compilation, but will build natively on x64 and expect 'PCBuild'
> to have libraries they can link with to create an x64 binary.
I'm with Martin on this one as well I think. If I understand correctly
> > Yes, that's all I meant: make it the committer's job
> > to merge or block as appropriate. I just wasn't sure if
> > there was some reason that this would be difficult or
> > undesirable.
>
> Ah, yes. It is indeed difficult or undesirable, or was
> so in the past: Some committers don't care (
> def rename_and_remove (filename):
> os.rename (filename, filename + ".deleted")
> os.remove (filename + ".deleted")
> Isn't this still going to run into problems when the rename
> fails because the earlier tests remove still left the .deleted
> file around due to some other running desktop se
30 matches
Mail list logo
