Sorry that should be Lubos. Autocorrect on my phone is overzealous. On Sunday, March 10, 2013, Gregory Casamento wrote:
> Confirmed. Lucid can freely commit to the gnustep repo. I will update > the web page to reflect this. > > On Sunday, March 10, 2013, Gregory Casamento wrote: > >> 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/**<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 >> > > > -- > 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 > -- 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
