Re: D/Objective-C 64bit
On 2014-12-29 22:39, Christian Schneider wrote:
I just report another finding here. It's about properties and NSStrings.
So far, it was possible to set the strings of an alert like this (source
copied from the Chocolat example):
auto alert = new NSAlert ;
alert.messageText = "Want Chocolate?" ;
alert.informativeText = "Chocolate is sweet." ;
This now needs to be written like this:
auto alert = new NSAlert ;
alert.setMessageText("Want Chocolate?") ;
alert.setInformativeText("Chocolate is sweet.") ;
In the NSAlert class, the respective code is:
extern (Objective-C)
class NSAlert : NSObject {
@property {
NSString messageText() ;
void setMessageText(NSString text) @selector("setMessageText:") ;
NSString informativeText() ;
void setInformativeText(NSString text)
@selector("setInformativeText:") ;
}
}
Of course, the property read/write access style is again just a
convenience, but for somebody coming from Objective-C, it is "natural"
to do it either way.
It might be some issue with properties. I'll have to look into that as
well. D/Objective-C has some special treatment for properties. As a
workaround you do one of the following alternatives:
* Declare the method as "messageText" instead of "setMessageText"
* Add a alias for "setMessageText" to "messageText"
* Add a method, "messageText", that forwards to "setMessageText". Any D
method that takes one argument can be called like a setter
* Add an overload for "messageText" to take an argument as well
You might need to drop @property for some of these alternatives
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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 problems
finding out that it was the destructor making dmd bail out a -11.
---
I just report another finding here. It's about properties and
NSStrings. So far, it was possible to set the strings of an alert
like this (source copied from the Chocolat example):
auto alert = new NSAlert ;
alert.messageText = "Want Chocolate?" ;
alert.informativeText = "Chocolate is sweet." ;
This now needs to be written like this:
auto alert = new NSAlert ;
alert.setMessageText("Want Chocolate?") ;
alert.setInformativeText("Chocolate is sweet.") ;
In the NSAlert class, the respective code is:
extern (Objective-C)
class NSAlert : NSObject {
@property {
NSString messageText() ;
void setMessageText(NSString text)
@selector("setMessageText:") ;
NSString informativeText() ;
void setInformativeText(NSString text)
@selector("setInformativeText:") ;
}
}
Of course, the property read/write access style is again just a
convenience, but for somebody coming from Objective-C, it is
"natural" to do it either way.
Re: D/Objective-C 64bit
On 2014-12-29 20:01, Christian Schneider wrote:
previously it was possible to have a few D methods "point" to the same
Objective-C method like this:
NSView initWithFrame(NSRect frameRect) @selector("initWithFrame:") ;
this(NSRect frameRect) @selector("initWithFrame:") ;
Now with the latest version I get this error for the above two lines:
../../Interfaces/appkit/view.d(19): Error: constructor
appkit.view.NSView.this Objcective-C selector 'initWithFrame:' already
in use by function 'initWithFrame'.
I thought, it was a nice convenience to make both potential types of
programmers happy, those leaning more towards Objective-C / named
parameters can use the verbose, first option, while the ones coming more
from C/C++ can use the shortcut, the 2nd option.
But it's no big deal, I'll just remove the "shortcut". My question was
more for understanding why it was a) possible in the past and b) what is
the motivation behind the decision that it is no longer possible now.
I'm not sure what's happened. Perhaps it's a bug that now have been
fixed. I'll add it to my todo list.
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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 quite nice to have overloaded d constructors
for the
various init.. methods.
Can you give me an example of what's not working?
previously it was possible to have a few D methods "point" to the
same Objective-C method like this:
NSView initWithFrame(NSRect frameRect)
@selector("initWithFrame:") ;
this(NSRect frameRect) @selector("initWithFrame:") ;
Now with the latest version I get this error for the above two
lines:
../../Interfaces/appkit/view.d(19): Error: constructor
appkit.view.NSView.this Objcective-C selector 'initWithFrame:'
already in use by function 'initWithFrame'.
I thought, it was a nice convenience to make both potential types
of programmers happy, those leaning more towards Objective-C /
named parameters can use the verbose, first option, while the
ones coming more from C/C++ can use the shortcut, the 2nd option.
But it's no big deal, I'll just remove the "shortcut". My
question was more for understanding why it was a) possible in the
past and b) what is the motivation behind the decision that it is
no longer possible now.
Re: D/Objective-C 64bit
On 2014-12-25 15:30, Christian Schneider wrote: 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 have a look at, it just declares a NSString and tries to log it: http://diveframework.com/files/supersimple.zip dub -v gives really no clue whatsoever is failing. I am really sorry that I can not be more specific / helpful for making this work. 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". -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 quite nice to have overloaded d constructors for the various init.. methods. Can you give me an example of what's not working? -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 have a look at, it just declares a NSString and tries to log it: http://diveframework.com/files/supersimple.zip dub -v gives really no clue whatsoever is failing. I am really sorry that I can not be more specific / helpful for making this work.
Re: D/Objective-C 64bit
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
awesome, thank you very much!
Re: D/Objective-C 64bit
On 2014-12-18 23:31, Christian Schneider wrote:
Regex is one of my weaknesses. If you don't mind sharing yours (and if
you have them still lying around) please send to schneider at
gerzonic.net, this would be greatly appreciated, and would make my life
a bit easier.
These are two simple regular expression that you can use:
\)\s*\[([\w:]+)\];$
Replace with
) @selector("$1");
And
\)\s*\[([\w:]+)\]$
Replace with
) @selector("$1")
They make some assumption about the code. They will match:
a closing parenthesis ->
zero or more spaces ->
opening bracket ->
at least one or more of: A-Z, a-z, a colon or 0-9 ->
closing bracket ->
semicolon ->
end of line
In the above description the arrow, "->", should be read as "followed by".
When replacing the text, $1 will represent what's caught in the first
group. In this case what's in between the brackets.
The difference between the first and the second regular expression is
the trailing semicolon, to handle both extern declarations and methods
defined in the D source code.
These regular expression assume you only have the selector on the right
side of the method declaration, i.e. no UDA's or similar.
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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 most likely have been used.
Hopefully this will also increase the chances of D/Objective-C
being merged with upstream DMD.
OK! Yes I understand, the merge with upstream DMD is one of the
most important things, i totally agree.
I updated all the tests quickly with some global search and
replace using regular expression.
Regex is one of my weaknesses. If you don't mind sharing yours
(and if you have them still lying around) please send to
schneider at gerzonic.net, this would be greatly appreciated, and
would make my life a bit easier.
this is all a great and exciting adventure ;)
Re: D/Objective-C 64bit
On 2014-12-17 20:51, Christian Schneider wrote:
OMG, what did you do? all my beautiful appkit and foundation header
files are destroyed! do you plan any other such attacks?
Hopefully no :)
lol, i must admit, i was a bit shocked about this sudden surprise. what
is the main motivation? i thought the old style looked good because it
made visually clear that it was glue into objective-c, as it looked very
familiar.
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 most likely have been used.
Hopefully this will also increase the chances of D/Objective-C being
merged with upstream DMD.
with a little scripting / string processing i can adapt to the
new style, i guess.
I updated all the tests quickly with some global search and replace
using regular expression.
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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 beautiful appkit and foundation
header files are destroyed! do you plan any other such attacks?
lol, i must admit, i was a bit shocked about this sudden
surprise. what is the main motivation? i thought the old style
looked good because it made visually clear that it was glue into
objective-c, as it looked very familiar. with a little scripting
/ string processing i can adapt to the new style, i guess.
Re: D/Objective-C 64bit
On 2014-11-04 10:07, Christian Schneider wrote:
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") ;
NSLog("the sender: %@", sender) ;
}
This works fine and prints the log: 2014-11-04 10:01:57.967
tableview[9988:507] the sender:
But now I would like to do something with this sender, like I do
often in an Objective-C project:
NSTableView tableView = cast(NSTableView)sender ;
I get a EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
replace both ObjcObject with NSObject (in tableview.d, the
mapping, and the target action) this cast works. I might be
missing something obvious here.
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
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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:
auto view = new KeyboardView(someFrame);
and have proper type safety.
Thanks Michel, my question was based on a completely wrong
assumption (really sorry, my bad), the code of course works,
which is again really cool about the D/Objective-C bridging.
When I prepare the framework glue headers I usually add both
variations init.. and this(), so the coder who uses it can take
the shortcut if he prefers. I try to stay as close as possible to
the naming conventions of the Cocoa framework, it facilitates
somewhat the documentation lookup in Xcode. Named parameters is
probably the feature I like most about Objective-C, it makes the
code so much more readable and auto-documents, if one is careful.
Re: D/Objective-C 64bit
On 2014-11-18 09:07:10 +, Christian Schneider said:
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
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:
auto view = new KeyboardView(someFrame);
and have proper type safety.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: D/Objective-C 64bit
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 report" dialog, this is where I found the other information. If you want to, you can open the most simple example in DiveFramework, e.g. OpenGLView and ask the main window for bounds or the frame. After a good night sleep, I came up with this: no way this can be a deal breaker, if push comes to shove I'll just create a small Framework containing wrapper functions with NSRect pointers for all the methods returning NSRect. Luckily, there are not too many of these. But still, they are extremely vital once you start messing with complicated gui stuff e.g. like darn NSScrollViews or even worse NSSplitViews. Thanks for having a look into this ;)
Re: D/Objective-C 64bit
On 2014-11-18 21:54, Christian Schneider wrote: 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. But this does not apply to NSSize, nor NSPoint, functions returning either NSSize or NSPoint work. What I have found out so far: all the extern C functions in geometry.d work just fine.. e.g. NSRectFromString does what it's supposed to do. I forgot to ask, do you have a small test case showing this problem? Without windows or any other fancy stuff. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 21:54, Christian Schneider wrote: 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. But this does not apply to NSSize, nor NSPoint, functions returning either NSSize or NSPoint work. What I have found out so far: all the extern C functions in geometry.d work just fine.. e.g. NSRectFromString does what it's supposed to do. If this is works for extern(C) functions then it might be a problem with the extern(Objective-C) functions. Perhaps it's not using the correct objc_msgSend functions under the hood. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 21:46, Christian Schneider wrote: Yes, of course, and this is really not an issue! And this convenience function can be rewritten in a few lines of code, if really necessary. Good, I just want to make sure you can continue. Than we can figure out the minor issues later. Anyway, I added it to my todo list. -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 and had an exception, but
not from the constructor! Of course this works just fine! Excuse
me for the noise, I should remove my post (if I only could ;).
Re: D/Objective-C 64bit
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. But this does not apply to NSSize, nor NSPoint, functions returning either NSSize or NSPoint work. What I have found out so far: all the extern C functions in geometry.d work just fine.. e.g. NSRectFromString does what it's supposed to do.
Re: D/Objective-C 64bit
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 to make the API simpler. Yes, of course, and this is really not an issue! And this convenience function can be rewritten in a few lines of code, if really necessary.
Re: D/Objective-C 64bit
On 2014-11-18 13:47, Christian Schneider wrote: 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 still 32 bit. After fixing this, it all worked perfectly. The parameter to drawRect, which is a NSRect as well contains correct values. So it seems to me that the NSRect struct declared as is should work just fine. I am trying to implement drawRect in an NSView subclass (in the Portmidi example, KeyboardView). Everything works fine, NSBezierPath drawing methods etc., but I cannot call this.frame() nor this.bounds() from within that method without triggering a runtime segmentation fault. Often I see this in the crash log as last "message": misaligned_stack_error_entering_dyld_stub_binder Sometimes there is other stuff, but always indicating a memory corruption. 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 -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 10:07, Christian Schneider wrote:
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) {
// Initialization code here.
}
return self;
}
@end
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
This compiles and does not throw any runtime error, but it's a bit
against the idea, because in Objective-C the idea is to first call the
super class, then adapt and override what is necessary. When calling
super in the very end, this of course is no longer guaranteed.
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;
}
--
/Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-18 09:46, Christian Schneider wrote: 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 course not an ObjcObject, how could it be. I think here is a limit to what is possible, this is the darn id of Objective-C that makes all this funky convenience possible. Actually, it's not a big deal, there is other methods to get what you want and the above mentioned function in question is by itself just a convenience. Hmm, I don't know. Can you use a cast to get around the problem? Perhaps use a variadic template to make the API simpler. -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 still 32 bit. After
fixing this, it all worked perfectly. The parameter to drawRect,
which is a NSRect as well contains correct values. So it seems to
me that the NSRect struct declared as is should work just fine.
I am trying to implement drawRect in an NSView subclass (in the
Portmidi example, KeyboardView). Everything works fine,
NSBezierPath drawing methods etc., but I cannot call this.frame()
nor this.bounds() from within that method without triggering a
runtime segmentation fault. Often I see this in the crash log as
last "message":
misaligned_stack_error_entering_dyld_stub_binder
Sometimes there is other stuff, but always indicating a memory
corruption.
I have not the slightest idea what could be the problem here, it
most likely is not a threading issue, as drawRect is anyway
called on the main thread, and usually one only has crashes if
one tries to update widgets from background threads, which of
course is not allowed in Cocoa, as the AppKit is not thread safe.
I just checked back, for any widget it fails. You can easily
reproduce it by e.g. opening the SimpleWebBrowser example and add
in applicationDidFinishLaunching (this is a good point, because
all the UI element should be ready):
NSRect backButtonFrame = backButton.frame() ;
NSLog("frame %f %f %f %f", backButtonFrame.origin.x,
backButtonFrame.origin.y, backButtonFrame.size.width,
backButtonFrame.size.height) ;
For custom components, if this won't work, it is almost a deal
breaker for using Cocoa through D. This is quite a setback, all
the rest so far encountered is working so beautifully.
Re: D/Objective-C 64bit
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) {
// Initialization code here.
}
return self;
}
@end
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame)
[initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
This compiles and does not throw any runtime error, but it's a
bit against the idea, because in Objective-C the idea is to first
call the super class, then adapt and override what is necessary.
When calling super in the very end, this of course is no longer
guaranteed.
Re: D/Objective-C 64bit
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 course not an ObjcObject, how could it be. I think here is a limit to what is possible, this is the darn id of Objective-C that makes all this funky convenience possible. Actually, it's not a big deal, there is other methods to get what you want and the above mentioned function in question is by itself just a convenience.
Re: D/Objective-C 64bit
On 2014-11-16 12:16, Christian Schneider wrote: 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 = NSPasteboard.generalPasteboard() ; NSArray classes = NSArray.arrayWithObjects(NSString.class, NSAttributedString.class, null) ; NSString pbItem = cast(NSString) pb.readObjectsForClasses_options(classes, null).lastObject() ; Do you get a compile time error or runtime error? -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 = NSPasteboard.generalPasteboard() ; NSArray classes = NSArray.arrayWithObjects(NSString.class, NSAttributedString.class, null) ; NSString pbItem = cast(NSString) pb.readObjectsForClasses_options(classes, null).lastObject() ; Sure, there are other functions in NSPasteboard, and readObjectsForClasses_options is not the only way to get the pasteboard items, but a great convenience in given settings.
Re: D/Objective-C 64bit
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 but that's only casting from a class to an interface, not the other way around. Either there's an issue in the druntime function "_dobjc_interface_cast" or in the compiler (most likely in the compiler). OK, I see. I can live with that for now, it's just a bit unfortunate because then I will have to touch the interface headers again once it works. Just stumbled upon this thing once again while trying to use mutableCopy ;) It looks like the casting is implemented here [2], or at least parts of it. [2] https://github.com/jacob-carlborg/dmd/blob/d-objc/src/e2ir.c#L3843-L3854 whoa, thanks for that look deep into the abyss ;)
Re: D/Objective-C 64bit
On 2014-11-07 17:05, Christian Schneider wrote: Ha, awesome! It works! I'll add this to a wiki page in the DiveFramework github repos. Thanks again! No problem :). This isn't mention in the DIP since this has nothing to do with Objective-C, it's rather plain C. This is documented here [1]. Oh, and btw, I was briefly looking into the DMD source for trying to fix myself the issue with the protocol to class instance cast (trying to be useful), but I am seriously completely not hardcore enough of digging anything in there, lol. I had no idea what I was doing when I started with this :) Anyhow, if you got a hint, let me know. It's not just in the example discussed in my other posts, I found it to be an issue in other places as well, as often framework classes return id / ObjcObject instead of a further typed instance. I don't remember where exactly I had a problem, but I remember I used NSObject instead of ObjcObject in these places, which of course is not the way to go. 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 but that's only casting from a class to an interface, not the other way around. Either there's an issue in the druntime function "_dobjc_interface_cast" or in the compiler (most likely in the compiler). It looks like the casting is implemented here [2], or at least parts of it. [1] http://dlang.org/interfaceToC.html [2] https://github.com/jacob-carlborg/dmd/blob/d-objc/src/e2ir.c#L3843-L3854 -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 works! I'll add this to a wiki page in the DiveFramework github repos. Thanks again! Oh, and btw, I was briefly looking into the DMD source for trying to fix myself the issue with the protocol to class instance cast (trying to be useful), but I am seriously completely not hardcore enough of digging anything in there, lol. Anyhow, if you got a hint, let me know. It's not just in the example discussed in my other posts, I found it to be an issue in other places as well, as often framework classes return id / ObjcObject instead of a further typed instance. I don't remember where exactly I had a problem, but I remember I used NSObject instead of ObjcObject in these places, which of course is not the way to go. Have a nice weekend!
Re: D/Objective-C 64bit
On 2014-11-07 15:23, Christian Schneider wrote: I get the SIGSEGV when i try to NSLog this string constant. I was not looking any further, because if it fails to NSLog, i can't do anything with it ;) 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. -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 try to NSLog this string constant. I was not looking any further, because if it fails to NSLog, i can't do anything with it ;)
Re: D/Objective-C 64bit
On 2014-11-07 13:12, Christian Schneider wrote: Jacob, thank you very much for your reply and explanations! 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? In the case for notification string constants, when I log it in Objective-C, it just equals to "NSApplicationDidHideNotification", so these could be simply redeclared for such strings, but that's not very stylish and against the basic idea, i guess. Yeah, that's not pretty, it should work like in Objective-C. -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 declared like this: extern (C) extern NSString NSApplicationDidHideNotification; I tried with a standard D compiler and void* instead of NSString and that worked. "extern (C)" tells the compiler to use C linkage, the second "extern" tells the compiler this symbols is defined somewhere else, i.e. in some library. Jacob, thank you very much for your reply and explanations! I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if I use the declaration you suggested. In the case for notification string constants, when I log it in Objective-C, it just equals to "NSApplicationDidHideNotification", so these could be simply redeclared for such strings, but that's not very stylish and against the basic idea, i guess.
Re: D/Objective-C 64bit
On 2014-11-06 17:06, Christian Schneider wrote:
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 range2) ;
NSString NSStringFromRange(NSRange range) ;
NSRange NSRangeFromString(NSString aString) ;
NSRange NSMakeRange(NSUInteger loc, NSUInteger len) ;
NSUInteger NSMaxRange(NSRange range) ;
bool NSEqualRanges(NSRange range1, NSRange range2) ;
}
When trying to use NSMakeRange i get:
Undefined symbols for architecture x86_64:
"_NSMakeRange", referenced from:
I wasn't able to link with the symbol either. But when I tried in
Objective-C it worked, but only when I imported Foundation.h, not when I
declared NSMakeRange myself. That got me thinking and I had a look in
the Foundation NSRange.h header file. "NSMakeRange" and friends are
implement directly in the header file to allow inlining. D cannot access
inlined functions if they don't exist in a library.
In general you need to reimplement these functions in D. In this
particular case, with NSMakeRange, you can just do this in D instead:
auto range = NSRange(1, 2);
The above is a syntax that is allowed for all structs. If you really
want to type "NSMakeRange" you need implement the function yourself or
make an alias and use the above syntax:
alias NSMakeRange = NSRange;
The downside with the alias is that it allows to use "NSMakeRange" as a
struct as well:
NSMakeRange range;
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 declared
like this:
extern (C) extern NSString NSApplicationDidHideNotification;
I tried with a standard D compiler and void* instead of NSString and
that worked.
"extern (C)" tells the compiler to use C linkage, the second "extern"
tells the compiler this symbols is defined somewhere else, i.e. in some
library.
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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 range2) ;
NSStringNSStringFromRange(NSRange range) ;
NSRange NSRangeFromString(NSString aString) ;
NSRange NSMakeRange(NSUInteger loc, NSUInteger len) ;
NSUInteger NSMaxRange(NSRange range) ;
boolNSEqualRanges(NSRange range1, NSRange range2) ;
}
When trying to use NSMakeRange i get:
Undefined symbols for architecture x86_64:
"_NSMakeRange", referenced from:
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?
Thanks again. Christian
Re: D/Objective-C 64bit
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 programming gets a lot from the
fact that any object can be the sender of an action. In this
particular case I'd even prefer the conditional if the sender
"is" the local table view member var, which then basically has
the same effect as what you suggested above.
I think the best thing will be to fix the interface-to-class
casts in the compiler, as Michel suggests above.
Thanks again
Christian
Re: D/Objective-C 64bit
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 good to have this fixed, as the target action mechanism gets a lot of it's spice that the "sender" only needs to comply to a protocol and can be whatever control or even nil. Best! Christian
Re: D/Objective-C 64bit
On 2014-11-04 23:46, Michel Fortin wrote: Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. Yeah, that would be preferable. I would like to avoid the mess that the migration from D1 to D2 caused. Where if one wanted to support both some D2 code needed to be in a string mixin guarded with a version block. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-04 13:29, Christian Schneider wrote:
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
That will just compare the address of the objects.
, only a cast to a NSTableView object
fails. Of course, in this setting it's not really a problem, I
can work directly on the demoTableView member and can forget
about the sender, but this is against how I would do it in
Objective-C where I can always cast an id reference to the
expected type.
See the reply by Michel. It's probably a bug/oversight in the compiler.
As a workaround you can, as you said, use NSObject instead of ObjcObject
in both places.
What happens if you declare "doubleClickAction" like this:
void doubleClickAction(NSTableView sender) { ... }
That will probably require a cast when passing the selector to
"setDoubleAction".
--
/Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-01 10:47:54 +, Jacob Carlborg said: On 2014-11-01 01:58, Michel Fortin wrote: That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or "this.class" to get the metaclass) "this.class" could perhaps be called "this.classof", at least that's valid syntax. Although I don't know what to do about __selector. Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-04 09:07:08 +, "Christian Schneider"
said:
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
That's indeed the best way to do it.
This should be the way to do it. Now in the implementation of the
action:
void doubleClickAction(ObjcObject sender) {
NSLog("double click action") ;
NSLog("the sender: %@", sender) ;
}
This works fine and prints the log: 2014-11-04 10:01:57.967
tableview[9988:507] the sender:
But now I would like to do something with this sender, like I do
often in an Objective-C project:
NSTableView tableView = cast(NSTableView)sender ;
I get a EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
replace both ObjcObject with NSObject (in tableview.d, the
mapping, and the target action) this cast works. I might be
missing something obvious here.
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.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: D/Objective-C 64bit
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 work directly on the demoTableView member and can forget
about the sender, but this is against how I would do it in
Objective-C where I can always cast an id reference to the
expected type.
Re: D/Objective-C 64bit
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") ;
NSLog("the sender: %@", sender) ;
}
This works fine and prints the log: 2014-11-04 10:01:57.967
tableview[9988:507] the sender:
But now I would like to do something with this sender, like I do
often in an Objective-C project:
NSTableView tableView = cast(NSTableView)sender ;
I get a EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
replace both ObjcObject with NSObject (in tableview.d, the
mapping, and the target action) this cast works. I might be
missing something obvious here.
Thanks again.
Re: D/Objective-C 64bit
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 you get?
source/appdelegate.d(47): Error: function
appkit.tableview.NSTableView.setDoubleAction (objc_selector*
aSelector) is not callable using argument types (extern
(Objective-C) void __selector(ObjcObject))
Line 46 & 47:
auto doubleAction = &AppDelegate.doubleClickAction ;
demoTableView.setDoubleAction(doubleAction) ;
Line 80:
void doubleClickAction(ObjcObject sender) {
actually, when line 46 & 47 are like above, it doesn't matter if
I change ObjcObject to NSObject, but I guess my problem here is
how Map the function in tableview.d:
void setDoubleAction(objc.runtime.SEL aSelector)
[setDoubleAction:] ;
[1]
https://github.com/jacob-carlborg/dmd/blob/d-objc/test/runnable/objc/objc_selector.d
I know Dip 43 almost by heart now, but I haven't yet discovered
the tests you wrote. Nice, this will be extremely helpful.
Best!
Re: D/Objective-C 64bit
On 2014-11-03 09:51, Christian Schneider wrote:
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 this the recommended/right way to do it?
No, have a look at the tests for selectors [1]. I'm not sure if you need
to cast it to "SEL". Try just using "auto":
auto doubleAction = &AppDelegate.doubleClickAction;
Then the double-click action looks like this:
void doubleClickAction(NSObject sender) {
NSTableView tableView = cast(NSTableView)sender ;
if (sender is demoTableView) {
NSInteger clickedRow = demoTableView.clickedRow() ;
Item item = cast(Item)_applications.objectAtIndex(clickedRow) ;
NSWorkspace.sharedWorkspace().launchApplication(item.itemDisplayName()) ;
}
}
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 you get?
[1]
https://github.com/jacob-carlborg/dmd/blob/d-objc/test/runnable/objc/objc_selector.d
--
/Jacob Carlborg
Re: D/Objective-C 64bit
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 this the recommended/right way to do it?
Then the double-click action looks like this:
void doubleClickAction(NSObject sender) {
NSTableView tableView = cast(NSTableView)sender ;
if (sender is demoTableView) {
NSInteger clickedRow = demoTableView.clickedRow() ;
Item item =
cast(Item)_applications.objectAtIndex(clickedRow) ;
NSWorkspace.sharedWorkspace().launchApplication(item.itemDisplayName())
;
}
}
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. In
Objective-C, if the action signature does not comply you will get
warnings or errors.
Re: D/Objective-C 64bit
On 2014-11-01 01:58, Michel Fortin wrote: That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or "this.class" to get the metaclass) "this.class" could perhaps be called "this.classof", at least that's valid syntax. Although I don't know what to do about __selector. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-01 01:54, Michel Fortin wrote: I can't remember if this is an oversight or just something that I hadn't got to yet. In my mind this was already done. I did a grep for "dealloc" and couldn't find anything related. Anyway, the answer is *yes*: the destructor should be mapped to the "dealloc" selector. It should also implicitly call the destructor for any struct within the object and call it's superclass's destructor (if present), the usual D semantics for a destructor (that part might already work actually). -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-10-30 09:16:34 +, "Martin Nowak" said:
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
A DIP is available here [1] and the latest implementation is available
here [2].
[1] http://wiki.dlang.org/DIP43
Instead of adding the selector syntaxsyntax you could reuse pragma mangle.
Nooo! Mangling is something different from the selector name. Mangling
is the linker symbol for the function. The selector is the name used to
find the function pointer for a given a dynamic object (with similar
purpose to a vtable offset). The function has both a mangled name and a
selector name, and they're always two different names.
Alternatively a compiler recognized UDA would work too.
@objcSel!("insertItemWithObjectValue", "atIndex")
void insertItem(ObjcObject object, NSInteger value);
Ah, that's better. Except you really should use a single string with
colons, otherwise you'll have a problem distinguishing no-parameter
selectors from single-parameter selectors.
Changing the lexer and parser would affect all D language tools
(editors, formatters, linters, other compilers). So now that we do have
UDAs I don't see a justification for changing the syntax and grammar of
D.
Very true. I agree. Now that UDAs exist, it'd be preferable to use them.
That said, there are other parts of D/Objective-C that could pose
difficulties to existing languages tools, some syntactic (__selector,
or "this.class" to get the metaclass), some semantic (overridable
static methods having a "this" pointing to the metaclass). I had to
bend the rules in some places to make all that work. But it's true that
nothing will be more confusing to those tools than the selector
declaration currently following a function name.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: D/Objective-C 64bit
On 2014-10-30 07:13:08 +, Jacob Carlborg said: 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. D/Objective-C never allocates Objective-C objects on the GC heap. If an object derives from NSObject it is allocated using the usual Objective-C alloc class method when you use the "new" keyword. Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc". Whoever instantiated the object has no bearing on who will deallocate and call its destructor. When you call release() and the counter falls to zero, "dealloc" is called and the memory is then released. Whether that call to release() was made from D or Objective-C code is irrelevant. Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init". I can't remember if this is an oversight or just something that I hadn't got to yet. In my mind this was already done. Anyway, the answer is *yes*: the destructor should be mapped to the "dealloc" selector. It should also implicitly call the destructor for any struct within the object and call it's superclass's destructor (if present), the usual D semantics for a destructor (that part might already work actually). -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-10-30 10:16, Martin Nowak wrote:
Instead of adding the selector syntaxsyntax you could reuse pragma mangle.
extern (Objective-C)
class NSComboBox : NSTextField
{
private void* _dataSource;
pragma(mangle, objcMangle!(NSComboBox, "insertItemWithObjectValue",
"atIndex")
void insertItem(ObjcObject object, NSInteger value);
}
Alternatively a compiler recognized UDA would work too.
@objcSel!("insertItemWithObjectValue", "atIndex")
void insertItem(ObjcObject object, NSInteger value);
Changing the lexer and parser would affect all D language tools
(editors, formatters, linters, other compilers). So now that we do have
UDAs I don't see a justification for changing the syntax and grammar of D.
Seems like a fair point, I guess I could change that. I prefer using a
UDA for this.
--
/Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-10-30 16:28, Christian Schneider wrote: So far, I was not even considering a D library that would be used through Objective-C code, but yeah, that's a good point as well. Isn't that what's usually happens when using something like an app delegate. It will be instantiated by the framework when loading a nib. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-10-30 10:23, John Colvin wrote: Slightly derailing the conversation, but I see this all the time... Isn't the situation actually this: GC allocated objects are not guaranteed to be de-allocated before program termination. If a GC allocated object is deallocated, its destructor *is* guaranteed to be called. Except: Destructors are not called for arrays of objects, whether they are structs or emplaced classes, even when they are de-allocated. Yes, that's the longer explanation :) -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 et al. if I am going Objective-C memory management, then I should do it the intended way indeed! Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc". So far, I was not even considering a D library that would be used through Objective-C code, but yeah, that's a good point as well. Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init". We will have to find out, but dealloc definitely is the destructor in Objc.
Re: D/Objective-C 64bit
On Thursday, 30 October 2014 at 07:13:09 UTC, Jacob Carlborg wrote: On 2014-10-29 22:51, Christian Schneider wrote: 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 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. Slightly derailing the conversation, but I see this all the time... Isn't the situation actually this: GC allocated objects are not guaranteed to be de-allocated before program termination. If a GC allocated object is deallocated, its destructor *is* guaranteed to be called. Except: Destructors are not called for arrays of objects, whether they are structs or emplaced classes, even when they are de-allocated.
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
A DIP is available here [1] and the latest implementation is
available here [2].
[1] http://wiki.dlang.org/DIP43
Instead of adding the selector syntaxsyntax you could reuse
pragma mangle.
extern (Objective-C)
class NSComboBox : NSTextField
{
private void* _dataSource;
pragma(mangle, objcMangle!(NSComboBox,
"insertItemWithObjectValue", "atIndex")
void insertItem(ObjcObject object, NSInteger value);
}
Alternatively a compiler recognized UDA would work too.
@objcSel!("insertItemWithObjectValue", "atIndex")
void insertItem(ObjcObject object, NSInteger value);
Changing the lexer and parser would affect all D language tools
(editors, formatters, linters, other compilers). So now that we
do have UDAs I don't see a justification for changing the syntax
and grammar of D.
Re: D/Objective-C 64bit
On 2014-10-29 22:51, Christian Schneider wrote: 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 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. Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc". Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init". I have all the tools ready now! I can't believe how this all rocks ;) Awesome :) -- /Jacob Carlborg
Re: D/Objective-C 64bit
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 ;)
Re: D/Objective-C 64bit
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 " 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
Re: D/Objective-C 64bit
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!
Re: D/Objective-C 64bit
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
Re: D/Objective-C 64bit
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
Re: D/Objective-C 64bit
On 2014-03-13 18:13:44 +, Jacob Carlborg 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.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
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
Re: D/Objective-C 64bit
Am Thu, 13 Mar 2014 14:20:54 + schrieb "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 Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff?
Re: D/Objective-C 64bit
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
Re: D/Objective-C 64bit
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
Re: D/Objective-C 64bit
"Jacob Carlborg" wrote in message news:lfqf4t$2v1o$1...@digitalmars.com... I think Daniel has said he as a working Linux compiler. He just need to create pull requests (and get them merged) for all changes his tool requires. The changes to dmd's source are all done(!), it's now time to start putting the manually ported stuff into the main repo.
Re: D/Objective-C 64bit
"Michel Fortin" wrote in message news:lfqcs6$2su5$1...@digitalmars.com... If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. The converter can convert git master, compile it with git master, and pass the full test suite + phobos on linux32/linux64/win32. If someone wants to give me access to an OSX box I'll get it working there too. The main problem with these patches is their use of #if in places where D's version blocks don't work. These will all need to be fixed before it is merged, as I've done for the rest of the frontend. I'm happy to help anyone set up the converter - contact me here/by email/on github. It should be as simple as 1. Build dmd master 2. git clone g...@github.com:yebblies/magicport2.git 3. Fix paths if you have a different layout than I do 4. make
Re: D/Objective-C 64bit
On 2014-03-12 20:37, Iain Buclaw wrote: Sorry, some context. The two 32bit ABIs are part of the same source, I'd take them to be identical, with the exception that the second option supports features that are on-by-default in the 64bit ABI. I see. As in, if I were to support NeXT. I'd support the same as implemented by GNU ObjC. I'd have to look up if there are incompatibilities between GCC > 4.3 and Clang on the ObjC side... Sounds reasonable. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-03-12 20:34, Michel Fortin wrote: If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. I think Daniel has said he as a working Linux compiler. He just need to create pull requests (and get them merged) for all changes his tool requires. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 12 March 2014 19:34, Michel Fortin wrote: > On 2014-03-12 17:53:35 +, Andrei Alexandrescu > said: > >> On 3/12/14, 12:15 AM, Jacob Carlborg wrote: >>> >>> On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: >>> Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. >>> >>> >>> In theory I could create a pull request tonight. It depends on what >>> state we need the language support to be in. As I said exceptions are >>> missing on 64bit. But on the other hand when support for C++ was >>> introduced in D it had very limited support. >>> >>> One idea is to merge the changes but wait with enabling the languages >>> changes. The test machines could run the tests with the changes enabled. >> >> >> I'll defer to domain experts on this one. Please advise. > > > If the compiler is going to be converted to the D language (how is that > progressing?), it'd probably be better to merge before that, otherwise it'll > be a lot of work to port all those changes. > Daniel's DDMD conversion tool is on github, you could run it through that to get most of the legwork converted over I guess?
Re: D/Objective-C 64bit
On 12 March 2014 19:36, Michel Fortin wrote: > On 2014-03-12 19:02:10 +, Iain Buclaw said: > >> From my POV, I wouldn't want to support the ABI of a language that GCC >> itself doesn't support. So code compiled by GNU ObjC should be >> compatible with extern(ObjC) code generated by GDC - even if it isn't >> compatible with Clang ObjC. But then, I'd be surprised if it wasn't >> compatible. > > > It all comes to how you integrate the thing with GCC. My guess is that you > have three choices: > > 1. ignore Objective-C support: don't define DMD_OBJC in the code and the > compiler will complain whenever it sees extern(Objective-C) > > 2. translate the calls to the DMD backend creating the various sections and > segments to equivalent calls for creating sections and segments in GCC > > 3. replace the codegen for Objective-C data structures by what's already > implemented in GCC for Objective-C > > This last option will support whatever ABI GCC has support for. That's > probably the way to go if you want to make sure ABIs are compatible. All the > Objective-C ABI DMD knows about is implemented in objc.c, so what you have > to do is to rewrite objc.c to call the GCC equivalent implementation, > probably getting rid of most of the code in there. > > > >> NeXT: >> NSConstantString >> objc_getClass >> objc_getMetaClass >> objc_msgSend >> objc_msgSendSuper >> >> GNU: >> NXConstantString >> objc_get_class >> objc_get_meta_class >> objc_msg_lookup >> objc_msg_lookup_super >> >> Some which greps for s(n)printf also show: >> >> NeXT: >> ".objc_class_name_%s" >> ".objc_category_name_%s_%s" >> >> GNU: >> "__objc_class_name_%s" >> "__objc_category_name_%s_%s" >> >> >> Most others look the same? Maybe you'll be able to find out more with >> this information. > > > My understanding is that the differences are pretty trivial. But regardless, > we probably don't have to care about them if you can hook directly to the > GCC Objective-C codegen. > > Hooking to ObjC could be done, but requires patching GCC proper so that ObjC mangling becomes common code, not front-end specific.
Re: D/Objective-C 64bit
On 2014-03-12 19:02:10 +, Iain Buclaw said: From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. It all comes to how you integrate the thing with GCC. My guess is that you have three choices: 1. ignore Objective-C support: don't define DMD_OBJC in the code and the compiler will complain whenever it sees extern(Objective-C) 2. translate the calls to the DMD backend creating the various sections and segments to equivalent calls for creating sections and segments in GCC 3. replace the codegen for Objective-C data structures by what's already implemented in GCC for Objective-C This last option will support whatever ABI GCC has support for. That's probably the way to go if you want to make sure ABIs are compatible. All the Objective-C ABI DMD knows about is implemented in objc.c, so what you have to do is to rewrite objc.c to call the GCC equivalent implementation, probably getting rid of most of the code in there. NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: ".objc_class_name_%s" ".objc_category_name_%s_%s" GNU: "__objc_class_name_%s" "__objc_category_name_%s_%s" Most others look the same? Maybe you'll be able to find out more with this information. My understanding is that the differences are pretty trivial. But regardless, we probably don't have to care about them if you can hook directly to the GCC Objective-C codegen. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 12 March 2014 19:29, Jacob Carlborg wrote: > On 2014-03-12 20:02, Iain Buclaw wrote: > >> gobjc supports both, there's two ABI's for the NeXT - which I take to >> mean the difference between the difference between 32bit and 64bit. > > > You previously listed three ABI's. It's the modern runtime for 64bit and the > traditional for 32bit with with properties that are interesting. I don't > know how much difference these properties do. > Sorry, some context. The two 32bit ABIs are part of the same source, I'd take them to be identical, with the exception that the second option supports features that are on-by-default in the 64bit ABI. > > I'm not sure I understand. Do you want to support the NeXT or GNU runtime? > As in, if I were to support NeXT. I'd support the same as implemented by GNU ObjC. I'd have to look up if there are incompatibilities between GCC > 4.3 and Clang on the ObjC side...
Re: D/Objective-C 64bit
On 2014-03-12 17:53:35 +, Andrei Alexandrescu said: On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. The first question should about the review process. This patch touches a lot of things, so I wonder if Walter will be confortable reviewing it. Should different people review different parts? Here's a comparison view: DMD: 94 changed files with 8,005 additions and 48 deletions. https://github.com/jacob-carlborg/dmd/compare/d-objc druntime: 10 changed files with 1,263 additions and 0 deletions. https://github.com/jacob-carlborg/druntime/compare/d-objc Most of the changes to the compiler are inside #if DMD_OBJC/#endif blocks. Changes outside of those blocks shouldn't affect the semantics or the binary output of existing code. So I think a review could be done in two steps: 1. Review changes outside of those #if DMD_OBJC blocks. Those are the most critical changes as they'll affect the next version of the compiler that'll ship (I'm assuming Objective-C features won't be turned on until they're more usable). This includes some changes in the lexer, but it shouldn't affect current D code. This review could exclude the two files objc.h/objc.c, since the makefile ignores them without the D_OBJC flag. 2. Maybe review things inside of those #if DMD_OBJC blocks. Those things won't affect the compiler unless compiled with the D_OBJC flag, so it's less critical to review them. Most of them are there to implement Objective-C semantics so you'll need to be somewhat familiar with Objective-C to judge whether they're correct or not. What should be checked is whether an error would make them affect non-Objective-C constructs when they're compiled in. We also need to know what to do about the test suite. I made a separate test suite for D/Objective-C since those tests can only run on OS X and only with the compiler compiled with Objective-C support enabled. It could easily be merged with the main test suite, but the tests should be made conditional to whether the compiler is compiled with Objective-C or not. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 20:02, Iain Buclaw wrote: gobjc supports both, there's two ABI's for the NeXT - which I take to mean the difference between the difference between 32bit and 64bit. You previously listed three ABI's. It's the modern runtime for 64bit and the traditional for 32bit with with properties that are interesting. I don't know how much difference these properties do. It seems that (now I read up on it) the GNU runtime came about from decades back when NeXT was not open sourced by Apple. From what I can gather, a move towards the modern ABI is the direction, but not considered production ready. From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. I'm not sure I understand. Do you want to support the NeXT or GNU runtime? Clang is at least compatible with the Apple GCC. I don't know about FSF GCC. That's hard to say at an initial glance. There's a handy hook system into each ABI to allow you to switch between versions easily. The common differences I do however see are: NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: ".objc_class_name_%s" ".objc_category_name_%s_%s" GNU: "__objc_class_name_%s" "__objc_category_name_%s_%s" Most others look the same? Maybe you'll be able to find out more with this information. One basically need to look at each single feature and see what differs. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-03-12 13:14, Michel Fortin wrote: I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. It is now :). I added support for properties. But as you say, I don't really know what they add. -- /Jacob Carlborg
Re: D/Objective-C 64bit
Am Wed, 12 Mar 2014 10:53:35 -0700 schrieb Andrei Alexandrescu : > On 3/12/14, 12:15 AM, Jacob Carlborg wrote: > > On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu > > wrote: > > > >> Great. Jacob, what's your plan to take this forward? We're very > >> interested in merging this as part of the official D compiler. > > > > In theory I could create a pull request tonight. It depends on what > > state we need the language support to be in. As I said exceptions > > are missing on 64bit. But on the other hand when support for C++ was > > introduced in D it had very limited support. > > > > One idea is to merge the changes but wait with enabling the > > languages changes. The test machines could run the tests with the > > changes enabled. > > I'll defer to domain experts on this one. Please advise. > > Andrei > > We could also start a (better: the first) feature branch. http://wiki.dlang.org/Release_Process#Branching%20model
Re: D/Objective-C 64bit
On 12 March 2014 12:14, Michel Fortin wrote: > On 2014-03-12 09:26:56 +, Iain Buclaw said: > >> On 12 March 2014 07:10, Jacob Carlborg wrote: >>> >>> Yeah, since Objective-C uses the C calling convention it's mostly about >>> outputting symbols and data to the object files. >> >> >> In what ABI may I ask? Your choices are: >> - Traditional (32bit) ABI without properties and Obj-C 2.0 additions >> - Traditional (32bit) ABI with properties and Obj-C 2.0 additions >> - Modern (64bit) ABI > > > I made the 32-bit legacy runtime support, Jacob added the 64-bit modern > runtime support. > > There's no support at this time for properties declarations in the ABI, but > it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 > additions only include property declarations and attributes in the ABI. > > > >> That can be mixed in with either: >> - GNU Runtime ABI >> - NeXT Runtime ABI > > > It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and > probably most people out there, don't care about the GNU runtime. Although > probably the GCC guys do. Do you think it'd make it more difficult to merge > GCC in the GCC project if it had support for Apple's runtime and not for the > GNU one? > gobjc supports both, there's two ABI's for the NeXT - which I take to mean the difference between the difference between 32bit and 64bit. It seems that (now I read up on it) the GNU runtime came about from decades back when NeXT was not open sourced by Apple. From what I can gather, a move towards the modern ABI is the direction, but not considered production ready. >From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. > Also, is there a list of differences between the two runtimes somewhere? > That's hard to say at an initial glance. There's a handy hook system into each ABI to allow you to switch between versions easily. The common differences I do however see are: NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: ".objc_class_name_%s" ".objc_category_name_%s_%s" GNU: "__objc_class_name_%s" "__objc_category_name_%s_%s" Most others look the same? Maybe you'll be able to find out more with this information.
Re: D/Objective-C 64bit
On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. Andrei
Re: D/Objective-C 64bit
"Szymon Gatner" writes: > Wow, this is fantastic! This and recent progress on iOS/ARM/LDC > porting make me so happy :) Yeah, it will be cool to combine this with the LDC iOS work. I haven't posted progress lately. I got Fibers working on an iPhone 4. I found that GDC's thread.d already had ARM Fiber support so used it until it gets pulled into dmd. It's really coming down to just a few fundumental things (cross compiling getting real "real" type, and supporting TLS). -- Dan
Re: D/Objective-C 64bit
"w0rp" writes: > This is really awesome work. If you combined ARM support with > Objective C support, it would mean you could write iOS programs > in D without much frustration, and that would be a huge step > forward. Objective C has a good runtime, but lacks templates and > CTFE. Using CTFE for an iOS program could be very cool. Just a plug that the LDC iOS work is coming along well. D iOS programming may not be too far in the future. -- Dan
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 12:14:23 UTC, Michel Fortin wrote: On 2014-03-12 09:26:56 +, Iain Buclaw said: On 12 March 2014 07:10, Jacob Carlborg wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one? Also, is there a list of differences between the two runtimes somewhere? Each combination being incompatible with each other subtly different ways... Which is why we have a test suite. There is an outdated list here, http://wiki.gnustep.org/index.php/ObjC2_FAQ I wouldn't care for GNUStep support. Objective-C support in gcc is almost dead and GNUStep seems to have hardly changed since I used WindowMaker as my main window manager. Which was around 1999 - 2004! -- Paulo
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote: I just wanted to let everyone know that I have implemented D/Objective-C for 64bit. Everything that worked for 32bit should work, except for exceptions, which are not implemented yet. Objective-C on 64bit uses the modern runtime, which is also the same used on iOS. This means D/Objective-C should now be compatible with iOS as well, at least in theory. For those how don't know what D/Objective-C is. It is a language extension to D making it ABI compatible with Objective-C. This means it's possible to use Objective-C classes, methods, protocols (interfaces) and so on, directly just as it's currently possible to do with regular C functions. Here's a recap of what's implemented, both for 32 and 64bit unless otherwise noticed: * Classes * Subclasses * Instance and class methods * Protocols (interfaces) * Properties * Exceptions (only 32bit) * Selectors * Class references * String literals * Casts Some improvements that are really not part of Objective-C but are very convenient to have in D : * Constructors * Inheriting selectors * Automatically generated selectors On the other hand, here a list of what's not implemented yet: * Blocks (similar to delegates) * Categories (class extensions) * Any form of automatic memory management * Exceptions (64bit) * Vtable optimization (64bit) Objective-C exceptions on 64bit is implemented using the same mechanism as C++. I'm wondering if it would be possible for D (not just for this extension) to adapt this mechanism as well. This would make D compatible with both C++ and Objective-C exceptions on 64bit. A DIP is available here [1] and the latest implementation is available here [2]. [1] http://wiki.dlang.org/DIP43 [2] https://github.com/jacob-carlborg/dmd/tree/d-objc Wow, this is fantastic! This and recent progress on iOS/ARM/LDC porting make me so happy :)
Re: D/Objective-C 64bit
On 2014-03-12 09:26:56 +, Iain Buclaw said: On 12 March 2014 07:10, Jacob Carlborg wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one? Also, is there a list of differences between the two runtimes somewhere? Each combination being incompatible with each other subtly different ways... Which is why we have a test suite. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 08:06:47 +, "w0rp" said: This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool. How do you plan to handle automatic reference counting? I imagine that's a hard part. When I was writing Objective C I remember having to write bridged casts so I could manually extend or limit object lifetime, but I never handled it from within a C library. Well, there's three ways. (a) The first one is to implement ARC for Objective-C objects, and to automatically add/remove roots to member variables when constructing/destroying Objective-C objects that were defined in D so the GC can those pointers. (b) The second one is to not implement ARC and implement something in the GC so it can track Objective-C objects: retain them on first sight, release them once no longer connected to a root. (c) The third one is to implement ARC as an alternative memory management scheme for D and bolt Objective-C object support on top of it. I'd tend to go for (a) at first, as it's the simplest thing that can be done. But I fear always adding/removing roots will impact performance in a negative way. There's also the issue in (a) and (b) that if the last reference to an object is released from the GC thread the Objective-C object's destructor will be called in a different thread than what is expected which might cause some bugs. So we might want to implement (c) later on to have something more solid and deterministic. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 12 March 2014 07:10, Jacob Carlborg wrote: > On Tuesday, 11 March 2014 at 23:20:23 UTC, Michel Fortin wrote: > >> The codegen elements in objc.c will need to be changed to bind to the >> LLVM/GCC backend. Shouldn't be too hard, I guess. > > > Yeah, since Objective-C uses the C calling convention it's mostly about > outputting symbols and data to the object files. > In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI Each combination being incompatible with each other subtly different ways...
Re: D/Objective-C 64bit
On 3/11/14, Jacob Carlborg wrote: > I just wanted to let everyone know that I have implemented D/Objective-C > for 64bit. Excellent! One thing that's hard to implement right now in D is drag & drop support on OSX, at least when I tried to do it. The problem is I need to call ObjC functions or provide ObjC callbacks, so I end up having to create a C layer, compile that, and then link that to D. Actual support for interfacing with Objective C would be great. Thanks for all the work to both you and Michel Fortin.
Re: D/Objective-C 64bit
This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool. How do you plan to handle automatic reference counting? I imagine that's a hard part. When I was writing Objective C I remember having to write bridged casts so I could manually extend or limit object lifetime, but I never handled it from within a C library.
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 01:09:25 UTC, Walter Bright wrote: I'm glad to see this is building on the great groundwork you've already done. Yes, absolutely. Michel has done most of the work, forgot to mention that. I'm just polishing now. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 22:13:07 UTC, Paolo Invernizzi wrote: Thanks Jacob, great work! If someone is trying it like me, I don't know the proper way for doing that, but the compiler must be built with the DMD_OBJC define turned on. Yes, D_OBJC. You need the corresponding changes for druntime [1] as well. It seems I haven't pushed the changes for 64bit, I'll do that tonight. [1] https://github.com/jacob-carlborg/druntime/tree/d-objc -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 23:20:23 UTC, Michel Fortin wrote: The codegen elements in objc.c will need to be changed to bind to the LLVM/GCC backend. Shouldn't be too hard, I guess. Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 21:48:45 UTC, Asman01 wrote: It's really awesome. Congratulations! If this DIP is actually approved will dmd have "native" integration/support to Objective-C language just like we can do with C? I'm not a Obj-C programmer but I like the idea. Yes. -- /Jacob Carlborg
