On Thursday, 13 March 2014 at 12:02:24 UTC, Daniel Murphy wrote:

> The changes to dmd's source are all done(!), it's now time to start putting the manually ported stuff into the main repo.

That's great :).

--
/Jacob Carlborg

On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu wrote:

> I'll defer to domain experts on this one. Please advise.

Yeah, we need some comments from Walter, Daniel, Kenji and others of the core DMD developers. Probably good to have comments from David and Iain as well, to get a LDC and GDC perspective.

--
/Jacob Carlborg

Am Thu, 13 Mar 2014 14:20:54 +0000
schrieb "Jacob Carlborg" <doob@me.com>:

> On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu wrote:
> 
> > I'll defer to domain experts on this one. Please advise.
> 
> Yeah, we need some comments from Walter, Daniel, Kenji and others of the core DMD developers. Probably good to have comments from David and Iain as well, to get a LDC and GDC perspective.
> 
> --
> /Jacob Carlborg

Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff?

On 2014-03-13 17:16, Johannes Pfau wrote:

> Is it possible to split objc.c into two files, one for backend
> interfacing functions (ObjcSymbols) and one for the generic frontend
> stuff?

I would guess so. I would need to take a look to see how coupled the code in objc.c is. Although, most code is for backend.

-- 
/Jacob Carlborg

On 2014-03-13 18:13:44 +0000, Jacob Carlborg <doob@me.com> said:

> On 2014-03-13 17:16, Johannes Pfau wrote:
> 
>> Is it possible to split objc.c into two files, one for backend
>> interfacing functions (ObjcSymbols) and one for the generic frontend
>> stuff?
> 
> I would guess so. I would need to take a look to see how coupled the code in objc.c is. Although, most code is for backend.

I think that'd be a good idea too. When I wrote that code I wanted everything to be close by as it was easier to experiment, but there's no need for that now.

Perhaps, instead of splitting, classes derived from frontend classes (Expression, Declaration, Type) should be moved to their corresponding files and live with other similar classes of the frontend, protected in #if DMD_OBJC blocks.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

Can somebody with a greater d-objc knowledge have a look at this example project and tell this naive D-noob what he is missing?

https://github.com/DiveFramework/DiveFramework/tree/master/Examples/Tableview

I am pretty sure that it has something to do with memory management and ARC. First it all starts up right, but then a delegate method get's called in the wild and some memory segmentation is occurring calling  objectAtIndex, which is called on very different objects on multiple runs, and I cannot get any closer to the real issue.

NSMutableArray _applications ;

is the main culprit, in this I am trying to put some NSObject subclass objects. I have to admit that my mind is all Objective-C and very little D yet, and probably the solution is very simple. What I have further found is, that the crash occurs in relation to the visible table cells. As soon as a view for an invisible cell is requested, the seg fault occurs. I am trying to elaborate a TableView example using View based cells.

To compile the program, you only need to execute "dub" in the Examples/Tableview directory, of course assuming you have the latest d-objc branch dmd installed and dub (and Xcode, I am using 5.1.1 but 6 should work just as well).

Thanks a lot in advance!
Christian

On 2014-10-27 19:03, Christian Schneider wrote:
> Can somebody with a greater d-objc knowledge have a look at this example
> project and tell this naive D-noob what he is missing?
>
> https://github.com/DiveFramework/DiveFramework/tree/master/Examples/Tableview
>
>
> I am pretty sure that it has something to do with memory management and
> ARC. First it all starts up right, but then a delegate method get's
> called in the wild and some memory segmentation is occurring calling
> objectAtIndex, which is called on very different objects on multiple
> runs, and I cannot get any closer to the real issue.
>
> NSMutableArray _applications ;
>
> is the main culprit, in this I am trying to put some NSObject subclass
> objects. I have to admit that my mind is all Objective-C and very little
> D yet, and probably the solution is very simple. What I have further
> found is, that the crash occurs in relation to the visible table cells.
> As soon as a view for an invisible cell is requested, the seg fault
> occurs. I am trying to elaborate a TableView example using View based
> cells.
>
> To compile the program, you only need to execute "dub" in the
> Examples/Tableview directory, of course assuming you have the latest
> d-objc branch dmd installed and dub (and Xcode, I am using 5.1.1 but 6
> should work just as well).

I tried running your code and could observe the behavior. Although I have not been able to figure you why it behaves like this. In general there are a couple of things to think of and watch out for when interfacing between D and Objective-C :

* The D compiler does not support any form of ARC, it's back to using retain/release

* When allocating memory with the GC in D and passing it to Objective-C (or C for that matter) you have to make sure there is still a root pointing to the memory. This can either be a variable that is still in scope or by explicitly adding a new root by calling core.GC.addRoot.

I don't know if any of the above is the actual problem, but it could be. I would recommend trying to contact Michel Fortin how original implemented D/Objective-C.

BTW, There is a tool, DStep [1], that can automatically generate bindings for Objective-C code.

[1] https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg

> I tried running your code and could observe the behavior. Although I have not been able to figure you why it behaves like this. In general there are a couple of things to think of and watch out for when interfacing between D and Objective-C :
>
> * The D compiler does not support any form of ARC, it's back to using retain/release
>
> * When allocating memory with the GC in D and passing it to Objective-C (or C for that matter) you have to make sure there is still a root pointing to the memory. This can either be a variable that is still in scope or by explicitly adding a new root by calling core.GC.addRoot.
>
> I don't know if any of the above is the actual problem, but it could be. I would recommend trying to contact Michel Fortin how original implemented D/Objective-C.
>
> BTW, There is a tool, DStep [1], that can automatically generate bindings for Objective-C code.

Hey Jacob, thanks very much for your reply! It is of course this NSMutableArray that stores the custom objects containing NSString's and an NSImage, which gets deallocated after some time (still can see some garbage if I make it a static member). I will try to figure out how to use retain and release, I once knew how to do this quite well, but since ARC I quit to worry ;) Thanks for the core.GC.addRoot tip!

DStep was not very helpful when I tried it, it wanted to find all the referenced includes, which of course can be quite complicated when trying to get foundation and appkit headers processed.

Once this ARC / memory management stuff is resolved, d-objc on OSX will be super awesome!! Thanks to you and Michel for all the work!

On 2014-10-29 16:09, Christian Schneider wrote:

> DStep was not very helpful when I tried it, it wanted to find all the
> referenced includes, which of course can be quite complicated when
> trying to get foundation and appkit headers processed.

How do you mean? That it can't find stdarg.h and other header files? I think that can be solved by passing "-include <umbrella_header.h>" when invoking DStep. The problem is that these header files are not meant to be processed individually, but rather as a whole, i.e a translation unit.

In the future I hope to make it possible to use pass a framework to DStep and it will create bindings for the whole framework.

-- 
/Jacob Carlborg

> In the future I hope to make it possible to use pass a framework to DStep and it will create bindings for the whole framework.

That would be so cool!

Btw, fixed the example, thanks for giving me the right clues. Of course, it was just the manual memory management à la Objective-C that was missing! I am really lucky that I spent already days, maybe weeks debugging retain / release / autorelease on many projects, so for me this will be peanuts! I just had a little flashback. I love ARC and am looking forward for D to feature it as well, but for now, manual memory management is really not the thing that will put me off.

I have all the tools ready now! I can't believe how this all rocks ;)