Hi, On 10 Apr 2013, at 23:28, Ibadinov Marat <[email protected]> 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 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
