February 18, 2016
On Monday, 15 February 2016 at 22:04:51 UTC, kinke wrote:
> On Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen wrote:
>> All green!
>>
>> https://travis-ci.org/ldc-developers/ldc/builds/109326006
>
> Very nice. Win64 still needs some love though... :)

Green green green!
https://ci.appveyor.com/project/kinke/ldc/build/1.0.891
February 18, 2016
On Thursday, 18 February 2016 at 10:52:47 UTC, Johan Engelen wrote:
> On Monday, 15 February 2016 at 22:04:51 UTC, kinke wrote:
>> On Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen wrote:
>>> All green!
>>>
>>> https://travis-ci.org/ldc-developers/ldc/builds/109326006
>>
>> Very nice. Win64 still needs some love though... :)
>
> Green green green!
> https://ci.appveyor.com/project/kinke/ldc/build/1.0.891

This really rocks. The next alpha version of ldc is not too far away!!!

Regards,
Kai
February 18, 2016
LDC 0.17.0 builds merge-2.069
without issues on Travis:
  https://travis-ci.org/ldc-developers/ldc/builds/110114415

waiting for result on AppVeyor:
  https://ci.appveyor.com/project/kinke/ldc/build/1.0.902

February 18, 2016
On 2016-02-04 04:36, David Nadlinger via digitalmars-d-ldc wrote:
> Hi all,
>
> Thanks to Johan Engelen's awesome work, the first usable LDC version
> with a D-based frontend is inching closer and closer.

Is the Objective-C supported implemented?

-- 
/Jacob Carlborg
February 18, 2016
Hi Jacob,

On 18 Feb 2016, at 21:00, Jacob Carlborg via digitalmars-d-ldc wrote:
> Is the Objective-C supported implemented?

Unfortunately, ObjC support is not implemented in master right now.

I haven't had a look at what this would entail myself yet. If you can spare some time, your help with that would be very much appreciated, since most of us would probably have to reverse-engineer the DMD implementation first.

Best
David
February 18, 2016
On 2016-02-18 21:07, David Nadlinger via digitalmars-d-ldc wrote:

> Unfortunately, ObjC support is not implemented in master right now.
>
> I haven't had a look at what this would entail myself yet. If you can
> spare some time, your help with that would be very much appreciated,
> since most of us would probably have to reverse-engineer the DMD
> implementation first.

I kind of know what needs to be done, but I would not know how to do it in LDC. It was hard enough to figure out how to do it in DMD.

What would be the best way? That I describe how it works and a LDC developer implements it. Or do I need to implement it myself?

-- 
/Jacob Carlborg
February 19, 2016
On Thursday, 18 February 2016 at 21:09:27 UTC, Jacob Carlborg wrote:
> On 2016-02-18 21:07, David Nadlinger via digitalmars-d-ldc wrote:
>
>> Unfortunately, ObjC support is not implemented in master right now.
>>
>> I haven't had a look at what this would entail myself yet. If you can
>> spare some time, your help with that would be very much appreciated,
>> since most of us would probably have to reverse-engineer the DMD
>> implementation first.
>
> I kind of know what needs to be done, but I would not know how to do it in LDC. It was hard enough to figure out how to do it in DMD.
>
> What would be the best way? That I describe how it works and a LDC developer implements it. Or do I need to implement it myself?

I might be able to help once I get done with arm-linux.  Last summer for fun I started integrating your older fully functional obj-d branch with ldc.  I got instance method calls and selectors working, although the code was very much a kludge.

Dan

February 19, 2016
On 2016-02-19 02:04, Dan Olson wrote:

> I might be able to help once I get done with arm-linux.

Ok, cool.

> Last summer for fun I started integrating your older fully functional obj-d branch with
> ldc.  I got instance method calls and selectors working, although the
> code was very much a kludge.

It's only external classes and instance methods that are implemented so far in upstream DMD.

The commit message for the commit [1] that implements the support contains some explanation on how it works. The explanation is pretty high level and doesn't explain the data layout in the object files.

I included the commit message here for convince:

================ Commit Message ================

Basic support for classes, interfaces and instance methods.
This is implemented by adding a new linkage attribute, `Objective-C`,
and a compiler recognized UDA, `@selector`. The linkage attribute is
to be used on a class or interface. The UDA is attached to a method.

The linkage attribute tells the compiler that the class should use the
name mangling that matches the one used by Objective-C
(same as C, no mangling) and that all methods in the class
should use the Objective-C way of calling methods, see below.
The calling convention for Objective-C methods and functions is the
same as for C.

The selector UDA tells the compiler what Objective-C selector the
method should have. The selector is used in the Objective-C runtime
to find the implementation of a given method.

An Objective-C method call is implemented by making a regular C call
to the `objc_msgSend` function in the Objective-C runtime.
The signature of `objc_msgSend` looks something like this:

