gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreBase toll-free bridging


From: Gregory Casamento
Subject: Re: CoreBase toll-free bridging
Date: Mon, 11 Mar 2013 00:41:49 -0400

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

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, 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
address@hidden
https://lists.gnu.org/mailman/
--
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]