Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)

2004-03-29 Thread Nicola Ken Barozzi
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...)

2004-03-29 Thread Sam Ruby
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...)

2004-03-29 Thread Adam R. B. Jack

   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...)

2004-03-29 Thread Adam R. B. Jack

 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...)

2004-03-29 Thread Nicola Ken Barozzi
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...)

2004-03-29 Thread Stefano Mazzocchi
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...

2004-03-27 Thread Sam Ruby
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...

2004-03-27 Thread Adam R. B. Jack
 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...

2004-03-27 Thread Nick Chalko
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...

2004-03-25 Thread Leo Simons
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...

2004-03-25 Thread matthew.hawthorne
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...

2004-03-25 Thread Stefano Mazzocchi
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...

2004-03-25 Thread Nick Chalko
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...

2004-03-25 Thread Adam Jack

   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...

2004-03-25 Thread Michael Davey
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...

2004-03-25 Thread Adam Jack
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]