Richard:
I've run the test suite with GC disabled on Linux/x86-64 and nothing broke, but can you please review these changes carefully anyway?
We seem to be using a complex custom allocator for a structure that is not allocated or deallocated. In typical programs, it looks like we're actually just wasting memory by using the memory pool here. Looking at the commit log, this hasn't really been touched for about 10 years, so possibly the assumptions are no longer valid. I can only see this being useful if someone is adding and removing hundreds of notification observers every run loop iteration. Do you have code that does this? If not, then can I remove the custom allocator?
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33165 72102866-910b-0410-8b05-ffd578937521
Replace all -release messages sent to autorelease pools with -drain. In non-GC mode, these are equivalent. In GC mode, these trigger a collection.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33143 72102866-910b-0410-8b05-ffd578937521
GC now works well enough for LanguageKit to run.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33123 72102866-910b-0410-8b05-ffd578937521
Gorm now works correctly when built with GC enabled.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33109 72102866-910b-0410-8b05-ffd578937521
Currently, there are a few places where we should be calling NSAllocateCollectable() without NSScannedOption, but are actually calling NSZoneMalloc() unless we're in GC mode. We should not need separate code paths for this anywhere outside NSZone, since NSAllocateCollectable() will work in non-GC mode as well.
A few of the changes should be tweaked slightly so that they do run-time tests. For example, when compiling with -fobjc-gc, we may be linked against non-GC code, which will use -retain and -release but won't use the memory barriers. Supporting this nicely is a lot of effort, and I'm not fully convinced it's a good idea.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@33104 72102866-910b-0410-8b05-ffd578937521
With gcc 4.6 libobjc, GSSelectorFromNameAndTypes was calling some
functions like sel_get_any_typed_uid that were not declared (they're
declared in objc/objc-api.h which cannot be imported). I had to copy
over these function declarations, otherwise incorrect function calls
are generated which corrupt selectors (at least on x86-64).
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32968 72102866-910b-0410-8b05-ffd578937521
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html
Several of the things in the documentation are wrong:
- The encoding of structures does not include the field names in property
encodings. This encoding format appears to only be used in ivars (yes, it is
frustrating)
- Apple appears to encode long as q on LP64 platforms. This is probably a
compiler bug.
- The N flag is not set for non-atomic properties. This appears to be a clang
bug, since the non-atomic flag is not set in the AST - both the Mac and
GNUstep runtimes generate the same wrong result.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32944 72102866-910b-0410-8b05-ffd578937521
-_NSNumberFormatterInit, and call this in -initWithCoder: so that
instances created with -initWithCoder: are initialized correctly.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32931 72102866-910b-0410-8b05-ffd578937521
It would probably be a good idea if we skipped the entire disassemble / reassemble code path if we've got sensible method encoding strings.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32908 72102866-910b-0410-8b05-ffd578937521
No functionality change, just a switch to using the portable public functions.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@32863 72102866-910b-0410-8b05-ffd578937521
