httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Abele <>
Subject Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Date Mon, 16 Dec 2002 23:09:26 GMT
André Malo wrote:
> * Erik Abele wrote:
>>To quote you from another mail on the dev@ list: 'A feature that can't be
>>disabled is a *bug*' (Message-ID:
>><n2m-g.19snvq46nezxb$>). Therefore, I consider this
>>definitely as a bug ;-)
> ehm, yes ;-)
> *mumblesomething*

hehe ;-)

>>>However. I'm not happy with that solution, since it adds a dependency to
>>>the process that is (currently) not needed. If we consider sometime not to
>>>distribute the entity files (that are only required for the transformation
>>>process), we may simply re-add the stuff, that's now in.
>>>The .dtds are already referenced absolute and with publicId, so there's no
>>Well, I'm going fine with this; we don't _need_ it now, that's right, but I
>>just can't see how 8 (?) lines complicate the build process so much and IMO
>>'foreign' resources should be referenced to their original source instead of
>>referencing them with local copies, but that's more a personal thing...
> Hmm. seems really to be a question of taste. So I'm putting a +/- 0 ;-)

To be really honest: this might not the best possible solution for 
everybody, but I don't see it doing any harm, so +/- 0 from me too ;-)

>>However, another more important concern is Ants memory usage. After playing
>>with some entities I realized strong problems: just randomly touch some
>>files in the manual dir and add some entities (e.g. &copy;) to some of them.
>>Then build. I'm always getting OutOfMemory failures and can only build the
>>whole tree after calling several times. I don't know if it's
>>machine-dependent (I can currently build only on redhat8.0, P4/128MB, will
>>test it later with 1GB RAM on freebsd) but I would like to hear some other
>>experiences with this. Perhaps the conclusion is, that we have to back out
>>the whole entity-thing :-(
> Cannot reproduce it with first tests. But this may be dependant on my 
> "optimized" java call. I increased the thread stack size already some time 
> ago (while playing around with design improvements...)

fine, sounds good. I also couldn't recreate the mentioned problems on my 
home machine...

> i.e. the commandline options
> -Xmx128m -mx128m
> set the stack size to 128K instead of 64 (default in newer java machines, 
> at least on win32). found this on the xalan pages (I believe).

Ahh, interesting; didn't know that, but will try tomorrow. Perhaps this 
will eleminate some other problems I had with this machine ;-)


View raw message