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 > [email protected] > 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
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
