Re: GNUstep on OSX

[Richard Frith-Macdonald]

On 29 May 2013, at 15:20, Ibadinov Marat <address@hidden> wrote:

> 
> On May 29, 2013, at 4:48 PM, Richard Frith-Macdonald wrote:
> 
>> I tried looking at a few ...
>> 
>> sqlclient.patch ... the patch here is a reasonable size, but seems to just 
>> remove some correct code from one file.
> 
> It contains two changes:
> 1. Changed signature  of  -(NSMutableArray*)backendQuery: (NSString*)stmt 
> recordType:(id)rtype listType:(id)ltype
> to be: -(NSMutableArray*)backendQuery: (NSString*)stmt 
> recordType:(Class)rtype listType: (Class)ltype
> Change is made to allow this library work with GNUstep runtime’s 
> type-dependent dispatch.
> It was sending messages to abstract superclass instead of concrete subclass.

Hmm ... but this API does not necessarily expect to get a class as an argument 
... the type can be a template object or a class object.
I guess the thing to do here is fix the runtime bug.
A workaround might be to add a new method as a category, to prevent the runtime 
calling the wrong methods on the template objects.

> 2. Removed string trimming. It cased the framework to be almost useless, 
> cause you can't get real data from DB. 
> It was done a month before you made it optional. While merging with upstream, 
> I chose to leave it removed, because
> it looks like a feature added “just because we can”.

There is LOT of code which depends on trimming (because few systems actually 
want leading and trailing space).

>> make.patch ... a large patch most of which I can't understand
> 
> Did you try?

Yes ... and I realised that it was pointless trying since the vast majority of 
the changes were in configure, which is going to be regenerated anyway.

> Changes:
> 1. Corrections in configure.ac to make it work nice on OSX. Big size of patch 
> is caused by regeneration of ./configure.

I missed those ... all I managed to figure out was a change to the default 
library-combo.  I don't know whether that change would break things for other 
people, or if nobody uses it/cares.

> 2. In Testing.h function pass(int, const char*, ...) was made to accept 
> NSInteger instead of int to avoid shortening 64bit to 32bit.

Probably largely harmless, but to be consistent you would have to change the 
documentation to match ... and I would have said that if there was any good 
rationale to change it would be to make the parameter an explicit boolean type. 
 There's no merit to avoiding shortening 64bit to 32bit when the value is 
explicitly documented as an integer expression used as a truth value (ie it's 
going to be shortened anyway).

>> base.patch ...  github tewlls me it's too big to view
> 
> ... and suggests to view raw version instead of HTML.
> It's big for three reasons:
> 1. xCode project
> 2. ./configure regenerated due to changes in configure.ac
> 3. there are loads of changes, really
> 
>> you'll need to figure out how to produce individual patches
> 
> Any suggestions?

Only to:
1. try to shrink the problem by removing all changes that clearly shouldn't be 
applied (any file generated automatically, and any changes which are purely 
cosmetic and moving away from the condign standards).
2. try to split up to separate issues addressed, so the problem can  be 
described and tested and the solution applied and tested.

Sorry I can't help more ... perhaps we could start with something simple like 
the change to use symbolic constants in versaion macros throughout?