Re: gnustep-make experiment
On Jan 24, 2007, at 15:10, Matt Rice wrote: I've come across at least 2 instances of needing the environment variables GDL2 needs to attempt to link to the Gorm libraries to see if it should enable building of the GDL2 Gorm palette and in porting aquaterm, and the gnuplot adaptor for aquaterm, it needs to also look for a lib in the GNUstep heirarchy to enable that. Maybe I'm entirely off-track, but I suppose whats being talked about is resource or bundle lookup :-) Which of course should also work in FHS settings. (ie Gorm should ideally work in plain FHS, no?) In OGo/SOPE we explicitly support both variants. If the GNUstep environment is sourced, we look in "GNUstep style pathes". If such a lookup fails (or if no environment is sourced), we continue searching in FHS locations (currently we hardcode /usr/local/ and /usr/, which obviously should be configurable using configure ...). Eg, a bundle "ABC.bundle" with resources a.gif/b.gif in GNUstep setup: (pathprefixlist) + Library /Bundles/ABC.bundle ABC /Resources /a.gif /b.gif In FHS: (pathprefixlist: /usr, /usr/local): /lib /abc-1.2.so /share /abc-1.2 /a.gif /b.gif Something like that ;-) Frameworks/bundles need to be "debundled" for FHS. Of course this can be done transparently in the NSBundle class. (though a separate class has the advantage that you can do FHS in combination with Cocoa). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 25, 2007, at 01:35, Matt Rice wrote: Anyhow i'll read this more thoroughly tomorrow, but my main problem with GNUstep.sh isn't actually technical at all, its the very first thing potential developers are going to see, so will be the first impression, and imho gives the impression of being strange because it is uncommon for a build system to depend on environment variables to function. Yes. The thing we do (... ;-) is to have a very small (hand written) 'configure' script which locates gnustep-make and writes a small 'config.make' files containing the relevant GS variables. Then all makefiles include that config.make file like this: -include config.make include $(GNUSTEP_MAKEFILES)/common.make If configure was run, it works w/o an environment. If it wasn't, it still works when GNUstep.sh is sourced. Which is quite nice IMHO ;-) [actually SOPE even embeds gstep-make and builds that as part of the 'configure' process if it can't find an installed gstep-make. Which makes the package completely self-contained, IMHO rather nice and similiar to autoconf] Possibly a 'make dist' should automatically generate such a configure script for a given project? Don't know. Probably there is a smart solution to the issue ;-) BTW: personally I'm not quite sure whether I understand that /etc/ GNUstep.conf thing :-) Is it necessary or optional? Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 26, 2007, at 24:04, David Ayers wrote: Personally I'd prefer to suspend the release until we have an environment that has a chance of remaining stable. It seems that we already require -make users to adapt thier projects for this release (I remeber you cleaning up many projects in SVN) and it seems they may need to adapt again for the subsequent release. Thats a good point. The last gstep-make release already gave us a major headache. Well, if the next one is explicitly marked as unstable it would be probably OK ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 25, 2007, at 07:15, Nicola Pero wrote: So we could have a small makefile fragment, let's call it find- gnustep.make, that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES to the best match. I'll write that makefile fragment, and it will be maintained inside gnustep-make. I don't get this one, you want to let the fragment search for gnustep- make? Where will it search? Isn't it expensive to search all locations everytime? I'm not convinced that this can happen automagically. My configure scripts has options to specify the gnustep-make installation you want to use (though of course it tests a few hardcoded locations as a fallback, but only once, at configure time). I think the 'configure' script should be maintained inside gnustep- make (the script which generates the config.make, usually not a real autoconf configure). You probably don't want to run configure everytime you call make ;-) BTW: personally I'm not quite sure whether I understand that /etc/ GNUstep.conf thing :-) Is it necessary or optional? It is necessary. The reason is that it allows gnustep-make and gnustep-base to have a common understanding of where the various directories are. The GNUstep.conf file describes the GNUstep filesystem and both gnustep-make and gnustep-base read it to know where to find things. Well, I'm talking about FHS, why would they need to know? In an FHS the gstep-base just needs a (fallback) prefix like other libraries to know where to look for associated files. Eg ./configure --prefix=/opt/gnustep-base-15 it would then know where to look for resources etc (because thats fixed in FHS). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Jan 26, 2007, at 02:58, Nicola Pero wrote: The other main change is that using GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, etc. in makefiles is now discouraged (because it won't work with Linux FHS). I wonder whether those are still useful in an FHS setup (eg let GNUSTEP_SYSTEM_ROOT point to /usr, GNUSTEP_LOCAL_ROOT to /usr/local, etc). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On Feb 8, 2007, at 14:13, Nicola Pero wrote: Here is an example -- put this at the top of your GNUmakefile, just before include $(GNUSTEP_MAKEFILES)/common.make -- GNUSTEP_MAKEFILES = $(word 1, \ $(wildcard /usr/GNUstep/System/Library/Makefiles) \ $(wildcard /var/lib/GNUstep/System/Library/Makefiles) \ $(wildcard /usr/local/GNUstep/System/Library/Makefiles) \ $(wildcard /opt/GNUstep/System/Library/Makefiles) \ $(wildcard /System/Library/Makefiles)) the result is that: * if you source GNUstep.sh or have your GNUstep environment properly setup, it gets used I suppose this hack would work for me, but I don't think that this is what admins expect from a GNU software package. Regular thing to do is ./configure --prefix, then make. Though of course the real fragment could also check for 'config.make', giving us both things, the automatic attempt and the configurability ;-) Well, I'm talking about FHS, why would they need to know? They would need to know because you can have different FHSes. Last time I checked there is only one file hierarchy standard! ;-) Well, really, this is something which belongs into the resource- lookup class (NSBundle and friends), not into an environment configuration (why would you ever want to switch that for a compiled binary!). I think Unixes only really differ in the PREFIX? Then we have Windows, completely different approach. MacOS is more like GNUstep and should not be treated as FHS (in contrary, on MacOS you probably also want to have some stuff in FHS, and some in MacOS layout). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
tagged SOPE 4.6beta, JOPE 1.2
Hi, I've tagged SOPE 4.6beta and bumped SOPE trunk to 4.7. Same goes for JOPE 1.2/1.3. Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash with new-style exceptions on FreeBSD amd64
On Mar 14, 2007, at 21:46, Michael Gardner wrote: I'm having problems using "new-style" exceptions with GNUstep on FreeBSD 6.2 (amd64). Does GNUstep support @throw, @catch?? Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use of libobjc from gcc 4.1 with MinGW
On Mar 21, 2007, at 17:52, Xavier Glattard wrote: Why the hell should libobjc be build as a dll ;-) Don't know whether this was really a joke ;-) Anyways, its *very* important that libobjc is built as a DLL if you build any other ObjC library/framework/bundle as a shared object. Otherwise you end up with multiple ObjC runtimes in a single application! This has cost me a LOT of time in the past because its an easy to make mistake. DLLs do not work like a shared library on Unix, they are much more separated (which is why you need the DLL *and* the static stub library to access the actual contents of a DLL). A DLL gets its own memory in Windows, its almost like a separate process. Notably thats actually a very cool feature for using Objective-C for Windows development. Because ObjC stuff is bound dynamically using the ObjC runtime, you don't need to fiddle as much with Windows linking as with plain C or C++. Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use of libobjc from gcc 4.1 with MinGW
On Mar 22, 2007, at 14:47, Xavier Glattard wrote: An other stupid question : why dont link _only_ gnustep-base to a static libobjc ? Because your Objective-C code needs to access functions contained in libobjc? So you would not had multiple objc runtime ! In theory the gnustep-base.dll could contain the libobjc, but then it would need to expose the libobjc API in its DLL wrapper AND you would need to tell all your makefiles that they don't need to link libobjc. And you would need to tell gcc/ld *not* to link libobjc automatically. This could be the hardest part since internal libraries of GCC have weird lookup hacks in the compiler (-L has different semantics). I don't think its a good idea to embed libobjc into gnustep-base. Though I'm not 100% sure ;-) Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problems with a custom constant string class
On 06.08.2007, at 00:37, Vincent Geddes wrote:
I am experimenting with Objective-C, and I am trying to create some
custom string classes.
The problem is that the gcc '-fconstant-string-class' option only
seems to allow custom classes which subclass `Object' (in the GNU
runtime).
Thats definitely wrong, the class doesn't matter (in both, gstep-base
and libFoundation NSConstantString inherits from NSObject, not Object).
The thing which _is_ required (for rather obvious reasons?) is the
constant ivar layout, which is
- Class isa;
- uchar *; // string
- uint;// length
gcc keeps on giving me the error `interface 'GooConstantString'
does not have valid constant string layout' if I subclass anything
other than `Object'.
Well, its because the ivar layout doesn't match the required constant
one?!
Interfaces:
@interface GooObject
...
@end
@interface GooString : GooObject
...
@end
@interface GooConstantString : GooString
{
Class isa;
char *c_string;
unsigned int len;
}
@end
Well, you don't give the ivar layout of your hierarchy (...?). Eg
that GooConstantString has an 'isa' ivar looks utterly wrong given
that any object needs to have an isa pointer (=> it has to be in your
root class). Maybe removing the 'isa' does the trick?
Greets,
Helge
--
Helge Hess
http://www.helgehess.eu/
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: KeyValueCoding compatibility issues
On 29.11.2007, at 22:23, David Ayers wrote: I understand that -base intends to track Cocoa while GDL2 and GSWeb aim at an ancient static API. I didn't look at Marcus' patch but on MacOS *both* KVC styles work at the same time, w/o any #define's or such. I assume it does so by checking whether the -setValue:forKey: method being invoked is the NSObject one (new style was not overridden), and if so, checking for - takeValue:forKey:. etc Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gprof and GNUstep?
On 04.12.2007, at 00:51, David Wetzel wrote: I tried to use gprof (hm, doesn't gprof require static binaries?) Don't know what you want to do, but for profiling I would suggest Valgrind/KCachegrind. Those are awesome. Well, and of course the Apple tools which are much faster than Valgrind. Though obviously applications will have different profiles depending on the foundation, depends on your specific bottleneck. Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On 01.03.2008, at 12:16, Nicola Pero wrote: make CC=g++ Hm, is there a special CC variable for CPP files? I think I wondered about that. It would be nice if gnustep-make was to automatically do all of this. Not that sure how to decide when to use C++ linking (is it when only CC_FILES are non-empty and all the other xxx_FILES are empty ?) and how to best automate it. Suggestions from C++ users are welcome. I qualify, unfortunately ;-) I also tried using gstep-make (on MacOSX) to compile a C++ project, but failed for reasons I don't remember anymore :-) I think activating C++ linking on non-empty CC_FILES should be OK. However, then CC_FILES should support compilation of .c files using g+ +. Eg: CC_FILES = \ a.cpp \ b.c If all that would work as-is on Windows to produce DLLs and such, it would be awesome! :-) Further it would be very nice if one could use the VS C++ compiler instead of g++. But that probably works already (CC=vcc++ or whatever) Hm, sweet. I think I give it another try today and see what was wrong with using gsmake for me. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On 01.03.2008, at 14:19, Helge Hess wrote: Hm, sweet. I think I give it another try today and see what was wrong with using gsmake for me. I just tried again with gsmake2 and everything works like a charm. The only thing I had to do was setting LD: ---snip--- LD=g++ -include GNUmakefile.preamble include $(GNUSTEP_MAKEFILES)/tool.make -include GNUmakefile.postamble ---snap--- I'm building the tool against two static (C++) libraries and it just works (on MacOSX 10.5 that is). Next thing would be to move the whole compilation on Windows to gsmake (currently its all VS projects). Maybe next weekend ;-) Thanks a lot! Helge PS: or should I move to SCons instead? ;-> -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On 02.03.2008, at 00:47, Jiva DeVoe wrote: Y'know... I looked at scons a year or so back.. This comment was an exclusive for Nicola ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On 08.03.2008, at 00:33, Gregory John Casamento wrote: Currently there is a lot of space which is marked as "reserved" in Apple's header files. This allows for future additions without changing the memory layout of the class which is what leads to ABI issues and subsequently the need for recompilation. Didn't that change in Objective-C 2.0 / the 64bit ABI? I thought the fragile base class problem is no more? (due to ivar indirection). The trick is to reserve just the right amount of space so that you don't make your classes needlessly big Well, the instances would be big, not the classes :-) Another potential solution to this problem, a bit different from the one above and probably a little risky is to simply have a void pointer in each class' ivar section and have it point to the appropriate structure when initialized during runtime. I *guess* thats how its implemented in ObjC 2.0. The class probably doesn't contain the ivars directly, but just a pointer to the ivar block of the specific class. But I didn't check. Maybe someone else knows more. The third option is to get gui to a point where it's ABI is actually stable. Consider that base hasn't changed much for a long time. The ABI unfortunately *did* change a lot, I outlined that in detail several times, please check the archives. Stable ABI is not just ivar layout, but also stable method behaviour and constant public API (no public methods added!/changed, no classes added/changed, no methods moved to categories etc etc). Having a stable ABI might even imply preserving certain kinds of bugs :-) I can't say how stable the GUI ABI is, but the base ABI definitely is NOT stable at all (just say KVC ;-). And *please* remember that I don't refer to the stability of the code, but to the stability of the ABI only. The stability of the code is very nice, so if you don't have a problem with staying at trunk / last branch, everything is awesome-O :-) We do. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
BTW: sometimes people don't know what ABI compatibility implies in the real world. The basic idea is that if I have a library and a tool, I can replace 'library' with any ABI compatible library and the tool still works. Stuff like crasher bugs being fixed. Say, I have installed gnustep-base 0.13.0 SOGo 0.7.3 If gnustep-base 0.17.0 would be ABI compatible to 0.13.0, I could just replace it and SOGo 0.7.3 would still work. This is much harder than API (not ABI) compat with 0.7.3. The latter only requires that I can recompile 0.7.3 against the new API version (fragile baseclass is just a small part in this scenario). A simple (admittedly constructed) example: lets say gnustep-base 0.13.0 had: @interface NSObject ... - (BOOL)isNotEmpty; @end Well, and SOGo might have choosen to *override* that method using a category. Which is perfectly valid in ObjC: @interface NSObject(SOGo) - (BOOL)isNotEmpty; @end Now gnustep-base 0.17.0 might have said: well, isNotEmpty really does not belong to NSObject!, lets refactor it! and move it to a category: @interface NSObject(GSAdditions) - (BOOL)isNotEmpty; @end Hey! We just b0rked ABI compat :-) SOGo's implementation of - isNotEmpty won't get used anymore, even though it worked just fine before. Apple's frameworks are in fact ABI compatible this way (well they sometimes have bugs in that, but overall they have great ABI compatibility). ABI compat bascially means you are not allowed to touch the code except in *very* well defined ways. (eg Apple reserves the NS* namespace, so they are 'allowed' to add classes and still have ABI downwards compat). Greets, Helge ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: EOFault / NSAutoreleasePool
On 11.03.2008, at 19:37, David Ayers wrote: if you are using ogo with gdl2... is that the case? No, OGo/SOPE uses its own variant of GDL1. But I assume that EOFault handling is more or less the same. Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: EOFault / NSAutoreleasePool
On 13.03.2008, at 16:35, Fred Kiefer wrote: It seems wrong to me to return a different selector from +instanceMethodForSelector: than from -methodForSelector:. Really? To me this is one of the most important core features of Objective-C. +instanceMethodForSelector: returns the method the class object provides, while -methodForSelector: returns the method the object actually uses. Which will usually be the class method, but in all kinds of dynamic language bridges, faults, etc, something else. Thats why I call ObjC an _object_ oriented programming language (in contrast to _class_ oriented languages like C++). Greets, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On 02.03.2008, at 00:42, Helge Hess wrote: I just tried again with gsmake2 and everything works like a charm. The only thing I had to do was setting LD: ---snip--- LD=g++ -include GNUmakefile.preamble include $(GNUSTEP_MAKEFILES)/tool.make -include GNUmakefile.postamble ---snap--- I'm building the tool against two static (C++) libraries and it just works (on MacOSX 10.5 that is). BTW: just added two subprojects and noticed a warning by libtool on MacOS 10.5. Doesn't seem to be critical though: ---snip--- /usr/bin/libtool -static -o obj/libZ1Core.a obj/z1ne_groupdav.o [...cut...] obj/Z1BootstrapNamedProps.o Z1Versit/obj/subproject.o Z1VersitMap/obj/subproject.o /usr/bin/libtool: warning same member name (subproject.o) in output file used for input files: Z1VersitMap/obj/subproject.o and: Z1Versit/ obj/subproject.o (due to use of basename, truncation, blank padding or duplicate input files) ---snap--- Don't know what/why it is, but I thought you might be interested ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [FOSDEM] Accepted: GNUstep+Etoilé+O penGroupware.org devroom
BTW: I think someone asked about hotels to avoid? :-) IMHO it would be a good thing if we would all stay in the same hotel, and maybe we could get an offer if we book as a group? I think the one selected by Nicola last year was quite good: http://www.hotel-argus.be/ Lars, can you organize that? Thanks, Helge -- Helge Hess http://helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSIMap
On Jun 10, 2011, at 6:14 AM, Richard Frith-Macdonald wrote: > is pretty much unique to you I think I was also assuming that -retain can return a different object. Otherwise it should be void (aka AddRef()) ... hh ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: More Windows stuff ... Gorm works ... sort of
On Mar 22, 2005, at 23:39, Gregory John Casamento wrote: Basically, the problem is that the palettes include symbols which are defined in the app. Just to grasp what the discussion is about - what kind of symbols are shared here? As long as you stick to the OO features of ObjC, all the linking is done by ObjC itself anyway (either class or method lookup) and you won't need weak symbols. I always considered that a major strength because it works around all that weaky-magic (which only really works well with ELF). 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: Glib runloop
On 16. Apr 2005, at 14:31 Uhr, Banlu Kemiyatorn wrote: Has anyone tried to unify Glib runloop and NSRunLoop? Well, yes, I did for GTKKit: http://mail.gnome.org/archives/gtk-devel-list/1999-March/msg00158.html but 1999 is quite a while ago ;-) Does this mean to reimplement NSRunLoop entirely? I think not necessarily, but it might be the easiest approach. I suppose a lot of things have changed in glib since 1999, so it might be rather easy to wrap the glib runloop as an NSRunLoop object. Personally I would be quite interested in such a work. 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: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On 8. Mai 2005, at 04:00 Uhr, Sheldon Gill wrote: P.S.: All the methods handling C strings are in the depreceated section now. How disappointing! :-| I suppose it was dropped because people did not understand what it is doing / good for and misused the methods (pretty similiar to - fileSystemRepresentationWithPath: which is seldom used). That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. Thats not the same. The -initWithCString: per definition takes strings in the system encoding, so if you are getting a value from a standard C-API (say readlink()) you now need to do: s = [NSString stringWithCString:buf encoding:[NSString defaultCStringEncoding]]; which obviously is a major inconvenience (and slowdown!) when interfacing with C. That is right. As I see it, they are rightly trying to move things forward for better internationalisation. I wonder how this is supposed to improve internationalization. A pretty good optimization which had _no_ drawback wrt internationalization was dropped in favor to a method which will hardly get used in practice. Instead they could have used their energy to add Cocoa API for supporting arbitary encodings without resorting to CoreFoundation. _That_ would have been an improvement for internationalization. Relying on a "default" encoding and using a C string isn't a good idea. Why not? This way its guaranteed to match. The "default" encoding is the encoding configured in your Unix environment. You know, modern Unix _has_ proper support for localization (see LANG, LC_xxx etc)? In the modern unix world you are much better off using UTF8 strings. In the modern windows world it should all be UTF16 Hm, yes? This is why UTF-8 or UTF-16 might be the default C-String encoding if this is the case. This is what -initWithCString: aka defaultCStringEncoding is made for! If your Unix does UTF-8, you just switch the default encoding and everything works instantly. Also your point doesn't apply since we already have - initWithUTF8String: (every C API which doesn't use the system encoding most likely uses UTF-8 on Unix) and -initWithCharacters:. So dropping -initWithCString: gains you nothing here. Oh well, 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: Considering Gorm 1.0.0
On 22. Jun 2005, at 07:58 Uhr, Gregory John Casamento wrote: Does anyone have any comments? I would still love to see a viable OpenSource replacement for IB on MacOSX. Are there any plans to port Gorm to Cocoa? 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: STS Template Engine
On 21. Jul 2005, at 16:53 Uhr, Markus Hitter wrote: Am 21.07.2005 um 16:03 schrieb Sunrise Ltd: we've just released the STS TemplateEngine, a library for expanding templates using tagged placeholders and it features its own macro lanuguage for conditional template expansion. This is was I thought first: Well, my first thought was: why another templating engine? We already have WO (either in SOPE or in gstep-web). 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: STS Template Engine
On 25. Jul 2005, at 02:35 Uhr, Lars Sonchocky-Helldorf wrote: Well, my first thought was: why another templating engine? We already have WO (either in SOPE or in gstep-web). maybe because WO would be overkill for some simple tasks (or do you use a semitrailer truck to carry a crate of beer to your home)? Hear hear! ;-) The WO framework just has ~20 public classes and is hardely a truck, its rather a beautifully modular bike: http://developer.apple.com/documentation/LegacyTechnologies/ WebObjects/WebObjects_4.5/System/Library/Frameworks/ WebObjects.framework/ObjC_classic/WebObjectsTOC.html Stripping down to the classes required for templating you may end up with something like 5-10 classes for text rendering. 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: STS Template Engine
On 25. Jul 2005, at 23:10 Uhr, Lars Sonchocky-Helldorf wrote: I wasn't aware that WO was such a lithe and lissom animal once. it has put on a lot weight since then (Java disease?). This: http:// developer.apple.com/documentation/WebObjects/Reference/API/ index.html is definitely a truck. (and yeah, you omitted EOF, could you install WO without it those days?) Of course I omitted EOF since its not required for templating (nor for any other basic WO operation). AFAIK the only class which refers EOF is WODisplayGroup and this can easily be omitted. The Java reference contains all the other WO related frameworks like D2W etc, those however are not part of the WebObjects _framework_ (not the whole product). (addition it contains additional classes necessary due to the Java language, but actually not that much). The full WO product consists of a lot of different frameworks (aka packages in Java WO), but those are rather cleanly designed and stack up pretty nicely. On 26. Jul 2005, at 08:37 Uhr, Stefan Urbanek wrote: What about WO dependencies? ... The WO framework classes required here have no dependencies but Foundation (since KVC is now in Foundation). "stripping down ..." does not seem like out-of-the-box solution... Hu? Just build a library which contains only the classes you require. Of course you may need one or the other additional class for WO framework purposes (like WOContext), but this probably makes more sense than rewriting the templating from scratch! Nothing against WO - each tool has its purpose... WO is a nice framework which can be applied to many different purposes, not a monolithic "tool". Its actually quite beautiful for templating all kinds of files. Presenting WO as a bloated tool is simply incorrect. Now I wouldn't recommend it for stuff like [str replaceString:... withString:...] but as soon as you start with conditions, repetitions and stuff, you are very likely reinventing the wheel. And indeed the existing wheel is kick-ass ;-) 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
Headerfile-bug in framework.make
Hi, I think I've found a bug in framework.make of gstep-make 1.10.0. It doesn't honor the HEADER_FILES_DIR variable which results in missing dependencies. I've added the "addprefix" call to the right side: ---snip: Instance/framework.make:299--- # Need to share this code with the headers code ... but how. $(FRAMEWORK_HEADER_FILES):: $(addprefix $(HEADER_FILES_DIR)/,$ (HEADER_FILES)) ifneq ($(HEADER_FILES),) ---snap Could someone please confirm, apply the change and maybe release a new gstep-make? Thanks, 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: Headerfile-bug in framework.make
On Aug 10, 2005, at 3:50, Nicola Pero wrote: Ehm ... thanks ... we have just released a new gnustep-make (1.11.0), which includes the fix ... :-) Excellent :-) Any incompatibilities between 1.10 and 1.11 which I need to be aware of? Another annoying issue is that gstep-make doesn't seem to notice when the linking of a framework fails on OSX. It just continues building: ---snip--- Compiling file WEExtensionsBundle.m ... Linking framework WEExtensions ... ld: can't locate framework for: -framework NGObjWeb /usr/bin/libtool: internal link edit command failed Copying resources from subprojects into the framework wrapper... Creating WEExtensions.framework/Versions/A/Resources/Info.plist... Compilation finished at Thu Aug 11 16:47:06 ---snap--- Also fixed in 1.11? ;-) 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: Headerfile-bug in framework.make
On 11. Aug 2005, at 17:48 Uhr, Adam Fedor wrote: * Psuedo-framwork support was implemented on MingW. This essentially involves copying the framework to several places so it can be used without links, which Windows does not really support. There's no other clean way to do it. BTW: is this really the case? I had the impression that its pretty similiar to OSX, expose only Aliases (aka symbolic links) to the user, but support "real" links internally. In the case of Windows creation of such via the Posix APIs. 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
PCH Support
Hi,
I've added some PCH support to gstep-make 1.11.0 and I'm almost ready
to send it for inclusion. At least on OSX it gives a major performance
boost (compilation of libSaxObjC in 13s instead of 23s on a G4/800MHz).
Problem is, it only works completely on OSX (only checked 10.4 so far).
On Linux, gcc 4.0.2 seems to be able to compile the header but I get
errors when trying to use it with a source file.
OSX, works fine:
---snip---
[EMAIL PROTECTED] make messages=yes all
Making all for library libSaxObjC...
cd .; \
/Users/helge/dev/SOPE-4.5-gs/.gsmake/Library/Makefiles/mkinstalldirs
./shared_debug_obj; \
rm -f obj; \
ln -s ./shared_debug_obj obj
if ! test -d ./derived_src; then \
/Users/helge/dev/SOPE-4.5-gs/.gsmake/Library/Makefiles/mkinstalldirs
./derived_src; \
fi
gcc -x objective-c-header common.h -c \
-MMD -MP -pipe -Wall -Wno-protocol -Wall
-DCOMPILE_FOR_GSTEP_MAKE=1 -DSOPE_MAJOR_VERSION=4
-DSOPE_MINOR_VERSION=5 -DSOPE_SUBMINOR_VERSION=52 -Wno-protocol
-DNeXT_Foundation_LIBRARY=1 -DNeXT_RUNTIME=1 -dynamic -fno-common -g
-Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE
-fno-strict-aliasing -fnext-runtime -I.. -I. \
-o derived_src/common.h.gch
gcc SaxAttributeList.m -c \
-MMD -MP -pipe -Wall -Wno-protocol -Wall
-DCOMPILE_FOR_GSTEP_MAKE=1 -DSOPE_MAJOR_VERSION=4
-DSOPE_MINOR_VERSION=5 -DSOPE_SUBMINOR_VERSION=52 -Wno-protocol
-DNeXT_Foundation_LIBRARY=1 -DNeXT_RUNTIME=1 -dynamic -fno-common -g
-Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE
-fno-strict-aliasing -fnext-runtime -I.. -I. \
-include ./derived_src/common.h \
-o shared_debug_obj/SaxAttributeList.o
...
---snap---
Linux:
---snip---
[EMAIL PROTECTED]:~/dev/SOPE-4.5/sope-xml/SaxObjC$ make messages=yes
Making all for library libSaxObjC...
cd .; \
/home/helge/GNUstep/Library/Makefiles/mkinstalldirs ./shared_debug_obj;
\
rm -f obj; \
ln -s ./shared_debug_obj obj
if ! test -d ./derived_src; then \
/home/helge/GNUstep/Library/Makefiles/mkinstalldirs ./derived_src; \
fi
gcc -x objective-c-header common.h -c \
-pipe -Wall -Wno-protocol -Wall -DCOMPILE_FOR_GSTEP_MAKE=1
-DSOPE_MAJOR_VERSION=4 -DSOPE_MINOR_VERSION=5
-DSOPE_SUBMINOR_VERSION=52 -Wno-protocol
-I/home/helge/GNUstep/Library/Headers/libFoundation/ix86/linux-gnu/GNU
-DGNUSTEP=1 -DWITH_GSTEP_MAKE=1 -DLIB_FOUNDATION_LIBRARY=1
-DFD_WITH_GSMAKE=1 -DGNUSTEP=1 -DGNU_RUNTIME=1 -D_REENTRANT -fPIC -g
-Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE
-fno-strict-aliasing -fgnu-runtime -I.. -I.
-I/home/helge/GNUstep/Library/Headers
-I/home/helge/GNUstep//Library/Headers
-I/home/helge/GNUstep/Library/Headers/libFoundation
-I/home/helge/GNUstep//Library/Headers/libFoundation
-I/home/helge/GNUstep//Library/Headers/libFoundation
-I/home/helge/GNUstep/Library/Headers/libFoundation
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU \
-o derived_src/common.h.gch
gcc SaxAttributeList.m -c \
-pipe -Wall -Wno-protocol -Wall -DCOMPILE_FOR_GSTEP_MAKE=1
-DSOPE_MAJOR_VERSION=4 -DSOPE_MINOR_VERSION=5
-DSOPE_SUBMINOR_VERSION=52 -Wno-protocol
-I/home/helge/GNUstep/Library/Headers/libFoundation/ix86/linux-gnu/GNU
-DGNUSTEP=1 -DWITH_GSTEP_MAKE=1 -DLIB_FOUNDATION_LIBRARY=1
-DFD_WITH_GSMAKE=1 -DGNUSTEP=1 -DGNU_RUNTIME=1 -D_REENTRANT -fPIC -g
-Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE
-fno-strict-aliasing -fgnu-runtime -I.. -I.
-I/home/helge/GNUstep/Library/Headers
-I/home/helge/GNUstep//Library/Headers
-I/home/helge/GNUstep/Library/Headers/libFoundation
-I/home/helge/GNUstep//Library/Headers/libFoundation
-I/home/helge/GNUstep//Library/Headers/libFoundation
-I/home/helge/GNUstep/Library/Headers/libFoundation
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU \
-include ./derived_src/common.h \
-o shared_debug_obj/SaxAttributeList.o
SaxAttributeList.m:188: error: redefinition of 'struct _objc_symtab'
SaxAttributeList.m:188: error: redefinition of 'struct _objc_module'
SaxAttributeList.m:188: error: redefinition of '__objc_gnu_init'
common.h:26: error: previous definition of '__objc_gnu_init' was here
{standard input}: Assembler messages:
{standard input}:2136: Error: symbol `_OBJC_SYMBOLS' is already defined
{standard input}:2302: Error: symbol `_OBJC_MODULES' is already defined
{standard input}:2351: Error: symbol `_OBJC_CLASS_NAME_0' is already
defined
...
[EMAIL PROTECTED]:~/dev/SOPE-4.5/sope-xml/SaxObjC$ file derived_src/common.h.gch
derived_src/common.h.gch: GCC precompiled header (version 012) for
Objective C
---snap---
Does someone know whether PCH is fully implemented in the GNU
Re: PCH Support
On 26. Aug 2005, at 16:46 Uhr, Nicola Pero wrote: ... just wanted to encourage you and say that this would be a fantastic addition to gnustep-make! :-) OK, the Linux/gcc4 issue isn't solved yet, but at least on OSX it works (almost) like a charm. I've added PCH to SOPE 4.5 and it now compiles in ~8mins instead of ~16mins on a PM G5, so it indeed gives a huge speed boost. How to use == First you need to reconfigure/reinstall gstep-make with --enable-pch: ./configure --enable-pch In your projects you create a header file which contains all the files you usually want to include, in SOPE we already had such files called "common.h", eg: common.h: #import #import After that you need to tell gstep-make about that file by adding a new variable: MyProject_PCH_FILE = common.h Thats it. 'make clean all' and it should compile much faster. Notes = - The common.h will be included in _every_ source file of the project at the very top (automagically using -include). This is sometimes confusing and can lead to bugs with non-PCH setups, but necessary to ensure that the PCH actually gets used. - On the first 'make all' the PCH will be generated. Subsequent "touch *.m; make all" are marginally faster (for SOPE 4.5 with ~20 PCH's this is no measurable difference) - The PCH will NOT pick up changes automagically. So you should not add 'volatile' headers to the PCH or you might experience weird effects (old headers getting used). Don't know whether auto- dependencies help here, at least a .d file is generated. - Do not use PCH if your project/subproject has just one or two files. Will gain you nothin' but wasted diskspace. - Precompiled headers are quite big! For SOPE common.h around ~13MB each (~250MB for SOPE). - I have the impression that PCH also increases Dual-CPU saturation on the G5 (w/o using -j), don't know why. Maybe because cpp=>cc1obj pipeline is multitasked and somehow better used. - The newer Xcode's do something called shared PCH. Don't know how this works, I suppose they hash the header-file and only regenerate when they differ. Should save disk-space and some PCH generation time. How to get it = My gstep-make branch is available at: http://svn.opengroupware.org/SOPE/trunk/gnustep-make You can retrieve it as a patch to 1.11.0 using: svn diff http://svn.opengroupware.org/SOPE/vendor/gnustep-make/ 1.11.0 \ http://svn.opengroupware.org/SOPE/trunk/gnustep-make Issues == I have one issue with subprojects, apparently they are run w/o a submake invocation and somehow pick up wrong PCH_FILEs. Nicola, maybe you can look into the changes and tell me what I did wrong? ;-) Another minor issue the patch has is that the PCH must live in the same directory like the makefile - when I use $(notdir), the PCH compilation rule somehow doesn't get picked up (see comments in makefile). I failed to see why (Nicola again ;-) Note: to see this behaviour your main project and your subproject need to use different PCH_FILE names (otherwise the subproject picks the one of the parent). PCH in Sarge gcc4 doesn't work. I won't have the time to run through the full gcc bug-reporting procedure as outlined in: http://gcc.gnu.org/bugs.html If someone would find the time to build/submit a testcase it would be excellent. Greets, Helge PS: ratmice: I think you saw no speed gain because you didn't use - include which you should to ensure that the PCH is actually used (the PCH MUST be the first included header). -- 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: PCH Support
On Aug 27, 2005, at 20:22, Matt Rice wrote: PS: ratmice: I think you saw no speed gain because you didn't use - include which you should to ensure that the PCH is actually used (the PCH MUST be the first included header). of course i did.. line 20 and 29 of pch.diff OK, was just a wild guess ;-) Then, I don't know why you didn't see a speedup. Its fairly huge over here. Of course tests on Linux/ix86 are pending and it will be interesting to see whether it gives measurable speedup given that Linux/ix86 is already thrice as fast as my G5 over here. 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
HEADER_FILES_INSTALL_DIR
Hi, I think HEADER_FILES_INSTALL_DIR is b0rked in gstep-make 1.11. First my assumption: a) HEADER_FILES_DIR is where header files are located in the source code, has nothing to do with the install location b) HEADER_FILES_INSTALL_DIR is where files live in the installation headers.make in 1.11 does this: HEADER_FILES_INSTALL_DIR = \ $(HEADER_FILES_DIR)/$($(GNUSTEP_INSTANCE)_HEADER_FILES_INSTALL_DIR) I think it should be just: HEADER_FILES_INSTALL_DIR = \ $($(GNUSTEP_INSTANCE)_HEADER_FILES_INSTALL_DIR) why is it prefixed by $(HEADER_FILES_DIR)/? This currently breaks libFoundation compilation. 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: HEADER_FILES_INSTALL_DIR
On 31. Aug 2005, at 17:59 Uhr, Nicola Pero wrote: Ehm ... thanks for your bug report, :-) ... I'm a bit puzzled though because I couldn't find this line in gnustep-make's CVS or 1.11 ... Can you point me to the .tgz or CVS version you used that contained those lines ? Maybe the 1.11 .tgz is broken ? Hm, this is most weird ;-) I can't find it in my vendor branch either: http://svn.opengroupware.org/SOPE/vendor/gnustep-make/1.11.0/ Instance/Shared Probably Subversion somehow "break merged" this, though I have no idea how this could happen. Sorry for false accusations, I have no idea how that got into my copy, we just use vendor branches w/o modifications (prior PCH). Need to be more careful in subsequent merges. 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: STS Template Engine
On 2. Sep 2005, at 17:01 Uhr, Sunrise Ltd wrote: Well, my first thought was: why another templating engine? We already have WO (either in SOPE or in gstep-web). It would seem that your idea of "templating engine" is a little narrow. How to you come to this conclusion? WO is great for webservers and templating of webcontent. Indeed. But there are far more templating requirements than webcontent. Obviously. As mentioned, the STS Template Engine was specifically designed to generate configuration files for faceless server apps, such as in our case Asterisk. And you can't do this with WO? Interesting, we can and its rather cool for this kind of things. It would seem that your idea of "WO" is a little narrow. It could be used for webcontent templating, but it is specifically designed for system configuration tasks. And for this purpose it beats WO hands down. If you say so. You might want to add actual reasons on why your NIH templating is better than WO for the task instead of accusing someone of having a "narrow idea". Your mail has no interesting content on that actual point. regards, Helge PS: your email address doesn't work. -- 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: xcode files in GNUstep cvs
On 21. Sep 2005, at 16:59 Uhr, [EMAIL PROTECTED] wrote: So I'd recommend we only do it for projects where we will actively maintain the xcode port. ;-) You can also add a "legacy" target to the Xcode project which builds the files using the gstep-make files to avoid the need for two build environments. 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: xcode files in GNUstep cvs
On Sep 22, 2005, at 14:00, Nicola Pero wrote: Thanks ... that's quite an interesting idea :-) ... you still need to install gnustep-make before you build though. You could make a .pkg package which installs gstep-make in the system. In SOPE we embed a snapshot of gstep-make which is setup at configure time (yes, of course you can also call external processes from Xcode ... ;-) But I suppose some OSX guys would still prefer to build inside Xcode rather than from a terminal's command line. ;-) I don't understand the point, maybe you are not aware thats trivial to call an external program as part of an Xcode build? The main advantages of using the Xcode build system are: - ZeroLink - distributed builds - predictive compilation - better multi-CPU support - direct IDE support But those are more relevant for applications, less for "premade" frameworks. Well, but then why the need to build a premade framework from source, just provide a .pkg ;-) 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: Proposal: Subversion Migration
On 23. Okt 2005, at 13:25 Uhr, Markus Hitter wrote: Unlike CVS, Subversion numbers versions throughout the whole repository. A bunch of files checked out have always the same version; files get higher version numbers even without being changed. As a result, one should tend to make small repositories, i.e. one for each app, one for each tool, one for each lib. Exactly. But notable repositories can refer each other so that other repositories are checked out automagically as subtrees. So the user doesn't usually need to be concerned about the actual repository a source comes from. 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: Gorm 1.0 on GNUstep site
On 2. Nov 2005, at 21:22 Uhr, Scott Stevenson wrote: http://treehouseideas.com/downloads/gnustep.page Very nice! 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: Repository change to SVN, Jan 28th
On Jan 22, 2006, at 16:42, Sheldon Gill wrote: Actually, I think Fred has raised a good point here. We do, I think, need some clarification about branches and merging back to trunk. While I agree that the point is good in general and some rules need to be set up, its not the most important point _right now_. For now, why not just apply the same conventions used as in CVS? A few additional rules and guidelines may be useful. I've some questions: - are we going to stick with the SVN recommended 'trunk', 'branch' and 'tag' This seems like a rather obvious yes? - how are branches to be named? What about sub-branches? Same like CVS? - how are developers going to communicate about branches and what's going on in them? Same like CVS? - what goes into tag? When? Same like CVS? - Are we going to import more vendor trees? (like ffcall, portaudio etc) What would be the rational and why would that be different to CVS? Things to think about. Yes, but not relevant to the migration itself? 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: Planning Fosdem
On 12. Feb 2006, at 15:26 Uhr, Nicolas Roard wrote: I didn't hear any complaint about the planning, so well I guess it is fine ? :-) Note: AFAIK the FOSDEM flyers are already _in print_, so you can't change the schedule as it was on the Wiki page anymore. best regards, 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: Planning Fosdem
On Feb 12, 2006, at 17:15, Nicolas Roard wrote: Well, yes, but the schedule is not uploaded on the fosdem site, so I would guess they don't have any schedule for us anyway... They know the reference to the Wiki site, I told them they'll find the line-up over there ... Well, we'll see, if you want to know for sure, ask the devroom list ;-) The FOSDEM site schedule is not used (internally), they asked for the schedule in a separate mail. Greets, Helge PS: why did you cross-post? -- 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 19. Feb 2006, at 08:35 Uhr, Richard Frith-Macdonald wrote: 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. Well, we (SOPE/OGo) don't need DO but I don't care to have an NSPort class linked into my binary either. Of course the binary should not attempt to connect the daemons or setup the DO system unless I actually use it. I suppose this is already true for gstep-base. However ... either configure-time or run-time options makes more sense to me than a splitup. Configure-time makes red lights go on, but otherwise I agree :-) 3. NSUserDefaults As I already mentioned, this already copes with read-only database, so it would be easy to continue using it without any external files. Major restucturing to avoid using it therefore seems very counterproductive. The only thing we have here in SOPE is that NSUserDefaults looks for its database in $HOME instead of $GNUSTEP_USER_DIR if the latter is not set. 5. NSBundle I'm not sure what the perceived problem is here. One feature I would like to see in NSBundle is the ability to load a .so module w/o any resources since otherwise one needs to rebuild a lot of API to load plain modules. But thats an additional feature, not a bug :-) 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 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! :-) GNUstep, however, brings along a whole lot of other problems: crazy GNUstep/ directory structure, daemons, config files, etc.. etc.. I wouldn't call the GNUstep directory structure crazy at all, its actually a rather cool thing. 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. 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. I don't understand the brackets, obviously this is offending. But no need to discuss it :-) We can easily fill the role that libFoundation and derivatives are made to fill. Quite honestly I can't follow you, libFoundation was not made to fill missing flexibility in gstep-base, it was started a looong time ago by Ovidiu and others as a "pure" Foundation API implementation. When they did that gstep-base was still quite an ugly mix of libobjects and Foundation. I think this was fixed reasonably well in the last years so the initial reasoning for libFoundation is gone (though I have the impression that gstep-base still contains too much GS* stuff). Why is there any more than a single free Foundation implementation being developed right now? AFAIK there are three worth mentioning: a) gstep-base b) libFoundation c) mgstep? So now a bit about the "why". a) well, thats the GNUstep community which doesn't want to drop gstep- base for unknown reasons ;-) b) libFoundation is not really "developed", its more or less in "maintenance" mode. It does what it does and it does it well. The OGo project is more or less the only user of libFoundation (though lF very likely has multitudes more deployments than gstep-base). As mentioned before we would rather like to move OGo to gstep- base. If its possible w/o loosing features/speed/on-bugs which are important to us. c) if I remember right the motivation behind mgstep is providing full binary compatibility with Cocoa. I think few people care about that and the huge additional maintenance overhead. Though I might be wrong. Finally I think that there is nothing particulary bad with having multiple Foundation implementations which have different goals. In contrary, its a demonstration of how well the Foundation API actually works and actually _the_ feature of GNUstep - since exactly this is what you do for Cocoa. In essence, I'd like to propose that the -base library be split to fill this role. Can't see how splitting will help since the main issue is not bloat but different goals or history or missing functionality. If you want to know all the issues I have with using gstep-base instead of libFoundation, I could try to write that up. A major problem is that we don't have the time to fix/implement those issues in gstep-base (or bugs in gstep-base which might come up when using it with OGo!). Any thoughts? I think you very much misinterpret the reasons why there are multiple Foundation libraries and your motivation to do changes might be a bit "inappropriate" (no offense ;-) IMHO one should rather come up with a list of the features missing in gstep-base (like FHS support) and implement them step-by-step. We would definitely like to move to gstep-base if certain things do work. Also note that you will need to have MUCH better API/ABI stability if you want to become the "standard" library. This is also something which is lacking in GNUstep (not a core feature for us though, we would probably maintain our own _stable_ branch). 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 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
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 24. Feb 2006, at 08:42 Uhr, Philippe C.D. Robert wrote: 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)? Well, Richard said that multiple times now - so yes! :-) I think DO should also work as explained by Richard?! 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
Svn checkout instructions
Hi, the Svn checkout instructions on: https://gna.org/svn/?group=gnustep are incorrect. They say one should checkout: svn co http://svn.gna.org/svn/gnustep/trunk gnustep while its just svn co http://svn.gna.org/svn/gnustep/ BTW: why is that? Shouldn't there be a trunk? 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: Proposal: Mandatory periodic releases
On 7. Mrz 2006, at 16:41 Uhr, Adam Fedor wrote: Well, I try to do something like this, only I aim for binary compatibility, rather than API stability. That's way too hard for me to track - something that all the developers would have to sign up to do, not just me. The last binary incompatible release was September, last year (7 months). I'm not entirely sure what you mean by that. Ensuring ABI/API stability just implies that every once in a while a new version is branched. This branch then is only allowed to add fixes, no new API/ ABI stuff. "Development" of course will continue as usual (with breaking things ;-) in the trunk and with alpha releases. Technically patches (aka bugfixes) to the branch could/should only be allowed for a release manager, could be you or someone else. A patch would need to ensure that nothing ABI/API is changed, this should be reasonably easy. Since a stable release should happen max every 12 months this should be no big burden. And interest to provide fixes when necessary should be high because only stable versions (and API/ABI compatible fixes) are usually allowed in distributions. Summary: IMHO this should be easy with Subversion. Just do a copy of trunk every 12/18/24 months and mark that the stable release and disallow changes. This might imply that this only makes sense for core components like gstep-make and gstep-base since maybe gstep-gui has so many bugs that it doesn't make sense to tag a stable. Can't decide that. 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: Proposal: Mandatory periodic releases
Hi, On 1. Mrz 2006, at 15:15 Uhr, Gregory John Casamento wrote: One of the ways I've noticed that other projects act is that they, under normal circumstances, try to make regular releases of the code at predictable intervals. This helps to reassure people that the project is active and it also helps to focus developers on impending releases. I'm wondering if this might not be a good thing to start in this project, since our releases tend to be occasional. Just a thought. :) personally I would like to see a split between stable releases and development releases. I talked about that with Nicola at FOSDEM and the impression is that GNUstep lacks both, more frequent AND less frequent releases. More frequent because it will be easier to try out new features (and have a less moving target even for developers) and less frequent because the GNUstep API is too instable for distribution inclusion and to base binary software packages upon. (and ABI change in the core library every 6 months or so is FAR to much, 12 months might be OK, 24 considered stable). In SOPE/OGo we do this by using the Linux version numbering, that is, we have stable releases which are even numbered and NEVER change the API (no additional methods, no additional classes, only fixes). And we have odd numbers which are alpha releases and are allowed to break the ABI. Eg SOPE 4.4.0 is a stable release and 4.4 will never change the ABI while 4.5.1, 4.5.2, ... 4.5.6 are unstable releases and have no soname ABI guarantee. How do we do that in Subversion? If we release a stable version, we copy the trunk tree to a branch, eg: svn cp /trunk /branches/4.4 The trunk then becames the next unstable. Trunk always has an odd numbers and you never have an odd number in (release) branches. To make a stable release, we copy the branch to a release, eg: svn cp /branches/4.4 /releases/4.4.0 To make an unstable release we just copy the trunk, eg svn cp /trunk /releases/4.5.7 BTW: beta releases are also supposed to be ABI stable to the final release. So the first branch is actually a beta, not a final release. I would like to suggest something similiar for GNUstep (at least base ;-). With Subversion this is reasonably easy to do. Keeping ABI stability of course requires A LOT of discipline. 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 26. Feb 2006, at 15:49 Uhr, Chris Vetter wrote: 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. I think it would be more helpful to explain how your favorite system differs to FHS than bashing FHS so that the required setup can be taken into account. The point of course is not so much of supporting FHS in special but in supporting a hierarchy which follows the conventions of the host system. This is FHS on Linux and might be something else on other platforms (eg the Apple one would be quite similiar to the GNUstep environment) Thanks, 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: GNUSTEP_CONFIG_FILE value ('/etc/GNUstep/GNUstep.conf') is not an absolute path
On 10. Mrz 2006, at 20:13 Uhr, Jeremy Bettis wrote: You can't have every platform tested for every release. But you need to decide (and declare!) what platforms are actually tested prior a release. Otherwise a stable release is pretty useless, no? For GNUstep this means that there needs to be a decision whether it supports Windows in releases or not. Which in turn has direct consequences on whether this can be a marketing feature or not. (don't tell someone that gstep-base works on Windows if a downloaded *release* doesn't ...) Even for GCC, windows is on the non-critical list. I am a heavy Mingw user (the only heavy mingw user of gnustep?) and I don't care if Mingw is tested before every release. Frankly the idea of someone who never normally uses windows dual booting over to windows once every 3 months to test under mingw before calling the version RELEASE, doesn't really boost my confidence any. Well, the usual way it works is that you have multiple people responsible for reporting on whether a certain state of the source (usually the RC, release candidate) works on 'their' platform. Of course for mingw32 this should not be someone who doesn't use Windows ... More exactly basically every major project doing "stable releases" has AT LEAST a beta cycle, usually there is also an RC cycle. GNUstep has nothing like that and the 'releases' are nothing more than tagged alpha releases. Not a good base to build upon :-( BTW: even if you don't want to fix a certain platform support for a given release, its much better to know whether a releases does support that platform in advance. So that the release announcement can be correct ... 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: Re[2]: Daily snapshot tarball of the trunk/ hierarchy (on GNA)
On 19. Mrz 2006, at 16:08 Uhr, Manuel Guesdon wrote: About daily snapshots, could you tell me what to snaphost and how to do it ? I'm not familiar with SVN :-( Something like this: SUBPROJECT=base BRANCH=trunk rm -rf checkout-tmp svn export \ "http://svn.gna.org/svn/gnustep/libs/$SUBPROJECT/$BRANCH"; \ checkout-tmp \ >checkout-out REV=`tail -n 1 checkout-out | sed "s/Exported revision\ //" | sed "s/\.//"` SNAPNAME="$SUBPROJECT-$BRANCH-$REV" mv checkout-tmp "$SNAPNAME" tar jcf "$SUBPROJECT-$REV-`date +%Y%m%d`.tar.bz2" "$SNAPNAME" rm -rf "$SNAPNAME" checkout-out 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: Change type signature of objectForKey: ?
On 29. Mrz 2006, at 10:35 Uhr, Richard Frith-Macdonald wrote: The -objectForKey: and -setobject:forKey: methods exist in NSUserDefaults and NSDictionary with two different type signatures. For NSDictionary the key is of type 'id' but for NSUserDefaults it is of type 'NSString*' This can cause a lot of irritating compiler warnings when using these methods, so I was wondering if we should standardise on the 'id' type, and just have NSUserDefaults perform a runtime check (or even use [key description] to be sure that a key is a string). That would mean that the formally declared API for NSUserDefaults would differ slightly from the MacOS-X version, but it should not cause any problems that I can see. What do people think? IMHO you should stick to MacOSX API compatibility and require a cast, just like on OSX. BTW: application level code should use KVC, not -objectForKey: (unless of course you do not work with string keys). This avoids the issue in most situations and is more generic in the same run. 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: FHS compliance/Abstraction of NSBundle
On 9. Mai 2006, at 23:06 Uhr, Hubert Chan wrote: One problem with getting general FHS compliance that I can see is that the FHS doesn't have anything analogous to the Network or user domains. Well, Network is _roughly_ like /opt and user domains are basically in ~ (~/bin, ~/lib if you wish to have that). I think the bigger issue is that while it has PATH and LD_LIBRARY_PATH, standard Unix does not provide a "resource lookup path" (in what sequence to scan share directories). Which is why most GNU-like/autoconf-based tools specify their "location" at compile time (--prefix). Which is fine in realworld but certainly not perfect. BTW: I still think that its unnecessary to force .app wrappers into FHS. FHS should be for low level libraries and tools/daemons. (just like on 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: FHS compliance/Abstraction of NSBundle
On 9. Mai 2006, at 06:17 Uhr, Andrew Ruder wrote: I don't believe that this should be an option; this should be *STANDARD* operation. Maybe I'm wrong but people seem to consider FHS vs GNUstep hierarchy and either/or thing. It certainly isn't. FHS (or other system hierarchies) is just an *additional* fallback path hierarchy which should be searched after the GNUstep hierarchy (if its setup). Some additional information is required (like versioning information for resource/bundle lookup), but there should be some way to add this to NSBundle. Thats how it works in OGo, if you did source GNUstep.sh, you have all the flexibility and features of the GNUstep hierarchy, if you don't it still works. (though real world shows that _no one_ cares about the latter ...) Its a bit like library combos vs flattened or _d, _dp library suffixes. I love the former, but of course its really overkill in 98% of the use cases. So is the GNUstep hierarchy. It doesn't provide any real-world gain. Now how the packager decides how to package stuff is his own choice. Obviously most will choose to use FHS (well, even refuse GNUstep if it doesn't support FHS), but some (eg GNUstep centric) distris may not. 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: FHS compliance/Abstraction of NSBundle
On May 10, 2006, at 6:11 AM, Hubert Chan wrote: the FHS doesn't define things BTW: before this starts to go in the wrong direction again, we are not talking about "just" FHS but integrating with the underlying operating systems conventions. Which may not use FHS but some other FS structure. We are just using the FHS name because we have no better word for it and because its the most common layout :-) What we actually refer to is more like "flat ld.so/Unix lookup process", that is, lookup based on the "regular" Unix lookup approaches (PATH, LD_LIBRARY_PATH, etc). Greets, Helge PS: FHS doesn't specify ~bin/~lib etc because FHS is concerned about system packages, not on user customizations. And system packages never install into ~. Well, at least thats how I understand it :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FHS compliance/Abstraction of NSBundle
On May 10, 2006, at 7:25 PM, Hubert Chan wrote: My main concern, though, is that since the FHS doesn't define those directories, users might get upset if we start creating random directories in ~. OK, I see. Sure, we should not do this. But is anything put into GNUSTEP_USER_ROOT except maybe defaults? I guess not unless this is specifically requested by the user. I think creating a ~/.gnustep directory containing per-user configuration is reasonable and common practice. BTW: libFoundation actually uses $GNUSTEP_USER_ROOT/.libFoundation if the GNUSTEP_USER_ROOT env var is set, otherwise ~/.libFoundation. Greets, Helge ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FHS compliance/Abstraction of NSBundle
On May 11, 2006, at 12:39 AM, Hubert Chan wrote: But if we make GNUSTEP_USER_ROOT to be ~/.GNUstep, then user-installed applications, libraries, etc. get installed in a not-too-nice place, IHMO. I can't see how this matters for user-installed applications. They can (and should be able to) live everywhere the user wants. Especially for applications even PATH is irrelevant as they will be started by GWorkspace or the dock. Would be cool to be able to deploy libraries inside .app wrappers, I think this isn't supported by GNUstep? Libraries can live whereever the user wants too. He just needs to set the LD_LIBRARY_PATH - plain Unix. He might choose to use ~/lib for that. Or not ... Personally I do have a ~/bin which I add to my PATH for own scripts. Finally, I wouldn't equal GNUSTEP_USER_ROOT to ~/.GNUstep (or ~). ~/.GNUstep is for configuration when no GNUstep environment is sourced. Its definitely not for binaries or resources, just for configuration. Greets, Helge ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] GNUstep Testfarm Results
On Aug 11, 2006, at 12:27, Fred Kiefer wrote: and in many cases it is still faster than the later gcc releases. I don't think thats true anymore for gcc4 and up. Not to mention PCH ... libFoundation recently deprecated 2.95 support because those do not support -fconstant-string-class. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Sep 7, 2006, at 19:11, Adrian Robert wrote: This is probably best for simplification as you say but it will impose a cost to switching back and forth between, e.g., profiled and non-profiled versions. Do you actually use profiling with gprof? I've always used KCachegrind in the last few years instead. So IMHO its superflous anyway. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
On Sep 10, 2006, at 18:19, Nicola Pero wrote: Good point ... I'm afraid I was thinking of the "server-side" Java. ;-) I mean, you know all those "enterprise applications" that have no GUI -- or that have a web interface as the user interface. :-) Well, for the advertisement. What would you say, _why_ is GNUstep good for that? :-) Eg Ruby tries to get into that market by allowing the user to contruct flashy web 2.0 apps in a few minutes (and they do not seem to succeed). Do we have a similiar unique feature which could drive enterprise people to try GNUstep? Thanks, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
On Sep 10, 2006, at 22:00, Philippe C.D. Robert wrote: Well, for the advertisement. What would you say, _why_ is GNUstep good for that? :-) Eg Ruby tries to get into that market by allowing the user to contruct flashy web 2.0 apps in a few minutes (and they do not seem to succeed). Do we have a similiar unique feature which could drive enterprise people to try GNUstep? These people are not exactly waiting for yet another cross-platform framework. IMO the only chance for GNUstep to get some wider adoption is to focus on the desktop paradigm for X11 based Unices. But then again, we had this discussion for a very long time... Hm, the response is slightly out of context, no? :-) Please don't turn it into the discussion "we had a for a very long time", we all know that :-) The initial point was an agreement that as a desktop we have nothing to advertise successfully _right now_ and the question what we _could_ advertise w/o disappointing people. Nicola correctly said that the best thing about GNUstep is the Foundation library. Though I have a few issues (eg bad out-of-the-box FHS support) it can certainly be considered finished. Now the question is whether we can somehow advertise this fact? As we all inofficially know the few places where GNUstep is in fact successful are a few large scale GNUstep based enterprise applications. The bad thing is that you are not usually allowed to talk about them :-) Well and the other issue is that most usually exist for legacy reasons, not because it would be the environment of choice nowadays. So the question is whether gstep-base could be interesting for people and why. Can we put that into an ad which triggers someone? Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
On Sep 11, 2006, at 21:07, Philippe C.D. Robert wrote: Well, maybe was the phrasing slightly suboptimal, but not the message behind it ... ;-) Besides, we don't have a desktop (yet) and never will because some project members don't want GNUstep to become a desktop in the first place. I didn't say that your writing was wrong or that the phrasing was suboptimal. I just think that you put things out of context. Why do you think do we have "nothing to advertise successfully" after all those years? I'm not quite sure whether you read my mail. All your points are good but thats a different thread, and one which I'm not very motivated to discuss again ;-) In fact thats what I liked about Nicola's proposal, it suggests to do something with the things we actually do have, right now, instead of arguing about what GNUstep could be. Anyway, what would be your proposal? I've no proposal which is why I _asked_ for suggestions on how it would be possible to turn Nicola's idea into something which can be advertised. I'm kinda confused why you reask the same question to me. Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
On Sep 12, 2006, at 13:38, Gürkan Sengün wrote: Please pretty please, don't make new themes, new looks, another "we are gnome, we are cool", "we are KDE, we are new", "whatever new thing that is just ugly". As mentioned by Chris this is indeed a major selling point of GNOME and KDE, they look like Windows. Eg GNOME Evolution is an extreme example being almost an exact replica of Outlook. Having a MacOS primary theme would certainly be great instead of a Windows like theme. Especially since this has a big potential to aquire in Cocoa developers. But then you'll most likely get letters from the Apple lawyers making that a no go ;-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
On Sep 13, 2006, at 24:19, Yavor Doganov wrote: And as a surplus we also would get some more apps for GNUstep (even if some of those would be commercial ones). Free commercial apps are welcome, but not proprietary ones. Obviously this is non-sense. If proprietary apps wouldn't be welcome, GNUstep would be GPL, not LGPL. GNUstep is LGPL to explicitly allow for that. It will be a contribution equal to zero (even a negative number) if someone ports a non-free app for GNUstep. Again utter non-sense. Its quite an excellent contribution for plenty of reasons (not only the app itself, but also in the related framework improvements) until it gets possibly replaced by a free application. Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Debug as default...
On Sep 20, 2006, at 06:19, Nicola Pero wrote: Anyway, let me know if '-g -O2' causes problems, I presume if the '- O2' seriously confuse the debugger let me know and we can revert that change, or maybe use '-g -O' ? At least the exception handling in libFoundation (which uses nested functions) is b0rked with -O2. Not sure about -O. Which is why we always disable it ... (is it possibly to filter out the -O per file?, eg MyStream_OPTIMIZE = no or something like this?) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Makes Fast Scientific Code, Faster Than Cocoa.
On Oct 3, 2006, at 18:17, Daniel J Farrell wrote: Now, not a true test by any means just a tentative suggestion from a large command line app. The app is basically a scientific number cruncher. I have run the same code, on the same computer, one compiled in xcode linking to Cocoa Foundation and the other compiled using gcc make, make install, openapp etc. linked to GNUstep Base. The GNUstep version is 50% faster (47.8% increase to be more precise). Does GNUstep-base work with the Apple runtime or do you use the GNU Objective-C runtime? If you want to further optimize the issue you should have a look in Shark. By comparing the output of the Cocoa with GNUstep binary you should also be able to tell why GNUstep performs better in your specific case. Thanks, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep release numbers
Hi, could we please change the numbering scheme for GNUstep releases? In my understanding: Currently when Adam does a release he bumps the soname version (eg from 1.12.0 to 1.13.0) in trunk and then tags the release. That means after the release, trunk will continue carrying that tag. I propose a simple modification: Also bump the version after a release so that trunk libs can be identified properly. I would also suggest to use even numbers for releases and odd numbers for trunk. That is: Lets bump the trunk version to 1.15.0 _now_. Next release will be 1.16.0 and right after its tagged, we bump trunk to 1.17.0. And so on. Still less than ideal because we have no stable version but an improvement over the current situation which makes it hard to distinguish dev snapshots from final releases. Thanks a lot, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 4, 2006, at 13:30, Richard Frith-Macdonald wrote: Still less than ideal because we have no stable version but an improvement over the current situation which makes it hard to distinguish dev snapshots from final releases. I don't think we have a policy of making unstable releases ... so all releases are stable. As far as I'm concerned all GNUstep releases are in fact unstable because they always change the ABI. But we discussed / outlined in a long thread a while ago. Note: by 'unstable' I don't mean that the code itself is buggy but that the ABI is unstable. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 4, 2006, at 13:46, David Ayers wrote: IIRC we have a long discussion in the archive about not bumping SO numbers unless we know binary compatibility was broken. Did we have a single gstep-base release which did NOT break the ABI? I don't think so. As mentioned in that long discussion ;-) I'm in favor of doing an occasional ABI stable release and have frequent ABI unstable ones properly tagged as such. The latter then do not need to preserve ABI stability for sonames. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 4, 2006, at 18:33, Gregory John Casamento wrote: Since, you're the one making this assertion, I believe it's up to you to prove that we have broken it in every release. Thats trivial, just check the changelog: http://www.gnustep.org/resources/documentation/Developer/Base/ ReleaseNotes/ReleaseNotes.html As outlined in the ChangeLog every single release broke the ABI. Well there is one, 1.10.3, which didn't seem too just by looking at the changelog (at least this was a subminor release). Absolutely no offense intended, but its a matter of fact GNUstep is highly ABI unstable. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 4, 2006, at 18:42, Richard Frith-Macdonald wrote:
Note: by 'unstable' I don't mean that the code itself is buggy but
that the ABI is unstable.
Fair enough ... that's your definition ... but it's rather an
unusual one.
Really? I think thats the term usually used by OpenSource projects.
But anyway ;-)
Stability is an inherent requirement for Linux distributions because
they can't change the ABI constantly. Which makes it a cycle of ~2
years for all (serious) distributions. But at least 12 months.
In fact not all GNUstep releases change the ABI,
See my other mail. According to the changelog all the late GNUstep
releases always changed the ABI.
but the ones which you term 'stable' are what are generally called
bugfix releases.
Yes, 'stable' is the branch. And individual release after the first
release of the stable branch is a bugfix release.
There are very few of those in GNUstep ... not because there are no
bugs, but because we generally lack the manpower (volunteers with
the inclination to do it) to make lots of bugfix releases.
I honestly don't think that this is a major issue. Those people who
need a stable release and have issues with a certain bug will
backport fixes (not trunk developers).
Most likely this doesn't need to happen very often because gnustep-
make and gnustep-base code is in fact largely bug free. The changes
in those libraries are additions/fixups to the API, code improvements/
rewrites, performance updates, etc.
And of course the interest in providing bugfix releases to a stable
branch increases as the number of stable branches is reduced. Leading
to solid software :-)
However, it should be easy to tell a bugfix ('stable') release ...
it has the same major and minor version number as a normal release,
but an incremented subminor number.
Yes. But prior having bugfix releases we need a stable branch. One
which doesn't change ABI every 3 months but lasts for at least a
year, better two. We don't have that.
Anyway, not sure whether we can find a solution here. We didn't found
one in past discussions :-)
Which I find a bit unfortunate because the code itself of gnustep-
base/gnustep-make is stable for such a long time.
Greets,
Helge
--
Helge Hess
http://docs.opengroupware.org/Members/helge/
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
Richard, you outline the scenario as an either/or (more frequent vs less frequent) while IMHO its quite the contrary. The current situation suits neither of the "camps", for most its too slow, for some its (by far) too fast. I don't think there is anyone who wants an "almost stable" version. I think my proposal suits _both_ camps much better. It allows for more frequent alpha releases while at the same time allowing for a stable release. Why? Currently you have a mixed situation where you even make bugfix releases for unstable releases (1.10.1, 1.10.2 etc). In my scenario you have one version where you don't need to care at all about backwards compatibility and just *one* which you keep ABI stable. Your suggestion that one can just "stop" updating is really incomprehensible. By this you suggest that everyone who wants to use GNUstep libraries in broader deployments needs to maintain his own stable branch (and pkgs for distris). Well, at least for us thats (much) more work than just staying with libFoundation. And it wouldn't really be GNUstep anymore anyway but a fork. I think I can safely assume thats exactly the same for other people (if there are any ;-) who actually want to use GNUstep in a setting with out-of-the- house deployments. We recently upgraded libFoundation from 1.0 to 1.1 which in fact was a major migration (and amount of confusion) for users (which 95% use binary packages). Notably we did this in our unstable branch (OGo 1.1). I guess that the users which use the ages old but rock solid OGo 1.0 and the ones which use OGo 1.1 is about 50/50. Even the latter complain with 1.0=>1.1 changes ;-) Anyway, don't mind ;-) IMHO we can stop the thread now, the proposal doesn't matter for people who really use GNUstep now. So it won't change. As always. Greets, Helge PS: "So GNUstep releases are now 'stable' because each release starts a branch in svn where bugfixes can be applied ... this is a purely academic distinction". Of course this is nonsense. A branch itself doesn't make a version stable, but a branch can be marked as a stable branch (eg by an even version number ;-). Declaring something "stable" is a commitment/discipline not to change the ABI of that branch in the next n months, nothing technically enforced (well, real projects have release managers ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 5, 2006, at 24:30, Hubert Chan wrote: I would prefer to have more frequent releases, but with a stable SONAME/ABI. Thats an obvious contradiction. Its close to impossible to advance the functionality w/o changing the ABI. If you have set an ABI its set in stone, you can only provide bugfixes. (you never need to recompile programs for a new release if you keep the old libraries ... that's what library versioning is for)e . [users do NOT compile programs, developers do] Actually, with the recent GNUstep 0.11.0/1.13.0 release, you are unable to run programs compiled against 0.10.3/1.12.0 because the old library could not communicate with ... I think it was gdnc (I assume due to a change in the communication protocol). ... On the other hand, if you take a program compiled against 0.10.3/1.12.0 and make libgnustep-base.so.1.12.0 a symlink to libgnustep-base.so.1.13.0, and libgnustep-gui.so.0.10.3 a symlink to libgnustep-gui.so.0.11.0, it seems to run perfectly fine. Thats because the program you check only uses the "old" API. ABI compatibility is _exact_. You can't add a (public) class or method and you must not "fix"(/change) the behaviour in an incompatible way. Eg if gnustep-base 1.13.0 adds NSOutputStream and a tool uses that it can't be ABI compatible with 1.10.0 for obvious reasons. So keeping a stable ABI bites with advancing gnustep-base which is often work for adding additional Cocoa methods, classes or fixing incompatible behaviours etc. Which is why I _encourage_ having more GNUstep _alpha_ releases to move things forward quickly in the release-early-release-often spirit. But at the same time its not really hard to keep _one_ maintained and published "guaranteed" state a "thirdparty" developer can rely on. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 5, 2006, at 01:27, Jeremy Bettis wrote: I thought that to provide a "stable" ABI, you just can't do these things: ... But these things should not cause instabilitity: Adding a class Adding a method Thats wrong. A soname fixes one API, it can be neither extended nor reduced (nor changed in the behaviour). I already gave the example of adding a class. You are mixing up ABIs (or more exactly sonames) with backward compatible APIs :-) APIs ensure source code compatibility while ABIs ensure binary compatibility. (you can replace the library and an arbitary program linked against the specific soname still works) GNUstep has very good API compatibility but this doesn't help at all with binary packages. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
which first need to get into the system w/o being exposed to update issues and other sideeffects they do not care about when getting it up and running. The stable OGo (1.0) packages are very well tested and all install-issues are well known and well supported by the community. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Checking breakage of backward compatibility
On Oct 5, 2006, at 12:45, Richard Frith-Macdonald wrote: On 4 Oct 2006, at 12:46, David Ayers wrote: I'm almost indifferent on the subject. But in practice I believe people will unknowingly break binary compatibility and forget to bump the SO name. I think this is worse than forcing folks to recompile apps just because the SO name bumped even though it didn't break binary compatibility but like I said. I wouldn't mind either way. That worries me too ... but I think we *must* try to be strict about it. I don't think it will work to enforce being strict about this on all developers (same for other non-hack stuff, like documentation). Its too much work and slows down development because you can't concentrate on the actual thing you want to do. So in my model we would just bump the soname before/after each alpha release. Or possibly even keep it the same because it has little practical value for alpha anyways, no special preferences here. Writing an automated testsuite (which would also need to be maintained) is IMHO a waste of efforts. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Oct 5, 2006, at 16:01, Dennis Leeuw wrote: Currently the frequency in which we jump Major release numbers, and thus breaking the ABI are not frequent. Thats incorrect. For GNUstep the soname is Major.Minor, not Major. Which is correct because the soname compatibility indeed broke for every major.minor release in the past (classes or methods got added/ removed/behaviour changed). --- lrwxrwxrwx 1 root root 23 Oct 4 11:58 libgnustep-base.so -> libgnustep-base.so.1.13 lrwxrwxrwx 1 root root 25 Oct 4 11:58 libgnustep-base.so.1.13 -> libgnustep-base.so.1.13.0 -rwxr-xr-x 1 root root 7721941 Oct 4 11:58 libgnustep-base.so.1.13.0 --- You can't expect an application developed against 1.13.0 to run with base 1.10 (despite having the same major version). I think its rather trivial to proove that. Again, you can easily check for (required!) soname increases in the ChangeLog: http://www.gnustep.org/resources/documentation/Developer/Base/ ReleaseNotes/ReleaseNotes.html eg: ---snip--- Version 1.13.0 Several sets of classes have been added for dealing with urls and predicates Version 1.12.0 NSStream, NSIndexPath New classes added to the library. Version 1.10.1 NSXMLParser class added Version 1.9.2: NSError New MacOSX compatibility class ---snap--- etc. just extracted one example. per version and just included 4 versions. Base is a highly moving target for any developer. He can't know what he will be able to use on a deployed system (eg is NSStream available or not). Am I missing a point here? Yes, see above ;-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Versioning/release policy proposal
On Oct 6, 2006, at 20:16, Fred Kiefer wrote: I like this proposal very much, there is one area, where I see problems, but we could wait until we actually face them. This is the question, who will be willing to work on the bugfix releases? Most developers will spend their time and efforts on the new unstable release, then somebody needs to decide that some change to the unstable release is worthwhile to be ported back to the last stable release, integrate it there and make a release. The procedure itself sounds fine, but as long as nobody volunteers to actually follow it, it wont help. Any volunteers? I've already volunteered to do that if we have a real stable release, one which is official, promoted that way and lasts for a long time (~12..24 months). I have not reviewed Richard's proposal yet so I can't say yet whether it matches what I would expect from a stable release. (its on my [long] todo list ;-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
