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

Reply via email to