www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DerelictCocoa

reply "ponce" <contact gam3sfrommars.fr> writes:
Based on prior Jacob Carlborg'work (AFAIK) and inspired by 
DerelictCF (https://github.com/Extrawurst/DerelictCF), 
DerelictCocoa is an elaborated hack to be able to use Cocoa 
without Xcode (tm).

It does _not_ rely on the recent extern(Objective-C) additions so 
I'm a bit unsure how far the compatibility will go in the OS X 
lineage.

https://github.com/p0nce/DerelictCocoa

This is an unofficial Derelict package, so use at your own risk.
Jul 30 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-30 12:19, ponce wrote:

 Based on prior Jacob Carlborg'work (AFAIK) and inspired by DerelictCF
 (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an
 elaborated hack to be able to use Cocoa without Xcode (tm).

 It does _not_ rely on the recent extern(Objective-C) additions so I'm a
 bit unsure how far the compatibility will go in the OS X lineage.

 https://github.com/p0nce/DerelictCocoa

 This is an unofficial Derelict package, so use at your own risk.


I had a quick look at the implementation. You're not using the 
objc_msgSend_* family of functions correctly. That's one of the main 
reasons why extern(Objective-C) was implemented. I strongly recommend 
you adapting extern(Objective-C) instead. At least read the commit 
message [1] for the commit which implements extern(Objective-C). It 
explains how objc_msgSend_* works.

I can provide more detail if necessary.

[1] 
https://github.com/D-Programming-Language/dmd/commit/867d5479b6d98b23b6c797ee487d1ec1474bee10

-- 
/Jacob Carlborg
Jul 30 2015
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 30 July 2015 at 18:21:00 UTC, Jacob Carlborg wrote:

 On 2015-07-30 12:19, ponce wrote:

 Based on prior Jacob Carlborg'work (AFAIK) and inspired by 
 DerelictCF
 (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an
 elaborated hack to be able to use Cocoa without Xcode (tm).

 It does _not_ rely on the recent extern(Objective-C) additions 
 so I'm a
 bit unsure how far the compatibility will go in the OS X 
 lineage.

 https://github.com/p0nce/DerelictCocoa

 This is an unofficial Derelict package, so use at your own 
 risk.


 I had a quick look at the implementation. You're not using the 
 objc_msgSend_* family of functions correctly. That's one of the 
 main reasons why extern(Objective-C) was implemented.


Indeed there are things I don't know why it works when it 
shouldn't considering the calling convention. This is more like a 
80% solution until something better can be done.


 I strongly recommend you adapting extern(Objective-C) instead. 
 At least read the commit message [1] for the commit which 
 implements extern(Objective-C). It explains how objc_msgSend_* 
 works.


Unfortunately I'm stuck because OS X shared libraries are not 
implemented in DMD so it may be quite a long time before I can 
use a 2.068 front-end for all this. My target is the currently 
available 2.066/2.067.


 I can provide more detail if necessary.


Thanks for the feedback. I'll start by reading by reading the 
commit in more detail.

Actually I've skimmed it before and failed to understand if it 
allows to subclass ObjC objects. If it doesn't then calling the 
runtime might still be necessary.
Not really a problem since class functions do not seem tricky 
like objc_msgSend_*.

I was also unsure if extern(Objective-C) helps with the runtime 
functions themselves, or rather only dispatch to the right 
runtime function obj_msgSend_*. Or both.
Jul 30 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 31/07/15 01:21, ponce wrote:


 Unfortunately I'm stuck because OS X shared libraries are not
 implemented in DMD so it may be quite a long time before I can use a
 2.068 front-end for all this. My target is the currently available
 2.066/2.067.


I see, you're using LDC? Then I recommend you have a look at the 
Objective-C bridge [1] I created. It has not been updated in a very long 
time but I think you can use it as a base. Perhaps just update it for D2.


 Actually I've skimmed it before and failed to understand if it allows to
 subclass ObjC objects. If it doesn't then calling the runtime might
 still be necessary.


The implementation that is currently in DMD head is a very limited 
implementation that only supports calling instance methods. So no, 
currently it's not possible to subclass Objective-C classes.


 Not really a problem since class functions do not seem tricky like
 objc_msgSend_*.


Class methods work the same as instance methods. In Objective-C classes 
are objects themselves.


 I was also unsure if extern(Objective-C) helps with the runtime
 functions themselves, or rather only dispatch to the right runtime
 function obj_msgSend_*. Or both.


It will call a method in the same way as the Objective-C compiler would 
do. That means calling obj_msgSend_*.

[1] http://dsource.org/projects/dstep

-- 
/Jacob Carlborg
Jul 31 2015
parent "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 31 July 2015 at 19:10:05 UTC, Jacob Carlborg wrote:

 On 31/07/15 01:21, ponce wrote:


 Unfortunately I'm stuck because OS X shared libraries are not
 implemented in DMD so it may be quite a long time before I can 
 use a
 2.068 front-end for all this. My target is the currently 
 available
 2.066/2.067.


 I see, you're using LDC? Then I recommend you have a look at 
 the Objective-C bridge [1] I created. It has not been updated 
 in a very long time but I think you can use it as a base. 
 Perhaps just update it for D2.


It looks very interesting indeed. Another gem from the D1 days 
(Cocoa in 2008?).
That said, I don't promise anything because of time scarcity.
Jul 31 2015
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 30 July 2015 at 18:21:00 UTC, Jacob Carlborg wrote:

 I had a quick look at the implementation. You're not using the 
 objc_msgSend_* family of functions correctly. That's one of the 
 main reasons why extern(Objective-C) was implemented. I 
 strongly recommend you adapting extern(Objective-C) instead. At 
 least read the commit message [1] for the commit which 
 implements extern(Objective-C). It explains how objc_msgSend_* 
 works.

 I can provide more detail if necessary.


Hi Jacob,

I'd be interested by an email or IRC conversation about this. How 
best to contact you?

I managed to create a NSView subclass classes at runtime and 
override methods (that involved instance variables for the this 
pointer).

However a painful thing is for those function returning NSPoint. 
Some guidance would be welcome!
Aug 14 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-08-14 13:19, ponce wrote:


 Hi Jacob,

 I'd be interested by an email or IRC conversation about this. How best
 to contact you?


I guess it depends on the time zones, I'm living in UTC+2.


 I managed to create a NSView subclass classes at runtime and override
 methods (that involved instance variables for the this pointer).

 However a painful thing is for those function returning NSPoint. Some
 guidance would be welcome!


Yeah, here comes the tricky part. All methods returning a struct must 
use the objc_msgSend_stret, EXCEPT if the struct is so small it will fit 
in registers, then it must use the regular objc_msgSend function.

Also, you always need to cast the objc_msgSend_* function to the correct 
signature, the signature of the target method.

-- 
/Jacob Carlborg
Aug 14 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 14 August 2015 at 12:31:15 UTC, Jacob Carlborg wrote:

 On 2015-08-14 13:19, ponce wrote:

 How best
 to contact you?


 I guess it depends on the time zones, I'm living in UTC+2.


I'm in the UTC+1 zone.


 Yeah, here comes the tricky part. All methods returning a 
 struct must use the objc_msgSend_stret, EXCEPT if the struct is 
 so small it will fit in registers, then it must use the regular 
 objc_msgSend function.

 Also, you always need to cast the objc_msgSend_* function to 
 the correct signature, the signature of the target method.


I see. I've indeed started to cast but only to get the right 
return type, and left the vararg list. That may be the problem.
Aug 14 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-08-14 14:39, ponce wrote:


 I see. I've indeed started to cast but only to get the right return
 type, and left the vararg list. That may be the problem.


The signature of the objc_msgSend function is mostly irrelevant. The 
function needs to be casted because it will jump to the implementation 
of the method so the arguments to the objc_msgSend call needs to be 
setup as the implementation of the method expects.

-- 
/Jacob Carlborg
Aug 14 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 14 August 2015 at 14:44:13 UTC, Jacob Carlborg wrote:

 On 2015-08-14 14:39, ponce wrote:


 I see. I've indeed started to cast but only to get the right 
 return
 type, and left the vararg list. That may be the problem.


 The signature of the objc_msgSend function is mostly 
 irrelevant. The function needs to be casted because it will 
 jump to the implementation of the method so the arguments to 
 the objc_msgSend call needs to be setup as the implementation 
 of the method expects.


Thanks. I've solved my problem which was about D callbacks 
signatures instead of objc_msgSend trampolines. Oddly enough, 
variadic calls seem to work for now.
Aug 14 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-08-14 22:38, ponce wrote:


 Thanks. I've solved my problem which was about D callbacks signatures
 instead of objc_msgSend trampolines. Oddly enough, variadic calls seem
 to work for now.


I guess that depends on the ABI. I know I had some problems with 
floating point numbers because I made some mistake, but perhaps that was 
for method returning a floating point number.

-- 
/Jacob Carlborg
Aug 15 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-30 12:19, ponce wrote:

 Based on prior Jacob Carlborg'work (AFAIK) and inspired by DerelictCF
 (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an
 elaborated hack to be able to use Cocoa without Xcode (tm).


Also, why using the Derelict approach and load the library at runtime? 
The library will always be available and the correct version.

-- 
/Jacob Carlborg
Jul 30 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 30 July 2015 at 18:23:21 UTC, Jacob Carlborg wrote:

 On 2015-07-30 12:19, ponce wrote:

 Based on prior Jacob Carlborg'work (AFAIK) and inspired by 
 DerelictCF
 (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an
 elaborated hack to be able to use Cocoa without Xcode (tm).


 Also, why using the Derelict approach and load the library at 
 runtime? The library will always be available and the correct 
 version.


I guess it's because I based DerelictCocoa on the old DerelictSDL 
code you wrote, which was using dynamic binding. It never 
occurred to me it could also work statically.
Jul 30 2015
parent Jacob Carlborg <doob me.com> writes:
On 31/07/15 01:05, ponce wrote:


 I guess it's because I based DerelictCocoa on the old DerelictSDL code
 you wrote, which was using dynamic binding. It never occurred to me it
 could also work statically.


Oh, you looked at _that_ code. I thought you found my Objective-C bridge 
[1].

[1] http://dsource.org/projects/dstep

-- 
/Jacob Carlborg
Jul 31 2015