On Apr 11, 2013, at 10:54 AM, David Chisnall wrote:
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?
Imagine yourself developing for GNUstep, using it's additions and not even targeting the official Cocoa. Now consider a visible presence of bugs in GNUstep and
inconsistencies between GNUstep and Cocoa you are accustomed to. And you just happen to face some sporadic SEGFAULT (e.g. NSStream got released while calling it's
delegate) or a mysterious deadlock which occurs only on multiprocessor machines (e.g. iLock was locked in KVO subsystem after kvoLock, but another thread has locked
iLock first, than called observeValueForKeyPath: and observer called back to unregister itself causing kvoLock to be locked while the iLock is held by the thread).
And you need to find out what is going on under the hood. What would you choose: use xCode and Instruments, or tinker with this huge codebase using only raw GDB
in conjunction with vim/Sublime+clang_completion plugin.
If you are used to power and usability of Apple's developer tools, resorting to the last option will cause an enormous amount of frustration.
En passant, by the “Second one” i was referring to GNUstep's reliability. We do use it extensively on our servers (on Linux) and it's a part of my job to ensure that it behaves itself.
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.
Recently, i've been thinking about factoring out these pieces of code, lets call them “runtime related workarounds”, into a separate MIT-licensed static library,
so they can be easily incorporated into any runtime without licensing issues. I'll try to do so this weekend.
* 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?
Amd64 System V ABI. Looking forward to implement Darwin i386 ABI support.
For the sake of mutual understanding: with Apple's runtime, implementing ABI-specific marg_list handling in C is the only option available. The only question is whether to implement the invocation of a function, or
to use some universal approach like libffi and waste CPU time on conversion of a frame from marg_list to FFI call frame.
* 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.
Go ahead and try building upstream version of base with following flags:
-Wshorten-64-to-32 -Wmissing-prototypes -Wreturn-type -Wparentheses -Wswitch -Wunused-variable -Wunused-value
* introduced NS_FORMAT_FUNCTION, corrected all misuses of NSLog, [NString stringWithFormat:] etc.
Hmm, I thought we had one of those already.
Yep, i do remember this from recent merge with upstream. The above only states, that i'm sure that all such methods have this attribute and
all misuses of formatting methods that can be found by clang 3.3 are eliminated in fork's code base.
* 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...
As i recall NSInvocation had Apple-incompatible behavior enforced by it's test, NSHTTPCookie, NSURLProtocol and NSURLConnection also did misbehave a little.
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.
Just finished testing AppKit with art backend on OSX and art/cairo on Linux. Everything is just fine. But i can't state the same about Windows backends, unfortunately we have
no ObjC developers using Microsoft products. Nevertheless, i'll setup a virtual machine and will try to test them in there.