Re: brutus may be having a problem
> Adam R. B. Jack wrote:
> > 2) Restore the config such that http://brutus.apache.org/gump/{flavour}
goes
> > to /usr/local/gump/{flavour}/results.
>
> done (for public, jdk15 and test, not any "flavour").
Thanks, I've restored the config to write back to these places.
regards
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
Adam R. B. Jack wrote:
2) Restore the config such that http://brutus.apache.org/gump/{flavour} goes
to /usr/local/gump/{flavour}/results.
done (for public, jdk15 and test, not any "flavour").
- LSD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
> > Hey, I spent so long on having Gump use Forrest 'cos I'm no GUI guy. The > > style sheet is here, feel free to help me fix it: > > > > http://cvs.apache.org/viewcvs.cgi/gump/template/xhtml/css/style.css > > I'm on it! Thanks. Let me know if you need me to change the class attributes on anything. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
Adam R. B. Jack wrote: Hey, I spent so long on having Gump use Forrest 'cos I'm no GUI guy. The style sheet is here, feel free to help me fix it: http://cvs.apache.org/viewcvs.cgi/gump/template/xhtml/css/style.css I'm on it! Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
> 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. Not really, much of the leakage of memory (and hence the slow down) was the web page generation. We still have some of that, but things are better. Now the pages that are listed in the buildLog.html (updated every 5 projects or so) is new. We (sub-optimally) redo the pages in a batch run at the end (so we can document dependendees and such) but I'll whittle that down over time. > > 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) Yup, and one ought now get an e-mail notification at this point also (for first time failures/state changes). > 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. > > :-) Hey, I spent so long on having Gump use Forrest 'cos I'm no GUI guy. The style sheet is here, feel free to help me fix it: http://cvs.apache.org/viewcvs.cgi/gump/template/xhtml/css/style.css > > > 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! Yup. We have 50 Mb (crazy I know, but it is 100K a project) of XML/DOM/model in memory, and we seem to start off fine. We creep that up to 75 Mb and we slow to a crawl. I don't think it is (exactly) the memory tree (although we do keep adding to it, e.g. with results of executed commands) but something is such clogging up. The page generation (DOM-like, and not a favourite of many here) starts fast but ends slow, when there ought be no difference. Hmm -- sometime I wonder if I ought turn off the garbage collector, or try some optimizations. I keep meaning to seeif I can cope w/ comp.lang.python, but I doubt I can w/ my network bandwidth. Q: Has anybody thought of an ASF developers python mailing list? Just for folks working in Python for ASF, be it MoinMoin extensions, or Gump, or ... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
> 3h 23m. > That's an improvement! > :-) Daft, but I've not been paying attention (too painful to look) -- what was it before? 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. Ever tried a targeted run? 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). 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. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
3h 23m. That's an improvement! :-) Adam R. B. Jack wrote: Until we can get a config change, I've (1) shutdown tomcat (2) reconfigured to sue these addresses: Note the ~ character. http://brutus.apache.org/~gump/public/ http://brutus.apache.org/~gump/jdk15/ http://brutus.apache.org/~gump/test/ For example: http://brutus.apache.org/~gump/public/buildLog.html regards Adam -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
Until we can get a config change, I've (1) shutdown tomcat (2) reconfigured
to sue these addresses:
Note the ~ character.
http://brutus.apache.org/~gump/public/
http://brutus.apache.org/~gump/jdk15/
http://brutus.apache.org/~gump/test/
For example:
http://brutus.apache.org/~gump/public/buildLog.html
regards
Adam
- Original Message -
From: "Adam R. B. Jack" <[EMAIL PROTECTED]>
To: "Gump code and data" <[EMAIL PROTECTED]>
Sent: Friday, July 09, 2004 7:25 AM
Subject: Re: brutus may be having a problem
> Darn, seems I picked a day to get stuck behind a config change, when Leo
is
> able to help out quickly. Hmm. We are getting HTML in {flavour}/results
but
> they aren't visible. :(
>
> Can anybody help me out with this, I'd like to ensure that this release is
> working as well as the old (I found one delete issue), if not better.
>
> If I don't get a response shortly I'll give a go at using XDOCs again.
>
> regards,
>
> Adam
> - Original Message -
> From: "Adam R. B. Jack" <[EMAIL PROTECTED]>
> To: "Gump code and data" <[EMAIL PROTECTED]>
> Sent: Thursday, July 08, 2004 11:27 PM
> Subject: Re: brutus may be having a problem
>
>
> >
> > >
> > > http://brutus.apache.org:8080/gump/modules.html
> > >
> >
> > Yup, maybe my merge has some kinks to work out. Still, Leo (or other),
> could
> > I request a quick reconfigure?
> >
> > 1) Let's remove tomcat.
> > 2) Restore the config such that http://brutus.apache.org/gump/{flavour}
> goes
> > to /usr/local/gump/{flavour}/results.
> >
> > I've reconfigure both public and jdk15 (and test) to write here &
stopped
> > the XDOCs output, am trying the better tested XHTML.
> >
> > regards,
> >
> > Adam
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
Darn, seems I picked a day to get stuck behind a config change, when Leo is
able to help out quickly. Hmm. We are getting HTML in {flavour}/results but
they aren't visible. :(
Can anybody help me out with this, I'd like to ensure that this release is
working as well as the old (I found one delete issue), if not better.
If I don't get a response shortly I'll give a go at using XDOCs again.
regards,
Adam
- Original Message -
From: "Adam R. B. Jack" <[EMAIL PROTECTED]>
To: "Gump code and data" <[EMAIL PROTECTED]>
Sent: Thursday, July 08, 2004 11:27 PM
Subject: Re: brutus may be having a problem
>
> >
> > http://brutus.apache.org:8080/gump/modules.html
> >
>
> Yup, maybe my merge has some kinks to work out. Still, Leo (or other),
could
> I request a quick reconfigure?
>
> 1) Let's remove tomcat.
> 2) Restore the config such that http://brutus.apache.org/gump/{flavour}
goes
> to /usr/local/gump/{flavour}/results.
>
> I've reconfigure both public and jdk15 (and test) to write here & stopped
> the XDOCs output, am trying the better tested XHTML.
>
> regards,
>
> Adam
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
>
> http://brutus.apache.org:8080/gump/modules.html
>
Yup, maybe my merge has some kinks to work out. Still, Leo (or other), could
I request a quick reconfigure?
1) Let's remove tomcat.
2) Restore the config such that http://brutus.apache.org/gump/{flavour} goes
to /usr/local/gump/{flavour}/results.
I've reconfigure both public and jdk15 (and test) to write here & stopped
the XDOCs output, am trying the better tested XHTML.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
brutus may be having a problem
http://brutus.apache.org:8080/gump/modules.html Message: null Description: No details available. Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet Request URI modules.html cause /home/gump/jakarta-tomcat-5.0.24/webapps/gump/content/xdocs/modules.xml (No such file or directory) request-uri /gump/modules.html Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
