I get an email every time an assignment or disclaimer isapproved for GNUstep. I will check to see of i got one for you and put you on the list if I did.
On Sunday, March 10, 2013, Luboš Doležel wrote: > On 03/10/2013 09:55 PM, Fred Kiefer wrote: > >> On 10.03.2013 15:58, Luboš Doležel wrote: >> >>> I've started working on toll-free bridging support for gnustep-corebase. >>> I'm pushing my work to github: >>> >>> https://github.com/LubosD/**gnustep-corebase<https://github.com/LubosD/gnustep-corebase> >>> >> >> You are surely aware that the actual GNUstep development doesn't happen >> on github, we are still using our old fashioned SVN system. >> > > Yeah, I am aware of that, but creating a fork on github is the easiest > option there is. Once the work is done, I'd submit it in a single batch. > > And for your contribution to be usable by GNUstep we need you to signe a >> copyright assignment to the FSF. For small patches this will not be >> needed, but you seem to work on bigger changes. >> I did not find your name on this list >> http://www.gnu.org/software/**gnustep/developers/copyright.**html<http://www.gnu.org/software/gnustep/developers/copyright.html>, >> maybe the >> assignment is still being processed? >> > > I've signed the paperwork last year and it was confirmed in December. But > I'm not sure if the assignment itself would promote me to this page. > > So far I have NSString/CFString and NSArray/CFArray somewhat working and >>> I'm moving to other types. >>> >>> The bridging is implemented via a helper category, so nothing in Base >>> had to be touched for bridging to work in both directions. Given >>> CoreBase's alpha state, it's the only feasible option anyway, I guess. >>> >> >> You change results in base not using its highly optimized internal >> NSString subclasses, instead it will use the CF implementation, which >> isn't and probably cannot be optimized that much. That way you don't >> just get toll free bridging, but all strings will be of the same type. >> You explained that in your later mail yourself. This should work, but is >> it the only way to do it? And the best one? >> > > I'm gradually reducing the amount of CF calls in NSCFString to a minimum. > I haven't checked all of the existing calls, but in an optimal case, the CF > would only be called to instantiate a string from a byte buffer and to > retrieve the byte buffer again (as long as the program doesn't make CF > calls manually). Then it shouldn't pose any performance penalty. > > Thankfully, GNUstep's NSString makes this sort of subclassing very > straightforward. > > As an aside, it should be discussed whether CoreBase's __CFString should >>> contain a "hashCode" field. The one from Apple does not. I would make it >>> go away for two reasons: >>> >>> 1) It gives me a headache in Darling, because this extra field doesn't >>> fit into the original struct when doing fixups :-) >>> 2) It makes the hash computation part of the ABI >>> >> >> Doing away with the hash code may result in a performance issue. I have >> done a few performance analysis for GNUstep gui applications and it is >> surprising to see what big portion of the runtime gets spend on >> comparing strings. This is one of the reasons Richard spend so much time >> optimizing the base string classes and why we even convert some of the >> constant strings into NSString to have a stored hash code. Maybe we >> could come up with a solution where the compiler provides the memory for >> the hash code and the actual GNUstep code fills that space up when the >> hash code is requested for the first time? >> > > Yes, that would be doable as long as the string is in a writable data > segment. Or we just agree that the hash algorithm used by NSString is good > enough and make it part of the ABI. I think selectors already have > something like that(?). > > -- > Luboš Doležel > > > ______________________________**_________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/**listinfo/gnustep-dev<https://lists.gnu.org/mailman/listinfo/gnustep-dev> > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
