On 2010-03-23 14:38:17 -0400, Wayne Anderson <wanderon@comcast.net> said:

> I too, initially, misinterpreted the language and checked the version of my copy of XCode to see if it was 1.2.  I would suggest "D plugin, version 1.2, for Xcode" or "version 1.2 of the D Plugin for Xcode"

Not having "plugin" in the name leaves more room for growth. The current package downloads and installs a compiler, so in a way it's already more than a plugin. Adding modules for OS X APIs might be the next step.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 3/22/10 14:30, Michel Fortin wrote:
> It's been a while since DMD has been available on Mac OS X, but I
> haven't made an official release of D for Xcode to support DMD. Today
> I'm fixing that.
>
> So D for Xcode 2.1 now supports DMD. It comes with an installer package
> that does the following:
>
> * Install D plugin for Xcode
> * Install Xcode file and project templates for D
> * Download and install latest version of DMD 2.x
> * Download and install latest version of DMD 1.x
>
> This means that someone can just run the installer and immediately start
> writing/compiling D code within Xcode. It's using DMD 2.x by default,
> but there is no problem installing both versions at the same time and
> changing the default.
>
> More details and some screenshots on the website:
>
> <http://michelf.com/projects/d-for-xcode/>

I've download the new version of your plugin and have tested it and have few comments.

The first thing I noticed when I compiled a project was that it tries to pass the '-noboundscheck' flag to DMD, which it doesn't support.

I also noted that now the plugin overwrites/removes the GDC support. It would be nice if both could be supported.

Have you ever investigated if it would be possible create a plugin for Interface Builder that would add D support? I've been thinking of two ways this might be done.

I've found this blog post which I think is quite interesting: http://cocoawithlove.com/2009/02/interprocess-communication-snooping.html . I was thinking if the method described there could be used to add D support to Interface Builder. I was thinking of implementing a class that generates temporary Objective-C header files out of D files, implementing the methods described in the post and responding with the temporary Objective-C files. I've tried to implement a kind of dummy class which responds to the methods but Interface Builder didn't like them for some reason.

The other idea I was thinking of was to create an actual plugin for Interface Builder containing a D parser that does the same as Interface Builder does but for D files.

Great work by the way with the plugin, I specially like that D files are correctly recognized now.


/Jacob Carlborg

On 2010-04-01 15:24:59 -0400, Jacob Carlborg <doob@me.com> said:

> I've download the new version of your plugin and have tested it and have few comments.
> 
> The first thing I noticed when I compiled a project was that it tries to pass the '-noboundscheck' flag to DMD, which it doesn't support.

Yes it does, but only for D2. It should not do that by default though... I'll look at it. Ideally this option wouldn't be available for D1, but the way the default compiler version is chosen makes it difficult to know which one is used.


> I also noted that now the plugin overwrites/removes the GDC support. It would be nice if both could be supported.

It's not really gone. You can add a build rule in each target specifying GDC as the compiler for D source files. I would like to have a better solution, but right now I don't.

Ideally, there would be a build setting for choosing the default compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2, GCC-LLVM and Clang. But I haven't been able to make something similar.


> Have you ever investigated if it would be possible create a plugin for Interface Builder that would add D support? I've been thinking of two ways this might be done.
> 
> I've found this blog post which I think is quite interesting: http://cocoawithlove.com/2009/02/interprocess-communication-snooping.html . I was thinking if the method described there could be used to add D support to Interface Builder. I was thinking of implementing a class that generates temporary Objective-C header files out of D files, implementing the methods described in the post and responding with the temporary Objective-C files. I've tried to implement a kind of dummy class which responds to the methods but Interface Builder didn't like them for some reason.
> 
> The other idea I was thinking of was to create an actual plugin for Interface Builder containing a D parser that does the same as Interface Builder does but for D files.

I'm not sure I understand clearly what you mean by 'D support for IB', but here's what I can say:

Interface Builder generates some sort of serialization of Objective-C objects. You need the D/Objective-C bridge to load Nib files instantiating D classes (but it works!). If you want Interface Builder to recognize D files with the IBOutlet and IBAction templates found in the D/Objective-C bridge, then making a parser plugin for IB (your second option) would make most sense.

But I'm not there yet. making the bridge work on Snow Leopard has a higher priority right now (even though I'm not really working on that currently).


> Great work by the way with the plugin, I specially like that D files are correctly recognized now.

Thanks for your comments.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 4/2/10 03:35, Michel Fortin wrote:
> On 2010-04-01 15:24:59 -0400, Jacob Carlborg <doob@me.com> said:
>
>> I've download the new version of your plugin and have tested it and
>> have few comments.
>>
>> The first thing I noticed when I compiled a project was that it tries
>> to pass the '-noboundscheck' flag to DMD, which it doesn't support.
>
> Yes it does, but only for D2. It should not do that by default though...
> I'll look at it. Ideally this option wouldn't be available for D1, but
> the way the default compiler version is chosen makes it difficult to
> know which one is used.

I had no idea that DMD2 supported the -noboundscheck flag.

>> I also noted that now the plugin overwrites/removes the GDC support.
>> It would be nice if both could be supported.
>
> It's not really gone. You can add a build rule in each target specifying
> GDC as the compiler for D source files. I would like to have a better
> solution, but right now I don't.
>
> Ideally, there would be a build setting for choosing the default
> compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2,
> GCC-LLVM and Clang. But I haven't been able to make something similar.

