On 22 Feb 2006, at 20:32, Matt Rice wrote:
--- Richard Frith-Macdonald <[EMAIL PROTECTED]>
wrote:
On 19 Feb 2006, at 22:30, Riccardo wrote:
Hey all,
On Sunday, February 19, 2006, at 06:27 AM, Andrew
Ruder wrote:
Jeremy Cowgar said that he had problems because the
base library
creates/uses a user defaults database, and he didn't
want it doing
that... so I spent a little while making that
behavior optional ...
and you can pick up the new version from svn.
Setting the config value
'GNUSTEP_USER_DEFAULTS_DIR=:INTERNAL:' will
tell it not to use the external defaults database
while keeping all
the rest of the defaults functionality intact.
why not just have it instead of having to setup a
config entry just not have it create the defaults
database until something is written to defaults then
if his program doesn't use it, it won't ever be
created?
Not a problem ... but I expect people want it to not even try
accessing the directory ... which is the reason for the option to
turn it off completely.
on the whole split proposal though,
theres also NSProcessInfo which requires /proc or a
specificially built gnustep-base with the user_main
hack, making it impossible to use base in an init
system without hard coding the mounting of /proc....
though this isn't really a generic issue, and Andy
didn't mention NSProcessInfo being one of the level 2
classes.
I agree that the suggested split of classes doesn't make sense, but
NSProcessInfo is not really an issue ... the use of /proc etc is
purely a convenience for writing MacOS-X (previously OPENSTEP)
compatible code ... in the sense of having the same code build and
run the same in both platforms.
In the context of a standalone library ... the programmer just has to
call NSProcessInfo's initialisation method explicitly.
Apart from localisation, NSTimeZone is really the one class in the
base library where the absence of external resources is a real
annoyance. It can use the native timezone info, but that is *much*
slower and more memory hungry for anything dealing with timezone
abbreviations. That's because the GNUstep timezone info contains
files with pre-processed information that the class can read in ...
when using native zone information the class has to load and parse
*all* the individual timezone files to determine the available
abbreviations. So having the library without the resources will
run ... but will not be nearly as fast the first time it attempts to
do data/time things. Of course, it won't be any slower than other
implementations either, but it seems ironic that a standalone
'lightweight' installation means a slower more memory hungry one.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
