Re: libgnustep-base split proposal
On Wed, 22 Feb 2006 18:29:55 +, Richard Frith-Macdonald [EMAIL PROTECTED] said: Maybe all we really need here is FHS support in the make package so you can opt to install in FHS locations? And lots of publicity so people know about it. FWIW, Debian is currently handling the FHS issue by using a script to move files around after they are installed by gnustep-make, and using lots of symlinks. (This is just for packages installed by dpkg, installed into the System domain. Packages that are manually installed just using gnustep-make are installed normally.) So under Debian, there is a /usr/lib/libgnustep-base.so.1.11, and other libraries can be found under /usr/lib too. But if gnustep-make had better support for FHS locations, that would be helpful too. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 2006-02-26 03:12:10 +0100 Alex Perez [EMAIL PROTECTED] wrote: Hear, Hear! This should be the default location. The other gnustep junk can still live in /usr/gnustep or wherever else, but the libs should be in *STANDARD FHS LOCATIONS*. Uhm ... 'scuse me, this is all good and stuff, BUT... ... NOT everyone is using GNUstep on a system that adheres to a _LINUX_ specific standard. Bash me, if you want, I just checked the FHS' web site, and as far as I can see, the only system this so called standard is targeting is Linux. Or rather the other way around, Linux is the only system 'using' the FHS. So calling the FHS a standard is a bit over the top. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Chris Vetter wrote: On 2006-02-26 03:12:10 +0100 Alex Perez [EMAIL PROTECTED] wrote: Hear, Hear! This should be the default location. The other gnustep junk can still live in /usr/gnustep or wherever else, but the libs should be in *STANDARD FHS LOCATIONS*. Uhm ... 'scuse me, this is all good and stuff, BUT... ... NOT everyone is using GNUstep on a system that adheres to a _LINUX_ specific standard. Bash me, if you want, I just checked the FHS' web site, and as far as I can see, the only system this so called standard is targeting is Linux. Or rather the other way around, Linux is the only system 'using' the FHS. So calling the FHS a standard is a bit over the top. Maybe using pkg-config would solve this... although I do not know how portable pkg-config is to other platforms... Dennis -- It is not necessary to change. After all, survival is not mandatory. Dr. W. Edwards Deming ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On Sunday, February 26, 2006, at 03:49 PM, Chris Vetter wrote: Uhm ... 'scuse me, this is all good and stuff, BUT... ... NOT everyone is using GNUstep on a system that adheres to a _LINUX_ specific standard. Bash me, if you want, I just checked the FHS' web site, and as far as I can see, the only system this so called standard is targeting is Linux. Or rather the other way around, Linux is the only system 'using' the FHS. So calling the FHS a standard is a bit over the top. Finally, some wise words. Also, on other systems, FHS looks a bit out of place. -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 22 Feb 2006, at 19:58, Jeremy Cowgar wrote: On Feb 22, 2006, at 1:29 PM, Richard Frith-Macdonald wrote: I boggled when I read that ... then realised that my initial incomprehension was due to 20+ years experience programming on unix style systems ... it simply didn't occur to me that copying the library from one directory to another would be an issue for a developer (for a user, yes). GNUstep is by no means alone in putting its libraries in its own directories ... many packages (ssh, postgres etc) use their own subdirectories. It's not hard, obviously. But, what about when you upgrade your system, begin working on another system, copy from your development box to your deploy box, upgrade your servers, etc... It becomes a head ache trying to remember do this for this program, this special thing for that program, etc... All I am getting at is it would be nice to have an objective C library that installs w/no strings attached and allowed one to program in Objective C w/o knowing a thing about the existence of *anything* special or even the existence of GNUstep for that matter. A simple libobjcbase.so, a /usr/include/objc and be done with it. OK ... but my point is we already have that ... you just have to install it where you want it. But we don't install it where *you* want it by default. So what's a good solution? An alternative installer script to install it where you want it? Automatic use of symbolic links so it's installed in the normal location but you can also find it in (say) /usr/lib? Then on top of all that, yeah, I give my program to John Doe and say John Doe, you have to install gnustep-base, then copy this folder to that folder, then move the includes from here to there, then do this, then that, then compile my program, then copy it from here to the /usr/bin and put it's libs in /usr/lib, etc... Obviously *some* of that can be automated but... Now, John Doe is a new unix user. It get's harder. Now he is a windows user and it's really hard. Surely you just give him the prebuilt package :-) By the way, we gave considerable thought, when designing the new config system, to making it easy to provide standalone packages that people can just copy to their system and run without having to install anything. This was specially intended for windows users. You just have everything in one directory, the library finds it's config by looking in the same directory it's in, and the config tells it where resources are. However to address your eight stage example for the developer ... you have to install gnustep-base, then copy this folder to that folder, then move the includes from here to there, then do this, then that, then compile my program, then copy it from here to the /usr/bin and put it's libs in /usr/lib You say *some* can be automated, but steps 2 to 5 are unnecessary, so it's you have to install gnustep-base, then compile my program, then copy it from here to the /usr/bin and put it's libs in /usr/lib If you have a makefile, that's two stages you have to install gnustep-base, then 'make install' my program, If we made an alternative install script to install just library and headers in /usr/lib and /usr/include, its you have to install gnustep-base using alternative install script xxx then 'make install' my program, and the make file would omit -H and -L flags in the compile and not need to copy the library into place. I don't understand objections to having a great objc library that people can use. AFIK nobody has ever objected to that. I'm just trying to find out exactly what your problems are so we can do something to avoid them ... and it's sounding to me like we just need an alternative installation script to install stuff in the FHS locations ... something that's been on the roadmap for gnustep-make for quite a while now. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On Feb 22, 2006, at 2:22 AM, Richard Frith-Macdonald 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. It was also due to libraries being in odd places and Apache not knowing where to find them. It would have been much easier if there was a /usr/lib/libgnustep-base.so or something like that. Jeremy ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Richard/Andy,This gives me an idea. Instead of a split, why not simply make those DO classes non-functional given a parameter. This allow developers to use base as a library without the need for daemons, and it would avoid a messy and, possibly, unnatural, split in the base lib.Later, GJCGregory John Casamento-- Principal Consultant, Open Logic Corp. (A MD Corp.)## Maintainer of Gorm(IB) GUI(AppKit) for GNUstep.- Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED]To: Riccardo [EMAIL PROTECTED]Cc: Developer GNUstep gnustep-dev@gnu.orgSent: Wednesday, February 22, 2006 2:22:14 AMSubject: Re: libgnustep-base split proposalOn 19 Feb 2006, at 22:30, Riccardo wrote: Hey all, On Sunday, February 19, 2006, at 06:27 AM, Andrew Ruder wrote: Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a "standard library."Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X.Obviously the biggest problem with OS X is that it is not free.GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc..A typical developer not familiar with GNUstep sees these things and runs the other direction. this triggers some thoughts in my mind and some desires I have since long. On the other hand it uncover fears. Thus in this email I essentially don't take a position. Although it could be seen as I have one, if some conditions are met. Personally, the only think I have against this split is complication. I want to retain the current set-up for the typical user install (even more personally I'd desire a back/gui merge so that only two packages would exist: Foundation and AppKit). I also fear it could create inefficiencies int he code and generally I do like every much that ALL gnustep libraries stay in one tree and notspread around. ON the other side, I must admit that more than once I'd like to use objective-c as a "normal OOP" language, using basic stuff as collections and strings. POC for example, has some of these basic classes. Using gcc obj-c I have nothing. And I don't want all the big base library,daemons, etc. In that case I just need a "library" to install in /usr/lib if I can explain myself. Maybe even be able to making static binaries...You can do that now with the base library ... simply copy the sharedlibrary file into place rather than installing the whole base package.I doubt whether it works as a static library though ... last time Itried (some years ago) the static library faileddue to somedifference in the order in which things were loaded into the runtimewhich I failed to track down.Jeremy Cowgar said that he had problems because the base librarycreates/uses a user defaults database, and he didn't want it doingthat... 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:' willtell it not to use the external defaults database while keeping allthe rest of the defaults functionality intact.There are four ways to set config values ...1. Set default config values when you run 'configure' prior tobuilding gnustep-base (not recommended normally)2. Edit the system-wide config file /etc/GNUstep/GNUstep.conf3. Edit your personal config file .GNUstep.conf4. Use the GNUstepConfig() function to set it ... also allowing youto prevent the config files (2 and 3) being read. Thus if I had such a small "standard library" small and lean and even usable with POC (or mimicking some of what POC already has) I could use obj-c much more freely and also untied from GCC. We could extract some of our extensions to a library, clean up some of the classes to make small and lean objects (not NS* stuff) and then base the NS* stuff on them.The POC manages a *very* different dialect of ObjC and all theruntime stuff is different ... so core stuff right back to much ofNSObject would need changing if you want a library which does notneed GCC.The ideal does have a lot of appeal, but I fear it wouldbe far too much work,___Gnustep-dev mailing listGnustep-dev@gnu.orghttp://lists.gnu.org/mailman/listinfo/gnustep-dev___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 22 Feb 2006, at 10:20, Philippe C.D. Robert wrote: On 19.02.2006, at 17:12, Helge Hess wrote: On 19. Feb 2006, at 06:27 Uhr, Andrew Ruder wrote: Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Where did you get that conclusion I never heard about that one before! :-) I believe his point is a valid one. It would be nice to have some kind of a standard ObjC library which comes with gcc-objc and which provides some basic functionality needed in most applications. But I don't think splitting base would help a lot here, unless we're talking about a more tight integration with gcc, which would be very interesting... Whats problematic is that it isn't possible to go w/o it and run GNUstep binaries/libraries like a regular Unix tool. Thats one of the reasons why its currently not possible for OGo to switch to gstep-base. Exactly, this is IMO a severe drawback of GNUstep, even worse, a major show stopper (at least for me)! While there are obvious cases (attempting to use a name server daemon if there isn't one installed for instance) where there are problems ... and I'm all in favour of improving anything like that where possible, I have to say again that it is simply NOT TRUE that you can't just compile/link with the base library and run a tool. This problem *USED* to exist because the NSCharacterSet data used to be held in external files and without NSCharacterSet working properly, string handling doesn't work properly ... so everything is messed up. But this was changed about a year ago, it's not been true for a long time now. I'm sure there are rough edges where behavior of some classes is not ideal and needs fixing, but there are no 'show stoppers' that I have heard of. Most likely what we have are usability issues ... where we have rough edges because either nobody has reported problems or because a few (FHS support in 'make install' for instance) just haven't been dealt with yet. And those rough edges might seem like show stoppers to people who don't know how to deal with them ... so we need to know about them and smooth them off. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 23 Feb 2006, at 01:04, Gregory John Casamento wrote: Richard/Andy, This gives me an idea. Instead of a split, why not simply make those DO classes non-functional given a parameter. This allow developers to use base as a library without the need for daemons, and it would avoid a messy and, possibly, unnatural, split in the base lib. Well that's really what I was proposing ... except that we mostly don't need to make anything non-functional, and where a feature is non functional, we don't need a parameter to make it that way. As it currently stands, all you *need* to use base as a library without daemons (or any resource files) is to delete/not-install those daemons and resource files. What we need a parameter for is to get base to refrain from issueing warning messages (you can already disable warning/error logs of course, but it would be nice to only disable warnings about missing external resource files). Actually ... I'm getting the impression that the best thing to do might just be not warn about missing external resources if the library is installed in a path other than System/Library/Libraries ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 22 Feb 2006, at 20:32, Matt Rice wrote: 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? I did that... in svn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 22. Feb 2006, at 19:29 Uhr, Richard Frith-Macdonald wrote: I boggled when I read that ... then realised that my initial incomprehension was due to 20+ years experience programming on unix style systems ... it simply didn't occur to me that copying the library from one directory to another would be an issue for a developer (for a user, yes). GNUstep is by no means alone in putting its libraries in its own directories ... many packages (ssh, postgres etc) use their own subdirectories. Well, there is a reason that FHS was invented and that Debian is so popular. The OGo installation targets system adminstrators and they expect to find stuff in known/consistent places (they even wonder why there is nothing in /var/php/ ;-). And really, there is no good reason not to do it the standard way (on the Linux platform). I really don't know how to address that as a problem. Of course we could provide a script to copy the library ... but then people would need to know about the script. Honestly I can't see a reason why libgstep-base and associated resources should be installed into any other place but /usr/local or / usr as per FHS. This should be the default location. Even if GNUstep.sh is being used (which would be searched first when its sourced). The GNUstep hierarchy is IMO appropriate for a) ultra power users wanting the full flexibility of self contained environments (we do this occasionally, but less all the time due to the invention of Linux VServer) b) user-level desktop applications (I agree that a GNUmail.app should live in some /Applications directory, not in ~/bin ...) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 2/22/06, Richard Frith-Macdonald [EMAIL PROTECTED] wrote: [snip] I'm just trying to find out exactly what your problems are so we can do something to avoid them ... and it's sounding to me like we just need an alternative installation script to install stuff in the FHS locations ... something that's been on the roadmap for gnustep-make for quite a while now. Maybe a script called 'gnustep-config' can help. People can find the header and library with 'gnustep-config --cflags' and 'gnustep-config --libs'. It is used in many libraries. Yen-Ju ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Hi Richard, On 23.02.2006, at 08:49, Richard Frith-Macdonald wrote: Whats problematic is that it isn't possible to go w/o it and run GNUstep binaries/libraries like a regular Unix tool. Thats one of the reasons why its currently not possible for OGo to switch to gstep-base. Exactly, this is IMO a severe drawback of GNUstep, even worse, a major show stopper (at least for me)! While there are obvious cases (attempting to use a name server daemon if there isn't one installed for instance) where there are problems ... and I'm all in favour of improving anything like that where possible, I have to say again that it is simply NOT TRUE that you can't just compile/link with the base library and run a tool. This problem *USED* to exist because the NSCharacterSet data used to be held in external files and without NSCharacterSet working properly, string handling doesn't work properly ... so everything is messed up. But this was changed about a year ago, it's not been true for a long time now. I'm sure there are rough edges where behavior of some classes is not ideal and needs fixing, but there are no 'show stoppers' that I have heard of. Most likely what we have are usability issues ... where we have rough edges because either nobody has reported problems or because a few (FHS support in 'make install' for instance) just haven't been dealt with yet. And those rough edges might seem like show stoppers to people who don't know how to deal with them ... so we need to know about them and smooth them off. That's good to hear. So you are saying that one can copy solely the base .so to e.g. /usr/local/lib/ and it just works (w/o DO of course)? -Phil -- Philippe C.D. Robert http://www.nice.ch/~phip ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 19.02.2006, at 17:12, Helge Hess wrote: On 19. Feb 2006, at 06:27 Uhr, Andrew Ruder wrote: Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Where did you get that conclusion I never heard about that one before! :-) I believe his point is a valid one. It would be nice to have some kind of a standard ObjC library which comes with gcc-objc and which provides some basic functionality needed in most applications. But I don't think splitting base would help a lot here, unless we're talking about a more tight integration with gcc, which would be very interesting... Whats problematic is that it isn't possible to go w/o it and run GNUstep binaries/libraries like a regular Unix tool. Thats one of the reasons why its currently not possible for OGo to switch to gstep-base. Exactly, this is IMO a severe drawback of GNUstep, even worse, a major show stopper (at least for me)! cheers, -Phil -- Philippe C.D. Robert http://www.nice.ch/~phip ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 22 Feb 2006, at 17:42, Jeremy Cowgar wrote: On Feb 22, 2006, at 2:22 AM, Richard Frith-Macdonald 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. It was also due to libraries being in odd places and Apache not knowing where to find them. It would have been much easier if there was a /usr/lib/libgnustep-base.so or something like that. I boggled when I read that ... then realised that my initial incomprehension was due to 20+ years experience programming on unix style systems ... it simply didn't occur to me that copying the library from one directory to another would be an issue for a developer (for a user, yes). GNUstep is by no means alone in putting its libraries in its own directories ... many packages (ssh, postgres etc) use their own subdirectories. I really don't know how to address that as a problem. Of course we could provide a script to copy the library ... but then people would need to know about the script.And documentation is presumably not the issue, since there is already documentation telling you how to set up the LD_LIBRARY_PATH environment variable or /etc/ld.so.conf Maybe all we really need here is FHS support in the make package so you can opt to install in FHS locations? And lots of publicity so people know about it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
--- 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? note the defaults creation also has/had the side effect of creating the defaults database during make when running plmerge etc, and its generally not expected make will create things outside of the build dir and is disallowed on certain dists like gentoo... 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. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 19 Feb 2006, at 22:30, Riccardo wrote: Hey all, On Sunday, February 19, 2006, at 06:27 AM, Andrew Ruder wrote: Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with OS X is that it is not free. GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. A typical developer not familiar with GNUstep sees these things and runs the other direction. this triggers some thoughts in my mind and some desires I have since long. On the other hand it uncover fears. Thus in this email I essentially don't take a position. Although it could be seen as I have one, if some conditions are met. Personally, the only think I have against this split is complication. I want to retain the current set-up for the typical user install (even more personally I'd desire a back/gui merge so that only two packages would exist: Foundation and AppKit). I also fear it could create inefficiencies int he code and generally I do like every much that ALL gnustep libraries stay in one tree and not spread around. ON the other side, I must admit that more than once I'd like to use objective-c as a normal OOP language, using basic stuff as collections and strings. POC for example, has some of these basic classes. Using gcc obj-c I have nothing. And I don't want all the big base library,daemons, etc. In that case I just need a library to install in /usr/lib if I can explain myself. Maybe even be able to making static binaries... You can do that now with the base library ... simply copy the shared library file into place rather than installing the whole base package. I doubt whether it works as a static library though ... last time I tried (some years ago) the static library failed due to some difference in the order in which things were loaded into the runtime which I failed to track down. 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. There are four ways to set config values ... 1. Set default config values when you run 'configure' prior to building gnustep-base (not recommended normally) 2. Edit the system-wide config file /etc/GNUstep/GNUstep.conf 3. Edit your personal config file .GNUstep.conf 4. Use the GNUstepConfig() function to set it ... also allowing you to prevent the config files (2 and 3) being read. Thus if I had such a small standard library small and lean and even usable with POC (or mimicking some of what POC already has) I could use obj-c much more freely and also untied from GCC. We could extract some of our extensions to a library, clean up some of the classes to make small and lean objects (not NS* stuff) and then base the NS* stuff on them. The POC manages a *very* different dialect of ObjC and all the runtime stuff is different ... so core stuff right back to much of NSObject would need changing if you want a library which does not need GCC. The ideal does have a lot of appeal, but I fear it would be far too much work, ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On Feb 19, 2006, at 2:35 AM, Richard Frith-Macdonald wrote: On 19 Feb 2006, at 05:27, Andrew Ruder wrote: Hello all, Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with OS X is that it is not free. GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. A typical developer not familiar with GNUstep sees these things and runs the other direction. Is there actually real evidence of the above? If so I think we need to spend some time on publicity/education to let people know that the problems are almost entirely imaginary. Perhaps an introduction telling people how things can be used with no setup at all, and removal of a few warnings about missing setup. Me. I wrote an app that was a FastCGI web based app, wanted to write it in Obj C, have no use for ~/GNUstep, etc... It posed problems making it work in the forked, no env var, environment of Apache. I have another utility that was very easy and a pleasure to develop in Obj C that is nothing more than a command line utility that takes an EDI file (X12 837), parses, the compares the claim numbers to those in another file, and writes the new file out. It splits large files into smaller ones, updating cross-ref checks, numerical checks, counts, etc... That has no use either for ~/GNUstep/ and it poses problems for me saying, Here Luke, run this on your box to split the file. Jeremy ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
I think it's a great idea! On Feb 19, 2006, at 12:27 AM, Andrew Ruder wrote: Hello all, Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with OS X is that it is not free. GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. A typical developer not familiar with GNUstep sees these things and runs the other direction. We are throwing away a tremendous opportunity here, you have lots of developers who *could* be using a large chunk of GNUstep regardless if they are not interested in the full GNUstep environment. Instead they waste their time (no offense intended) on libFoundation and other such OpenStep-like API implementations, because GNUstep is not flexible enough for their needs. We can easily fill the role that libFoundation and derivatives are made to fill. Why is there any more than a single free Foundation implementation being developed right now? In essence, I'd like to propose that the -base library be split to fill this role. Now, since you're still reading :) what I've discovered over the course of the last couple weeks is that *most* of GNUstep really is just an object library. I started by separating out the following files: NSConnection.m NSDistantObject.m NSDistributedLock.m NSDistributedNotificationCenter.m NSMessagePort.m NSMessagePortNameServer.m NSPortCoder.m NSPort.m NSPortMessage.m NSPortNameServer.m NSSocketPort.m NSSocketPortNameServer.m The distributed objects make GNUstep more than just an objects library due to the additional overhead of the daemons. The only two files besides these that didn't fit in the just a library paradigm were: NSBundle.m NSUserDefaults.m Some parts of NSPathUtilities.m Now, these were *especially* tricky to remove from -base since they are used everywhere. After spending some considerable time (and lots of late nights ;)) I managed to get them removed in a manner that should allow them to be re-added in a library on top of -base. For the rest of this email I will refer to the eventual object library made out of the remaining files (NSString, NSDictionary, etc..) as level1 and the above more-GNUstep-environment-centric files as level2 The first change to level1 was to inventory exactly what it was looking up in defaults and from NSBundle to guage what exactly needed to be abstracted. In the end, I decided the best implementation would be to abstract all the uses into a GSDefaults class. The GSDefaults class is quite simple: @interface GSDefaults : NSObject [...] /** * Resource path for level 1 base */ - (NSString *)baseResourcePath; /** * Resource path for additions base */ - (NSString *)additionsResourcePath; [...] @end Of course, there are additional methods to deal with the other defaults used throughout -base. After the split, the GSDefaults in level1 could simply return the results obtained from ./configure, in level2 a category would be created that could also obtain this information from NSUserDefaults. If anyone has any specific objections to any part of this proposal, please reply with specific reasons why and how you think it could be done better. I'd like to begin work on -base by abstracting uses of NSBundle and NSUserDefaults into an additional class. With NSBundle and NSUserDefaults removed from most of -base, they can slide out into another library. The distributed objects and associated daemons would go with them or into an additional library. Also, it may be that other classes more properly belong in the environment-oriented library (NSUndoManager, the formatters, etc.), but I believe NSBundle and NSUserDefaults will be the most difficult and should be targeted first. As far as compilation against this reformulated -base, -make will simply change what it is linking against. I would like to eventually get level1 to have the ability to compile with full FHS compliance (/usr/lib, /usr/include, /usr/share, pkg-config for compiling/linking) but that is only an issue after the split is made. After that I will be personally reviving as many of the obj-c bindings projects for various libraries that I can find. Making obj-c a first class citizen on linux that plays nicely with a normal system setup = more eventual steppers (the next logical step after discovering obj-c is the great use of it by -gui, imo). Any thoughts? And as always, I will be willing to back up my suggestions/etc. with the code/effort needed to implement it ;). There is of course interest in this kind of project, I think. Cheers, Andrew Ruder And P.S., I really *do* have a *severely* hacked -base on my system right now that I can link against and run programs with no environment
Re: libgnustep-base split proposal ... alternative ideas
On 19. Feb 2006, at 10:21 Uhr, Richard Frith-Macdonald wrote: I don't think libFoundation is more flexible than GNUstep-base ... rather it's different, and I don't really see why gnustep needs to try to 'beat' it. I agree. For me lF is a bit more flexibile since I can change anything I want while I must deal with GNUstep people for gstep-base changes ;-) But this should be much better now because people (like me?) can get own branches in Svn. No? However, if that's what you want, it might be good to identify *exactly* why some people prefer it. As written in the other mail, some is actually just OGo and I can summarize some reasons if there is interest (but I've already explained most of them in the past). I've heard its string handling is fast but non-unicode (haven't looked for ages), perhaps it's the memory footprint and speed of strings? I don't expect that libFoundation is particulary faster or slower on strings than GNUstep. Why should Unicode matter for that? (don't you have 8-bit NSString cluster subclasses?) What I found when I tried a SOPE app with gnustep-base a while ago that lF was quite a bit faster. But I _never_ investigated the reason, so it might be something trivial to fix (it was actually you who suggested that it might be due to 8-bit strings, but I don't think thats very likely). Thats part of the problem moving to gstep-base, I honestly don't have the time to investigate such issues, even if they might be trivial changes inside gstep-base. I'm not sure about flexibility ... I often think we may be too flexible. I don't really mean that we should reduce that flexibility, but I do think we need to look into how we can make it really, really simple to manage. Agreed. Linux FHS installation (really just needs implementing in gnustep- make) If that would be in FHS it would be AWESOME for us :-) We currently use rather wicked hacks to accomplish that. Resource-free library usage I don't think that resource-free is the most important thing. The important thing is that gstep-base looks up the resources in the appropriate place, which would be [prefix]/share/gstep-base-1.12/... This is already implemented? Along with proper versioning? Also note that FHS and NeXT-style directory names are most likely different, eg [gs-prefix]/Library/WebServerResources vs [prefix]/share/www Same for application names. Expecially because NeXT naming never includes versions while FHS tools need to. Eg: [gs-prefix]/WOApps/OpenGroupware.woa vs [prefix]/sbin/ogo-webui-1.1 Summary: doing FHS properly is quite tricky and automatic approaches are most likely going to suck ;-) We also aim is to cut down on use of environment variables (we have already done that somewhat) by putting them in the config file ... though where MacOS-X uses environment variables we need to retain compatibility. Actually we have three modes here: a) env variables are set = search GNUstep environment b) not set = use just FHS c) on MacOSX = use MacOSX ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal ... alternative ideas
On 2/19/06, Richard Frith-Macdonald [EMAIL PROTECTED] wrote: On 19 Feb 2006, at 05:27, Andrew Ruder wrote: [snip] Possible setups might be ... Linux FHS installation (really just needs implementing in gnustep-make) I guess his point is that someone may just want to compile GNUstep-base as libgnustep-base.so and install it in /usr/local/lib and link it without the whole GNUstep/ directories. In this way, it might be easier to ship something in binary format. If this can be done, a document probably will do. Yen-Ju [snip] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Hey all, On Sunday, February 19, 2006, at 06:27 AM, Andrew Ruder wrote: Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with OS X is that it is not free. GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. A typical developer not familiar with GNUstep sees these things and runs the other direction. this triggers some thoughts in my mind and some desires I have since long. On the other hand it uncover fears. Thus in this email I essentially don't take a position. Although it could be seen as I have one, if some conditions are met. Personally, the only think I have against this split is complication. I want to retain the current set-up for the typical user install (even more personally I'd desire a back/gui merge so that only two packages would exist: Foundation and AppKit). I also fear it could create inefficiencies int he code and generally I do like every much that ALL gnustep libraries stay in one tree and not spread around. ON the other side, I must admit that more than once I'd like to use objective-c as a normal OOP language, using basic stuff as collections and strings. POC for example, has some of these basic classes. Using gcc obj-c I have nothing. And I don't want all the big base library,daemons, etc. In that case I just need a library to install in /usr/lib if I can explain myself. Maybe even be able to making static binaries... Thus if I had such a small standard library small and lean and even usable with POC (or mimicking some of what POC already has) I could use obj-c much more freely and also untied from GCC. We could extract some of our extensions to a library, clean up some of the classes to make small and lean objects (not NS* stuff) and then base the NS* stuff on them. That is just my 2 cents, have fun, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On 2006-02-19 17:12:20 +0100 Helge Hess [EMAIL PROTECTED] wrote: [...] (though I have the impression that gstep-base still contains too much GS* stuff). [...] Amen to that. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
libgnustep-base split proposal
Hello all, Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with OS X is that it is not free. GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. A typical developer not familiar with GNUstep sees these things and runs the other direction. We are throwing away a tremendous opportunity here, you have lots of developers who *could* be using a large chunk of GNUstep regardless if they are not interested in the full GNUstep environment. Instead they waste their time (no offense intended) on libFoundation and other such OpenStep-like API implementations, because GNUstep is not flexible enough for their needs. We can easily fill the role that libFoundation and derivatives are made to fill. Why is there any more than a single free Foundation implementation being developed right now? In essence, I'd like to propose that the -base library be split to fill this role. Now, since you're still reading :) what I've discovered over the course of the last couple weeks is that *most* of GNUstep really is just an object library. I started by separating out the following files: NSConnection.m NSDistantObject.m NSDistributedLock.m NSDistributedNotificationCenter.m NSMessagePort.m NSMessagePortNameServer.m NSPortCoder.m NSPort.m NSPortMessage.m NSPortNameServer.m NSSocketPort.m NSSocketPortNameServer.m The distributed objects make GNUstep more than just an objects library due to the additional overhead of the daemons. The only two files besides these that didn't fit in the just a library paradigm were: NSBundle.m NSUserDefaults.m Some parts of NSPathUtilities.m Now, these were *especially* tricky to remove from -base since they are used everywhere. After spending some considerable time (and lots of late nights ;)) I managed to get them removed in a manner that should allow them to be re-added in a library on top of -base. For the rest of this email I will refer to the eventual object library made out of the remaining files (NSString, NSDictionary, etc..) as level1 and the above more-GNUstep-environment-centric files as level2 The first change to level1 was to inventory exactly what it was looking up in defaults and from NSBundle to guage what exactly needed to be abstracted. In the end, I decided the best implementation would be to abstract all the uses into a GSDefaults class. The GSDefaults class is quite simple: @interface GSDefaults : NSObject [...] /** * Resource path for level 1 base */ - (NSString *)baseResourcePath; /** * Resource path for additions base */ - (NSString *)additionsResourcePath; [...] @end Of course, there are additional methods to deal with the other defaults used throughout -base. After the split, the GSDefaults in level1 could simply return the results obtained from ./configure, in level2 a category would be created that could also obtain this information from NSUserDefaults. If anyone has any specific objections to any part of this proposal, please reply with specific reasons why and how you think it could be done better. I'd like to begin work on -base by abstracting uses of NSBundle and NSUserDefaults into an additional class. With NSBundle and NSUserDefaults removed from most of -base, they can slide out into another library. The distributed objects and associated daemons would go with them or into an additional library. Also, it may be that other classes more properly belong in the environment-oriented library (NSUndoManager, the formatters, etc.), but I believe NSBundle and NSUserDefaults will be the most difficult and should be targeted first. As far as compilation against this reformulated -base, -make will simply change what it is linking against. I would like to eventually get level1 to have the ability to compile with full FHS compliance (/usr/lib, /usr/include, /usr/share, pkg-config for compiling/linking) but that is only an issue after the split is made. After that I will be personally reviving as many of the obj-c bindings projects for various libraries that I can find. Making obj-c a first class citizen on linux that plays nicely with a normal system setup = more eventual steppers (the next logical step after discovering obj-c is the great use of it by -gui, imo). Any thoughts? And as always, I will be willing to back up my suggestions/etc. with the code/effort needed to implement it ;). There is of course interest in this kind of project, I think. Cheers, Andrew Ruder And P.S., I really *do* have a *severely* hacked -base on my system right now that I can link against and run programs with no environment variables, config files, or GNUstep/* directory structure ;) -- Andrew Ruder [EMAIL PROTECTED] http://www.aeruder.net
Re: libgnustep-base split proposal
On 19 Feb 2006, at 05:27, Andrew Ruder wrote: Hello all, Objective-C is an incredible programming language, but right now the most crippling factor for its widespread use is the lack of a standard library. Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with OS X is that it is not free. GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. A typical developer not familiar with GNUstep sees these things and runs the other direction. Is there actually real evidence of the above? If so I think we need to spend some time on publicity/education to let people know that the problems are almost entirely imaginary. Perhaps an introduction telling people how things can be used with no setup at all, and removal of a few warnings about missing setup. We are throwing away a tremendous opportunity here, you have lots of developers who *could* be using a large chunk of GNUstep regardless if they are not interested in the full GNUstep environment. Instead they waste their time (no offense intended) on libFoundation and other such OpenStep-like API implementations, because GNUstep is not flexible enough for their needs. We can easily fill the role that libFoundation and derivatives are made to fill. Why is there any more than a single free Foundation implementation being developed right now? In essence, I'd like to propose that the -base library be split to fill this role. I'm not convince that splitting is necessary or desirable. On the downside, a splitup would be likely to add overall complexity and make things less maintainable, would require additional work to put in place, and might put off users by confusing them by making it less clear what features are available in the software. IMO our focus should be on trying to make things ever simpler to use so that they 'just work' rather than trying to pull out subsets of functionality for other uses. Now, since you're still reading :) what I've discovered over the course of the last couple weeks is that *most* of GNUstep really is just an object library. I started by separating out the following files: NSConnection.m NSDistantObject.m NSDistributedLock.m NSDistributedNotificationCenter.m NSMessagePort.m NSMessagePortNameServer.m NSPortCoder.m NSPort.m NSPortMessage.m NSPortNameServer.m NSSocketPort.m NSSocketPortNameServer.m The distributed objects make GNUstep more than just an objects library due to the additional overhead of the daemons. For me, distributed objects are one of the 'killer' features of the base library and the desire to use DO is perhaps the main reason I started GNUstep development! There do seem to be some people who just hate daemons, but even if you hate daemons that's no reason to get rid of DO since you can use it without them. What does need a daemon is NSDistributedNotificationCenter and NSSocketPortNameServer. Logically if you want to avoid daemons then those are the only bits of functionality you remove. Alternatively you could says'not running daemons just loses you distributed notifications and inter-host service lookup). \ The only two files besides these that didn't fit in the just a library paradigm were: NSBundle.m Hmm ... not sure why you lump NSBundle in here ... to my mind it's library code and doesn't *use* external resources, rather it makes external resources available. NSUserDefaults.m Some parts of NSPathUtilities.m Now, these were *especially* tricky to remove from -base since they are used everywhere. After spending some considerable time (and lots of late nights ;)) I managed to get them removed in a manner that should allow them to be re-added in a library on top of -base. For the rest of this email I will refer to the eventual object library made out of the remaining files (NSString, NSDictionary, etc..) as level1 and the above more-GNUstep-environment-centric files as level2 The first change to level1 was to inventory exactly what it was looking up in defaults and from NSBundle to guage what exactly needed to be abstracted. In the end, I decided the best implementation would be to abstract all the uses into a GSDefaults class. The GSDefaults class is quite simple: @interface GSDefaults : NSObject [...] /** * Resource path for level 1 base */ - (NSString *)baseResourcePath; /** * Resource path for additions base */ - (NSString *)additionsResourcePath; [...] @end Of course, there are additional methods to deal with the other defaults used throughout -base. After the split, the GSDefaults in level1 could simply return the results obtained from ./configure, in level2 a category would be created that could also obtain this information from NSUserDefaults. NSUserDefaults is already capable of running a. with a read only defaults file b. with no defaults file. So what is the point of
