Re: D/Objective-C, extern (Objective-C)

2014-09-24 Thread Christian Schneider via Digitalmars-d-announce
I almost got Chocolate running on a 10.9.4 machine with all the latest developer tools (including Xcode 6), all built from source and 64 bit with the latest git checkouts (including phobos). Of course it is not within Xcode but using dub, so the biggest thing yet to do is to bundle an OSX app

Re: D/Objective-C 64bit

2014-10-27 Thread Christian Schneider via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-29 Thread Christian Schneider via Digitalmars-d-announce
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,

Re: D/Objective-C 64bit

2014-10-29 Thread Christian Schneider via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-30 Thread Christian Schneider via Digitalmars-d-announce
I had a look at your fix. I see that you added a call to release in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all. Omg, how embarrassing ;) of course I need to put it in dealloc so that it will work with NSMutableArray

Re: D/Objective-C 64bit

2014-11-03 Thread Christian Schneider via Digitalmars-d-announce
I have a question regarding selectors. I wanted to set a double-click action in the tableview example. Currently i get the selector like this: objc.runtime.SEL doubleAction = cast(objc.runtime.SEL)AppDelegate.doubleClickAction ; demoTableView.setDoubleAction(doubleAction) ; Is

Re: D/Objective-C 64bit

2014-11-04 Thread Christian Schneider via Digitalmars-d-announce
I would expect to be using an ObjcObject instead of an NSObject here, but this does not compile. The signature of the target action seems to be irrelevant, it may have no or more parameters. I guess this is just ok and the expected behavior. Hmm, that sounds strange. What exact errors do

Re: D/Objective-C 64bit

