Fredrik Lundh wrote:
a dynamic registration approach would be even better, with a single entry point
used to register all methods and hooks your C extension has implemented, and
code on the other side that builds a properly initialized type descriptor from that
set, using fallback functions
Grig Gheorghiu schrieb:
> OK, I deleted the checkout directory on one of my buidslaves and
> re-ran the build steps. The tests passed. So my conclusion is that a
> full rebuild is needed for the tests to pass after the last checkins
> (which included files such as configure and configure.in).
Inde
Brian Warner schrieb:
> To be precise, you have have as many build procedures per slave as you like,
> but if the procedure depends upon running on a particular platform, then it
> is unlikely that a single slave can accomodate multiple platforms.
Ah, right, I can have multiple builders per slave.
On 10/19/06, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
On 10/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>>> On 10/19/06, Grig Gheorghiu <[EMAIL PROTECTED]
> wrote:> > On 10/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> > >> > > Possibly. If you look at the reason those tests failed it is beca
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> But I agree that
>> getting regular builds running would be a good thing. An x64 box
>> would be ideal to build both the x86 and x64 versions on. A single
>> bot can manage many platforms, right?
>
> A single machine, and a single buildbot install
On 10/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>
> On 10/19/06, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
> > On 10/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > >
> > > Possibly. If you look at the reason those tests failed it is because
> > > time.strftime is missing for some odd re
On 10/19/06, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
On 10/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>> Possibly. If you look at the reason those tests failed it is because> time.strftime is missing for some odd reason. But none of recent checkins
> seem to have anything to do with the 'tim
On 10/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> Possibly. If you look at the reason those tests failed it is because
> time.strftime is missing for some odd reason. But none of recent checkins
> seem to have anything to do with the 'time' module, let alone with how
> methods are added to
On 10/19/06, Grig Gheorghiu <[EMAIL PROTECTED]
> wrote:
The latest trunk checkin caused almost all Pybots to fail when runningthe Python unit tests.273 tests OK.12 tests failed:test___all__ test_calendar test_capi test_datetime test_emailtest_email_renamed test_imaplib test_mailbox test_str
Larry Hastings wrote:Chetan Pandya wrote:> I don't have a patch build, since I didn't download the revision used
> by the patch.> However, I did look at values in the debugger and it looked like x in> your example above had a reference count of 2 or more within> string_concat even when there were n
2006/10/19, Raymond Hettinger <[EMAIL PROTECTED]>:
> My colleague got an odd result today that is reproducible on his build
> of Python (RedHat's distribution of Py2.4.2) but not any other builds
> ...
> >>> set(-194 * (1/100.0) for i in range(1))
> set([-19400.0, -193995904.0, -19
> I noticed that you used both "nondeterministic" and
> "reproducible" though.
LOL. The nondeterministic part is that the same calculation will give
different answers and there doesn't appear to be a pattern to which of
the several answers will occur. The reproducible part is that it
happens f
[Raymond Hettinger]
> My colleague got an odd result today that is reproducible on his build
> of Python (RedHat's distribution of Py2.4.2) but not any other builds
> I've checked (including an Ubuntu Py2.4.2 built with a later version of
> GCC). I hypothesized that this was a bug in the underlyin
Raymond Hettinger wrote:
> My colleague got an odd result today that is reproducible on his build
> of Python (RedHat's distribution of Py2.4.2) but not any other builds
> I've checked (including an Ubuntu Py2.4.2 built with a later version of
> GCC). I hypothesized that this was a bug in the unde
Raymond Hettinger schrieb:
> My colleague got an odd result today that is reproducible on his build
> of Python (RedHat's distribution of Py2.4.2) but not any other builds
> I've checked (including an Ubuntu Py2.4.2 built with a later version of
> GCC). I hypothesized that this was a bug in the un
The latest trunk checkin caused almost all Pybots to fail when running
the Python unit tests.
273 tests OK.
12 tests failed:
test___all__ test_calendar test_capi test_datetime test_email
test_email_renamed test_imaplib test_mailbox test_strftime
test_strptime test_time test_xmlrpc
Her
Raymond> My colleague got an odd result today that is reproducible on
Raymond> his build of Python (RedHat's distribution of Py2.4.2) but not
Raymond> any other builds I've checked (including an Ubuntu Py2.4.2
Raymond> built with a later version of GCC). I hypothesized that this
My colleague got an odd result today that is reproducible on his build
of Python (RedHat's distribution of Py2.4.2) but not any other builds
I've checked (including an Ubuntu Py2.4.2 built with a later version of
GCC). I hypothesized that this was a bug in the underlying GCC
libraries, but the mag
On 10/19/06, Paul Moore <[EMAIL PROTECTED]> wrote:
On 10/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:> Anyway, all of the above is open to disagreement or other opinions - if you> have them, let me know.
My only thought is that you've done a fantastic job pushing throughall the recent releases.
On 10/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Anyway, all of the above is open to disagreement or other opinions - if you
> have them, let me know.
My only thought is that you've done a fantastic job pushing through
all the recent releases.
Thanks!
Paul.
__
OK - 2.4.4 is done. With that, the release24-maint branch moves into dignified
old age, where we get to mostly ignore it, yay! Unless you really feel like
it, I don't think there's much point to making the effort to backport fixes
to this branch. Any future releases from that branch will be of t
Mike Klaas wrote:
> On 10/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[...]
> Shouldn't the thread state generally be the same anyway? (I seem to
> recall some gloomy warning against resuming generators in separate
> threads).
>
Is this an indication that generators aren't thread-safe?
regards
On behalf of the Python development team and the Python community,
I'm happy to announce the release of Python 2.4.4 (FINAL).
Python 2.4.4 is a bug-fix release. While Python 2.5 is the latest
version of Python, we're making this release for people who are
still running Python 2.4. This is the fina
23 matches
Mail list logo
