www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD/Objective-C Alpha 1

reply Michel Fortin <michel.fortin michelf.com> writes:
It's been some time since I announced I'd be attempting to hack the 
official D compiler to implement support for the Objective-C object 
model, with the ultimate goal to write Cocoa apps entirely in D. I 
spent about 160 hours on this project since the announcement last 
September, and now I'm pleased to have a first version to release.

You can get it there:
<http://michelf.com/projects/d-objc/>

It's just the beginning. As the documentation says there is still a lot 
of things to implement, and there will be more bugs to fix after that. 
But it's nevertheless always good to make a first release of a project.

It's also good to know you're not working alone. Jacob Carlborg has an 
automated binding generator in the works. Hopefully this will allow us 
to provide declarations for most of Cocoa soon.

If you want to help in some way, let me know.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 01 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/1/2011 6:54 PM, Michel Fortin wrote:

 It's just the beginning. As the documentation says there is still a lot of
 things to implement, and there will be more bugs to fix after that. But it's
 nevertheless always good to make a first release of a project.


It's awesome that you're working on this.
Jun 01 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/1/11 8:54 PM, Michel Fortin wrote:

 It's been some time since I announced I'd be attempting to hack the
 official D compiler to implement support for the Objective-C object
 model, with the ultimate goal to write Cocoa apps entirely in D. I spent
 about 160 hours on this project since the announcement last September,
 and now I'm pleased to have a first version to release.

 You can get it there:
 <http://michelf.com/projects/d-objc/>

 It's just the beginning. As the documentation says there is still a lot
 of things to implement, and there will be more bugs to fix after that.
 But it's nevertheless always good to make a first release of a project.

 It's also good to know you're not working alone. Jacob Carlborg has an
 automated binding generator in the works. Hopefully this will allow us
 to provide declarations for most of Cocoa soon.

 If you want to help in some way, let me know.


Grats!

https://twitter.com/#!/incomputable/status/76142361226387456

http://www.reddit.com/r/programming/comments/hpo10/dobjective_c_compiler_alpha_1/


Andrei
Jun 01 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
From the page:

The ultimate goal is to merge the capabilities back into mainline DMD",


Do you want to add a syntax like this to D/DMD?

void insertItem(ObjcObject object, NSInteger value)
[insertItemWithObjectValue:atIndex:];

Bye,
bearophile
Jun 02 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-02 05:30:10 -0400, bearophile <bearophileHUGS lycos.com> said:


 From the page:

 The ultimate goal is to merge the capabilities back into mainline DMD",


 
 Do you want to add a syntax like this to D/DMD?
 
 void insertItem(ObjcObject object, NSInteger value) 
 [insertItemWithObjectValue:atIndex:];


Well, that's what I'd like. Given that you can't hide completely 
selectors as an implementation detail and that programmers might need 
to specify them from time to time -- which is all the time when 
declaring extern Objective-C classes! -- I thought it'd be very much 
appreciated if the syntax for that wasn't too unreadable.

That said, if Walter doesn't like it I could change it to a more 
"standard" pragma syntax:

	pragma(objc_selector, "insertIdemWithObjectValue:atIndex:")
	void insertItem(ObjcObject object, NSInteger value);

It's more verbose and less readable, but it'd work too.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 02 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:


 That said, if Walter doesn't like it I could change it to a more
 "standard" pragma syntax:
 
         pragma(objc_selector, "insertIdemWithObjectValue:atIndex:")
         void insertItem(ObjcObject object, NSInteger value);
 
 It's more verbose and less readable, but it'd work too.


Another possible syntax, using ddoc:

/// This is a selector for...
void insertItem(ObjcObject object, NSInteger value); ///
insertItemWithObjectValue:atIndex:

Bye,
bearophile
Jun 02 2011
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-02 09:58:06 -0400, bearophile <bearophileHUGS lycos.com> said:


 Michel Fortin:
 

 That said, if Walter doesn't like it I could change it to a more
 "standard" pragma syntax:
 
 pragma(objc_selector, "insertIdemWithObjectValue:atIndex:")
 void insertItem(ObjcObject object, NSInteger value);
 
 It's more verbose and less readable, but it'd work too.


 
 Another possible syntax, using ddoc:
 
 /// This is a selector for...
 void insertItem(ObjcObject object, NSInteger value); /// 
 insertItemWithObjectValue:atIndex:


Actually, that's not a very good idea because the selector is not 
documentation. The compiler cannot ignore it.