2014-11-04 Thread Christian Schneider via Digitalmars-d-announce
Ok, some more info: I changed the mapping in tableview.d to: void setDoubleAction(void __selector(ObjcObject)) [setDoubleAction:] ; This should be the way to do it. Now in the implementation of the action: void doubleClickAction(ObjcObject sender) { NSLog(double click action) ;

Re: D/Objective-C 64bit

2014-11-04 Thread Christian Schneider via Digitalmars-d-announce
what is funky in this context (see above): even when using ObjcObject in both the mapping and the action method, the test if (sender is demoTableView) { // } does not fail in the action, only a cast to a NSTableView object fails. Of course, in this setting it's not really a problem, I can

Re: D/Objective-C 64bit

2014-11-04 Thread Christian Schneider via Digitalmars-d-announce
There is no test for interface-to-class casts in the D/Objective-C test suite, which means you're likely the first person to try that. It's probably just an oversight in the compiler code. Hey Michel, thanks very much for this explanation! That's actually good news. It certainly will be

Re: D/Objective-C 64bit

2014-11-05 Thread Christian Schneider via Digitalmars-d-announce
What happens if you declare doubleClickAction like this: void doubleClickAction(NSTableView sender) { ... } That will probably require a cast when passing the selector to setDoubleAction. Hi Jacob This just delegates the problem to another place. The target/action paradigm in Cocoa

Re: D/Objective-C 64bit

2014-11-06 Thread Christian Schneider via Digitalmars-d-announce
Oh, just found out, it seems that currently the extern C declarations don't work. This comes from the original Chocolat range.d extern (C) { nothrow: NSRange NSUnionRange(NSRange range1, NSRange range2) ; NSRange NSIntersectionRange(NSRange range1, NSRange

Re: D/Objective-C 64bit

2014-11-07 Thread Christian Schneider via Digitalmars-d-announce
Also when I tried to declare / use extern strings like from NSApplication.h: APPKIT_EXTERN NSString *NSApplicationDidHideNotification; I found no way to get this working. Is this a limitation of the current 64 bit port? I think that should work. How did you declare it? It should be

Re: D/Objective-C 64bit

2014-11-07 Thread Christian Schneider via Digitalmars-d-announce
I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if I use the declaration you suggested. What exactly are you doing with the string when you get the EXC_BAD_ACCESS? Also, can you reproduce the issue in an program just printing this variable with NSLog? I get the SIGSEGV when i

Re: D/Objective-C 64bit

2014-11-07 Thread Christian Schneider via Digitalmars-d-announce
Now I know what the problem is. In D, module variables are by default in TLS (thread local storage). To make it refer to a global C variable, use __gshared: extern (C) extern __gshared NSString NSApplicationDidHideNotification; Sorry, I completely forgot about that. Ha, awesome! It

Re: D/Objective-C 64bit

2014-11-11 Thread Christian Schneider via Digitalmars-d-announce
I guess you have to live using NSObject for now, until I fixed that. But in practice NSObject is the only root class. So far I've seen one other class, NSProxy, that doesn't inherit from NSObject. Ok, I had a quick look at this issue. It is implemented but it's not working. There is a test

Re: D/Objective-C 64bit

2014-11-16 Thread Christian Schneider via Digitalmars-d-announce
I am just stumbling over adding class objects to an array: I get an error when trying to add class objects to an NSArray because e.g. NSString.class does not conform to ObjcObject. There is some functions in the API that require arrays of class objects, e.g. in NSPasteboard: NSPasteboard pb

Re: D/Objective-C 64bit

2014-11-18 Thread Christian Schneider via Digitalmars-d-announce
Do you get a compile time error or runtime error? Compiling using dmd... source/document.d(79): Error: function foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is not callable using argument types (Class, Class, typeof(null)) compile time. hmm, a class object is of

Re: D/Objective-C 64bit

2014-11-18 Thread Christian Schneider via Digitalmars-d-announce
I'm wondering how I should deal with overriding designated initailizers. I really have no clue about the part self = [super...]. KeyboardView is a subclass of NSView. @implementation KeyboardView - (id)initWithFrame:(NSRect)frame { self = [super initWithFrame:frame]; if (self) {

Re: D/Objective-C 64bit

2014-11-18 Thread Christian Schneider via Digitalmars-d-announce
Speaking of drawing, I have a very serious problem wit NSView. I cannot call frame() nor bounds() on instances or subclasses and get a valid NSRect. (same goes for NSWindow frame()). I had similar problems when working with NSAttributedString and NSRange, because NSRange from Chocolat was

Re: D/Objective-C 64bit

2014-11-18 Thread Christian Schneider via Digitalmars-d-announce
Compiling using dmd... source/document.d(79): Error: function foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is not callable using argument types (Class, Class, typeof(null)) Hmm, I don't know. Can you use a cast to get around the problem? Perhaps use a variadic template

Re: D/Objective-C 64bit

2014-11-18 Thread Christian Schneider via Digitalmars-d-announce
Could it be this issue [1]? Can you please see if you can reproduce it using just plain C. https://issues.dlang.org/show_bug.cgi?id=5570 Uh, oh, that bug looks like a major annoyance in 64bit! I made a few checks, all appkit methods returning a NSRect currently produce a runtime segfault.

Re: D/Objective-C 64bit

2014-11-18 Thread Christian Schneider via Digitalmars-d-announce
Can't you just call super in the beginning of the method and then call return this at the end. Something like this: override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] { super.initWithFrame(frame); // my stuff return this; } Ups, sorry, my bad! I was trying this

Re: D/Objective-C 64bit

2014-11-19 Thread Christian Schneider via Digitalmars-d-announce
I forgot to ask, do you have a small test case showing this problem? Without windows or any other fancy stuff. Just setup a small temporary repository for this: https://github.com/DiveFramework/FixingNSRect Without an OSX application with windows et al, it won't show you the send bug

Re: D/Objective-C 64bit

2014-11-26 Thread Christian Schneider via Digitalmars-d-announce
Why not use a constructor and let the compiler manage the boilerplate? this(NSRect frame) [initWithFrame:] { //my stuff super(frame); } This should emit the same code as the function above (but I haven't tested). And then you can write:

Re: D/Objective-C 64bit

2014-12-17 Thread Christian Schneider via Digitalmars-d-announce
This should be fixed now in my forks [1] [2]. Note, I've also replaced the selector syntax, [foo], with a compiler recognized UDA, @selector(foo). [1] https://github.com/jacob-carlborg/dmd/tree/d-objc [2] https://github.com/jacob-carlborg/druntime/tree/d-objc OMG, what did you do? all my

Re: D/Objective-C 64bit

2014-12-18 Thread Christian Schneider via Digitalmars-d-announce
The reason for the change is that the old syntax, [foo:bar:], required language changes wheres the new syntax, @selector(foo:bar:), doesn't. When D/Objective-C was initially created D didn't support UDA's, that's why a new syntax was invented. If D had supported UDA's back then, that would

Re: D/Objective-C 64bit

2014-12-21 Thread Christian Schneider via Digitalmars-d-announce
awesome, thank you very much!

Re: D/Objective-C 64bit

2014-12-25 Thread Christian Schneider via Digitalmars-d-announce
Just for my information: Why is it no longer possible to have multiple d methods (or overloaded constructors) to map to the same Objective-C implementation? I though it was quite nice to have overloaded d constructors for the various init.. methods.

Re: D/Objective-C 64bit

2014-12-25 Thread Christian Schneider via Digitalmars-d-announce
Was just upgrading everything to the latest Github, dmd, druntime (the d-objc branch). It does not seem to be able to link into the AppKit and Foundation anymore. dmd fails silently with error code -11 I uploaded a very stripped down project (containing everything) that you might want to

Re: D/Objective-C 64bit

2014-12-29 Thread Christian Schneider via Digitalmars-d-announce
On Friday, 26 December 2014 at 17:47:29 UTC, Jacob Carlborg wrote: On 2014-12-25 14:12, Christian Schneider wrote: Just for my information: Why is it no longer possible to have multiple d methods (or overloaded constructors) to map to the same Objective-C implementation? I though it was

Re: D/Objective-C 64bit

2014-12-29 Thread Christian Schneider via Digitalmars-d-announce
It's the destructor in NSObject that causes the problem. I'll take a look. Remove that and your example will work, after you import the missing foundation.runtime in app. Once again, thank you very much for your help! It works now with the new @selector style, and I would had the biggest