Re: DMD/Objective-C Alpha 1
On 2011-06-02 05:30:10 -0400, bearophile bearophileh...@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.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
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/
Re: DMD/Objective-C Alpha 1
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/
Re: DMD/Objective-C Alpha 1
On 2011-06-02 07:49:25 -0400, Robert Clipsham rob...@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.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
On 2011-06-02 07:50:20 -0400, Robert Clipsham rob...@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.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
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/
Re: DMD/Objective-C Alpha 1
On 02/06/2011 13:54, Michel Fortin wrote: On 2011-06-02 07:49:25 -0400, Robert Clipsham rob...@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/
Re: DMD/Objective-C Alpha 1
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
Re: DMD/Objective-C Alpha 1
On 2011-06-02 09:58:06 -0400, bearophile bearophileh...@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.for...@michelf.com http://michelf.com/
Re: DMD/Objective-C Alpha 1
On Jun 2, 11 18:17, Michel Fortin wrote: On 2011-06-02 05:30:10 -0400, bearophile bearophileh...@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); ;)
Re: DMD/Objective-C Alpha 1
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
Re: DMD/Objective-C Alpha 1
On 2011-06-02 14:54, Michel Fortin wrote: On 2011-06-02 07:49:25 -0400, Robert Clipsham rob...@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
Re: DMD/Objective-C Alpha 1
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
Re: DMD/Objective-C Alpha 1
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/
Re: DMD/Objective-C Alpha 1
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 (0x) is not valid. Maybe it's because the section names are now one character longer or there is something other that isn't working.