I'm away for a while
From tomorrow (wednesday 1st april) for three weeks I'll be away from home. I expect to be able to get online occasionally, but intermittently. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep Testfarm Results
Test results for GNUstep as of Tue Mar 31 06:34:14 EDT 2009 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Success Compile i386-unknown-freebsd7.1 Tue Mar 31 15:37:13 CST 2009 Fail Compile sparc-sun-solaris2.7 Tue Mar 31 01:39:41 EDT 2009 Success Compile x86_64-unknown-netbsd4.0 Tue Mar 31 03:56:52 CEST 2009 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 30 Mar 2009, at 16:37, David Chisnall wrote: The remaining issue is that clang (and llvm-gcc, for that matter) does not support the __builtin_apply() family of intrinsics. These are quite unreliable on GCC, and it seems that they are not used when FFCall or FFI is supported, but are still compiled in. mframe.m (which is really horrible) seems to be compiled unconditionally, even though it does not seem to be used when ffcall or libffi is provided. NSInvocation.m provides default implementations in terms of __builtin_apply() and friends that are not used when libffi or ffcall is provided. Is it possible to move these into a separate concrete subclass of NSInvocation along the lines of GSFFIInvocation/ GSFFCallInvocation and only compile them when no better mechanism is provided? I should think that's not only possible, but a very good idea. I *think* (iirc) a little of the code in mframe is used for some NSMethodSgnature features. It may be that we always need that part compiled in, but it should be possible to separate out what we need, and only build the rest of the code if we don't have libffi or ffcall. objc-gnu2next.m uses them in a function that is deprecated on the legacy Apple runtime and not supported by the modern Apple runtime. Does anyone actually use next_objc_msg_sendv()? I don't but it's always dangerous to assume that nobody else will. On the other hand, that's old enough that we might insist on people changing. The next major release will need to break ABI compatibility for 64bit code in order to be compatible with Apple's recent changes, so now is probably a good time to introduce other cleanups that break the ABI in little-used or unused ways. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote: On 30 Mar 2009, at 16:37, David Chisnall wrote: NSInvocation.m provides default implementations in terms of __builtin_apply() and friends that are not used when libffi or ffcall is provided. Is it possible to move these into a separate concrete subclass of NSInvocation along the lines of GSFFIInvocation/GSFFCallInvocation and only compile them when no better mechanism is provided? I should think that's not only possible, but a very good idea. Great news. I *think* (iirc) a little of the code in mframe is used for some NSMethodSgnature features. It may be that we always need that part compiled in, but it should be possible to separate out what we need, and only build the rest of the code if we don't have libffi or ffcall. Using the power of grep, I see: NSMethodSignature uses some mframe stuff for parsing type encodings. This doesn't really make sense being in mframe.m, since it's nothing to do with creating call frames. NSConnection uses them in -forwardForProxy:selector:argFrame:, which I believe is deprecated since all of the argframe stuff was deprecated years ago and never worked correctly, and in a few places with #ifdefs so they're not actually compiled. NSInvocation.m uses them in the fall-back code for when ffcall and libffi are not present. NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment(). The stuff for decoding type strings should probably be pulled into a separate file. objc-gnu2next.m uses them in a function that is deprecated on the legacy Apple runtime and not supported by the modern Apple runtime. Does anyone actually use next_objc_msg_sendv()? I don't but it's always dangerous to assume that nobody else will. On the other hand, that's old enough that we might insist on people changing. The next major release will need to break ABI compatibility for 64bit code in order to be compatible with Apple's recent changes, so now is probably a good time to introduce other cleanups that break the ABI in little-used or unused ways. This function seems to be part of an attempt to reproduce the old NeXT runtime API. More recently, I've been working on implementing the ObjC 2.0 runtime API (supported by Apple for both their new and old runtimes) on top of the GNU one. You can see the current version here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ At some point, I'd like to push this up to GNUstep[1] and have the Apple runtime APIs properly supported. Now that Apple has deprecated posing and defined a stable public API for the runtime, I would imagine a lot of programs are going to start using it. David [1] If possible, I'd like to keep the MIT license for these files so they can be easily used outside of GNUstep as well, since they are low- level and have potential applications for Objective-C code that does not use GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Is this base compilation warning a real problem?
Compiling file NSDistributedNotificationCenter.m ... NSDistributedNotificationCenter.m: In function ‘-[NSDistributedNotificationCenter addObserver:selector:name:object:suspensionBehavior:]’: NSDistributedNotificationCenter.m:343: warning: cast from pointer to integer of different size NSDistributedNotificationCenter.m: In function ‘-[NSDistributedNotificationCenter removeObserver:name:object:]’: NSDistributedNotificationCenter.m:469: warning: cast from pointer to integer of different size NSDistributedNotificationCenter.m: In function ‘-[NSDistributedNotificationCenter(Private) postNotificationName:object:userInfo:selector:to:]’: NSDistributedNotificationCenter.m:811: warning: cast to pointer from integer of different size I am on a 32 bit intel machine, I expect 64 bit machines would handle this code without warnings. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall: On 31 Mar 2009, at 20:00, David Ayers wrote: I'm mostly concerned about keeping support for deprecated API which was 1) part of either the OpenStep specification. 2) part of OPENSTEP 4.2 (widely distributed cross platform implementation of OpenStep) 3) part of WebObject 4.5 (last cross platform implementation of OpenStep) I'd agree with this. -forwardForProxy:selector:argFrame: is not part of OpenStep. I don't know if it was part of OPENSTEP 4.2 or WO - my impression was that it was a private GNUstep method that had since been superseded by the ffi stuff. Indeed... and I don't mind removing forwardForProxy:... as long as we can continue to support -forward:: for those archs that still still work with it...unless we officially want to deprecate support those archs. If we can implement the argframe approach (ie. -forward::) via libffi then we could also resolve some long standing libobjc issues. Yet I'm still unsure if it can be done at all. I'm also a bit concerned about statements like I believe ...[some code]... never worked correctly as we simply do not know who is using it and whether it works for production code. Mostly one finds out that things stopped working when it's too late... Reading the GCC and GNUstep lists, __builtin_apply() and friends are in the 'it may work, but if it stops working randomly then don't be surprised' category. Every time someone asks a question about them on the GCC lists, the reply seems to be 'don't use them unless you absolutely have to'. I am only proposing that we deprecate bits of GNUstep that are not in code paths that are used in the standard configurations and have not been for several years, including some parts that contain comments indicating that they probably don't work. OK, but the consequence is deprecating platforms. And that should be stated and communicated as such. I'm not too fond of doing that without very good reasons. (For example currently it seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't maintaining it anymore, and I hardly know anything about c++ to be of much use here... I'm am trying to takle some of the objc/libobjc bits.) This is one of the reasons I want to get clang supporting GNUstep. C+ + support in clang is still very immature, but it is improving at a rapid pace, and Apple has several people working on it full time. Because it uses a unified parser, the Objective-C++ front end supports everything that C++ one does. All we need to do to be able to make use of this is ensure that the CGObjCGNU class is implemented correctly. Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. I'd suggest modifying the configure script. The ffcall implementation doesn't work safely with EtoileThread, since it does not provide a mechanism for preventing the invocation from trampling over a random stack address if it lasts longer than the call frame. When I reported this, there was talk of deprecating ffcall, since there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't. I would suggest that for the next release we require libffi and see if anyone complains. Where do you get the information that there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't? IIRC peoples mileage varies. But indeed we need to start documenting which works with which. ... More recently, I've been working on implementing the ObjC 2.0 runtime API (supported by Apple for both their new and old runtimes) on top of the GNU one. You can see the current version here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ At some point, I'd like to push this up to GNUstep[1] and have the Apple runtime APIs properly supported. Now that Apple has deprecated posing and defined a stable public API for the runtime, I would imagine a lot of programs are going to start using it. I think the proper place to put this is FSF libobjc. I'd support a request to dual-license the respective files. (Not that I have any real clout but if we as a project request it, maybe are chances are not that bad.) Has anyone heard anything from the FSF about relicensing the GNU runtime? It is currently GPL with an exemption that only applies if code is compiled with GCC. I was told about a year ago that it would be moved to the same exemption as libc (which allows linking of any code), but haven't heard anything since then. I'm not really interested in working on adding
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 00:28, David Ayers wrote: Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall: On 31 Mar 2009, at 20:00, David Ayers wrote: If we can implement the argframe approach (ie. -forward::) via libffi then we could also resolve some long standing libobjc issues. Yet I'm still unsure if it can be done at all. I'm also a bit concerned about statements like I believe ...[some code]... never worked correctly as we simply do not know who is using it and whether it works for production code. Mostly one finds out that things stopped working when it's too late... Reading the GCC and GNUstep lists, __builtin_apply() and friends are in the 'it may work, but if it stops working randomly then don't be surprised' category. Every time someone asks a question about them on the GCC lists, the reply seems to be 'don't use them unless you absolutely have to'. I am only proposing that we deprecate bits of GNUstep that are not in code paths that are used in the standard configurations and have not been for several years, including some parts that contain comments indicating that they probably don't work. OK, but the consequence is deprecating platforms. And that should be stated and communicated as such. I'm not too fond of doing that without very good reasons. Are we? What platforms currently have no support for either ffcall or libffi, but do have support for __builtin_apply()? (Note the last condition; the further you get from Linux/x86, the less likely __builtin_apply() is to actually work) (For example currently it seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't maintaining it anymore, and I hardly know anything about c++ to be of much use here... I'm am trying to takle some of the objc/libobjc bits.) This is one of the reasons I want to get clang supporting GNUstep. C+ + support in clang is still very immature, but it is improving at a rapid pace, and Apple has several people working on it full time. Because it uses a unified parser, the Objective-C++ front end supports everything that C++ one does. All we need to do to be able to make use of this is ensure that the CGObjCGNU class is implemented correctly. Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. Neither am I, but no one on the GCC side seems to be working on Objective-C. I tried to persuade the FreeBSD port maintainer to enable ObjC++ recently in the default build, and his reaction was that ObjC was basically unmaintained in GCC and ObjC++ was in an even worse state. Someone at Apple created some patches over a year ago for adding support for properties to GCC on the GNU runtime. Are they merged yet? No. Is anyone planning on merging them, or rewriting their functionality? Not as far as I can see. Do any of the GCC folks outside of Apple give a dam about Objective-C? Not that I can tell; we had a /stable/ release ship generating errors with any Objective-C program containing constant strings a while ago, and the GCC response was 'Objective-C is not a priority'. If we continue to treat GCC as our main compiler then run the risk that we are depending on a project which has no interest in maintaining the features we need. As far as I can tell, the only reason ObjC is even included in the default builds for GCC is so that the FSF can keep that page telling everyone how great the GPL is because it got GCC its ObjC front-end and ignoring the fact that the code they got was horrible, unmaintainable, and completely useless until someone wrote a libobjc implementation (which ended up being more code than the compiler front end). I'd suggest modifying the configure script. The ffcall implementation doesn't work safely with EtoileThread, since it does not provide a mechanism for preventing the invocation from trampling over a random stack address if it lasts longer than the call frame. When I reported this, there was talk of deprecating ffcall, since there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't. I would suggest that for the next release we require libffi and see if anyone complains. Where do you get the information that there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't? IIRC peoples mileage varies. But indeed we need to start documenting which works with which. From the mailing list when I asked this last, and from comparing the list of supported platforms for the two. Again, can you name one platform supported by ffcall and GNUstep, but not libffi? Does anyone want to jump in and say 'My platform doesn't support libffi! Please don't drop
Re: GNUstep base almost builds with clang
From the mailing list when I asked this last, and from comparing the list of supported platforms for the two. Again, can you name one platform supported by ffcall and GNUstep, but not libffi? Does anyone want to jump in and say 'My platform doesn't support libffi! Please don't drop support!' or is this all hypothetical? My platform (FreeBSD/amd64) supports ffcall but not libffi (or this was the case last time I compiled GNUstep about a month ago) so please don't drop support :-) All the rest of the email, however, I agree with - the lack of ObjC maintenance on GCC worries me greatly. I depend on this stuff for my living, and for my business to make sales. Having somewhere else to jump to would make me give a huge sigh of relief. -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 00:56, Pete French wrote: My platform (FreeBSD/amd64) supports ffcall but not libffi (or this was the case last time I compiled GNUstep about a month ago) so please don't drop support :-) The FreeBSD port for libffi is not marked as broken on amd64. I'd be very surprised if libffi worked on x86-64 Linux but not FreeBSD, since they use exactly the same calling convention on this architecture (Linux uses PCC-compatible on-stack small-structure returns while FreeBSD returns them in register, and a few other minor differences on i386, but in 64-bit mode they are the same). Would it be possible for you to check whether GNUstep works with libffi? On FreeBSD/i386, it defaults to using ffcall, but works better with libffi (i.e. doesn't randomly corrupt the stack when you pass NSInvocations between threads). You probably need to explicitly specify /usr/local/include and /usr/local/lib as ffi lib/include directories in configure. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 4:56 PM, Pete French p...@twisted.org.uk wrote: All the rest of the email, however, I agree with - the lack of ObjC maintenance on GCC worries me greatly. I depend on this stuff for my living, and for my business to make sales. Having somewhere else to jump to would make me give a huge sigh of relief. Well if your business depends on it, you might want to hire someone someone to do the development. Apple has moved away from GCC so you can no longer depend on them. Maybe it is just me and your business model is incorrect to depend on free things when in reality there is no such thing as a free lunch. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Well if your business depends on it, you might want to hire someone someone to do the development. Well, that would be me. But I kind of have a lot of other stuff to do. I'll reprhrase it as I dont want to take this on myself. Apple has moved away from GCC so you can no longer depend on them. This I did not know. Interesting. I assumed Xcode was still using gcc. Maybe it is just me and your business model is incorrect to depend on free things when in reality there is no such thing as a free lunch. By that argument nobody should run a business on top of BSD or Linux. Yes, if you are going to be pedantic I dont depend on them - If BSD went away I would switch to Solaris, and if free Objective-C compilers went away then I shall switch to OS X. But in practice, currently the software runs on top of BSD using GCC/ObjC and it would be an imense pain if either of those things vanished tomorrow. But they are not likely to in my judgement. Indeed isn't the point of the GPL that the current version can't ever be actually taken away ? Or did I misunderstand that ? -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Would it be possible for you to check whether GNUstep works with libffi? On FreeBSD/i386, it defaults to using ffcall, but works better with libffi (i.e. doesn't randomly corrupt the stack when you pass NSInvocations between threads). You probably need to explicitly specify /usr/local/include and /usr/local/lib as ffi lib/include directories in configure. Sure I can give that a try tomorrow. Last time I looked at it I couldnt make it work with libffi, but things change. -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 5:51 PM, Pete French p...@twisted.org.uk wrote: Well if your business depends on it, you might want to hire someone someone to do the development. Well, that would be me. But I kind of have a lot of other stuff to do. I'll reprhrase it as I dont want to take this on myself. Apple has moved away from GCC so you can no longer depend on them. This I did not know. Interesting. I assumed Xcode was still using gcc. I should have said moving away but really they are so close to have moved away, it can be considered moved. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
I should have said moving away but really they are so close to have moved away, it can be considered moved. So what have they moved to out of interest, or can't you tell us ? Is this just for Obj-C or the whole operating system ? -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
