www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: dmd support for IDEs

reply breezes <wangyuanzju gmail.com> writes:
Ary Borenszweig Wrote:

 Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier 
 that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 So, while I'm not going to be writing an IDE, I figure that dmd can 
 help. dmd already puts out .doc and .di files. How about putting out an 
 xml file giving all the information needed for an IDE to implement 
 autocompletion? There'd be one .xml file generated per .d source file.
 
 What do you think?

What I think is that even with an xml representing the parse tree (maybe with some semantic stuff resolved) it'll be still incomplete for a real IDE (the kind of thing users expect from an IDE). You can see this video, for example: http://www.youtube.com/watch?v=KQbTT605ags So you have: --- module one; class Foo(T) { static if (is(T == class)) { T property; } else { T someMethod() { return T.init; } } mixin(guessWhat!(T)()); } --- You want to define an xml for that module that'll help IDEs. Can you think what it'll look like? Now the user writes in another module: class Bar { } void x() { auto foo = new Foo!(Bar)(); foo. <-- what does the IDE do here? } Now, the correct thing for the IDE to do is to suggest the field "Bar property". How can the IDE do that just with an xml? It can't. It need to perform some kind of semantic anlysis to Foo's argument to see if it's a class, match the static if in the template, replace template parameters, etc. It also needs to evaluate the string mixin. Of course you could say "Bah, just show all the declarations inside the template in the autocomplete", but that's wrong. That'll lead to files that don't compile. You could ommit supporting autocompletion or other nice features, but that's exactly the big features of D. If you don't support that then it's like using Java or C# from within the IDE: you could use the advanced features but the IDE won't help you. And in your discussions with companies adopting D, I'm sure they were talking about great IDEs like JDT Eclipse or Visual Studio, not just some tool that helps you a little but not anymore when things get interesting. Oh, and you need to have some kind of semantic analysis to know the type of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have: auto b = foo.property; b. <-- and here? // remember "property" is templated and depends on static analysis // or the IDE could need to resolve alias this or other things So... my opinion (like some others, I see) is to either ask things to the compiler directly (but here the compiler lacks some info, like exact source range positions), or to have a compiler (not a full-blown one, just the front-end) built into the IDE, and that's what Descent is. Unfortunately Descent is sometimes slow, sometimes buggy, but that's normal: just a few people develop and maintain it (so I can see a similarity with dmd here, where each day I see two or three new bugs reported). If more people were into it, more unit tests were written into it and, most of all, more people would use it, it'll get better. Another problem that people see in Descent (maybe also JDT Eclipse and Visual Studio0 is that it's huge, it consumes a lot of memory and they don't want to open a huge tool just to hack some lines. My answer is: memory performance can be improved (but not a lot), but since an IDE is a huge tool it requires a lof from the computer. And an IDE is not meant to be used to hack some lines, it's meant to help you write big project, huge projects without getting lost in the amount of code. So my bet would be to start supporting an existing IDE that integrates a compiler into it. Updating it is easy: just port the diffs between DMD versions. It's a huge job for one or two people, but if a lot of people were involved it's not that much. Of course I'd recommend you to try Descent since I'm one of it's creators and I do believe it can get pretty good. :-)

A lot of people like me have been waiting for a good IDE for D for a long time. In the field of IDE of D, Descent has already have a good baseline. So I think the community should put more effort in make Descent better, other than create another IDE. For this reason, I think Ary Borenszweig's opinion on in which way can dmd help in building a better IDE may be more valuable than Water's, for he is the author of the currently most advanced IDE of D. Sorry for my poor English.
Oct 12 2009
parent reply BLS <windevguy hotmail.de> writes:
On 12/10/2009 11:41, breezes wrote:
 Ary Borenszweig Wrote:

 Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.

 What do you think?

