Martin v. Löwis wrote:
http://bugs.python.org/issue3026 comes to mind.
And I would rather use a little bit different wording: The ones
truncating size_t/ssize_t do matter, unless you know in advance that
you will always deal with data lesser than 2GiB.
I thought Nick's comment was in the cont
> http://bugs.python.org/issue3026 comes to mind.
>
> And I would rather use a little bit different wording: The ones
> truncating size_t/ssize_t do matter, unless you know in advance that
> you will always deal with data lesser than 2GiB.
I thought Nick's comment was in the context of the build
On Sun, Jul 13, 2008 at 6:35 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>> The compilation step on this buildbot is failing because it can't delete
>> or overwrite any of the Python DLLs [1]. Is there any way to fix this
>> remotely, or at least to tell why kill_python i
Martin v. Löwis wrote:
Nick Coghlan wrote:
The number of 64-bit safeness
warnings being emitted by the current trunk is also fairly worrying)
Do you have a specific one in mind? The ones truncating size_t/ssize_t
should only matter when you actually do have data larger than 2GiB.
Nothing spe
Nick Coghlan wrote:
> The compilation step on this buildbot is failing because it can't delete
> or overwrite any of the Python DLLs [1]. Is there any way to fix this
> remotely, or at least to tell why kill_python isn't doing the trick?
That is in the log:
TerminateProcess failed: 5
where 5 is
The compilation step on this buildbot is failing because it can't delete
or overwrite any of the Python DLLs [1]. Is there any way to fix this
remotely, or at least to tell why kill_python isn't doing the trick?
(Going back a bit further, it looks like test_multiprocessing is the
culprit as th
