Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Message-ID: <40EEE45F.6090607@apache.org>
Date: Fri, 09 Jul 2004 20:30:55 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031208
MIME-Version: 1.0
To: Gump code and data <general@gump.apache.org>
Subject: Re: brutus may be having a problem
References: <40EE2597.9090708@apache.org>
 <066601c46575$ba9f5640$60bfea43@sybase.com>
 <074001c465b9$73dfabd0$60bfea43@sybase.com>
 <07b101c465bf$626101a0$60bfea43@sybase.com> <40EEDBF3.7060605@apache.org>
 <092501c465df$4bd3a350$60bfea43@sybase.com>
In-Reply-To: <092501c465df$4bd3a350$60bfea43@sybase.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Adam R. B. Jack wrote:
>>3h 23m.
>>That's an improvement!
>>:-)
> 
> 
> Daft, but I've not been paying attention (too painful to look) 

:-)

> -- what was it before?

The cycle time between updates of the web site was around 9 hours - gump 
was reporting about 5 hours for the run (so we are already seeing a big 
improvement on that aspect). In addition there is that mystery 4 hours 
between the end of the run and the appearance off documentation.

> Still, it can do far far better. Multi-threading the CVS/SVN ought reduce
> the latency. The main problem (for no clear reason I can gather) still seems
> to be generating documentation.

Just an observation - that way things are using the current setup is 
"for me" better.  Ok the docs are not a nice but what I can see 
immediately is the following:

   (a) a message saying "gump is running and it started at ..."
   (b) result as they unfold which gives me more time to hit the
       issue (e.g. I figure I've fixed james during the last run
       because I was able to access the info before the run had
       completed)

Things I wasn't too impressed with was the dirty big red banner 
complaining about my subversion of build.sysclasspath which kind of made 
me cringe.

:-)

> Ever tried a targeted run? 

Nope - never.
I'll leave that sort of thing to Niclas!

> If one runs to (say) depot or something like this
> (a trimmed stack), this thing flies. It is something that clogs up over time
> & I can't track it down (ok, haven't yet). 

Watching the interactive progress you get a feel for this as well - gump 
kicks off and rips though the early entries but things get progressively 
slower.  But the end of the run she's not showing the same degree 
enthusiasm!

> I sometimes wonder if it is the
> Python implementation, not Gumpy per se. Something to do with the number of
> objects in memory. Sooner or later I'll find it.

:-)

Steve.


> regards
> 
> Adam
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org