On Friday 06 January 2006 18:39, Martin v. Löwis wrote:
I would like to do this in buildbot, but I'm not sure how to
(i.e. wipe the build occasionally, but not every time).
For example, I could imagine completely cleaning the build
directory every time the build number % 10 == 0. Still, what
Martin v. Löwis [EMAIL PROTECTED] writes:
Currently, my buildbot isn't connected to IRC at all. If I ever
enable that aspect, I'll use allowForce=False again to disable
remotely invoking builds.
#python-dev on freenode is ready and waiting should you decide to
activate this :)
Cheers,
mwh
Example 1 (Python 2.x):
---
class Foo:
def __init__(self, x): # 1: Explicit 'self' argument
self.x = x # 2: 'self' must be used explicitly
def bar(self, a, b): # 3: There are three arguments...
print
[Martin v. Loewis wrote]
I would like to do this in buildbot, but I'm not sure how to
(i.e. wipe the build occasionally, but not every time).
For example, I could imagine completely cleaning the build directory
every time the build number % 10 == 0. Still, what the precise
buildbot
I just found that the intel compiler (icc 9.0)
also supports compiler warnings for portability
problems.
For the file
#include sys/types.h
int foo(size_t x)
{
return x;
}
it says (with -Wall)
a.c(3): remark #1418: external definition with no prior declaration
int foo(size_t x)
Nick Coghlan wrote:
Eliminate the need for explicit class and self
slots in class and instance methods by
implicitly providing those slots on all functions.
How many positional arguments does the function
have if I retrieve it from the class, rather than from
an instance?
To keep
Hi Alexander,
On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote:
There are three different peculiarity in Python 2.x
in respect of 'self' method argument:
Yuk! This has been discussed again and again already. *Please* move
this discussion to comp.lang.python.
A bientot,
Hello!
Ian Bicking wrote:
(As an aside directed at the original PEP, I think discussion of leaving
self out of expressions, e.g., .x for self.x, should be separate
from the rest of this PEP).
Yes, I'm fully agree.
Nick Coghlan wrote:
The main concern I have is with the answer to the
On 1/6/06, Armin Rigo [EMAIL PROTECTED] wrote:
On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote:
There are three different peculiarity in Python 2.x
in respect of 'self' method argument:
Yuk! This has been discussed again and again already. *Please* move
this
Trent Mick wrote:
(Still learning my buildbot mojo.) One idea would be to do what
Mozilla's Tinderbox does: they have one set of builds that are
incremental and one set that are full. Actually looking around on
tinderbox.mozilla.org I could only find incremental builds so I'm not
sure what
Anthony Baxter wrote:
At least with the way Twisted is set up, the buildbot also sits in an
IRC channel and sends updates there. It can also be controlled from
there. Is this worth doing? A 'force clean build' command could be
added...
The problem with irc-enabling (or web-enabling) such
Michael Hudson wrote:
#python-dev on freenode is ready and waiting should you decide to
activate this :)
Ok, I added him; his nick is py-bb. Commands include hello,
status, version. force is disabled.
Regards,
Martin
___
Python-Dev mailing list
To wipe out the build occassionally you could (presumably) add a
starting step to the Python 'builder' (in the build master.cfg) to
rm -rf $builddir
every, say, Sunday night.
Sure, that would be the idea. How to formulate it?
I think I'm part of the way there with the following.
Trent Mick wrote:
I think I'm part of the way there with the following. I've subclassed
the SVN source build step to add support for new source mode:
update_and_clobber_occassionally. Basically it (hackily) changes the
source type btwn update, which we usually want, and clobber, which
we
[Martin v. Loewis wrote]
Trent Mick wrote:
I think I'm part of the way there with the following. I've subclassed
the SVN source build step to add support for new source mode:
update_and_clobber_occassionally. Basically it (hackily) changes the
source type btwn update, which we usually
[I just noticed that I sent this mail to just Martin when I meant it
for the list. Sorry Martin!]
On 1/5/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
More precisely, the printf style of function calling, and varargs
functions. ISO C is pretty type safe, but with varargs functions,
you lose
On 1/6/06, Michael Urman [EMAIL PROTECTED] wrote:
I put together a non-parsing checker last month to help me feel more
secure after http://python.org/sf/1365916. It's awful code, but the
simple things are easy to change or extend. Fixing the false positives
and other misinterpretations is
On Saturday 07 January 2006 10:01, Martin v. Löwis wrote:
The problem with irc-enabling (or web-enabling) such things is that
there is a potential for abuse. Of course, in this case, we could
wait for the abuse to happen.
That would be my vote. Worst comes to worst, we lock it down to a list
Guido van Rossum wrote:
Yuk! This has been discussed again and again already. *Please* move
this discussion to comp.lang.python.
Yes please. This won't change.
Then simply reject the PEP and the discussion can be stopped on
comp.lang.python too. Or why do you think it should be discussed
19 matches
Mail list logo
