[Neal Norwitz]
> The windows buildbot slaves (cygwin too) are still having problems
> with the DLL being in use when we start compiling so the compile
> fails. clean.bat is not called afterwards based on the buildbot log.
> I don't know if clean fixes the problem. If it does, would this patch
> f
Back from vacation, just did an svn up and make, and...:
...
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes Parser/acceler.o
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser
The windows buildbot slaves (cygwin too) are still having problems
with the DLL being in use when we start compiling so the compile
fails. clean.bat is not called afterwards based on the buildbot log.
I don't know if clean fixes the problem. If it does, would this patch
fix the problem:
Index:
[Tim]
>> Because new-style classes create cycles that Py_Finalize() doesn't
>> clean up, it may make analysis easier to stick a PyGC_Collect() call
>> (or two! repeat until it returns 0) inside the loop now.
[Martin]
> I'm shy to do this: the comment in Py_Finalize suggests that things
> will bre
On 4/16/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Basically, from all the replies I have gotten has said that package
> > that were/are externally maintained either considers Python HEAD as
> > the current version or watches checkins and the bug tracker and thus
> >
Brett Cannon wrote:
> Basically, from all the replies I have gotten has said that package
> that were/are externally maintained either considers Python HEAD as
> the current version or watches checkins and the bug tracker and thus
> the PEP is really not needed. So unless some package steps forwar
On 4/8/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bugs on issues. This should
On 4/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> >make :
> >
>
> I don't like the position of the name being defined.
> It should be straight after the opening keyword, as
> with 'def' and 'class'.
I see where you're coming from, but the current ordering
On 4/16/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
test_threading_local is not entirely consistent, but it looks a lot more reliable on my box than on Neal's automated mails:test_threading_localbeginning 11 repetitions12345678901
...
test_threading_local leaked [34, 34, 34, 34, 34, 26, 2
On my box, the latest batch of refleak fixes seems to have fixed all but one of the leaky tests. test_threading_local still leaks, but it leaks rather consistently now (which is new.) I'm not able to make the other ones leak with any combination of '-u' or removing .pyc's beforehand or running long
On Sun, 16 Apr 2006, Guido van Rossum wrote:
> On 4/16/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>> Personally, my instinct is that having the whole traceback in a
>> doctest is at least as ugly.
You don't need the whole traceback -- e.g.:
"""
If a URL is supplied, it must have an authority
On 4/16/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> Personally, my instinct is that having the whole traceback in a
> doctest is at least as ugly.
Well, it depends on what you use doctest for. If you use it to write
unit tests, the try/except solution is fine, and perhaps preferable.
If you use i
On 4/16/06, John J Lee <[EMAIL PROTECTED]> wrote:
> OK, I suppose I should have asked "will 2.5's module traceback work with
> Python 2.4?". I guess the answer is something resembling "no", but of
> course (?) the question I'm really interested in is "how, without too much
> effort or ugliness, ca
On Sat, 15 Apr 2006, Tim Peters wrote:
[...]
>> Hmm, will 2.5's doctest work under Python 2.4? I guess that's not
>> guaranteed, since I don't see any comment in doctest.py implying it needs
>> to be compatible with old Pythons.
>
> doctest compatibility with 2.4 is neither a goal nor a non-goal f
Tim Peters wrote:
> Since we're spread across time zones, I think 24 hours is a good
> minimum.
Ok, done.
> If something is set to 12 hours now, doesn't look like it's
> working: when I wrote my msg, it showed (as I said) about 5 hours of
> history. Right now it shows only about 3 hrs, from Sa
15 matches
Mail list logo
