You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Sam Ruby <ru...@apache.org> on 2004/03/29 21:05:17 UTC
Speed of brutus
I see from http://brutus.apache.org/gump/public/
Elapsed Time : 1 hour 56 mins 20 secs
Putting it mildly, this doesn't look half bad. I presume that this
includes the time of cvs/svn checkouts? Are the logs of the cvs/svn
checkouts captured? This sometimes is helpful when trying to track down
why a build that worked yesterday failed today.
Note that this is only with one CPU and less than one gig of RAM.
Looking at the build times, it looks to me like gump 2.0 tries to do
parallel builds whenever possible?
And finally, a nit: I see useful information like the name of the java
command ("java") and the Operating System ("posix"), but I don't see the
values of System.getProperties which contains values such as:
java.vm.version=1.4.2_04-b05
java.vm.vendor=Sun Microsystems Inc.
os.arch=i386
os.name=Linux
Are these available someplace?
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
CVS failed for jdom was: Speed of brutus
Posted by Nick Chalko <ni...@chalko.com>.
Note this cvs error
http://brutus.apache.org/gump/public/jdom/gump_work/update_jdom.html
can't create temporary directory /tmp/cvs-serv17931 No space left on device
Sam Ruby wrote:
> I see from http://brutus.apache.org/gump/public/
>
> Elapsed Time : 1 hour 56 mins 20 secs
>
> Putting it mildly, this doesn't look half bad. I presume that this
> includes the time of cvs/svn checkouts? Are the logs of the cvs/svn
> checkouts captured? This sometimes is helpful when trying to track
> down why a build that worked yesterday failed today.
>
> Note that this is only with one CPU and less than one gig of RAM.
> Looking at the build times, it looks to me like gump 2.0 tries to do
> parallel builds whenever possible?
>
> And finally, a nit: I see useful information like the name of the java
> command ("java") and the Operating System ("posix"), but I don't see
> the values of System.getProperties which contains values such as:
>
> java.vm.version=1.4.2_04-b05
> java.vm.vendor=Sun Microsystems Inc.
> os.arch=i386
> os.name=Linux
>
> Are these available someplace?
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: System Info
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> These questions are not straightfoward.
True.
Stepping back, my intention was to to be careful to listen to what folks on
the list say today. I've been hacking away alone for far too long, and want
to ensure that I don't get too comfortable thinking I know what this
community wants/thinks. That said, I did fall into the trap of being too
close to my own view on the world, and hence applied spin I wasn't even
seeing.
> At the moment, Gump has a nearly hard dependency on the CVS head version
> of a Java project which can't be built by gump. And the completely
> optional dependency on a completely stable and completely free of
> dependencies "C" program brings up this discussion. As does the adding
> of some code which will optionally provide version information for java
> in the case where java happens to be installed.
Err, good point. I kinda overlooked that didn't I. ;-)
I guess I still have hope that w'll build forrest via Gump, and so can
bootstrap it.
Still, just for discussion --- it does seem like Forrest (something one has
to install) really grates on folks wanting to install/run Gump. Even the
smart Apache folks on this list seem to baulk at it, and I can understand
that. As such, much as I love what Forrest can do for us (with skins/SVGs,
etc) I do recognize that it might be too heavy for Gump & that Gump really
ought have no manual installation dependencies. I am game to work towards
getting HTML or XHTML or whatever outputs (via Cheetah) and make Forrest
optional.
Meaning, I apply the same logic to Forrest as I do the 'timeout' (when I
stop and think about Forrest).
> We each apparently place different weights on different attributes. All
> other things being equal, yes I would prefer a pure Python solution.
> When things aren't equal, I would tend to yeild first on the language
> before yielding on bootstrappability.
I think bootstrapability is a 'good thing', and since Gump is (eventually,
as some hope) intended to compile more than just Java, maybe languages ought
give first. [Am I reading you right on this? I think so.]
I wonder if we could (strive towards) separating any Java build login (env
vars, compiler commandlines, CLASSPATH?) out into separate classes defining
'Java Building', and allow a peer builder for C. We'd want 'timeout' early
on in the process, so we probably couldn't use ant to build it, but maybe we
can just detect/launch cc or something.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: System Info
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
> Folk,
>
> When both Stefano and Leo both misinterpret me, I realize I failed to
> communicate yet again. English truly ought not be counted as my first
> language (despite being born a Brit. ;-)
>
> You triggered off this:
>
>
>>As I'm sure you are aware ... there is a strong feeling on this list that
>
> no
>
>>Java pre-requisite ought exist, so Gump can be run in a 'clean'
>
> environment
>
>>w/o worrying about CLASSPATHs and such.
>
>
> But didn't seem to register this, which was part of the same paragraph.
>
>
>>(Might seem odd for a Java Builder,
>>but Gump may do more/other than Java one day). That said, you seem to have
>>cleverly worked around that. So long as Python Gump generates it, compiles
>>it, and runs it -- I can't see folks objecting.
>
>
> where (1) I agree it is odd [I was being polite] for a Java Builder not to
> want Java, but then explained it and (2) I agree that this worked around any
> objection. Heck, I never even said they were my objections, I was just
> trying to summarize what I understood from prior threads/comments on this
> list.
>
> So, for the record (to try to clear up any miscommunication):
>
> - I agreed from the start that this was a nice to have. I said that
> 'ant --debug' might display it, but that I didn't know how to get it
> directly without writing Java. (Seems others don't either.)
> - I didn't think this list (from comments I've heard supporting Python Gump)
> wanted to have to configure/install/environment a Java compiler, but they
> are happy for Python to auto-discover and use one [clearly].
> - I agreed that this solution is consistent with the purist (some might say
> bootstrap) approach, of starting with pure Python.
> - All in all, I agreed this was a good solution to the requirement, and
> fitting within what I understood as the philosophy.
>
> That all said, let's please clarify (because it came up again with C, I
> believe) and I don't want to be assuming that I understand the views of this
> community:
>
> - Do folks want a pure Python Gump, that one can download & run directly?
> [This solution investigates and locates tools in the environment and uses
> what it finds, even bootstrapping with those to build more of it's own
> tools.]
>
> - Or, are folks ok with Gump having other language components, and requiring
> a build prior to being able to run it. Any such build would need to be
> automated so we could deploy remote Gump agents. (Clearly this approach is
> achievable, traditional Gump did it, and clearly one could use ant in order
> to build Java, and perhaps C, etc.)
>
> I prefer the Python approach (even if I do get called a purist and not a
> pragmatist, this time. ;). That said, I could live with either.
These questions are not straightfoward.
At the moment, Gump has a nearly hard dependency on the CVS head version
of a Java project which can't be built by gump. And the completely
optional dependency on a completely stable and completely free of
dependencies "C" program brings up this discussion. As does the adding
of some code which will optionally provide version information for java
in the case where java happens to be installed.
We each apparently place different weights on different attributes. All
other things being equal, yes I would prefer a pure Python solution.
When things aren't equal, I would tend to yeild first on the language
before yielding on bootstrappability.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Bootstrapping Gump (was: Re: System Info)
Posted by Michael Davey <Mi...@coderage.org>.
Leo Simons wrote:
> being a pragmatist, if I can "apt-get install gump", that would be
> perfect, regardless of the dependencies. In case you don't know, apt
> could download all those dependencies before installing gump.
I know that Ant is supposed to be a Java build system but these days it
is so powerful that you could easily use it to download everything.
Then you would have a two stage bootstrap:
0a download Java if not available (probably already on the system)
0b set Java path (probably already set)
0c download Ant if not available (probably supplied with Java)
0d set Ant path (probably already set)
1 download bootstrap-gump.xml
2 type "ant -f bootstrap-gump.xml"
You could additionally provide a .jnlp file on the gump website that
would do 0c, 0d, 1 and 2 automatically for those that have Java WebStart
available.
I understand the rationale of not wanting to using non-Java to build
Java projects, but can't see any reason to avoid Java for the
installation process. After all, Java needs to be in the tin when we
come to build (until (fi*) Gump supports non-java builds) and the whole
purpose of Java is that it abstracts away other language and OS
differencies. The alternative would seem to be:
support seperate bootstraps for RedHat, Debian, SUSE, Solaris, MacOS
X, Windows and so on
write a bootstrap for Gump in python
write a python version of Ant (perhaps only supporting the tags we
need to use to bootstrap Gump)
--
Michael
[*1] fi - future tense "if" - is there a proper word for this?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: System Info
Posted by Leo Simons <ls...@jicarilla.org>.
Adam R. B. Jack wrote:
> When both Stefano and Leo both misinterpret me, I realize I failed to
> communicate yet again. English truly ought not be counted as my first
> language (despite being born a Brit. ;-)
you're too harsh on yourself dude :-D. I agreed with most of your post,
so I snipped it. Just wanting to have everyone aware of everyone's
"feelings" ;)
> - Do folks want a pure Python Gump, that one can download & run directly?
that would be nice. It doesn't itch though (I have a working gump, and I
can install it from scratch again in 1/2 hour).
> - Or, are folks ok with Gump having other language components, and requiring
> a build prior to being able to run it.
being a pragmatist, if I can "apt-get install gump", that would be
perfect, regardless of the dependencies. In case you don't know, apt
could download all those dependencies before installing gump.
That won't work on windows of course, but windows is not a concern of
mine (hey, you asked for opinions ;).
> I prefer the Python approach (even if I do get called a purist and not a
> pragmatist, this time. ;).
I prefer the python approach for pragmatic reasons :D
> That said, I could live with either.
me too.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: System Info (was: Speed of brutus)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Adam R. B. Jack [mailto:ajack@trysybase.com]
> Sent: Saturday, April 03, 2004 7:34 AM
> To: Gump code and data
> Subject: Re: System Info (was: Speed of brutus)
>
>
> Folk,
>
> When both Stefano and Leo both misinterpret me, I realize I failed to
> communicate yet again. English truly ought not be counted as my first
> language (despite being born a Brit. ;-)
>
> You triggered off this:
>
> > As I'm sure you are aware ... there is a strong feeling on this
> list that
> no
> > Java pre-requisite ought exist, so Gump can be run in a 'clean'
> environment
> > w/o worrying about CLASSPATHs and such.
>
> But didn't seem to register this, which was part of the same paragraph.
>
> > (Might seem odd for a Java Builder,
> > but Gump may do more/other than Java one day). That said, you
> seem to have
> > cleverly worked around that. So long as Python Gump generates
> it, compiles
> > it, and runs it -- I can't see folks objecting.
>
> where (1) I agree it is odd [I was being polite] for a Java Builder not to
> want Java, but then explained it and (2) I agree that this worked
> around any
> objection. Heck, I never even said they were my objections, I was just
> trying to summarize what I understood from prior threads/comments on this
> list.
>
> So, for the record (to try to clear up any miscommunication):
>
> - I agreed from the start that this was a nice to have. I said that
> 'ant --debug' might display it, but that I didn't know how to get it
> directly without writing Java. (Seems others don't either.)
> - I didn't think this list (from comments I've heard supporting
> Python Gump)
> wanted to have to configure/install/environment a Java compiler, but they
> are happy for Python to auto-discover and use one [clearly].
> - I agreed that this solution is consistent with the purist (some
> might say
> bootstrap) approach, of starting with pure Python.
> - All in all, I agreed this was a good solution to the requirement, and
> fitting within what I understood as the philosophy.
>
> That all said, let's please clarify (because it came up again with C, I
> believe) and I don't want to be assuming that I understand the
> views of this
> community:
>
> - Do folks want a pure Python Gump, that one can download & run directly?
> [This solution investigates and locates tools in the environment and uses
> what it finds, even bootstrapping with those to build more of it's own
> tools.]
>
> - Or, are folks ok with Gump having other language components,
> and requiring
> a build prior to being able to run it. Any such build would need to be
> automated so we could deploy remote Gump agents. (Clearly this approach is
> achievable, traditional Gump did it, and clearly one could use
> ant in order
> to build Java, and perhaps C, etc.)
>
> I prefer the Python approach (even if I do get called a purist and not a
> pragmatist, this time. ;). That said, I could live with either.
+1. To both of the above sentences. ;-)
--
Martin Cooper
>
> regards,
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: System Info (was: Speed of brutus)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Folk,
When both Stefano and Leo both misinterpret me, I realize I failed to
communicate yet again. English truly ought not be counted as my first
language (despite being born a Brit. ;-)
You triggered off this:
> As I'm sure you are aware ... there is a strong feeling on this list that
no
> Java pre-requisite ought exist, so Gump can be run in a 'clean'
environment
> w/o worrying about CLASSPATHs and such.
But didn't seem to register this, which was part of the same paragraph.
> (Might seem odd for a Java Builder,
> but Gump may do more/other than Java one day). That said, you seem to have
> cleverly worked around that. So long as Python Gump generates it, compiles
> it, and runs it -- I can't see folks objecting.
where (1) I agree it is odd [I was being polite] for a Java Builder not to
want Java, but then explained it and (2) I agree that this worked around any
objection. Heck, I never even said they were my objections, I was just
trying to summarize what I understood from prior threads/comments on this
list.
So, for the record (to try to clear up any miscommunication):
- I agreed from the start that this was a nice to have. I said that
'ant --debug' might display it, but that I didn't know how to get it
directly without writing Java. (Seems others don't either.)
- I didn't think this list (from comments I've heard supporting Python Gump)
wanted to have to configure/install/environment a Java compiler, but they
are happy for Python to auto-discover and use one [clearly].
- I agreed that this solution is consistent with the purist (some might say
bootstrap) approach, of starting with pure Python.
- All in all, I agreed this was a good solution to the requirement, and
fitting within what I understood as the philosophy.
That all said, let's please clarify (because it came up again with C, I
believe) and I don't want to be assuming that I understand the views of this
community:
- Do folks want a pure Python Gump, that one can download & run directly?
[This solution investigates and locates tools in the environment and uses
what it finds, even bootstrapping with those to build more of it's own
tools.]
- Or, are folks ok with Gump having other language components, and requiring
a build prior to being able to run it. Any such build would need to be
automated so we could deploy remote Gump agents. (Clearly this approach is
achievable, traditional Gump did it, and clearly one could use ant in order
to build Java, and perhaps C, etc.)
I prefer the Python approach (even if I do get called a purist and not a
pragmatist, this time. ;). That said, I could live with either.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
java prerequisite (Re: System Info)
Posted by Leo Simons <ls...@jicarilla.org>.
Adam R. B. Jack wrote:
>>What's wrong with writing some Java? ;-)
>
> As I'm sure you are aware ... there is a strong feeling on this list that no
> Java pre-requisite ought exist, so Gump can be run in a 'clean' environment
> w/o worrying about CLASSPATHs and such.
I don't see "have a jdk installed and its binary utilities on the PATH"
as a troubling prerequisite. Especially not if it is optional for
additional java-specific functionality. It's only fair you can't get
java debugging information unless you have java.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: System Info
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
>>>Hmm. No, not directly. If a project repeatedly fails Gump automatically
>>>turns on ant verbose and/or debug, and maybe this show those values. Is
>>>there a way to list these things (above) without writing some Java?
>>
>>What's wrong with writing some Java? ;-)
>>
>
>
> As I'm sure you are aware ... there is a strong feeling on this list that no
> Java pre-requisite ought exist, so Gump can be run in a 'clean' environment
> w/o worrying about CLASSPATHs and such.
Gump depends on java anyway for building java stuff, so finding out if
java is present and if so, what properties is has, it's a nice thing
because, in fact, you *do* need to know that anyway.
--
Stefano.
Re: System Info (was: Speed of brutus)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > Hmm. No, not directly. If a project repeatedly fails Gump automatically
> > turns on ant verbose and/or debug, and maybe this show those values. Is
> > there a way to list these things (above) without writing some Java?
>
> What's wrong with writing some Java? ;-)
>
As I'm sure you are aware ... there is a strong feeling on this list that no
Java pre-requisite ought exist, so Gump can be run in a 'clean' environment
w/o worrying about CLASSPATHs and such. (Might seem odd for a Java Builder,
but Gump may do more/other than Java one day). That said, you seem to have
cleverly worked around that. So long as Python Gump generates it, compiles
it, and runs it -- I can't see folks objecting.
It would (IMHO) be good if you added this code into GumpEnvironment in
gumpenv.py, and used some things like self.javaCommand (defaults to 'java',
but can be overwritten). If you do it after the check for java and javac,
it'd be best.
If you could manage to use checkExecutable (which adds the result/output to
the GumpEnvironment object as work, and hence shows up in documentation)
that would be good. Might I ask that you simply listProperties --- so we can
see all, not just these (important) few? You could get the output file from
the command, and parse that, if you are interested in having the values. [As
you know I like to start verbose and trim backwards, one never knows (it
seems) what information might be interesting.]
Just and FYI: We have a slight issue with 'tmp', not so much what you've
done as what exists. I'd like everything to run in $WORKSPACE/tmp, but some
things (like this, are pre-workspace) and dir.tmp is what we ought use.
[This is only an issue when we run multiple things in one install, which we
don't typically do, but it bugs me.]
BTW: Nice addition.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
System Info (was: Speed of brutus)
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
>
>>And finally, a nit: I see useful information like the name of the java
>>command ("java") and the Operating System ("posix"), but I don't see the
>>values of System.getProperties which contains values such as:
>>
>> java.vm.version=1.4.2_04-b05
>> java.vm.vendor=Sun Microsystems Inc.
>> os.arch=i386
>> os.name=Linux
>
> Hmm. No, not directly. If a project repeatedly fails Gump automatically
> turns on ant verbose and/or debug, and maybe this show those values. Is
> there a way to list these things (above) without writing some Java?
What's wrong with writing some Java? ;-)
import commands, os, re
TMP_DIR = '/home/rubys/tmp'
JAVA_SOURCE = TMP_DIR + '/sysprop.java'
properties = [
'java.vendor',
'java.version',
'os.name',
'os.arch',
'os.version'
]
source=open(JAVA_SOURCE,'w')
source.write("""
public class sysprop {
public static void main(String [] args) {
for (int i=0; i<args.length; i++) {
System.out.print(args[i]);
System.out.print(": ");
System.out.println(System.getProperty(args[i]));
}
}
}
""")
source.close()
os.system('javac ' + JAVA_SOURCE)
os.unlink(JAVA_SOURCE)
cmd='java -cp ' + TMP_DIR + ' sysprop ' + ' '.join(properties)
properties = dict(re.findall('(.*?): (.*)', commands.getoutput(cmd)))
os.unlink(JAVA_SOURCE.replace('.java','.class'))
for (key,value) in properties.items():
print key, "=>", value
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Speed of brutus
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Sam Ruby wrote:
> Antoine Lévy-Lambert wrote:
>
>>>
>> Hi Adam,
>>
>> I have noticed that some cvs update failed due to /tmp being full.
>> For instance jdom.
>> http://brutus.apache.org/gump/public/jdom/index.html
>
>
> I'm pretty sure that "can't create temporary directory /tmp/cvs-serv"
> is an indication that there is a problem on the cvs server end. I'll
> send a note to Jason and Brett to see what's up...
>
> - Sam Ruby
>
This is an even better catch Sam ! :-)
Cheers,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Speed of brutus
Posted by Sam Ruby <ru...@apache.org>.
Antoine Lévy-Lambert wrote:
>>
> Hi Adam,
>
> I have noticed that some cvs update failed due to /tmp being full.
> For instance jdom.
> http://brutus.apache.org/gump/public/jdom/index.html
I'm pretty sure that "can't create temporary directory /tmp/cvs-serv" is
an indication that there is a problem on the cvs server end. I'll send
a note to Jason and Brett to see what's up...
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Speed of brutus
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I have noticed that some cvs update failed due to /tmp being full.
> For instance jdom.
> http://brutus.apache.org/gump/public/jdom/index.html
Good catch Antoine.
BTW: I do like how the servers page helps us catch 'environment' issues,
especially when one stands out against the others.
http://brutus.apache.org/gump/public/jdom/index.html#Servers
Perhaps we need a page that does a 'diff' of the server.xml file, and
produces a "failed here but worked elsewhere". Not high priority though.
BTW: I'll re-instate the 'notesLog' page once we get a Forrest webapp. I'm
looking forward to that page for showing us all entities with "issues" --
annotations that are warning or error. I think that'll help us quickly find
problems that we overlook today.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Speed of brutus
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Adam R. B. Jack wrote:
>>I see from http://brutus.apache.org/gump/public/
>>
>>Elapsed Time : 1 hour 56 mins 20 secs
>>
>>
>
>I have to agree, I was very impressed with speed. For some reason a little
>less was built than on LSD, see these, but still -- it is very fast.
>
> http://lsd.student.utwente.nl/gump/#Project+Summary
> http://brutus.apache.org/gump/public/ndex.html#Project+Summary
>
>
>
Hi Adam,
I have noticed that some cvs update failed due to /tmp being full.
For instance jdom.
http://brutus.apache.org/gump/public/jdom/index.html
Cheers,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by Nick Chalko <ni...@chalko.com>.
Davanum Srinivas wrote:
>Should we run gump every 6 hours on brutus?
>
>-
>
I do not think we should do this until we are keeping copies of old
builds, so people have time to analyze before they change.
R,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by Nick Chalko <ni...@chalko.com>.
Sam Ruby wrote:
> Adam R. B. Jack wrote:
>
>>> Should we run gump every 6 hours on brutus?
>>
>>
>> Some thoughts I've had...
>>
>> Since we have dedicated cycles, why not do it as soon as the last one
>> stops?
>> What about doing N with --optimise (only build what has changed) and the
>> Nth+1 a full one?
>>
>> BTW: Have a separate 'check metadata' loop (that doesn't build just
>> checks)
>> might be nice for folks committing descriptor changes.
>>
>> I've not written the code (ok, I did, but I ripped it out -- it was
>> inside
>> the engine, not outside) but how about an external script that runs
>> gumpy.py
>> as above [which does CVS update of self in there]?
>
>
> My recommendation is that we first figure out how often we want to
> nag, and work backwards from that.
>
Nag on first failure, and then daily.
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
>>Should we run gump every 6 hours on brutus?
>
> Some thoughts I've had...
>
> Since we have dedicated cycles, why not do it as soon as the last one stops?
> What about doing N with --optimise (only build what has changed) and the
> Nth+1 a full one?
>
> BTW: Have a separate 'check metadata' loop (that doesn't build just checks)
> might be nice for folks committing descriptor changes.
>
> I've not written the code (ok, I did, but I ripped it out -- it was inside
> the engine, not outside) but how about an external script that runs gumpy.py
> as above [which does CVS update of self in there]?
My recommendation is that we first figure out how often we want to nag,
and work backwards from that.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: run gump 4 times a day (Re: Speed of brutus)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Should we run gump every 6 hours on brutus?
Some thoughts I've had...
Since we have dedicated cycles, why not do it as soon as the last one stops?
What about doing N with --optimise (only build what has changed) and the
Nth+1 a full one?
BTW: Have a separate 'check metadata' loop (that doesn't build just checks)
might be nice for folks committing descriptor changes.
I've not written the code (ok, I did, but I ripped it out -- it was inside
the engine, not outside) but how about an external script that runs gumpy.py
as above [which does CVS update of self in there]?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
run gump 4 times a day (Re: Speed of brutus)
Posted by Davanum Srinivas <di...@yahoo.com>.
Should we run gump every 6 hours on brutus?
-- dims
--- "Adam R. B. Jack" <aj...@trysybase.com> wrote:
>
> > I see from http://brutus.apache.org/gump/public/
> >
> > Elapsed Time : 1 hour 56 mins 20 secs
>
> I have to agree, I was very impressed with speed. For some reason a little
> less was built than on LSD, see these, but still -- it is very fast.
>
> http://lsd.student.utwente.nl/gump/#Project+Summary
> http://brutus.apache.org/gump/public/ndex.html#Project+Summary
>
> >
> > Putting it mildly, this doesn't look half bad. I presume that this
> > includes the time of cvs/svn checkouts?
>
> Yup, and the metadata load.
>
> > Are the logs of the cvs/svn
> > checkouts captured? This sometimes is helpful when trying to track down
> > why a build that worked yesterday failed today.
>
> Yup, look at the documentation for each module. Basically we use -q, so if
> there is no output there was no change/update. [FWIIW: The 'last updated'
> date is calculated using that fact. A tad dodgy, but...]
>
> e.g
>
> http://brutus.apache.org/gump/public/checkstyle/index.html#Module-level+Work
> http://brutus.apache.org/gump/public/checkstyle/gump_work/update_checkstyle.html
>
> > Note that this is only with one CPU and less than one gig of RAM.
>
> :-)
>
> > Looking at the build times, it looks to me like gump 2.0 tries to do
> > parallel builds whenever possible?
>
> I would love to take credit for such smarts, but I don't think so. Gump 2.0
> is (todate) completely single threaded. Do we have a timestamp issue I've
> not picked up on? Sometime with so much Gump output I don't see the wood for
> the trees (Forest pun intended ;-).
>
> > And finally, a nit: I see useful information like the name of the java
> > command ("java") and the Operating System ("posix"), but I don't see the
> > values of System.getProperties which contains values such as:
> >
> > java.vm.version=1.4.2_04-b05
> > java.vm.vendor=Sun Microsystems Inc.
> > os.arch=i386
> > os.name=Linux
>
> Hmm. No, not directly. If a project repeatedly fails Gump automatically
> turns on ant verbose and/or debug, and maybe this show those values. Is
> there a way to list these things (above) without writing some Java?
>
> Tangentially related ... When Gump runs (as an agent) it checks it's
> environment (e.g. runs 'env', runs 'java --version', etc.) and captures
> results. This used to be code (incorrectly) located on the Workspace class,
> but I moved it to a separate Environment class. Only today have I restored
> that to the documentation, so watch that space.
>
> regards
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Speed of brutus
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I see from http://brutus.apache.org/gump/public/
>
> Elapsed Time : 1 hour 56 mins 20 secs
I have to agree, I was very impressed with speed. For some reason a little
less was built than on LSD, see these, but still -- it is very fast.
http://lsd.student.utwente.nl/gump/#Project+Summary
http://brutus.apache.org/gump/public/ndex.html#Project+Summary
>
> Putting it mildly, this doesn't look half bad. I presume that this
> includes the time of cvs/svn checkouts?
Yup, and the metadata load.
> Are the logs of the cvs/svn
> checkouts captured? This sometimes is helpful when trying to track down
> why a build that worked yesterday failed today.
Yup, look at the documentation for each module. Basically we use -q, so if
there is no output there was no change/update. [FWIIW: The 'last updated'
date is calculated using that fact. A tad dodgy, but...]
e.g
http://brutus.apache.org/gump/public/checkstyle/index.html#Module-level+Work
http://brutus.apache.org/gump/public/checkstyle/gump_work/update_checkstyle.html
> Note that this is only with one CPU and less than one gig of RAM.
:-)
> Looking at the build times, it looks to me like gump 2.0 tries to do
> parallel builds whenever possible?
I would love to take credit for such smarts, but I don't think so. Gump 2.0
is (todate) completely single threaded. Do we have a timestamp issue I've
not picked up on? Sometime with so much Gump output I don't see the wood for
the trees (Forest pun intended ;-).
> And finally, a nit: I see useful information like the name of the java
> command ("java") and the Operating System ("posix"), but I don't see the
> values of System.getProperties which contains values such as:
>
> java.vm.version=1.4.2_04-b05
> java.vm.vendor=Sun Microsystems Inc.
> os.arch=i386
> os.name=Linux
Hmm. No, not directly. If a project repeatedly fails Gump automatically
turns on ant verbose and/or debug, and maybe this show those values. Is
there a way to list these things (above) without writing some Java?
Tangentially related ... When Gump runs (as an agent) it checks it's
environment (e.g. runs 'env', runs 'java --version', etc.) and captures
results. This used to be code (incorrectly) located on the Workspace class,
but I moved it to a separate Environment class. Only today have I restored
that to the documentation, so watch that space.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org