Project descriptors (was Re: [RT] href considered harmful)
Stefano Mazzocchi wrote: Leo Simons wrote: I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I agree with you as a general principle. Too bad that the entire cocoon build system relies on the gump descriptor for its blocks and this is going to be so for a while. If you deprecate href, cocoon will be seriously damaged. Now, I am the one to blame for this, Actually I was the one that started it ;-P History: when I needed a descriptor for Centipede, I looked at the Gump one, and extended it. Then Cocoon needed a similar system, so out of my experience with Centipede I created the code-generating block build system but my rationale was to keep gump and cocoon in synch by making sure that everytime you built cocoon, you were also testing if the gump descriptor was right. ...that was what I thought... Of course, only gump can do the full check, but the cocoon build can help a little bit. ... and here is where it broke. The fact is that the two are now so different in the way they work that the check is not good enough. Or we make the Cocoon build system more akin to Gump, or we make something that keeps the two descriptors lazily in synch. Stefano, I need your help. We've been banging our head on this for months, and I still remember a discussion like this with Sam more than a year ago. We *must* resolve this. Let's see: 1. Gump needs to have all the descriptors at hand. Href is too volatile for Gump. 2. Gumpers need to be able to change that information. 3. Project developers need to be able to change that info too. 4. The two descriptors should be able to stey out of synch. So: From point 1 and 2 we need a repository with all the descriptors. From point 3 and 4 we need to have a replication system between the repository and the project. Let's say that each project has a Gump descriptor in the Gump repo and *can* *also* have an href. A cron job can check the two and report the differrences to the respective communities (ie the one that has the oldest descriptor). In this way we have bi-community peer review of changes. Even better, on every descriptor checkin, a quick build is performed with last night's jars, to see that the descriptor works. But this is part of the -build per checkin- thing that is on the agenda in any case. So, is this an option. Let's get this nailed :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon.xml
mcconnell2004/03/25 03:24:49 Modified:project avalon.xml Log: Correct package name for the avalon logging impl package. Revision ChangesPath 1.44 +1 -1 gump/project/avalon.xml Index: avalon.xml === RCS file: /home/cvs/gump/project/avalon.xml,v retrieving revision 1.43 retrieving revision 1.44 diff -u -r1.43 -r1.44 --- avalon.xml24 Mar 2004 08:37:49 - 1.43 +++ avalon.xml25 Mar 2004 11:24:49 - 1.44 @@ -142,7 +142,7 @@ /project project name=avalon-logging-impl -packageorg.apache.avalon.logginf.impl/package +packageorg.apache.avalon.logging.impl/package ant basedir=logging/impl target=jar property name=project.version value=@@DATE@@/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon.xml
mcconnell2004/03/25 03:26:12 Modified:project avalon.xml Log: Fix avalon meta impl package name. Revision ChangesPath 1.45 +1 -1 gump/project/avalon.xml Index: avalon.xml === RCS file: /home/cvs/gump/project/avalon.xml,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- avalon.xml25 Mar 2004 11:24:49 - 1.44 +++ avalon.xml25 Mar 2004 11:26:12 - 1.45 @@ -562,7 +562,7 @@ /project project name=avalon-meta-impl -packageorg.apache.avalon.impl/package +packageorg.apache.avalon.meta.impl/package ant basedir=meta/impl target=jar property name=project.version value=@@DATE@@/ /ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/profile gump.xml
mcconnell2004/03/25 05:15:59 Modified:profile gump.xml Log: Add the avalon-legacy.xml project. Revision ChangesPath 1.329 +2 -1 gump/profile/gump.xml Index: gump.xml === RCS file: /home/cvs/gump/profile/gump.xml,v retrieving revision 1.328 retrieving revision 1.329 diff -u -r1.328 -r1.329 --- gump.xml 24 Mar 2004 13:44:00 - 1.328 +++ gump.xml 25 Mar 2004 13:15:59 - 1.329 @@ -26,9 +26,10 @@ module href=project/avalon-components.xml/ module href=project/avalon-excalibur.xml/ module href=project/avalon-logkit.xml/ - module href=project/avalon-phoenix.xml/ module href=project/avalon-sandbox.xml/ module href=project/avalon-site.xml/ + module href=project/avalon-legacy.xml/ + module href=project/avalon-phoenix.xml/ !-- Apache.Cocoon -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs@gump.apache.org?
how do you feel about setting up [EMAIL PROTECTED] for all change notifications? +0 regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: last night's build on lsd
Yeah, it seems not. I don't know if this is related, but I had woes trying to run/test Gump on my VM server Gump-box yesterday also. Basically the poor box swapped itself to death, in part 'cos forrest grew so large. The xdocs were written, but the forrest site wasn't generated. I wonder if something similar happened (or is happening) to LSD. [I just tried logging in, and I'm not getting in -- due to timeouts.] Looks like the same is happening to LSD, huge load, with what I assume is swapping takign up the CPU. I am in, but one command ever five minutes...: 16:24:16 up 22 days, 18:05, 3 users, load average: 110.71, 77.43, 63.57 196 processes: 186 sleeping, 9 running, 1 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total0.9%1.0% 75.1% 0.0% 0.0%0.0% 22.8% Mem: 255584k av, 251740k used,3844k free, 0k shrd,7216k buff 77344k active, 131400k inactive Swap: 1052248k av, 1052248k used, 0k free 10820k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 5 root 16 0 00 0 SW 83.9 0.0 94:21 0 kswapd regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: last night's build on lsd
I just rebooted (remotely via ssh, took ages). Things seem alright now. Poor machine :D -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-34) Upgrade JDK on lsd to java 1.4.2_04
The following comment has been added to this issue: Author: Leo Simons Created: Thu, 25 Mar 2004 8:32 AM Body: the release notes page says the following: --- Documentation Java[tm] 2 SDK, Standard Edition Version 1.4.2_03 (Microsoft Windows, Linux, and Solaris Operating Envirnoment) Release Notes JavaTM 2 SDK, Standard Edition Version 1.4.2_04 (Microsoft Windows, Linux, and Solaris Operating Environment) --- weird. Anyway, installing right now :D - View this comment: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-34page=comments#action_27806 - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-34 Here is an overview of the issue: - Key: GUMP-34 Summary: Upgrade JDK on lsd to java 1.4.2_04 Type: Task Status: Open Priority: Minor Project: Gump Assignee: Leo Simons Reporter: Antoine Levy-Lambert Created: Mon, 15 Mar 2004 11:09 PM Updated: Thu, 25 Mar 2004 8:32 AM Environment: Gump [EMAIL PROTECTED] Description: The build of xml-xerces1 is currently failing due to Unicode escapes present in javadoc comments. I am quoting Michael Glavassevich : http://article.gmane.org/gmane.comp.jakarta.gump/4990 I understand that this was a compiler bug [1] which was recently fixed in JDK 1.4.2_04 [2]. Whomever's responsible for the environment on lsd may want to upgrade the JDK. [1] http://developer.java.sun.com/developer/bugParade/bugs/4863451.html [2] http://java.sun.com/j2se/1.4.2/ReleaseNotes.html I have checked that JDK 1.4.2_04 fixes the problem. So we should go for it. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work Started: (GUMP-34) Upgrade JDK on lsd to java 1.4.2_04
Message: Work on this issue has been started by Leo Simons (mailto:[EMAIL PROTECTED]) - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-34 Here is an overview of the issue: - Key: GUMP-34 Summary: Upgrade JDK on lsd to java 1.4.2_04 Type: Task Status: In Progress Priority: Minor Project: Gump Assignee: Leo Simons Reporter: Antoine Levy-Lambert Created: Mon, 15 Mar 2004 11:09 PM Updated: Thu, 25 Mar 2004 8:38 AM Environment: Gump [EMAIL PROTECTED] Description: The build of xml-xerces1 is currently failing due to Unicode escapes present in javadoc comments. I am quoting Michael Glavassevich : http://article.gmane.org/gmane.comp.jakarta.gump/4990 I understand that this was a compiler bug [1] which was recently fixed in JDK 1.4.2_04 [2]. Whomever's responsible for the environment on lsd may want to upgrade the JDK. [1] http://developer.java.sun.com/developer/bugParade/bugs/4863451.html [2] http://java.sun.com/j2se/1.4.2/ReleaseNotes.html I have checked that JDK 1.4.2_04 fixes the problem. So we should go for it. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work Stopped: (GUMP-34) Upgrade JDK on lsd to java 1.4.2_04
Message: Work on this issue has been stopped by Leo Simons (mailto:[EMAIL PROTECTED]) - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-34 Here is an overview of the issue: - Key: GUMP-34 Summary: Upgrade JDK on lsd to java 1.4.2_04 Type: Task Status: Open Priority: Minor Project: Gump Assignee: Leo Simons Reporter: Antoine Levy-Lambert Created: Mon, 15 Mar 2004 11:09 PM Updated: Thu, 25 Mar 2004 8:38 AM Environment: Gump [EMAIL PROTECTED] Description: The build of xml-xerces1 is currently failing due to Unicode escapes present in javadoc comments. I am quoting Michael Glavassevich : http://article.gmane.org/gmane.comp.jakarta.gump/4990 I understand that this was a compiler bug [1] which was recently fixed in JDK 1.4.2_04 [2]. Whomever's responsible for the environment on lsd may want to upgrade the JDK. [1] http://developer.java.sun.com/developer/bugParade/bugs/4863451.html [2] http://java.sun.com/j2se/1.4.2/ReleaseNotes.html I have checked that JDK 1.4.2_04 fixes the problem. So we should go for it. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-24) Make gump build directories accessible through web browser
Message: The following issue has been closed. Resolver: Leo Simons Date: Thu, 25 Mar 2004 8:39 AM after some more talk on the mailing list, it came up that this is distribution of software, often without paying due respect to license requirements for distribution. So that's a no-can do. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-24 Here is an overview of the issue: - Key: GUMP-24 Summary: Make gump build directories accessible through web browser Type: Task Status: Closed Priority: Minor Resolution: WON'T FIX Project: Gump Components: Python Fix Fors: unspecified Versions: unspecified Assignee: Leo Simons Reporter: Leo Simons Created: Sun, 14 Mar 2004 11:46 AM Updated: Thu, 25 Mar 2004 8:39 AM Environment: lsd.student.utwente.nl, moof.apache.org Description: Vincent Massol requested we make the full gump outputs accessible through the web browser. Need to think a little about security and then JFDI. It'll help people debug things. (Also update the relevant docs to point to this feature). - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work Started: (GUMP-25) document actual gump installations
Message: Work on this issue has been started by Leo Simons (mailto:[EMAIL PROTECTED]) - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-25 Here is an overview of the issue: - Key: GUMP-25 Summary: document actual gump installations Type: New Feature Status: In Progress Priority: Minor Project: Gump Components: Python Fix Fors: unspecified Versions: unspecified Assignee: Leo Simons Reporter: Leo Simons Created: Sun, 14 Mar 2004 11:49 AM Updated: Thu, 25 Mar 2004 8:40 AM Description: Add some docs on the wiki about the actual gump setups on various machines, how they were set up, and how they are being maintained. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: FrontPage
Date: 2004-03-25T08:41:05 Editor: 130.89.169.128 Wiki: Gump Wiki Page: FrontPage URL: http://wiki.apache.org/gump/FrontPage no comment Change Log: -- @@ -26,6 +26,9 @@ '''GumpCommandLineOptions''' Some more notes about those commandline scripts. + '''GumpInfrastructure''' + Some notes on the machines that run gump. Please add your machine here if it runs gump, especially if the results are published publicly. + = Design Topics = * HistoricalResultsDatabase - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] New: GumpInfrastructure
Date: 2004-03-25T08:49:28 Editor: 130.89.169.128 Wiki: Gump Wiki Page: GumpInfrastructure URL: http://wiki.apache.org/gump/GumpInfrastructure no comment New Page: == Gump on lsd.student.utwente.nl == [http://lsd.student.utwente.nl/ lsd] is currently the main installation for gump, though that will change real soon now. It's a duron machine running a near-full install of Fedora Core 1 and some optional packages from freshrpms, atrpms, jpackage, sun, nvidia, etc, which are supposed to be kept in the /data/packages directory. About 30GB of disk is allocated to gump. [http://lsd.student.utwente.nl/ Results] are published every night (run starts at 1:00AM GMT, usually finished at about 10AM GMT). Leo Simons is the (only) root on the machine, with several people in a 'gump' group that log in via ssh to help admin the gump installation. Gump (v 2.0) lives in /data3/gump, with results published to /data3/gump/log, and the actual gump install (home of the metadata and the scripts and stuff) in /data3/gump/gump-install. The crontab runs in the user id of ajack, the profile is the lsd.xml file in the gump cvs module, with /data3/gump/gump-install/local-env-py.sh containing local settings (like JAVA_HOME), as is the case for any gump 2 install. If you have a good reason to want shell access to the machine, get in contact with Leo through the gump mailing list. If he knows who you are, chances are you'll be served :D - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-25) document actual gump installations
The following comment has been added to this issue: Author: Leo Simons Created: Thu, 25 Mar 2004 8:50 AM Body: http://wiki.apache.org/gump/GumpInfrastructure - View this comment: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-25page=comments#action_27809 - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-25 Here is an overview of the issue: - Key: GUMP-25 Summary: document actual gump installations Type: New Feature Status: Open Priority: Minor Project: Gump Components: Python Fix Fors: unspecified Versions: unspecified Assignee: Leo Simons Reporter: Leo Simons Created: Sun, 14 Mar 2004 11:49 AM Updated: Thu, 25 Mar 2004 8:50 AM Description: Add some docs on the wiki about the actual gump setups on various machines, how they were set up, and how they are being maintained. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (GUMP-25) document actual gump installations
Message: The following issue has been re-assigned. Assignee: (mailto:) - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-25 Here is an overview of the issue: - Key: GUMP-25 Summary: document actual gump installations Type: New Feature Status: Unassigned Priority: Minor Project: Gump Components: Python Fix Fors: unspecified Versions: unspecified Assignee: Reporter: Leo Simons Created: Sun, 14 Mar 2004 11:49 AM Updated: Thu, 25 Mar 2004 8:50 AM Description: Add some docs on the wiki about the actual gump setups on various machines, how they were set up, and how they are being maintained. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nagoya much slower again...
Who's Gump in whose account? Sam's? Is anybody aware of the outputs, let alone using them? I don't think folks have had access to the outputs (that they've known about) in forever. http://gump.apache.org/#Where+is+Gump%3F regards Adam - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Leo Simons [EMAIL PROTECTED]; Apache Infrastructure [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 10:12 AM Subject: RE: nagoya much slower again... a while ago someone changed something on nagoya (allocating more memory to tomcat or something) that made eyebrowse, jira, etc, much more snappy. That was nice. The effect seems to have gone away again. Any chance of making those apps more responsive? There are two problems. One is that GUMP runs for 6-10 hours every day, and there is a period during that time when GUMP drags nagoya to its knees. The other problem that I occasionally see is bugzilla's createattachment.cgi script going into an infinite spin loop, completely chewing up an entire CPU until I kill it. Bugzilla sucks, and I would love to see it die with nagoya, but I don't think that is likely to happen. :-( When we get the new issues server running, we will if there is someone willing to install a current version of bugzilla. I seem to recall that the SpamAssassin folks were willing, and I'm sure that we can control the access rights to allow that to happen. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: nagoya much slower again...
Who's Gump in whose account? Sam's? Is anybody aware of the outputs, let alone using them? Sam, and ask him. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Which gump on the new machines?
OK, it looks like there may be a new ASF hosted machine or two running gump in the next 24 or so hours. Which gump should be run on it? I'm willing to take the lead in getting it up and running, or simply suggest it be turned over to somebody who wishes to volunteer. Once it is up and running, it is my intent that this be a public resource Gump participants. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which gump on the new machines?
OK, it looks like there may be a new ASF hosted machine or two running gump in the next 24 or so hours. Which gump should be run on it? Which? As in traditioanl verse Python? I think concensus has been Python for a while. We have a README in /usr/local/gump on moof, ought I post it here for folks? I can't get there this mo, and my eyebrowse search isn't bringing up when I posted it before. It has the steps involved. I'm willing to take the lead in getting it up and running, or simply suggest it be turned over to somebody who wishes to volunteer. Once it is up and running, it is my intent that this be a public resource Gump participants. I will be online (from a hotel, after workout/dinner) tonight (PST time) and able to help. I do think we ought use the shared 'gump' account we've been discussing, that'd be good for a common place for the cronjob, etc. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which gump on the new machines?
We have a README in /usr/local/gump on moof, ought I post it here for folks? I can't get there this mo, and my eyebrowse search isn't bringing up when I posted it before. It has the steps involved. A google search found me this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00487.html regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project antworks-importer.xml
nickchalko2004/03/25 11:15:04 Modified:project antworks-importer.xml Log: Formated Revision ChangesPath 1.6 +12 -26gump/project/antworks-importer.xml Index: antworks-importer.xml === RCS file: /home/cvs/gump/project/antworks-importer.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- antworks-importer.xml 22 Mar 2004 10:31:29 - 1.5 +++ antworks-importer.xml 25 Mar 2004 19:15:04 - 1.6 @@ -15,30 +15,16 @@ limitations under the License. -- module name=antworks-importer - - url href=http://antworks.sourceforge.xml/importer/ - description -Autodownload and import ant build.xml's. - /description - - cvs repository=sourceforge host-prefix=cvs.antworks dir=antworks module=importer / - - - - project name=antworks-importer fullname=Antworks Importer -packageorg.krysalis.antworks.importer/package - -ant buildfile=build-bootstrap.xml target=gump - property name=project.version value=0.1-gump-@@DATE@@/ -/ant - -depend project=ant inherit=runtime/ - - -jar name=dist/antworks-importer-0.1-gump-@@DATE@@.jar / -nag to=[EMAIL PROTECTED] - from=[EMAIL PROTECTED]/ - /project - - +url href=http://antworks.sourceforge.xml/importer/ +description Autodownload and import ant build.xml's. /description +cvs repository=sourceforge host-prefix=cvs.antworks dir=antworks module=importer/ +project name=antworks-importer fullname=Antworks Importer +packageorg.krysalis.antworks.importer/package +ant buildfile=build-bootstrap.xml target=gump +property name=project.version value=0.1-gump-@@DATE@@/ +/ant +depend project=ant inherit=runtime/ +jar name=dist/antworks-importer-0.1-gump-@@DATE@@.jar/ +nag to=[EMAIL PROTECTED] from=[EMAIL PROTECTED]/ +/project /module - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Adam Jack wrote: Whatever the cause, I am really starting to get 'done' with forrest. I support it's use, I introduced it have dealt with the issues and built workarounds from day one, but it is hard work w/ no fun. I remember that feeling. I like the forrest project and I like the forrest devs a lot, but I've been very frustrated with the forrest software a few times. As to why python is a memory hog itself as well -- probably because variables don't go out of scope and because a lot of things (strings probably and object representations in the GOM) get copied around. I wonder if we ought consider replacing Forrest with a pure Python HTML producer. As above, I can't prove that forrest is the problem, but a pure Python solution might just halve the unknowns. Thoughts? It's a good plan, methinks. * I think some people would like gump a lot more if you could run it without needing java at all from a philosophical (free everything) view. * It's a lot simpler (we really don't need forrest's power). * It reduces the number of tools one has to be familiar with. We should probably use a template engine. I'm sure there's a python equivalent for something like velocity (or smarty). -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
I wonder if we ought consider replacing Forrest with a pure Python HTML producer. As above, I can't prove that forrest is the problem, but a pure Python solution might just halve the unknowns. I've been using Python to generate HTML from XML via XSL for a few weeks now using 4suite. I'm fairly new to Python so I wasn't really sure what my options were for XSL. It's been very good so far, speed wise. So, maybe it's an option. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Generating HTML (was Gump Threashing/Spinning)
We should probably use a template engine. I'm sure there's a python equivalent for something like velocity (or smarty). First, I like the dynamic 'tree of nodes' based approach to writing HTML/XML, rather than template -- in the main because of pleasant experiences with the Perl modules for this in the past. That said, even though there are some huge fields here (build output logs) maybe a template mechanism is enough for the simple structure (results tables, lists, etc.) that we have. We have huge pages, with options missing (or not) based off content. I'm not sure any template could cope with that, but I am open minded to it. Second, I didn't realize that Python DOM had nice serialization mechanism. Maybe I should've used that from the start. Now Gump generates it's xdocs using an object tree structure. Watching the python memory grow from 20M (after loading all XML) to 136M (during generating these pages) it has some sort of leak (actual or effective): Fixing this area is clearly important, and I'd appreciate all insights... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump Architecture
Leo Simons wrote: snip/ As for the buzzwords...let's create an action-based, data-centric, graph-based, versioning-enabled, highly componentized, extensible, continous integration system. I have no idea how to do any of that in python, but it sounds like fun to find out.. I had thought of using a event / black board system to support a distributed gump. Using something like javaspaces. A controller adds projects to a queue With information like * project name * cvs info including timestamp to use * List of dependencies * ant file / target The controller then walks through the project queue to find request that have all dependencies resolved and moves them to the a buildable queue Builders then get projects from the queue, and post the results which are ant output and jar files. When the controller has no more buildable projects it then posts the rest as dependency failures. This is a radically change but much more scalable. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Adam Jack wrote: I've been trying to run some quick jobs (a check.py not an integrate.py) to try to get insight into this problem. I'm finding (at least on my machine) that forrest is growing to huge size, and getting bogged down in swapping. I can't say this with certainty, but I feel that both Python and Java degrade very poorly when swapping, not just because they do so much dynamic memory management. I suspect any background thread for garbage collection is getting starved. I don't know if this is true, or even if it matters, but we are getting to a point of resoruce shortage, to the point of outage. I wonder if Python (Gumpy) and Java (Forrest ) are fighting with each other for resources. Both are hogs, but I am not sure if being a memory hog is cause or effect. I don't know if growth is occuring 'cos we finally added the last straw to the camel's back, or if we have some wierd loop bug. I suspect forrest is getting stuck on a certain page, but I have no insight into what is causing this -- nor if the cause is somehow Gumpy. Doing a much smaller Gump run, hence smaller xdocs set, works w/o problem. When doing a test run here (without even doign the build parts) I see Gumpy (the python instance) growing to 136M! I have no clue as to why it would do that! I wish I could get inside the Python instance to understand where the memory is, or if it is being leaked. Maybe this is just crowding out forrest. Whatever the cause, I am really starting to get 'done' with forrest. I support it's use, I introduced it have dealt with the issues and built workarounds from day one, but it is hard work w/ no fun. I feel it (through Gumpy trying to dynamically create xdocs) has been the weak/slow link in Gumpy for a while. I suspect even the forrest developers here might agree that I took this too far. Forrest is great for sites, but the gump outputs are getting huge and not really benefiting from Forrest skins, etc. Maybe I am wrong, maybe I need to approach the forrest developers (mail to their team) to see what they think on this. I wonder if we ought consider replacing Forrest with a pure Python HTML producer. As above, I can't prove that forrest is the problem, but a pure Python solution might just halve the unknowns. Two possible solutions here: 1) use forrest as a dynamic application 2) have HTML generate by python I would go for 1) since it would keep us the ability to do dynamic stuff like metadata manipulation. I volunteer to setup 1) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Gump Thrashing/Spinning...
Stefano Mazzocchi wrote: Adam Jack wrote: Two possible solutions here: 1) use forrest as a dynamic application 2) have HTML generate by python I would go for 1) since it would keep us the ability to do dynamic stuff like metadata manipulation. I volunteer to setup 1) +1 for dynamic forrest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump Architecture
Leo Simons wrote: (did I mention I'm an avalon guy? :D) did I mention that Avalon is dying out of flexibility cancer? Dude, let's just fix things incrementally. Lazyness is a virtue and Darwin is your man. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Gump Thrashing/Spinning...
1) use forrest as a dynamic application First, what do you mean by this, please? For those of us who don't know, could somebody elaborate? Second, I think it is forrest that is where we are getting stuck right now. Now sure why, but it is locking up. So, if we want forest, we have to figure out how to get inside that problem. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump Architecture
Stefano Mazzocchi wrote: Leo Simons wrote: (did I mention I'm an avalon guy? :D) did I mention that Avalon is dying out of flexibility cancer? Yes Stafano ... I've been watching your predications. Stephen. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating HTML (was Gump Threashing/Spinning)
First, I like the dynamic 'tree of nodes' based approach to writing HTML/XML, rather than template I like merging the concepts. Once you've built the tree, flatten the part of it that will make up the page, and feed that to the template engine. Even if you don't use a template engine, seperate the flattening and splitting from the transformation step. I am game to explore this. HTML or XML (xdoc) output ought be the same code, just with different templates, so we can have 'pure Python generating HTML' and/or 'forrest on xdocs' without us having to compromise, right? This is different from stuff like anakia, where the template walks the tree directly (bad). I think this is the key. I'd really like to find a good way to go from a tree of objects (not DOM, our models and context, etc.) to variables for templates, or whatever. I don't want this to be kludgy, and feel that cheetah/Python likely have some sort of slick solution. BTW: I can see the need to use includes, and I can see 'if' directives, but maybe we'd still want to use bits of templates glued together to get re-use. I think it depends upon the tree to tempalte choice we make... Second, I didn't realize that Python DOM had nice serialization mechanism. Maybe I should've used that from the start. No idea what you're talking about :D The Python DOM tree will serialize to an XML stream (unlike old DOMs I'm used to). I wrote some stuff I should never have in Python. Hey, we are here to learn, right? Now Gump generates it's xdocs using an object tree structure. Watching the python memory grow from 20M (after loading all XML) to 136M (during generating these pages) it has some sort of leak (actual or effective) ouch! Maybe it would pay off to use pipelining (you know, SAX, stuff) instead of DOM to generate the object tree. I wonder if it is some sort of circular dependency (amonst the objects) so when I destroy a tree (by pointing the variable to a new one) I wonder if it truely gets destroyed. I know the DOM has an unlink() method for some good reason, along these lines. There is so much thrown up into memory, more with translations to try to cope with character sets (and binary junk) and such. I no longer believe that any is being thrown away when I mean it to be... Fixing this area is clearly important, and I'd appreciate all insights... No insights here, just babbling along ;) Better than my just listening to the babbling in my head. ;-) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Adam Jack wrote: [snip] I think it is forrest that is where we are getting stuck right now. Now sure why, but it is locking up. So, if we want forest, we have to figure out how to get inside that problem. Which version are you using? Probably coincidence, but I recently stopped using CVS HEAD because cocoon would hang during the Forrest build-site stage. Version 0.51 of Forrest is quite happy building my site from exactly the same xdocs source. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Unfortunately we are stuck with a recent CVS HEAD, if not latest, due to some features in the skin. We can't go back to a release. FWIIW: The release we have has been working for the last month or so, something just changed and dorked it. regards Adam - Original Message - From: Michael Davey [EMAIL PROTECTED] To: Gump code and data [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 4:01 PM Subject: Re: Gump Thrashing/Spinning... Adam Jack wrote: [snip] I think it is forrest that is where we are getting stuck right now. Now sure why, but it is locking up. So, if we want forest, we have to figure out how to get inside that problem. Which version are you using? Probably coincidence, but I recently stopped using CVS HEAD because cocoon would hang during the Forrest build-site stage. Version 0.51 of Forrest is quite happy building my site from exactly the same xdocs source. -- Michael - 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: Cocoon not picking up framework api
On Thu, 25 Mar 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Seems like the cocoon core build is not picking up the avalon-framework-api. It does, but the jar file doesn't contain the CascadingThrowable class. Let's see [EMAIL PROTECTED] gump]$ find /javastuff/gump/avalon* -name CascadingThrowable.class /javastuff/gump/avalon/framework/api/target/classes/org/apache/avalon/framework/CascadingThrowable.class /javastuff/gump/avalon/framework/target/classes/org/apache/avalon/framework/CascadingThrowable.class not in impl, but in api and this is the jar that doesn't get picked up. Probably there is some logic (don't have the time to dive in ATM) that says the depend inside ant is unneeded since the one on the outside is sufficient. The appended patch should help and hopefully have cocoon building next night. Sorry Stefan Index: gump.xml === RCS file: /home/cvspublic/cocoon-2.1/gump.xml,v retrieving revision 1.132 diff -u -r1.132 gump.xml --- gump.xml25 Mar 2004 03:57:46 - 1.132 +++ gump.xml25 Mar 2004 14:05:24 - @@ -47,7 +47,7 @@ depend project=xml-xalan2/ depend project=xml-commons-resolver/ -depend project=avalon-framework ids=impl/ +depend project=avalon-framework ids=impl api/ depend project=excalibur-compatibility/ depend project=excalibur-instrument/ depend project=excalibur-instrument-manager/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
