Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Adam R. B. Jack wrote: I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. ... Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. IMHO making Forrest skin the html is the most reasonable way to go. Still, I think forrest is a sticking point. I'd like a pure Python solution, and I suspect Cheetah is the best way to go. Cheetah is IMHO the way to go for the basic html rendering. BTW: I'm eager to see some graphics. If SVG can be written (in XML, viua Python) can Forrest convert these to images (using Batik or somethough?) I'll happily continue with Forrest if that is a good way to get images rendered. It's there since some time now. -- 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]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Nicola Ken Barozzi wrote: Adam R. B. Jack wrote: I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. ... Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. That's darn near a circular definition. To demonstrate: what's wrong with the notion of switching the site to Anakia, which is stable, builds consistently with Gump, and powers www.apache.org, jakarta.apache.org, and a number of other sites? Now realize that I am *NOT* proposing Anakia. What I am proposing is that the ability to view a site as it is being produced is a very valuable thing to have, and an important consideration both for a machine which is a shared resource and for any hope of there ever being personal usage of gump. Beyond that, I would like to reiterate the point that there is value in keeping true to the original design where Gump bootstraps its own dependencies. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. I heard it, but I think I mentally filtered it somewhat, wondering if it was some sort of unholy compromise. Can you give more details on how this works, and the pros/cons of using HTML not xdocs? Does one simply write normal (but parsable) HTML and Forrest parse/processes it? Can we use the webapp approach with this output? BTW: With Forrest moving to xhtml eventually, does us moving to HTML help us? So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I don't have Stefano's dislike of DOM verses template generation. Perhaps because I wrote the code, perhaps because I am game to trade cycles/memory for easier coding. I know the code seems to be complex (at first) but I'll explain (see mail, to follow, on 'Documentation') that it really isn't. I want to see a Cheetah based approach (it seems interesting the Pythonic defacto standard) but I honestly have reservations about (1) it being easier (2) it being more manageable. Still, hopefully a good design (with Cheetah approach in mind) ought let us know in advance if this is the case. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. I've been frustrated with forrest spinning (it did it again last night for my machine) and builds working, but failing to output documentation. I proposed moving away from Forrest for this reason, no other. I think it has emerged that forrest is more of a stumbling block for others -- especially newcomers -- and it too much to expect/install (even thought it builds out of the box, and runs first time) for starters. As such, I am definately -1 to removing it completely, and +1 to having a simple HTML solution for starters. See mail (to follow) on 'Documentation'. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Now realize that I am *NOT* proposing Anakia. What I am proposing is that the ability to view a site as it is being produced is a very valuable thing to have, and an important consideration both for a machine which is a shared resource and for any hope of there ever being personal usage of gump. Sam, you seem to care more about timeliness of content than tooling, and I can respect that I think it can be accomodated w/o ruling out forrest. For example, what is wrong with writting HTML and/or XDOCS (whatever) as things go along? If we wrote xdocs to a webapp the cocoon/forrest webapp could detect the file change and rerender. I see nothing about timeliness that dictates format. BTW: We could do this today with gump.document.forrest -- calling the documentProject and documentModule methods with context. Not much in this code (other than stats/xref) cares when you call it. I'm not neccessarily proposing that, just stating we aren't so far off. Beyond that, I would like to reiterate the point that there is value in keeping true to the original design where Gump bootstraps its own dependencies. You are preaching to the choir. We've agonized over installing a Maven drop to build Maven projects. Unfortunately, we can't rely solely upon a (higher dependency) Gumped application for output, 'cos they (e.g Maven and Forrest/Cocoon) build so infrequently. [Good intentions can't force consistent builds.] The case of Maven is more persuasive than a documentation tool (of which we could pick) because communities have picked Maven. I'd love to developer a solution where we use the Gumped solution (if available) but fallback to a packaged/installed solution when not. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Sam Ruby wrote: Nicola Ken Barozzi wrote: ... Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. That's darn near a circular definition. I mean that since I want to keep the site done with Forrest, I would also like to have the other info done that way. To demonstrate: what's wrong with the notion of switching the site to Anakia, which is stable, builds consistently with Gump, and powers www.apache.org, jakarta.apache.org, and a number of other sites? Now realize that I am *NOT* proposing Anakia. What I am proposing is that the ability to view a site as it is being produced is a very valuable thing to have, and an important consideration both for a machine which is a shared resource and for any hope of there ever being personal usage of gump. Errr, did I say that this is not ok? Replay: So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I am trying to say that I am *+1* to outputting html, but also that Forrest can layer *on top* of that to make a skinned version *if* the user wants to. Note that this does not prevent you from putting a css in the html that Forrest can skin, so that even the non-forrest-skinned version can have nice looks. Is this clear? Beyond that, I would like to reiterate the point that there is value in keeping true to the original design where Gump bootstraps its own dependencies. -- 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]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Sam Ruby wrote: Beyond that, I would like to reiterate the point that there is value in keeping true to the original design where Gump bootstraps its own dependencies. I agree with that. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Gump Thrashing/Spinning...
Nick Chalko wrote: Stefano Mazzocchi wrote: \ . Ok, I think that reducing complexity is critical for wider adoption. +1 in removal of forrest and go plain XHTML + CSS. But please, let's use a velocity-like approach, not a DOM like approach! I am not sure how removing forrest reduces complexity. It just means we have to maintaining the template / site code ourself. I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. A design point for the original gump is that output was viewable as it was produced. Is this the case for gumppy w/ forrest? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. It is really just a lot of repetative simple code, building simple xdoc pieces. It it's pretty, but it isn't that bad. We have gump.document.text, and we could create gump.document.html that use cheetah to write it. I looked at Cheetah and liked the ability to create templates as classes, and sub-class (perhaps aggregate) such, but when I thought about it I couldn't really find much real different from what was going on with gump.document.forrest. Basically Cheetah requires code within the template to map memory into locations, and I didn't find it hughly different than what is there. Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Still, I think forrest is a sticking point. I'd like a pure Python solution, and I suspect Cheetah is the best way to go. BTW: I'm eager to see some graphics. If SVG can be written (in XML, viua Python) can Forrest convert these to images (using Batik or somethough?) I'll happily continue with Forrest if that is a good way to get images rendered. A design point for the original gump is that output was viewable as it was produced. Is this the case for gumppy w/ forrest? No, everything is stored in files with memory context. With gump.document.forrest we write a bunch of xdocs in one pass (before we call forrest). regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Adam R. B. Jack wrote: BTW: I'm eager to see some graphics. If SVG can be written (in XML, viua Python) can Forrest convert these to images (using Batik or somethough?) I'll happily continue with Forrest if that is a good way to get images rendered. Yes Just put foo.svg and then access it as foo.png For example http://antworks.sourceforge.net/importer/images/project-logo.png Comes from ?xml version=1.0 encoding=Windows-1252? svg xmlns=http://www.w3.org/2000/svg; xmlns:xlink=http://www.w3.org/1999/xlink; viewBox=0 0 340 60 height=60 width=340 titleantworks-importer logo/title defslinearGradient y2=1 x2=0 y1=0 x1=0 id=gradientstop offset=0 style=stop-color:white/ stop offset=1 style=stop-color:lightgreen//linearGradient filter filterUnits=objectBoundingBox id=shadowFilter feGaussianBlur result=blur stdDeviation=2 2 in=SourceAlpha/ feOffset result=offsetBlur dy=4 dx=4 in=blur/ feComposite operator=over in2=offsetBlur in=SourceGraphic//filter/defs g fill=url(#gradient) filter=url(#shadowFilter) text style=font-size:32pt; font-family:Verdana ; text-anchor: middle y=50% x=45%Antworks Importer/text text style=font-size:10pt; font-family:Arial ; text-anchor: middle y=80% x=55%autdownload and import ant build.xml/text/g /svg Is generated by the forrest.antlet http://antworks.sourceforge.net/antlets/forrest/xbuild-doc.html from a module.xml R, Nick - 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]
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: 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: 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]