`id objc_msgSend(id self, SEL op, ...);`

* The first parameter is the object (this/self pointer)
* The second parameter is the selector attached to the method
* The last parameter is for all the arguments that the
implementation expects

The call to `objc_msgSend` should not be performed as a variadic
call but instead as if it had the same signature as the method
that should be called but with the two additional parameter,
`self` and `op`, added first. The implementation of `objc_msgSend`
will jump to the method instead of calling it.

Because of the above, multiple versions exist of `objc_msgSend`.
Depending on the return type of the method that is called the correct
version need to be used. This depends on the ABI. This is a list of
functions and for which types they're used on OS X 64bit:

* objc_msgSend_stret - Used for structs too large to be returned in
registries
* objc_msgSend_fpret - Used for `long double`
* objc_msgSend_fp2ret - Used for `_Complex long double`
* objc_msgSend - Used for everything else

[1] 867d5479b6d98b23b6c797ee487d1ec1474bee10

-- 
/Jacob Carlborg
February 20, 2016
Jacob Carlborg <doob@me.com> writes:

> On 2016-02-19 02:04, Dan Olson wrote:
>
> It's only external classes and instance methods that are implemented so far in upstream DMD.

I think I had most of that working, but I'll have to review my old work.

> The commit message for the commit [1] that implements the support contains some explanation on how it works. The explanation is pretty high level and doesn't explain the data layout in the object files.
>
> I included the commit message here for convince:

It's a good description and I am excited to get it working!

I looked back and I stopped working on integrating your branch with LDC in Aug 2015.  I think that was when I realized there were darwin ABI problems with return structs like struct PointF {float x, y;} and worked on that instead.

Here was my last test file, with an example of what seemed to work.
There was a companion mainm.m file that defined MyClass and called dcall().

import objc.types;

struct PointF {
    float x, y;
}

struct PointR {
    real x, y;
}

extern (Objective-C)
class MyClass : NSObject
{
    int xyzzy;
    void funAtPointF(int i, PointF p) @selector("fun:atPointF:");
    void fun(int i) @selector("fun:");
    void fun(int a,int b) @selector("fun:and:");
    void foo(); // @selector("foo");
    int ifoo() @selector("ifoo");
    float ffoo() @selector("ffoo");
    double dfoo() @selector("dfoo");
    real rfoo() @selector("rfoo");
    creal crfoo() @selector("crfoo");
    PointF pfoo() @selector("pfoo");
    PointR prfoo() @selector("prfoo");
}

extern(C) int printf(const char*, ...);

extern(C)
int dcall(MyClass c)
{
    c.fun(42);
    c.fun(10, 1);
    c.funAtPointF(42, PointF(13,99));
    c.foo();

    auto i = c.ifoo();
    printf("%d\n", i);
    auto f = c.ffoo();
    printf("%f\n", f);
    auto d = c.dfoo();
    printf("%f\n", d);
    auto r = c.rfoo();
    printf("%Lf\n", r);
    //auto cr = c.crfoo();
    auto p = c.pfoo();
    printf("%g %g\n", p.x, p.y);
    auto pr = c.prfoo();
    printf("%Lg %Lg\n", pr.x, pr.y);

    void __selector(int) funSel = &MyClass.fun;
    funSel(c, 42);

    void __selector(int,int) funAndSel = &MyClass.fun;
    funAndSel(c, 1,10);

    auto funAtPointFSel = &MyClass.funAtPointF;
    //void __selector(int,PointF) funAtPointFSel = &MyClass.funAtPointF;
    funAtPointFSel(c, 101, PointF(1.5, 3.125));

    void __selector() fooSel = &MyClass.foo;
    fooSel(c);

    int __selector() ifooSel = &MyClass.ifoo;
    return ifooSel(c);
}

Output looked like this:
$ build/bin/ldc2 classd.d -c
$ cc mainm.m classd.o build/lib/libdruntime-ldc.a -lobjc
$ ./a.out
fun(42)
fun(10,1)
fun(42, PointF(13,99))
foo()
42 <- ifoo()
42
42 <- ffoo()
42.000000
42 <- dfoo()
42.000000
42 <- rfoo()
42.000000
42,2112 <- pfoo()
42 2112
42,2112 <- prfoo()
42 2112
fun(42)
fun(1,10)
fun(101, PointF(1.5,3.125))
foo()
42 <- ifoo()
dcall returned 42

-- 
Dan

February 21, 2016
On Thursday, 18 February 2016 at 11:49:15 UTC, Kai Nacke wrote:
> This really rocks. The next alpha version of ldc is not too far away!!!

I think the time would be right to merge-2.069 into master. We're green on Travis and AppVeyor, David's apparently already experimenting on merge-2.070 ;), and existing PRs shouldn't be that hard to rebase.

Great job guys! :)