www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D for Xcode 1.2

reply Michel Fortin <michel.fortin michelf.com> writes:
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/>

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Mar 22 2010
next sibling parent Nekuromento <necroment gmail.com> writes:
Great! Thank you for your efforts!
 
Btw, is there any progress with your D to Objective-C bridge ?
Mar 22 2010
prev sibling next sibling parent reply Nekuromento <necroment gmail.com> writes:
Great! Thank you for your efforts!
 
Btw, is there any progress with your D to Objective-C bridge ?
Mar 22 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-03-22 14:41:45 -0400, Nekuromento <necroment gmail.com> said:

 Great! Thank you for your efforts!
 
 Btw, is there any progress with your D to Objective-C bridge ?

Well, I made the necessary changes to make it compile with DMD, and I think I got it to work on Leopard, but right now it's crashing on Snow Leopard for some reasons hard to figure out. GDB not working right with DMD-generated code doesn't help working on this. I'm not sure if I should continue working on the D 1.0 branch of if I should jump directly to D 2.0 for future development. Porting it to D 2.0 would also be a good opportunity to add support for the Objective-C 2.0 "advanced" runtime. Because it only supports the 1.0 "legacy" runtime, the current bridge wouldn't work with Cocoa 64-bit, or on an iPhone, assuming we had a the proper backends and D runtime to go with it. You can look at the current state by fetching from the git repository. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 22 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-03-22 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/>

Very nice. Two things: 1. It's possible to misinterpret that the version number in "D for Xcode 1.2" is for Xcode and not for the plugin 2. Are D files still recognized as DTrace files by default?
Mar 22 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-03-22 14:51:31 -0400, Jacob Carlborg <doob me.com> said:

 On 2010-03-22 14.30, Michel Fortin wrote:
 More details and some screenshots on the website:
 
 <http://michelf.com/projects/d-for-xcode/>

Very nice. Two things: 1. It's possible to misinterpret that the version number in "D for Xcode 1.2" is for Xcode and not for the plugin

Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any suggestion?
 2. Are D files still recognized as DTrace files by default?

This is now fixed, thanks to method swizzling. :-) You can look at the version history on the website for a list of changes and the remaining known issues. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 22 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 23/03/10 10:03, Michel Fortin wrote:
 Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any
 suggestion?

D for Xcode, 1.2
Mar 22 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-03-22 17:19:02 -0400, Bernard Helyer <b.helyer gmail.com> said:

 On 23/03/10 10:03, Michel Fortin wrote:
 
 Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any
 suggestion?

D for Xcode, 1.2

Good idea. Thanks. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 22 2010
parent reply Wayne Anderson <wanderon comcast.net> writes:
Michel Fortin Wrote:

 On 2010-03-22 17:19:02 -0400, Bernard Helyer <b.helyer gmail.com> said:
 
 On 23/03/10 10:03, Michel Fortin wrote:
 
 Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any
 suggestion?

D for Xcode, 1.2

Good idea. Thanks. -- Michel Fortin michel.fortin michelf.com http://michelf.com/

Thanks, Wayne
Mar 23 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Wayne Anderson" <wanderon comcast.net> wrote in message 
news:hob1qp$6f4$1 digitalmars.com...
 Michel Fortin Wrote:

 On 2010-03-22 17:19:02 -0400, Bernard Helyer <b.helyer gmail.com> said:

 On 23/03/10 10:03, Michel Fortin wrote:
 Yeah, I know. But writing "(D for Xcode) 1.2" doesn't look good. Any
 suggestion?

D for Xcode, 1.2

Good idea. Thanks. -- Michel Fortin michel.fortin michelf.com http://michelf.com/

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"

Or, for brevity, just name the plugin "DForXCode" or "XCodeD" and say "DForXCode 1.2" or "XCodeD 1.2".
Mar 23 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Mar 23 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 01 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Apr 01 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.

Apr 02 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Apr 02 2010
parent Jacob Carlborg <doob me.com> writes:
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/
 

Apr 02 2010
prev sibling parent asd <ads sef.com> writes:
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/
Apr 09 2010