Re: timeout
Adam R. B. Jack wrote:
BTW: Your request to have xdocs pages (for projects, etc.) built as the
come, really ought be doable w/o much change. Calling
ForrestDocumenter.documentModule or ForrestDocumenter.documentProject ought
have no dependencies. Either we write directly to the log directory
(possible) or we write to staging and sync. I don't quite know how to do
this to a staging area, and then sync ('cos there are N pages) but I'd like
to try, otherwise our site could accumulate a lot of flotsom and jetsom.
If you want to have a dig in, feel free. If this area is a little
'convoluted' and you'd like me to have a shot, no problem. I ought be get
there within the next week or so.
I'm travelling at the moment, and quite frankly until Gump gets back to
the point where I can experiment on a change with a edit/compile/debug
cycle measured in minutes instead of hours, all of my contributions will
be in the margins. Furthermore, my knowledge of Forrest is nearly
approximately zero at the moment.
My brief forray into ForrestDocumenter lead me to the conclusion that a
good percentage of that code is really producing things like tables and
not particularly Forrest specific.
A way to manage the flotsam and jetsam is to write everything to a
directory whose name is based on today's date. latest can be a
symbolic link to the current date. At the beginning of the run can be
some code to create the directory if it doesn't exist (and updating the
symbolic link as required), and to delete all but the last n
directories that may exist.
Anyway, my suggestion is that if you can get something which
approximately works, I can help complete it. And we can clearly leave
the static forrest code in place until there is something worth
replacing it.
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
Sam Ruby wrote:
Adam R. B. Jack wrote:
BTW: Your request to have xdocs pages (for projects, etc.) built as the
come, really ought be doable w/o much change. Calling
ForrestDocumenter.documentModule or ForrestDocumenter.documentProject
ought
have no dependencies. Either we write directly to the log directory
(possible) or we write to staging and sync. I don't quite know how to do
this to a staging area, and then sync ('cos there are N pages) but I'd
like
to try, otherwise our site could accumulate a lot of flotsom and jetsom.
If you want to have a dig in, feel free. If this area is a little
'convoluted' and you'd like me to have a shot, no problem. I ought be get
there within the next week or so.
I'm travelling at the moment, and quite frankly until Gump gets back to
the point where I can experiment on a change with a edit/compile/debug
cycle measured in minutes instead of hours, all of my contributions will
be in the margins. Furthermore, my knowledge of Forrest is nearly
approximately zero at the moment.
My brief forray into ForrestDocumenter lead me to the conclusion that a
good percentage of that code is really producing things like tables and
not particularly Forrest specific.
A way to manage the flotsam and jetsam is to write everything to a
directory whose name is based on today's date. latest can be a
symbolic link to the current date. At the beginning of the run can be
some code to create the directory if it doesn't exist (and updating the
symbolic link as required), and to delete all but the last n
directories that may exist.
Anyway, my suggestion is that if you can get something which
approximately works, I can help complete it. And we can clearly leave
the static forrest code in place until there is something worth
replacing it.
I'll see what I can do to install dynamic forrest on gump today as soon
as I receive a password for brutus.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: timeout
I'll see what I can do to install dynamic forrest on gump today as soon as I receive a password for brutus. I've forwarded a mail (from Sam) to both you and Stefan. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
I'm travelling at the moment, and quite frankly until Gump gets back to the point where I can experiment on a change with a edit/compile/debug cycle measured in minutes instead of hours, all of my contributions will be in the margins. Understood. Between TextDocument (uglycrude, but --text if you want it) and ForrestDocument (slow) we don't have a nice option for quick runs. Mind you, there are lots of things you could help with on the margins, giving us Pythonic/Gumpological input. :-) Furthermore, my knowledge of Forrest is nearly approximately zero at the moment. Mine too (of it's internals). I write simple XML docs (it's xdocs, using a subset of this http://xml.apache.org/forrest/document-v11.dtdx.html#document, that I coded into xdocs.py), and Forrest works generates HTML/sites. That was what I was hoping for. It takes too long for any human to care to wait for, which is unfortunately where things fall down. I never really wanted/expected humans to have/want to, that is just how they've worked out, since we have poor alternatives. My brief forray into ForrestDocumenter lead me to the conclusion that a good percentage of that code is really producing things like tables and not particularly Forrest specific. Yes, basically page after page of paragraphs/lists/tables. In part 'cos that is all we get with xdocs, in part that is all I think we need. I wish we could abstract the 'data gathering/page forming logic' of this out of class (so we could have HTML or xdoc outputs), and I might try. This code isn't 'bad', but I have a gut feeling it could be a lot better. If anybody has an itch to work with Cheetah, I am more than game to help build a TemplateDocumenter. I could stub one out, if folks were interested. A way to manage the flotsam and jetsam is to write everything to a directory whose name is based on today's date. latest can be a symbolic link to the current date. At the beginning of the run can be some code to create the directory if it doesn't exist (and updating the symbolic link as required), and to delete all but the last n directories that may exist. Any chance you could take a look back at my mail with subject '--dated'. (If you use eyebrowse, be warned, it's index may still be dorked for us.) I was hoping for something as simple as putting things into a @@DATE@@ directory, but Nick pointed out that I have RSS and Atom file that ought be kept in a fixed (dateless) location. [Hmm, maybe 'latest' satisfys this.] In passing, do you have views on us dotting RSS and Atom files throughout the hierarchy? I wanted to allow folks to subscribe to multiple channels (whilst keep coding simple) so I created different files for 'workspace', 'module', 'project' levels. If we didn't have these, we'd have far less issue with matching hierarchies (for RSS) with dates ones for HTML. Anyway, my suggestion is that if you can get something which approximately works, I can help complete it. And we can clearly leave the static forrest code in place until there is something worth replacing it. Sure, I'll get there, but it comes third. Work work, SVG work (having fun), then this. I won't forget though, and I'll keep this list abreast of progress. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
Adam R. B. Jack wrote: ... Yes, basically page after page of paragraphs/lists/tables. In part 'cos that is all we get with xdocs, in part that is all I think we need. I wish we could abstract the 'data gathering/page forming logic' of this out of class (so we could have HTML or xdoc outputs), and I might try. This code isn't 'bad', but I have a gut feeling it could be a lot better. If anybody has an itch to work with Cheetah, I am more than game to help build a TemplateDocumenter. I could stub one out, if folks were interested. I'd like to work on it, as I have used Velocity recently, and of course I work on Forrest... but I've still not tried again to run Gump. It's unfortunate given that I could do it easily... some time back :-( Ok, so I wanna Gump a subset. Where do I start with the current CVS Gumpy given a W2000 system? -- 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: timeout
I'd like to work on it, as I have used Velocity recently, and of course I work on Forrest... Cheetah seems a blur of Python and template, to ther extends that one can write templates that become Python classes. I started to wonder why a Python programmer would need a 'Python shorthand', and then figures I was clearly a Cheetah philistine, and am glad somebody else will tinker. :) but I've still not tried again to run Gump. It's unfortunate given that I could do it easily... some time back :-( If I recall, I think the main issues were portability (and the lack of some 'simple' scripts). Both these ought be resolved. That, and there are isues with gettign a full Gump environment (the packages being the main issue) and I don't know how to resolve that for new users. It didn't hit you before 'cos Gump didn'ty work before, it just loaded metadata. Maybe we need to work (again) on a minimal workspace. Sorry, do you mind just trying again letting us know the issues. Ok, so I wanna Gump a subset. Do you mean trim a workspace, or use a derivative of gump.xml (with local tweaks) and run a sub-set of the profile? If the later... you ought be able to pass a comma separated list of project (wildcarded) expressions, e.g. ant or kry*,xml*. The --quick (default for most scripts) ought not work on the complete stack, just the projects/modules it matches. Where do I start with the current CVS Gumpy given a W2000 system? I think these are still valid: http://wiki.apache.org/gump/GumpPython and: http://wiki.apache.org/gump/GumpScripts Please let us have feedback. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
