Re: FOSDEM and beyond (next stable release of base)

[David Chisnall]

On 9 Feb 2010, at 10:58, Richard Frith-Macdonald wrote:

> I've been hesitating for ages because we don't have the OSX applescript 
> support classes, and I just hate them and don't want to write them (as we 
> already have loads of scripting options available), but David Chisnall (who 
> has just had a book on Cocoa programming published) told me that Cocoa 
> developers don't use the applescripting stuff because they don't like it any 
> more than I do ... so I no longer consider this a show-stopper.

Well, that's not quite what I said, however:

1) The AppleScript classes are ugly, and I don't think any Cocoa developers 
that use them actually like them.  Most of them also use them wrongly, because 
it's almost impossible to implement a non-trivial AppleScript interface without 
introducing fun race conditions that may crash your code.

2) AppleScript is the standard way of controlling applications on OS X, but on 
*NIX/Windows it is not.  For iTunes on OS X, Apple provides scripting via 
AppleScript, but they do not under Windows (they provide some COM stuff).  The 
AppleScript classes are not really useful without a complete AppleScript / 
osascript implementation.  

I also mentioned that a lot of developers seem to be adopting F-Script, which 
is very similar to StepTalk, for in-app scripting.  

> In this release, move to compatibility with the Apple objc runtime as much as 
> possible.

I'd like to move the ObjectiveC2 framework, which implements the new runtime 
APIs on top of the old Apple ones, into a sub-framework of -base.  When you 
compile with the new runtime, I'd like to make this an empty framework that 
links against libobjc, but contains no code itself (other than a runtime.h file 
that #includes <objc/runtime.h>).  When you compile with the old runtime, it 
should provide the runtime.c / runtime.h files that wrap the old code in the 
new code.  When you compile on OS X, it would not be linked at all.

I think the only reason that ObjectiveC2.framework is in Étoilé and not GNUstep 
is that I did not have commit access to GNUstep when I started it.  It doesn't 
really make sense for it to be there anymore.  

This framework also includes a blocks runtime, so we can support blocks on 
platforms where people want to use the GCC libobjc.

> Have a 'GNUstepBase/Additions.h' header (like Foundation/Foundation.h) to 
> pull together all the extensions so we can easily change code to include it, 
> or leave it out when compiling in strict OSX compatibility mode.


Maybe we could have a <GNUstep/GNUstep.h>, which is like <Cocoa/Cocoa.h> but 
also includes base and GUI additions?  Having a single header like this can 
improve compile times a lot if we use precompiled headers.  With a current 
version of GNUstep:

$ cat cocoa.m 
#import <Cocoa/Cocoa.h>
$ gcc -E cocoa.m -I /usr/local/GNUstep/Local/Library/Headers/ | wc 
   38186   65945  811099

So, if you include this header, the compiler has to parse 800KB of source code 
for each file, before it even gets to your classes.  This accounts for around 
90% of the preprocessing, parsing, and AST building time (which, with GCC, is 
more than 50% of a typical compile).  If, on the other hand, you have a 
precompiled header (basically a serialised AST of the headers), this just has 
to be loaded and the data structures can be quickly recreated (clang actually 
loads these lazily, so it will only load the interface definitions for the 
classes that you use from Cocoa.h).  

It would also be nice if GNUstep Make could easily support a precompiled header 
without needing custom rules.  Ideally, just setting whether you wanted strict 
OS X compatibility, and what you were building would select the correct header 
to precompile and would use -include to pre-include it in all Objective-C 
source files.

David

-- Sent from my STANTEC-ZEBRA