What I think is that even with an xml representing the parse tree (maybe with some semantic stuff resolved) it'll be still incomplete for a real IDE (the kind of thing users expect from an IDE). You can see this video, for example: http://www.youtube.com/watch?v=KQbTT605ags So you have: --- module one; class Foo(T) { static if (is(T == class)) { T property; } else { T someMethod() { return T.init; } } mixin(guessWhat!(T)()); } --- You want to define an xml for that module that'll help IDEs. Can you think what it'll look like? Now the user writes in another module: class Bar { } void x() { auto foo = new Foo!(Bar)(); foo.<-- what does the IDE do here? } Now, the correct thing for the IDE to do is to suggest the field "Bar property". How can the IDE do that just with an xml? It can't. It need to perform some kind of semantic anlysis to Foo's argument to see if it's a class, match the static if in the template, replace template parameters, etc. It also needs to evaluate the string mixin. Of course you could say "Bah, just show all the declarations inside the template in the autocomplete", but that's wrong. That'll lead to files that don't compile. You could ommit supporting autocompletion or other nice features, but that's exactly the big features of D. If you don't support that then it's like using Java or C# from within the IDE: you could use the advanced features but the IDE won't help you. And in your discussions with companies adopting D, I'm sure they were talking about great IDEs like JDT Eclipse or Visual Studio, not just some tool that helps you a little but not anymore when things get interesting. Oh, and you need to have some kind of semantic analysis to know the type of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have: auto b = foo.property; b.<-- and here? // remember "property" is templated and depends on static analysis // or the IDE could need to resolve alias this or other things So... my opinion (like some others, I see) is to either ask things to the compiler directly (but here the compiler lacks some info, like exact source range positions), or to have a compiler (not a full-blown one, just the front-end) built into the IDE, and that's what Descent is. Unfortunately Descent is sometimes slow, sometimes buggy, but that's normal: just a few people develop and maintain it (so I can see a similarity with dmd here, where each day I see two or three new bugs reported). If more people were into it, more unit tests were written into it and, most of all, more people would use it, it'll get better. Another problem that people see in Descent (maybe also JDT Eclipse and Visual Studio0 is that it's huge, it consumes a lot of memory and they don't want to open a huge tool just to hack some lines. My answer is: memory performance can be improved (but not a lot), but since an IDE is a huge tool it requires a lof from the computer. And an IDE is not meant to be used to hack some lines, it's meant to help you write big project, huge projects without getting lost in the amount of code. So my bet would be to start supporting an existing IDE that integrates a compiler into it. Updating it is easy: just port the diffs between DMD versions. It's a huge job for one or two people, but if a lot of people were involved it's not that much. Of course I'd recommend you to try Descent since I'm one of it's creators and I do believe it can get pretty good. :-)

A lot of people like me have been waiting for a good IDE for D for a long time. In the field of IDE of D, Descent has already have a good baseline. So I think the community should put more effort in make Descent better, other than create another IDE. For this reason, I think Ary Borenszweig's opinion on in which way can dmd help in building a better IDE may be more valuable than Water's, for he is the author of the currently most advanced IDE of D. Sorry for my poor English.

What I definitely don't like is that Decent is just a Eclipse plugin. I don't want a Java IDE plus D. I would prefer a pure D IDE. Being a Netbeans guy but I am pretty sure that it is possible to remove all the Java related things. side effects : less bloat more speed. my 2 euro cents
Oct 12 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
BLS wrote:
 On 12/10/2009 11:41, breezes wrote:
 Ary Borenszweig Wrote:

 Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.

 What do you think?

What I think is that even with an xml representing the parse tree (maybe with some semantic stuff resolved) it'll be still incomplete for a real IDE (the kind of thing users expect from an IDE). You can see this video, for example: http://www.youtube.com/watch?v=KQbTT605ags So you have: --- module one; class Foo(T) { static if (is(T == class)) { T property; } else { T someMethod() { return T.init; } } mixin(guessWhat!(T)()); } --- You want to define an xml for that module that'll help IDEs. Can you think what it'll look like? Now the user writes in another module: class Bar { } void x() { auto foo = new Foo!(Bar)(); foo.<-- what does the IDE do here? } Now, the correct thing for the IDE to do is to suggest the field "Bar property". How can the IDE do that just with an xml? It can't. It need to perform some kind of semantic anlysis to Foo's argument to see if it's a class, match the static if in the template, replace template parameters, etc. It also needs to evaluate the string mixin. Of course you could say "Bah, just show all the declarations inside the template in the autocomplete", but that's wrong. That'll lead to files that don't compile. You could ommit supporting autocompletion or other nice features, but that's exactly the big features of D. If you don't support that then it's like using Java or C# from within the IDE: you could use the advanced features but the IDE won't help you. And in your discussions with companies adopting D, I'm sure they were talking about great IDEs like JDT Eclipse or Visual Studio, not just some tool that helps you a little but not anymore when things get interesting. Oh, and you need to have some kind of semantic analysis to know the type of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have: auto b = foo.property; b.<-- and here? // remember "property" is templated and depends on static analysis // or the IDE could need to resolve alias this or other things So... my opinion (like some others, I see) is to either ask things to the compiler directly (but here the compiler lacks some info, like exact source range positions), or to have a compiler (not a full-blown one, just the front-end) built into the IDE, and that's what Descent is. Unfortunately Descent is sometimes slow, sometimes buggy, but that's normal: just a few people develop and maintain it (so I can see a similarity with dmd here, where each day I see two or three new bugs reported). If more people were into it, more unit tests were written into it and, most of all, more people would use it, it'll get better. Another problem that people see in Descent (maybe also JDT Eclipse and Visual Studio0 is that it's huge, it consumes a lot of memory and they don't want to open a huge tool just to hack some lines. My answer is: memory performance can be improved (but not a lot), but since an IDE is a huge tool it requires a lof from the computer. And an IDE is not meant to be used to hack some lines, it's meant to help you write big project, huge projects without getting lost in the amount of code. So my bet would be to start supporting an existing IDE that integrates a compiler into it. Updating it is easy: just port the diffs between DMD versions. It's a huge job for one or two people, but if a lot of people were involved it's not that much. Of course I'd recommend you to try Descent since I'm one of it's creators and I do believe it can get pretty good. :-)