With the Objective-C runtime, each function has a selector matching its 
actual Objective-C method name. The selector is what the compiler uses 
to call the function dynamically. The method name shouldn't be stripped 
like it was a comment or some documentation because that'll change and 
likely break the program.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 02 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Jun 2, 11 18:17, Michel Fortin wrote:

 On 2011-06-02 05:30:10 -0400, bearophile <bearophileHUGS lycos.com> said:


 From the page:

 The ultimate goal is to merge the capabilities back into mainline DMD",


 Do you want to add a syntax like this to D/DMD?

 void insertItem(ObjcObject object, NSInteger value)
 [insertItemWithObjectValue:atIndex:];


 Well, that's what I'd like. Given that you can't hide completely
 selectors as an implementation detail and that programmers might need to
 specify them from time to time -- which is all the time when declaring
 extern Objective-C classes! -- I thought it'd be very much appreciated
 if the syntax for that wasn't too unreadable.

 That said, if Walter doesn't like it I could change it to a more
 "standard" pragma syntax:

 pragma(objc_selector, "insertIdemWithObjectValue:atIndex:")
 void insertItem(ObjcObject object, NSInteger value);

 It's more verbose and less readable, but it'd work too.


 selector("insertIdemWithObjectValue:atIndex:")
void insertItem(ObjcObject object, NSInteger value);

;)
Jun 02 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/06/2011 02:54, Michel Fortin wrote:

 It's been some time since I announced I'd be attempting to hack the
 official D compiler to implement support for the Objective-C object
 model, with the ultimate goal to write Cocoa apps entirely in D. I spent
 about 160 hours on this project since the announcement last September,
 and now I'm pleased to have a first version to release.

 You can get it there:
 <http://michelf.com/projects/d-objc/>

 It's just the beginning. As the documentation says there is still a lot
 of things to implement, and there will be more bugs to fix after that.
 But it's nevertheless always good to make a first release of a project.

 It's also good to know you're not working alone. Jacob Carlborg has an
 automated binding generator in the works. Hopefully this will allow us
 to provide declarations for most of Cocoa soon.

 If you want to help in some way, let me know.


This is pretty cool! I'd test it, but D for XCode doesn't seem to play 
well with XCode 4, and my XCode 3 installation appears to have 
disappeared since I installed 4. Will the complete OS X toolchain work 
with this eventually? (Interface builder, instruments etc)

-- 
Robert
http://octarineparrot.com/
Jun 02 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/06/2011 12:49, Robert Clipsham wrote:

 This is pretty cool! I'd test it, but D for XCode doesn't seem to play
 well with XCode 4, and my XCode 3 installation appears to have
 disappeared since I installed 4. Will the complete OS X toolchain work
 with this eventually? (Interface builder, instruments etc)


Does this mean in the not too distant future we'll be able to write 
iPhone apps in D? :o

-- 
Robert
http://octarineparrot.com/
Jun 02 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-02 07:50:20 -0400, Robert Clipsham <robert octarineparrot.com> said:


 On 02/06/2011 12:49, Robert Clipsham wrote:

 This is pretty cool! I'd test it, but D for XCode doesn't seem to play
 well with XCode 4, and my XCode 3 installation appears to have
 disappeared since I installed 4. Will the complete OS X toolchain work
 with this eventually? (Interface builder, instruments etc)


 
 Does this mean in the not too distant future we'll be able to write 
 iPhone apps in D? :o


Define "not too distant". :-)

DMD doesn't have an ARM backend, so you'll need to port it to LDC or 
GDC. It might not be that easy however since a couple of parts are in 
the glue code that links to the DMD backend. But if you want to start 
working on LDC/Objective-C or GDC/Objective-C, I'll try to help.

The other issue is that it currently only support Apple's Legacy 
Objective-C runtime (used on 32-bit Mac OS X). iOS and 64-bit Mac OS X 
uses the Modern runtime which changed most of the ABI. I'll add support 
the Modern runtime eventually, but certainly not before DMD can emit 
64-bit code on Mac OS X.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 02 2011
parent Robert Clipsham <robert octarineparrot.com> writes:
On 02/06/2011 13:55, Michel Fortin wrote:

 Define "not too distant". :-)

 DMD doesn't have an ARM backend, so you'll need to port it to LDC or
 GDC. It might not be that easy however since a couple of parts are in
 the glue code that links to the DMD backend. But if you want to start
 working on LDC/Objective-C or GDC/Objective-C, I'll try to help.


I thought this might be the case. Unfortunately I have a million things 
of my own to be working on, so I probably wouldn't have time to work on 
porting it.


 The other issue is that it currently only support Apple's Legacy
 Objective-C runtime (used on 32-bit Mac OS X). iOS and 64-bit Mac OS X
 uses the Modern runtime which changed most of the ABI. I'll add support
 the Modern runtime eventually, but certainly not before DMD can emit
 64-bit code on Mac OS X.


That sounds like it's gonna be a big task! Good luck!


