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/

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

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/

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);

;)

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

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

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

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/

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."

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