Re: Is GNUstep Examples maintained?

[David Chisnall]

On 21 Aug 2013, at 08:45, Richard Frith-Macdonald 
<richardfrithmacdonald@gmail.com> wrote:

> 
> On 21 Aug 2013, at 08:19, David Chisnall <theraven@sucs.org> wrote:
> 
>> On 21 Aug 2013, at 08:03, Richard Frith-Macdonald 
>> <richardfrithmacdonald@gmail.com> wrote:
>> 
>>> I haven't spoken up before because I have no particular knowledge of most 
>>> of what you mention, but I do know that the Performance framework builds 
>>> fine with the latest release (and with trunk) on several platforms.  So if 
>>> it's not building for you then that must be with some specific unusual 
>>> setup.
>> 
>> The errors I see are:
>> 
>> Compiling file GSCache.m ...
>> GSCache.m:503:1: warning: conflicting distributed object modifiers on return
>>     type in implementation of 'release' [-Wdistributed-object-modifiers]
>> - (void) release
>> ^  ~~~~
>> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:180:1: note: 
>>     previous declaration is here
>> - (oneway void) release NS_AUTOMATED_REFCOUNT_UNAVAILABLE;
>> ^         ~~~~
>> GSCache.m:773:17: warning: incompatible pointer types assigning to 'NSLock *'
>>     from 'NSRecursiveLock *' [-Wincompatible-pointer-types]
>> allCachesLock = [NSRecursiveLock new];
>>               ^ ~~~~~~~~~~~~~~~~~~~~~
>> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:363:1: note: 
>>     class method 'new' is assumed to return an instance of its receiver type
>>     ('NSRecursiveLock *')
> 
> I'm not sure if the first two are compiler bugs?
> As I recall the DO type qualifiers like oneway are required in the interface 
> but not in the implementation.  Maybe that's a language change for objc2?

No, it was just a gcc bug that it never propagated the type information down 
into the class.

> And assigning a derived class instance to a variable types as the base class 
> is definitely legitimate/normal.

While true, this is irrelevant.  NSRecursiveLock is a direct subclass of 
NSObject, not of NSLock.  You probably meant NSObject<NSLocking> as the type of 
the variable.

> Anyway, I susppse we can twek things to make the compiler happy even if it's 
> a false alarm
> 
>> + (id) new;
>> ^
>> GSCache.m:857:32: warning: direct access to Objective-C's isa is deprecated 
>> in
>>     favor of object_getClass() [-Wdeprecated-objc-isa-usage]
>> return class_getInstanceSize(isa); 
>>                              ^
>> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:293:9: note: 
>>     instance variable is declared here
>> Class isa;
>>       ^
> 
> That's easy.

Yes.

>> GSCache.m:913:16: error: use of undeclared identifier 'content'; did you mean
>>     'cgetent'?
>>     size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude];
>>              ^~~~~~~
>>              cgetent
>> /usr/include/stdlib.h:262:6: note: 'cgetent' declared here
>> int      cgetent(char **, char **, const char *);
>>        ^
>> GSCache.m:913:16: warning: receiver type 'int (*)(char **, char **, const 
>> char
>>     *)' is not 'id' or interface pointer, consider casting it to 'id'
>>     [-Wreceiver-expr]
>>     size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude];
>>              ^~~~~~~
>> GSCache.m:913:49: error: use of undeclared identifier 'headers'
>>     size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude];
>>                                               ^
>> GSCache.m:926:16: error: use of undeclared identifier 'name'
>>     size += [name sizeInBytes: exclude]
>>              ^
>> GSCache.m:927:12: error: use of undeclared identifier 'value'
>>       + [value sizeInBytes: exclude]
>>          ^
>> GSCache.m:928:12: error: use of undeclared identifier 'objects'
>>       + [objects sizeInBytes: exclude]
>>          ^
>> GSCache.m:929:12: error: use of undeclared identifier 'params'
>>       + [params sizeInBytes: exclude];
>>          ^
>> 4 warnings and 6 errors generated.
>> 
>> They appear to be because it is directly accessing ivars that are not public 
>> and not exposed from a category on GSMimeDocument (in the first instance, 
>> I've not checked the subsequent ones).  If these ivars are expected to be 
>> used outside of the GNUstep Base Framework, then they should not be hidden.  
>> If they are not expected to be used outside of the GNUstep Base Framework, 
>> then the Performance framework has a bug that only shows up with the 
>> non-fragile ABI.
>> 
>> It fails after the first file, so I've not see what subsequent errors 
>> appear.  
> 
> Yes, the main part of this seems to be use of @defs which is no longer 
> supported with the non-fragile ABI (for obvious reasons).  I guess this must 
> never have worked for non-fragile setups.
> So why does it build for me on my clang-3.3 based system?  Guess I need to 
> look at what compiler flags are being passed.


I don't think it's using @defs.  It's trying to directly access an ivar, which 
is not exposed in the header except with the fragile or mixed ABI (and should 
be @private in those, but isn't).

David

--
This email complies with ISO 3103