-- 
Robert
http://octarineparrot.com/
Jun 02 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-02 07:49:25 -0400, Robert Clipsham <robert octarineparrot.com> said:


 This is pretty cool! I'd test it, but D for XCode doesn't seem to play 
 well with XCode 4, and my XCode 3 installation appears to have 
 disappeared since I installed 4. Will the complete OS X toolchain work 
 with this eventually? (Interface builder, instruments etc)


Current state the OSX toolchain:

- Problems getting gdb recognize debug symbols. Perhaps this can be 
alleviated by replacing gdb with a fresh GNU version instead of 
Apple's... I haven't tested. Ideally, DMD would generate symbols that 
Apple's gdb understands.

- Half-baked Xcode 4 support in D for Xcode. You can rely on Xcode 3 in 
the meanwhile. Given the Xcode plugin API is private and undocumented, 
it's not as trivial as it should be.

- It might be nice to add a D parser to Interface Builder so it 
automatically recognize outlets and actions in D files that have 
Objective-C objects (thanks to D/Objective-C). I'd guess this is a 
private API too, but I haven't verified. Not having that is just an 
inconvenience however, since you can always add them manually in the IB 
file too.

- I don't think you need to do anything for Instruments (and the 
underlying dtrace) to work with D code... except perhaps make debug 
symbols work so stack traces include line numbers. Perhaps one would 
want to create a custom instrument to observe the GC in druntime.

I don't have much time to work on D for Xcode at the moment, mostly 
because I'm putting my spare time into developing D/Objective-C these 
days. But I'd be glad to accept pull requests for D for Xcode.
<https://github.com/michelf/d-for-xcode>


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 02 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/06/2011 13:54, Michel Fortin wrote:

 On 2011-06-02 07:49:25 -0400, Robert Clipsham
 <robert octarineparrot.com> said:


 This is pretty cool! I'd test it, but D for XCode doesn't seem to play
 well with XCode 4, and my XCode 3 installation appears to have
 disappeared since I installed 4. Will the complete OS X toolchain work
 with this eventually? (Interface builder, instruments etc)


 Current state the OSX toolchain:

 - Problems getting gdb recognize debug symbols. Perhaps this can be
 alleviated by replacing gdb with a fresh GNU version instead of
 Apple's... I haven't tested. Ideally, DMD would generate symbols that
 Apple's gdb understands.


I assume Apple will eventually be moving to LLDB, it could be a good 
idea to see about adding some preliminary D support to clang, that would 
sort this out. Alternatively, there are patches for older gdb versions 
(they need some tweaking to work with Apple's gdb, I've done it before 
but never saved the modified patch).


 - Half-baked Xcode 4 support in D for Xcode. You can rely on Xcode 3 in
 the meanwhile. Given the Xcode plugin API is private and undocumented,
 it's not as trivial as it should be.


Again, perhaps some tweaking to clang would simplify this somewhat? At 
least for code completion/syntax highlighting/errors, not sure about 
anything else. I'm currently using vim due to the lack of XCode 4 support.


 - It might be nice to add a D parser to Interface Builder so it
 automatically recognize outlets and actions in D files that have
 Objective-C objects (thanks to D/Objective-C). I'd guess this is a
 private API too, but I haven't verified. Not having that is just an
 inconvenience however, since you can always add them manually in the IB
 file too.

 - I don't think you need to do anything for Instruments (and the
 underlying dtrace) to work with D code... except perhaps make debug
 symbols work so stack traces include line numbers. Perhaps one would
 want to create a custom instrument to observe the GC in druntime.


The lack of line numbers in debug info on OS X is something that's 
really annoying me, I may look into this in the future should I get 
chance - if someone doesn't beat me to it of course. Wouldn't be the 
first time I'd spent a week playing with dmd's debug info to get it 
working...


 I don't have much time to work on D for Xcode at the moment, mostly
 because I'm putting my spare time into developing D/Objective-C these
 days. But I'd be glad to accept pull requests for D for Xcode.
 <https://github.com/michelf/d-for-xcode>


Best of luck with this! Again, I doubt I'll have time to work on D for 
XCode.

-- 
Robert
http://octarineparrot.com/
Jun 02 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-02 15:21, Robert Clipsham wrote:

 The lack of line numbers in debug info on OS X is something that's
 really annoying me, I may look into this in the future should I get
 chance - if someone doesn't beat me to it of course. Wouldn't be the
 first time I'd spent a week playing with dmd's debug info to get it
 working...


http://d.puremagic.com/issues/show_bug.cgi?id=4154

-- 
/Jacob Carlborg
Jun 02 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/06/2011 16:09, Jacob Carlborg wrote:

 On 2011-06-02 15:21, Robert Clipsham wrote:

 The lack of line numbers in debug info on OS X is something that's
 really annoying me, I may look into this in the future should I get
 chance - if someone doesn't beat me to it of course. Wouldn't be the
 first time I'd spent a week playing with dmd's debug info to get it
 working...


 http://d.puremagic.com/issues/show_bug.cgi?id=4154


