You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by André Malo <nd...@perlig.de> on 2002/09/23 05:55:32 UTC
[PATCH] build.xml (was: cvs commit: httpd-2.0/docs/manual/style/xsl common.xsl directiveindex.xsl moduleindex.xsl quickreference.xsl sitemap.xsl)
> nd 2002/09/22 20:40:12
>
> Modified: docs/manual sitemap.html.en sitemap.xml
> docs/manual/mod directives.xml index.xml quickreference.xml
> docs/manual/style modulesynopsis.dtd
> docs/manual/style/xsl common.xsl directiveindex.xsl
> moduleindex.xsl quickreference.xsl sitemap.xsl
> Removed: docs/manual/mod allmodules.xml
> Log:
> move module list into sitemap.xml
> allmodules.xml is no longer needed.
This requires a patch of build.xml
- Because of reasons I really don't understand the processor otherwise
runs out of memory (!?).
- sitemap.xml can't be validated any longer, because it's included as
Entity
nd
--
Real programmers confuse Christmas and Halloween because
DEC 25 = OCT 31. -- Unknown
(found in ssl_engine_mutex.c)
Re: [PATCH] build.xml
Posted by André Malo <nd...@perlig.de>.
* Joshua Slive wrote:
> André Malo wrote:
>
>>
>> I've looked around a little bit and found a faa (frequently answered
>> answer ;-) at the xalan pages:
>
> Gosh. Who reads the documentation? Crazy! ;-)
hehe...
>> I think, when we separate the pages, which use document(...), so that
>> they are processed each for itself, we have a long working solution.
>> ^^^^^^^^^^^^^^^
>
> I would just say "one at a time", or "each on its own".
Ah, thank you :)
> But regardless,
> it does seem that is necessary. Perhaps we should reconsider merging
> allmodules with sitemap. That more than doubles the size of the glob
> that the processor needs to hold in memory.
really? I don't have actual values. My test were only binary (worked or
not...). However, after some days thinking about, holding a separate
allmodules.xml seems to be good idea at all.
Reverting the merge isn't a big deal.
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] build.xml
Posted by Joshua Slive <jo...@slive.ca>.
André Malo wrote:
>
> I've looked around a little bit and found a faa (frequently answered
> answer ;-) at the xalan pages:
Gosh. Who reads the documentation? Crazy! ;-)
>
> I think, when we separate the pages, which use document(...), so that
> they are processed each for itself, we have a long working solution.
> ^^^^^^^^^^^^^^^
I would just say "one at a time", or "each on its own". But regardless,
it does seem that is necessary. Perhaps we should reconsider merging
allmodules with sitemap. That more than doubles the size of the glob
that the processor needs to hold in memory.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] build.xml
Posted by André Malo <nd...@perlig.de>.
* Joshua Slive wrote:
>> - Because of reasons I really don't understand the processor
>> otherwise
>> runs out of memory (!?).
>
> I'll commit this, but I'm note entirely happy. It seems like things
> might be getting a little complex and fragile. We may need to spend
> some time simplifying and optimizing.
I've looked around a little bit and found a faa (frequently answered
answer ;-) at the xalan pages:
<http://xml.apache.org/xalan-j/faq.html#faq-18>
I guess all our caching problems aren't caused by ant rather than
Xalan-J. First I tried to simplify the loops. (rebuilt them to work
iterative instead of recursive, using a xalan extension
xalan:nodeset()). Didn't help. Splitted the loops and tried to turn off
caching with the PI given in the faq above - didn't help. piplining and
incremental processing aren't the way to do, I think.
My last trial was to increase the jvm hep size, that worked, but can't
be the final solution, I guess ;-( I inserted in build2.cmd:
%JAVA_HOME%\bin\java -Xmx128m -mx128m
^^^^^^^^^^^^^^^^
64 seems to be the default value.
> One thing we could do -- at least for the index pages -- is to change
> the xml file to directly include the page-specific stylesheet and have
> that stylesheet get what it needs from common.xsl with an include.
> (Right now we have the reverse; every page includes common.xsl which
> in turn includes the specific stylesheets.) It seems to be a waste
> for every page to need to process every stylesheet.
yep. but this will help only a little bit, I guess.
I think, when we separate the pages, which use document(...), so that
they are processed each for itself, we have a long working solution.
^^^^^^^^^^^^^^^
(correct English? :)
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #########################
[ $japh =~ /{(.)}/] -> [0] => map $_ -> () # André Malo #
=> @japh; # http://www.perlig.de/ #
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] build.xml (was: cvs commit: httpd-2.0/docs/manual/style/xsl
common.xsl directiveindex.xsl moduleindex.xsl quickreference.xsl sitemap.xsl)
Posted by Joshua Slive <jo...@slive.ca>.
André Malo wrote:
>
> This requires a patch of build.xml
>
> - Because of reasons I really don't understand the processor otherwise
> runs out of memory (!?).
> - sitemap.xml can't be validated any longer, because it's included as
> Entity
>
I'll commit this, but I'm note entirely happy. It seems like things
might be getting a little complex and fragile. We may need to spend
some time simplifying and optimizing.
One thing we could do -- at least for the index pages -- is to change
the xml file to directly include the page-specific stylesheet and have
that stylesheet get what it needs from common.xsl with an include.
(Right now we have the reverse; every page includes common.xsl which in
turn includes the specific stylesheets.) It seems to be a waste for
every page to need to process every stylesheet.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org