Re: D/Objective-C 64bit

2014-12-31 Thread Jacob Carlborg via Digitalmars-d-announce
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? ;

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-12-26 Thread Jacob Carlborg via Digitalmars-d-announce
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..

Re: D/Objective-C 64bit

2014-12-26 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-12-18 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-12-18 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-12-16 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-20 Thread Michel Fortin via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-18 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-11-18 Thread Jacob Carlborg via Digitalmars-d-announce
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 =

Re: D/Objective-C 64bit

2014-11-18 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-18 Thread Jacob Carlborg via Digitalmars-d-announce
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,

Re: D/Objective-C 64bit

2014-11-18 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-11-17 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-07 Thread Jacob Carlborg via Digitalmars-d-announce
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,

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-07 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-07 Thread Jacob Carlborg via Digitalmars-d-announce
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].

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-06 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-04 Thread Michel Fortin via Digitalmars-d-announce
On 2014-11-04 09:07:08 +, Christian Schneider schnei...@gerzonic.net 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

Re: D/Objective-C 64bit

2014-11-04 Thread Michel Fortin via Digitalmars-d-announce
On 2014-11-01 10:47:54 +, Jacob Carlborg d...@me.com 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

Re: D/Objective-C 64bit

2014-11-04 Thread Jacob Carlborg via Digitalmars-d-announce
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.

Re: D/Objective-C 64bit

2014-11-04 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-11-03 Thread Jacob Carlborg via Digitalmars-d-announce
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 ;

Re: D/Objective-C 64bit

2014-11-01 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-11-01 Thread Jacob Carlborg via Digitalmars-d-announce
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.

Re: D/Objective-C 64bit

2014-10-31 Thread Michel Fortin via Digitalmars-d-announce
On 2014-10-30 07:13:08 +, Jacob Carlborg d...@me.com 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

Re: D/Objective-C 64bit

2014-10-31 Thread Michel Fortin via Digitalmars-d-announce
On 2014-10-30 09:16:34 +, Martin Nowak c...@dawg.eu 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

Re: D/Objective-C 64bit

2014-10-30 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-30 Thread Martin Nowak via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-30 Thread John Colvin via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-10-30 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-30 Thread Jacob Carlborg via Digitalmars-d-announce
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*

Re: D/Objective-C 64bit

2014-10-30 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-29 Thread Christian Schneider via Digitalmars-d-announce
I tried running your code and could observe the behavior. Although I have not been able to figure you why it behaves like this. In general there are a couple of things to think of and watch out for when interfacing between D and Objective-C : * The D compiler does not support any form of ARC,

Re: D/Objective-C 64bit

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

Re: D/Objective-C 64bit

2014-10-29 Thread Christian Schneider via Digitalmars-d-announce
In the future I hope to make it possible to use pass a framework to DStep and it will create bindings for the whole framework. That would be so cool! Btw, fixed the example, thanks for giving me the right clues. Of course, it was just the manual memory management à la Objective-C that was

Re: D/Objective-C 64bit

2014-10-28 Thread Jacob Carlborg via Digitalmars-d-announce
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

Re: D/Objective-C 64bit

2014-10-27 Thread Christian Schneider via Digitalmars-d-announce
Can somebody with a greater d-objc knowledge have a look at this example project and tell this naive D-noob what he is missing? https://github.com/DiveFramework/DiveFramework/tree/master/Examples/Tableview I am pretty sure that it has something to do with memory management and ARC. First it

Re: D/Objective-C 64bit

2014-03-13 Thread Daniel Murphy
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

Re: D/Objective-C 64bit

2014-03-13 Thread Daniel Murphy
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

Re: D/Objective-C 64bit

2014-03-13 Thread Jacob Carlborg
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

2014-03-13 Thread 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

Re: D/Objective-C 64bit

2014-03-13 Thread Johannes Pfau
Am Thu, 13 Mar 2014 14:20:54 + schrieb Jacob Carlborg d...@me.com: On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu wrote: I'll defer to domain experts on this one. Please advise. Yeah, we need some comments from Walter, Daniel, Kenji and others of the core DMD

Re: D/Objective-C 64bit

2014-03-13 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-13 Thread Michel Fortin
On 2014-03-13 18:13:44 +, Jacob Carlborg d...@me.com said: On 2014-03-13 17:16, Johannes Pfau wrote: Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff? I would guess so. I would need to take a look

Re: D/Objective-C 64bit

2014-03-12 Thread Iain Buclaw
On 11 Mar 2014 23:25, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-11 22:43:58 +, John Colvin john.loughran.col...@gmail.com said: To what extent will this be portable to ldc/gdc? The codegen elements in objc.c will need to be changed to bind to the LLVM/GCC backend.

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread w0rp
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

Re: D/Objective-C 64bit

2014-03-12 Thread Andrej Mitrovic
On 3/11/14, Jacob Carlborg d...@me.com 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

Re: D/Objective-C 64bit

2014-03-12 Thread Iain Buclaw
On 12 March 2014 07:10, Jacob Carlborg d...@me.com 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

Re: D/Objective-C 64bit

2014-03-12 Thread Michel Fortin
On 2014-03-12 08:06:47 +, w0rp devw...@gmail.com 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

Re: D/Objective-C 64bit

2014-03-12 Thread Michel Fortin
On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said: On 12 March 2014 07:10, Jacob Carlborg d...@me.com 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:

Re: D/Objective-C 64bit

2014-03-12 Thread Szymon Gatner
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

Re: D/Objective-C 64bit

2014-03-12 Thread Paulo Pinto
On Wednesday, 12 March 2014 at 12:14:23 UTC, Michel Fortin wrote: On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said: On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and

Re: D/Objective-C 64bit

2014-03-12 Thread Dan Olson
w0rp devw...@gmail.com 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.

Re: D/Objective-C 64bit

2014-03-12 Thread Dan Olson
Szymon Gatner noem...@gmail.com 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

Re: D/Objective-C 64bit

2014-03-12 Thread 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.

Re: D/Objective-C 64bit

2014-03-12 Thread Iain Buclaw
On 12 March 2014 12:14, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said: On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread Johannes Pfau
Am Wed, 12 Mar 2014 10:53:35 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: 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

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread Michel Fortin
On 2014-03-12 17:53:35 +, Andrei Alexandrescu seewebsiteforem...@erdani.org 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

Re: D/Objective-C 64bit

2014-03-12 Thread Iain Buclaw
On 12 March 2014 19:29, Jacob Carlborg d...@me.com 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

Re: D/Objective-C 64bit

2014-03-12 Thread Michel Fortin
On 2014-03-12 19:02:10 +, Iain Buclaw ibuc...@gdcproject.org 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

Re: D/Objective-C 64bit

2014-03-12 Thread Iain Buclaw
On 12 March 2014 19:36, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 19:02:10 +, Iain Buclaw ibuc...@gdcproject.org 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

Re: D/Objective-C 64bit

2014-03-12 Thread Iain Buclaw
On 12 March 2014 19:34, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 17:53:35 +, Andrei Alexandrescu seewebsiteforem...@erdani.org 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,

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-12 Thread Jacob Carlborg
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

Re: D/Objective-C 64bit

2014-03-11 Thread Andrei Alexandrescu
On 3/11/14, 11:23 AM, Jacob Carlborg wrote: [1] http://wiki.dlang.org/DIP43 [2] https://github.com/jacob-carlborg/dmd/tree/d-objc Wow, this is fantastic. Congratulations! Upon a quick scan, the DIP seems tasteful and well put together. Let's see how to merge this into dmd! Andrei

  1   2   >