Oh cool - does this patch work then? Have you made a pull request for it?

-- 
Robert
http://octarineparrot.com/
Jun 02 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 02.06.2011 17:12, schrieb Robert Clipsham:

 On 02/06/2011 16:09, Jacob Carlborg wrote:

 On 2011-06-02 15:21, Robert Clipsham wrote:

 The lack of line numbers in debug info on OS X is something that's
 really annoying me, I may look into this in the future should I get
 chance - if someone doesn't beat me to it of course. Wouldn't be the
 first time I'd spent a week playing with dmd's debug info to get it
 working...


 http://d.puremagic.com/issues/show_bug.cgi?id=4154


 
 Oh cool - does this patch work then? Have you made a pull request for it?
 


According to the bugreport it doesn't work properly:

"I've attached a patch which fixes this. But with this patch (I think)
one or
several offsets somehow become incorrect. This is the output of dwarfdump
--verify:

The offset into the .debug_abbrev section (0xffffffff) is not valid.

Maybe it's because the section names are now one character longer or
there is
something other that isn't working."
Jun 02 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-02 17:12, Robert Clipsham wrote:

 On 02/06/2011 16:09, Jacob Carlborg wrote:

 On 2011-06-02 15:21, Robert Clipsham wrote:

 The lack of line numbers in debug info on OS X is something that's
 really annoying me, I may look into this in the future should I get
 chance - if someone doesn't beat me to it of course. Wouldn't be the
 first time I'd spent a week playing with dmd's debug info to get it
 working...


 http://d.puremagic.com/issues/show_bug.cgi?id=4154


 Oh cool - does this patch work then? Have you made a pull request for it?


No it doesn't work.

"But with this patch (I think) one or several offsets somehow become 
incorrect. This is the output of dwarfdump --verify:

The offset into the .debug_abbrev section (0xffffffff) is not valid.

Maybe it's because the section names are now one character longer or 
there is something other that isn't working."

-- 
/Jacob Carlborg
Jun 02 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-02 14:54, Michel Fortin wrote:

 On 2011-06-02 07:49:25 -0400, Robert Clipsham
 <robert octarineparrot.com> said:


 This is pretty cool! I'd test it, but D for XCode doesn't seem to play
 well with XCode 4, and my XCode 3 installation appears to have
 disappeared since I installed 4. Will the complete OS X toolchain work
 with this eventually? (Interface builder, instruments etc)


 Current state the OSX toolchain:

 - Problems getting gdb recognize debug symbols. Perhaps this can be
 alleviated by replacing gdb with a fresh GNU version instead of
 Apple's... I haven't tested. Ideally, DMD would generate symbols that
 Apple's gdb understands.

 - Half-baked Xcode 4 support in D for Xcode. You can rely on Xcode 3 in
 the meanwhile. Given the Xcode plugin API is private and undocumented,
 it's not as trivial as it should be.


I wonder if the MacRuby project contains code that could help figuring 
out the Xcode plugin API, it has recently got support for Xcode 4.


 - It might be nice to add a D parser to Interface Builder so it
 automatically recognize outlets and actions in D files that have
 Objective-C objects (thanks to D/Objective-C). I'd guess this is a
 private API too, but I haven't verified. Not having that is just an
 inconvenience however, since you can always add them manually in the IB
 file too.

 - I don't think you need to do anything for Instruments (and the
 underlying dtrace) to work with D code... except perhaps make debug
 symbols work so stack traces include line numbers. Perhaps one would
 want to create a custom instrument to observe the GC in druntime.

 I don't have much time to work on D for Xcode at the moment, mostly
 because I'm putting my spare time into developing D/Objective-C these
 days. But I'd be glad to accept pull requests for D for Xcode.
 <https://github.com/michelf/d-for-xcode>



-- 
/Jacob Carlborg
Jun 02 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-02 03:54, Michel Fortin wrote:

 It's been some time since I announced I'd be attempting to hack the
 official D compiler to implement support for the Objective-C objec
 model, with the ultimate goal to write Cocoa apps entirely in D. I spent
 about 160 hours on this project since the announcement last September,
 and now I'm pleased to have a first version to release.

 You can get it there:
 <http://michelf.com/projects/d-objc/>

 It's just the beginning. As the documentation says there is still a lot
 of things to implement, and there will be more bugs to fix after that.
 But it's nevertheless always good to make a first release of a project.

 It's also good to know you're not working alone. Jacob Carlborg has an
 automated binding generator in the works. Hopefully this will allow us
 to provide declarations for most of Cocoa soon.

 If you want to help in some way, let me know.


This is great.

-- 
/Jacob Carlborg
Jun 02 2011