A lot of people like me have been waiting for a good IDE for D for a long time. In the field of IDE of D, Descent has already have a good baseline. So I think the community should put more effort in make Descent better, other than create another IDE. For this reason, I think Ary Borenszweig's opinion on in which way can dmd help in building a better IDE may be more valuable than Water's, for he is the author of the currently most advanced IDE of D. Sorry for my poor English.

What I definitely don't like is that Decent is just a Eclipse plugin. I don't want a Java IDE plus D. I would prefer a pure D IDE. Being a Netbeans guy but I am pretty sure that it is possible to remove all the Java related things. side effects : less bloat more speed. my 2 euro cents

No, but that's the good thing about it: it's just a plugin. You don't need the Java IDE to run Descent. Michal Minich wrote somewhere else: --- You can try to download just bare Eclipse platform (which is just text editor) and install descent into it using Eclipse software updates. It starts up faster than C or Java version Eclipse and there is only D related stuff in the UI. http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php Under "Platform runtime binary" --- I tried it and it's true, it feels much lighter this way and you don't a lot of bloat in menus and other things.
Oct 12 2009
next sibling parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:

 Michal Minich wrote somewhere else:
 
 ---
 You can try to download just bare Eclipse platform (which is just text 
 editor) and install descent into it using Eclipse software updates. It 
 starts up faster than C or Java version Eclipse and there is only D 
 related stuff in the UI.
 
 http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-20
909170800/index.php 
 
 Under "Platform runtime binary"
 ---
 
 I tried it and it's true, it feels much lighter this way and you don't a 
 lot of bloat in menus and other things.

It would be great to put this on the Descent front page.
Oct 12 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Don wrote:
 Ary Borenszweig wrote:
 
 Michal Minich wrote somewhere else:

 ---
 You can try to download just bare Eclipse platform (which is just text 
 editor) and install descent into it using Eclipse software updates. It 
 starts up faster than C or Java version Eclipse and there is only D 
 related stuff in the UI.

 http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-20
909170800/index.php 

 Under "Platform runtime binary"
 ---

 I tried it and it's true, it feels much lighter this way and you don't 
 a lot of bloat in menus and other things.

It would be great to put this on the Descent front page.

I put it on the "Installing the plugin" page as soon as I saw it here. Thanks Michal Minich!
Oct 12 2009
parent Michal Minich <michal.minich gmail.com> writes:
Hello Ary,

 Don wrote:
 
 Ary Borenszweig wrote:
 
 Michal Minich wrote somewhere else:
 
 ---
 You can try to download just bare Eclipse platform (which is just
 text
 editor) and install descent into it using Eclipse software updates.
 It
 starts up faster than C or Java version Eclipse and there is only D
 related stuff in the UI.
 http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-20090917
 0800/index.php
 
 Under "Platform runtime binary"
 ---
 I tried it and it's true, it feels much lighter this way and you
 don't a lot of bloat in menus and other things.
 


Thanks Michal Minich!

You are welcome :) I use it this way from the beginning on both Windows and Ubuntu. I first installed Descent into Java Eclipse, but it was also first time I saw Java and Eclipse :) so I was quite overwhelmed by the lot functionality available and could not find which is for D and which for Java. This way it is more beginner friendly. Thank you for your hard work on Descent.
Oct 13 2009
prev sibling next sibling parent BLS <windevguy hotmail.de> writes:
On 12/10/2009 15:49, Ary Borenszweig wrote:

 Michal Minich wrote somewhere else:

 ---
 You can try to download just bare Eclipse platform (which is just text
 editor) and install descent into it using Eclipse software updates. It
 starts up faster than C or Java version Eclipse and there is only D
 related stuff in the UI.

 http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php

 Under "Platform runtime binary"
 ---

 I tried it and it's true, it feels much lighter this way and you don't a
 lot of bloat in menus and other things.

I tried it too. works fine, feels good.
Oct 12 2009
prev sibling next sibling parent dolive <dolive89 sina.com> writes:
Ary Borenszweig :


 
 ---
 You can try to download just bare Eclipse platform (which is just text 
 editor) and install descent into it using Eclipse software updates. It 
 starts up faster than C or Java version Eclipse and there is only D 
 related stuff in the UI.
 
 http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php
 Under "Platform runtime binary"
 ---
 
 I tried it and it's true, it feels much lighter this way and you don't a 
 lot of bloat in menus and other things.

if Descent is written in d so is very good !
Oct 12 2009
prev sibling parent dolive <dolive89 sina.com> writes:
Ary Borenszweig :


 
 ---
 You can try to download just bare Eclipse platform (which is just text 
 editor) and install descent into it using Eclipse software updates. It 
 starts up faster than C or Java version Eclipse and there is only D 
 related stuff in the UI.
 
 http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php
 Under "Platform runtime binary"
 ---
 
 I tried it and it's true, it feels much lighter this way and you don't a 
 lot of bloat in menus and other things.

if Descent is written in d so is very good !
Oct 12 2009