Re: CoreBase toll-free bridging
On 14 Mar 2013, at 20:19, Lars Sonchocky-Helldorf wrote: > > Am 14.03.2013 um 09:42 schrieb Fred Kiefer: > >> Having decided that I googled once more and found this article: >> http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html > > Interesting find in a comment there: > > http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html#comment-84b004a6a9b2e8b3a5fdec10f73b2393 > > "If you look at the Darwin sources, you'll see that the iPhone's > CoreFoundation classes are actually implemented in ObjC." > > Is that true? If the code is accessible (I did a cursory search but found > nothing, just this: http://opensource.apple.com/source/CF/ but I can't tell > if there are iPhone versions amongst this) could we use it (given the license > is compatible). If that were true, I'd expect CF_IS_OBJC() to return true for everything. It has the same code path for DEPLOYMENT_TARGET_MACOSX and DEPLOYMENT_TARGET_EMBEDDED (which, I believe, means iOS), and so probably it is not the case. That said, it would make sense, because iOS does not have a requirement be able to run Carbon code. On the other hand, neither did 64-bit OS X. Core Foundation is used by things like Launchd, and a variety of similar things on OS X (and iOS) that don't use any Objective-C code, so I'm not completely sure it is sensible. On the other hand, Apple decided to use COM for Quick Look, so sensible isn't necessarily a requirement... David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase toll-free bridging
Am 14.03.2013 um 09:42 schrieb Fred Kiefer: > Having decided that I googled once more and found this article: > http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html Interesting find in a comment there: http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html#comment-84b004a6a9b2e8b3a5fdec10f73b2393 "If you look at the Darwin sources, you'll see that the iPhone's CoreFoundation classes are actually implemented in ObjC." Is that true? If the code is accessible (I did a cursory search but found nothing, just this: http://opensource.apple.com/source/CF/ but I can't tell if there are iPhone versions amongst this) could we use it (given the license is compatible). cheers, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FreeBSD with ObjC (was Re: CoreBase toll-free bridging)
On 14 Mar 2013, at 16:39, Derek Fawcus wrote: > DriverKit reborn? Not exactly. I'd like to have a (very) cut-down version of a subset Foundation in the kernel and support ARC. I'd also like things along the lines of the TypedArray in WebGL so that Smalltalk code can do byte-accurate addressing, for example to address hardware. David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
FreeBSD with ObjC (was Re: CoreBase toll-free bridging)
On Thu, Mar 14, 2013 at 02:06:33pm -0400, David Chisnall wrote: > On a somewhat related note, I have (assuming the paperwork happens in time) > an intern this summer working on putting an Objective-C runtime in the > FreeBSD kernel to support Objective-C and Pragmatic Smalltalk in kernelspace. > We'll be looking at something similar to toll-free bridging to integrate > with the kernel's KObj system. DriverKit reborn? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase toll-free bridging
On 14.03.2013 14:15, Stefan Bidi wrote: Your suggestion is how toll-free bridging is currently implemented. There are no fast-track functions without the ObjC test. As far as I can tell, the overhead isn't that bad. Sorry, I did not notice that. But then when I looked in CFString.c I only found four calls or so, this is really easy to overlook. CFData.c seems to be more complete in that respect. The only problem is that not every function maps directly to a method, so there might some additional swizzling needed to make some of those functions work correctly with ObjC objects. Another interesting articles on toll-free bridging is: http://cocoadev.com/wiki/BridgingForFunAndProfit On Thu, Mar 14, 2013 at 3:42 AM, Fred Kiefer wrote: On 13.03.2013 09:12, Luboš Doležel wrote: So guys, what do we do? :-) I'd be unhappy if this topic just faded away... Same here :-) We need a solution where Corebase works without base being present. And when base is there it should fit in as well. I read through the documentation at http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html We have different options: - Implementing CoreBase on top of base wont work as Stef Bidi pointed out, or rather it only would if we put the full CoreBase into base. - Replacing the base classes with CoreBase ones, as implemented in your changes that started this thread, wont work either. As soon as somebody uses a self implemented NSString subclass that wont be bridgable to CoreBase. - We could make all the CoreBase functions tiny wrappers around Objective-C classes that are independent of base. I think this was the idea I originally proposed when we started out on CoreBase. That way we would be able to pass in base objects into CoreBase functions and things still would work. This would not allow for the special deallocation functions that are possible for many CoreBase data types and would thereby limit the way CoreBase could be used. - The only way that could work all the time is to add a test in each CoreBase function, whether the passed in reference is a CF reference or a real object and dispatch based on that. This is a lot of overhead, but only then we will have toll free bridging. Having decided that I googled once more and found this article: http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html Which just means, I could have saved myself a lot of reasoning, by doing this first :-) And this article even points to one with more details. I think this is the way to go. One downside here is that this means we will need each CoreBase function twice an internal version that contains the current implementation and an external, that checks the passed in reference before calling the internal one. And we will need to figure out a way to do the message send without objc_msgSend() for the old libobjc runtime. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase toll-free bridging
On 14 Mar 2013, at 09:09, Luboš Doležel wrote: > CF_OBJC_FUNCDISPATCH0 is something I've already seen in certain calls in > corebase. Now I fully understand the motivation behind it. Uff, lots of work > ahead! > > And it doesn't use objc_msgSend(), it uses class_getMethodImplementation(). This macro predates the runtime supporting objc_msgSend(), but there's no reason why it couldn't be modified to use it (and would only need to be changed in one place). The runtime currently support objc_msgSend() on i386, x86-64 (SysV ABI, not Win64), and ARM (AArch32). In the next release it will support MIPS (n64, possibly n32) and I plan on adding AArch64 support when I get some hardware to play with. Looking at the Apple implementation, it appears that they removed the isa < 0x trick some time ago. It's almost a shame, as it's quite neat, but they probably found the same thing I did when I tried dealing with it: that it added too much extra cost to every message send to be worth it. On a somewhat related note, I have (assuming the paperwork happens in time) an intern this summer working on putting an Objective-C runtime in the FreeBSD kernel to support Objective-C and Pragmatic Smalltalk in kernelspace. We'll be looking at something similar to toll-free bridging to integrate with the kernel's KObj system. David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase toll-free bridging
Fred, Your suggestion is how toll-free bridging is currently implemented. There are no fast-track functions without the ObjC test. As far as I can tell, the overhead isn't that bad. The only problem is that not every function maps directly to a method, so there might some additional swizzling needed to make some of those functions work correctly with ObjC objects. Another interesting articles on toll-free bridging is: http://cocoadev.com/wiki/BridgingForFunAndProfit On Thu, Mar 14, 2013 at 3:42 AM, Fred Kiefer wrote: > On 13.03.2013 09:12, Luboš Doležel wrote: >> >> So guys, what do we do? :-) >> >> I'd be unhappy if this topic just faded away... > > > Same here :-) > > We need a solution where Corebase works without base being present. And when > base is there it should fit in as well. > I read through the documentation at > http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html > > We have different options: > > - Implementing CoreBase on top of base wont work as Stef Bidi pointed out, > or rather it only would if we put the full CoreBase into base. > > - Replacing the base classes with CoreBase ones, as implemented in your > changes that started this thread, wont work either. As soon as somebody uses > a self implemented NSString subclass that wont be bridgable to CoreBase. > > - We could make all the CoreBase functions tiny wrappers around Objective-C > classes that are independent of base. I think this was the idea I originally > proposed when we started out on CoreBase. That way we would be able to pass > in base objects into CoreBase functions and things still would work. This > would not allow for the special deallocation functions that are possible for > many CoreBase data types and would thereby limit the way CoreBase could be > used. > > - The only way that could work all the time is to add a test in each > CoreBase function, whether the passed in reference is a CF reference or a > real object and dispatch based on that. This is a lot of overhead, but only > then we will have toll free bridging. > > Having decided that I googled once more and found this article: > http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html > > Which just means, I could have saved myself a lot of reasoning, by doing > this first :-) And this article even points to one with more details. I > think this is the way to go. One downside here is that this means we will > need each CoreBase function twice an internal version that contains the > current implementation and an external, that checks the passed in reference > before calling the internal one. And we will need to figure out a way to do > the message send without objc_msgSend() for the old libobjc runtime. > > Fred > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase toll-free bridging
On Thu, 14 Mar 2013 09:42:53 +0100, Fred Kiefer wrote: Having decided that I googled once more and found this article: http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html Which just means, I could have saved myself a lot of reasoning, by doing this first :-) And this article even points to one with more details. I think this is the way to go. One downside here is that this means we will need each CoreBase function twice an internal version that contains the current implementation and an external, that checks the passed in reference before calling the internal one. And we will need to figure out a way to do the message send without objc_msgSend() for the old libobjc runtime. CF_OBJC_FUNCDISPATCH0 is something I've already seen in certain calls in corebase. Now I fully understand the motivation behind it. Uff, lots of work ahead! And it doesn't use objc_msgSend(), it uses class_getMethodImplementation(). -- Luboš Doležel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building libobjc2 on FreeBSD 9.1 with clang 3.2 using cmake fails
On 14.03.2013, at 02:15, David Chisnall wrote:
> Hi Marcus,
>
> I find that strange, as FreeBSD 9.1 is the platform where I develop libobjc2…
Ok. I've gradually updated my system via /usr/src over the years starting from
FreeBSD 5.x to 9.1. I'm probably missing some flags in /etc/make.conf which
prevent things from going smoothly, but I'd really like to sort things out (see
below).
> Can you give me the output from the cmake command?
znek@creutzfeld:(~/Projects/GNUstep/libobjc2/Build)$ CC=clang CXX=clang++ cmake
..
-- The C compiler identification is Clang 3.2.0
-- The CXX compiler identification is Clang 3.2.0
-- Check for working C compiler: /usr/local/bin/clang
-- Check for working C compiler: /usr/local/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/bin/clang++
-- Check for working CXX compiler: /usr/local/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The ASM compiler identification is Clang
-- Found assembler: /usr/local/bin/clang
-- Warning: Did not find file Compiler/Clang-ASM
-- Using /usr/lib/libsupc++.so as the C++ runtime library
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found.
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- GNUstep install type set to LOCAL
-- Configuring done
-- Generating done
-- Build files have been written to: /home/znek/Projects/GNUstep/libobjc2/Build
> libcxxrt shipped in 9.1 - I'm using it there (it's in /usr/src/lib/libcxxrt
> if it isn't installed by default, but I think it is). I do have something in
> my libmap.conf telling everything that tries to use libsupc++ to use
> libcxxrt, but that's just for testing libcxxrt.
I think I've found the problem. By default, libcxxrt isn't built. According to
/usr/src/lib/Makefile:
.if ${MK_LIBCPLUSPLUS} != "no"
_libcxxrt= libcxxrt
_libcplusplus= libc++
.endif
But in /usr/src/share/mk/bsd.own.mk:
MK_LIBCPLUSPLUS?= no
I've put MK_LIBCPLUSPLUS = yes in /etc/make.conf now.
After installing libcxxrt, cmake properly picks it up and compiling libobjc2
succeeds.
I guess that means that the build is currently really broken when falling back
to using libsupc++ (the one shipped with 9.1).
Cheers,
Marcus
--
Marcus Müller . . . http://www.mulle-kybernetik.com/znek/
smime.p7s
Description: S/MIME cryptographic signature
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make: Add Android target definition
These patches look very useful. Can we pull them in? Do they require copyright assignment? They are small, but interesting, and there's several of them. Emmanuel, could you perhaps file papers with FSF so the ambiguity is cleared? http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html On 13. 3. 2013., at 17:24, Emmanuel Maillard wrote: > Hi, > > This the first patch to cross compile gnustep-base for Android. > > Changelog: > Add Android target definition > > Thanks > > Emmanuel > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Ivan Vučica i...@vucica.net - http://ivan.vucica.net/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase toll-free bridging
On 13.03.2013 09:12, Luboš Doležel wrote: So guys, what do we do? :-) I'd be unhappy if this topic just faded away... Same here :-) We need a solution where Corebase works without base being present. And when base is there it should fit in as well. I read through the documentation at http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html We have different options: - Implementing CoreBase on top of base wont work as Stef Bidi pointed out, or rather it only would if we put the full CoreBase into base. - Replacing the base classes with CoreBase ones, as implemented in your changes that started this thread, wont work either. As soon as somebody uses a self implemented NSString subclass that wont be bridgable to CoreBase. - We could make all the CoreBase functions tiny wrappers around Objective-C classes that are independent of base. I think this was the idea I originally proposed when we started out on CoreBase. That way we would be able to pass in base objects into CoreBase functions and things still would work. This would not allow for the special deallocation functions that are possible for many CoreBase data types and would thereby limit the way CoreBase could be used. - The only way that could work all the time is to add a test in each CoreBase function, whether the passed in reference is a CF reference or a real object and dispatch based on that. This is a lot of overhead, but only then we will have toll free bridging. Having decided that I googled once more and found this article: http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html Which just means, I could have saved myself a lot of reasoning, by doing this first :-) And this article even points to one with more details. I think this is the way to go. One downside here is that this means we will need each CoreBase function twice an internal version that contains the current implementation and an external, that checks the passed in reference before calling the internal one. And we will need to figure out a way to do the message send without objc_msgSend() for the old libobjc runtime. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