If you ever implement this there could be separate options for DMD1 and DMD2.

>> Have you ever investigated if it would be possible create a plugin for
>> Interface Builder that would add D support? I've been thinking of two
>> ways this might be done.
>>
>> I've found this blog post which I think is quite interesting:
>> http://cocoawithlove.com/2009/02/interprocess-communication-snooping.html
>> . I was thinking if the method described there could be used to add D
>> support to Interface Builder. I was thinking of implementing a class
>> that generates temporary Objective-C header files out of D files,
>> implementing the methods described in the post and responding with the
>> temporary Objective-C files. I've tried to implement a kind of dummy
>> class which responds to the methods but Interface Builder didn't like
>> them for some reason.
>>
>> The other idea I was thinking of was to create an actual plugin for
>> Interface Builder containing a D parser that does the same as
>> Interface Builder does but for D files.
>
> I'm not sure I understand clearly what you mean by 'D support for IB',
> but here's what I can say:
>
> Interface Builder generates some sort of serialization of Objective-C
> objects. You need the D/Objective-C bridge to load Nib files
> instantiating D classes (but it works!). If you want Interface Builder
> to recognize D files with the IBOutlet and IBAction templates found in
> the D/Objective-C bridge, then making a parser plugin for IB (your
> second option) would make most sense.

I was referring to Interface Builder recognizing D files with the IBOutlet and IBAction templates. I was thinking that since you already have an XCode plugin and if you could access the mentioned methods it could be easier using the first option. But as a long term solution the second option would be the preferred one.

> But I'm not there yet. making the bridge work on Snow Leopard has a
> higher priority right now (even though I'm not really working on that
> currently).
>
>
>> Great work by the way with the plugin, I specially like that D files
>> are correctly recognized now.
>
> Thanks for your comments.
>
>

On 2010-04-02 04:40:11 -0400, Jacob Carlborg <doob@me.com> said:

> I had no idea that DMD2 supported the -noboundscheck flag.

It's quite new, it disables bound checking in @safe function (safe functions normally keep bound checks in release mode).


>> It's not really gone. You can add a build rule in each target specifying
>> GDC as the compiler for D source files. I would like to have a better
>> solution, but right now I don't.
>> 
>> Ideally, there would be a build setting for choosing the default
>> compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2,
>> GCC-LLVM and Clang. But I haven't been able to make something similar.
> 
> If you ever implement this there could be separate options for DMD1 and DMD2.

You can also choose between DMD1 and DMD2 by creating a per-target custom build rule (if you have both versions installed). But I agree it'd make more sense to have this as a build setting similar to how you can choose your C/C++/Objective-C compiler.


> I was referring to Interface Builder recognizing D files with the IBOutlet and IBAction templates. I was thinking that since you already have an XCode plugin and if you could access the mentioned methods it could be easier using the first option. But as a long term solution the second option would be the preferred one.

Note that you don't really need IB integration to use actions and outlet in IB: you can create a class definition directly in IB and add your actions and outlets manually. Obviously, IB will think it's Objective-C, so your action names will have a colon suffix.

More importantly it's not automated. Generating Objective-C files and making them visible to IB can't be made to be easy to use in my opinion, but you should be able to write a script with a regular expression to do that and integrate it into your build process if you want.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Replying from the newsgroup, I have know idea how it will work, Thunderbird refuses to show this message for some reason.

Michel Fortin Wrote:

> On 2010-04-02 04:40:11 -0400, Jacob Carlborg <doob@me.com> said:
> 
> > I had no idea that DMD2 supported the -noboundscheck flag.
> 
> It's quite new, it disables bound checking in @safe function (safe functions normally keep bound checks in release mode).

Ok

> >> It's not really gone. You can add a build rule in each target specifying GDC as the compiler for D source files. I would like to have a better solution, but right now I don't.
> >> 
> >> Ideally, there would be a build setting for choosing the default compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2, GCC-LLVM and Clang. But I haven't been able to make something similar.
> > 
> > If you ever implement this there could be separate options for DMD1 and DMD2.
> 
> You can also choose between DMD1 and DMD2 by creating a per-target custom build rule (if you have both versions installed). But I agree it'd make more sense to have this as a build setting similar to how you can choose your C/C++/Objective-C compiler.
> 
> 
> > I was referring to Interface Builder recognizing D files with the IBOutlet and IBAction templates. I was thinking that since you already have an XCode plugin and if you could access the mentioned methods it could be easier using the first option. But as a long term solution the second option would be the preferred one.
> 
> Note that you don't really need IB integration to use actions and outlet in IB: you can create a class definition directly in IB and add your actions and outlets manually. Obviously, IB will think it's Objective-C, so your action names will have a colon suffix.

I know I can add actions, classes and outlets manually but the goal here, that I had in mind, was to make it automatically. I just want to have it as perfect as possible :)

> More importantly it's not automated. Generating Objective-C files and making them visible to IB can't be made to be easy to use in my opinion, but you should be able to write a script with a regular expression to do that and integrate it into your build process if you want.

That's an option.

> -- 
> Michel Fortin
> michel.fortin@michelf.com
> http://michelf.com/
> 

Michel Fortin Wrote:

> Ideally, there would be a build setting for choosing the default compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2, GCC-LLVM and Clang. But I haven't been able to make something similar.

Cocotron does it. Maybe you could see how they're doing it?

http://www.cocotron.org/