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