Re: GNUstep on OSX

[David Chisnall]

Hi,

On 10 Apr 2013, at 23:28, Ibadinov Marat <address@hidden> wrote:

> Hello, fellow GNUstepers.
> 
> For a quite some time i've been maintaining fork of GNUstep primarily focused 
> on OSX support and reliability.
> The first objective is motivated by prevalence of OSX users in Objective-C 
> user base (the only group people who could help with GNUstep development).
> Second one is simply an obligation to my employer (this forks are used in 
> production environment right now).

I'm fascinated to know why your employer wants to run GNUstep on OS X when 
Apple ships its own implementation of Cocoa.  Is it secret, or can you share it 
with us?  

> I seem to be a little bit tired to be alone on these journey, and am willing 
> to be a part of a team. So i would like to offer this code base for you 
> consideration.
> Lets try to make you interested, here goes a list of features that i could 
> remember:
> 
> FoundationKit:
>       * runs on OSX with apple-gnu-gnu combo

That's been neglected for a long time, and it would be great to see it brought 
up to standard.

>       * type encoding support written from scratch (Apple's runtime does not 
> offer it in the public API), and surprisingly it is faster and more robust 
> than implementations in both GNU and GNUstep runtimes.

I'd be very interested in applying these to the GNUstep runtime.  I haven't yet 
added support for the new extended type encodings to the GNUstep runtime, which 
I'd also like to do at some point.

I'm not surprised the code is better - the encodings support in the GNUstep 
runtime was intended as a first pass for optimisation later, and I never got 
around to it.  I don't have any code where encodings parsing was a bottleneck, 
so it never became a priority.

>       * invocations are implemented using assembly and have no external 
> dependencies (if you are already parsing platform-specific marg_lists, FFI 
> does seem like an overkill)

What architectures do these support?  

>       * reimplemented SOCKS proxy support, now both NSFileHandle and 
> NSSocketStream do support SOCKS4a and SOCKS5 simultaneously

Great!

>       * eliminated causes of many crashes (noteworthy changes are in 
> NSHTTPURLProtocol and NSStream) and memory leaks (found by Clang's static 
> analyzer, Leaks and Allocations tools in Instruments.app)
>       * eliminated loads of buffer overruns (spotted by clang's 
> address-sanitizer)

These also sound great.

>       * slightly redesigned constant string implementation to be ABI 
> independent (NSConstantString, NXConstantString and CFString are supported 
> simultaneously by the same gnustep-base build) and 
>       implemented constant CFString support inside the Foundation. This 
> implementation had proven to be reliable (CFString ABI is default on OSX and 
> this gnustep-base plays nice with it)

That sounds worthwhile.  I think it might be sensible for us to switch to 
CFStrings in the long term.  There are a few things I'd like to improve with 
the CFString layout (see previous list posts), but it might be better to just 
accept a slightly less good implementation in the interests of compatibility.

>       * “NSInteger crusade” is finished, all methods/functions have 
> reference-compatible signature, implementations are changed accordingly (no 
> single warning is emitted by clang with -Wshorten-64-to-32 and -Wformat) 

Sounds good.

>       * heed was given to all warnings emitted by clang

I think -trunk should compile without warnings with clang already.  I 
periodically go and fix the warnings when I find them.

>       * introduced NS_FORMAT_FUNCTION, corrected all misuses of NSLog, 
> [NString stringWithFormat:] etc.

Hmm, I thought we had one of those already.

>       * some improvements were made in compatibility with Apple's Foundation, 
> also some missing methods were implemented

More detail is nice, but generally that's a good thing...

> ApplicationKit:
>       * works on OSX with apple-gnu-gnu combo
>       * migration to NSInteger is completed (merged with Fred's changes, 
> works fine)

Sounds good.

> Finally, some precautions.
> AppKit: NSInteger changes are only tested with xlib backend, CUPS support is 
> disabled by ./configure on OSX (it is linked against Apple's CoreFoundation
> where all toll-free bridged classes are implemented, and causes runtime 
> clashes), Cairo backend is disabled by ./configure on OSX (same reason as 
> CUPS).

Hmm, the xlib back end lacks some important features (antialiasing, 
transparency) and probably won't be well supported going forward as we 
integrate CoreGraphics / CoreAnimation support.

> Foundation: GNUTLS support is disabled (it's also liked to Apple's 
> CoreFoundation), as for now assembly code is only present for x86_64 
> architecture,
> Mountain Lion support is underway (they have moved NSObject into runtime, 
> what causes a lot of troubles).
> 
> Links to repos:
> https://github.com/Ibadinov/gnustep-make (necessary configure.ac changes)
> https://github.com/Ibadinov/gnustep-libobjc2 (added missing and now required 
> objc_layout_finish_sructure())
> https://github.com/Ibadinov/gnustep-base
> https://github.com/Ibadinov/gnustep-gui
> https://github.com/Ibadinov/gnustep-back
> https://github.com/Ibadinov/gnustep-corebase (minor bugfixes)
> https://github.com/Ibadinov/gnustep-projectcenter (makefile changes for OSX 
> etc.)
> https://github.com/Ibadinov/gnustep-gorm (makefile changes for OSX etc.)
> https://github.com/Ibadinov/gnustep-sqlclient (bugfixes)
> 
> Not everything is currently merged into “master” branches, so it's better to 
> use “dev” (where it exists) to play with.
> 
> P.S. I know about copyright assignment requirement and, if you are willing to 
> merge this into upstream, i won't hesitate.

I'd definitely like to see most, if not all, of this merged upstream,

David




-- Sent from my PDP-11