October 11, 2009
Robert Clipsham 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.
>>
>> They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion).
>>
>> 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.
>>
>> The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax.
>>
>> What do you think?
> 
> How well will this work with partially parsable files? Will it recover and continue parsing the rest of the file, so all the gained data is still there in the rest of the file, or will it give an error and make the rest of the file lack autocompletion? Or is the idea to merge the newly parsed output with an old version so everything still has autocompletion but the line in question has an error?
> 
> Will it be possible to pass individual statements (maybe along with a previous symbol table) to dmd to save reparsing the whole file?
> 
> Other than that is sounds like a great idea, I can't wait for someone to write an omnicompletion plugin for vim using this!

That would be hard, if its a missing } then the entire parse tree will be in the wrong scope. The best the compiler can do is report an error at line x offset y and let the IDE highlight it, while it keeps on working with the info from the last successful analysis.
October 11, 2009
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.
> 
> They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion).
> 
> 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.
> 
> The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax.
> 
> What do you think?

Which phases of compilation must finish for the generated information? How error tolerant will this process be? If a statement is incompletely typed, will there be useful output? etc...
October 11, 2009
Jacob Carlborg wrote:
> On 10/11/09 11:56, Frank Benoit wrote:
>> Walter Bright schrieb:
>>> They say that the productivity gains of D's improvements are
>>> overbalanced by the loss of productivity by moving away from an IDE. And
>>> what is it about an IDE that is so productive?
>>
>> If you use Eclipse for Java, you have:
>> - Debugger in place
>> - Automatic builder, compile on save
>> * Jump to line from error list
>> * Jump to declaration
>> - Show JavaDoc in tooltip, even in autocompletion
>> - Show hierarchy tree
>> - Autocompletion
>> - Quick assist, e.g.
>>     - assign ctor parameter to new field
>>     - extract selected text into local variable
>>     - Mark source portion, extract to method, the IDE evaluates the needed
>> parameters and return value
>>     - ...
>> There is so much more. But the main thing is, you are not only able to
>> use grep and friends on the pure text level. With an IDE you have
>> semantic support. This makes refactoring your code so much easier. You
>> can say "rename this method" and it works, all references to this method
>> are also altered. "Move this inner class to a top level class in that
>> package", "Derive from that class, yes add the needed ctors". There is
>> even an API to automate refactorings.
>>
>> I think Descent is the right way. But here, a port of DMD is directly
>> integrated into the plugin. To put more manpower in this project would
>> be the best way imo.
> 
> I completely agree. I don't know if it would be better to have the parts of dmd that descent needs in a separate library to avoid porting half of dmd to java.
> 

Which is why i suggested that next to the XML/JSON output there can be an API for plugins like descent to build on top of, instead of forking the entire compiler source making it near impossible to keep up with changes.

In my opinion, more manpower needs to be put in dmd itself so more third party programs and plugins can use it directly, the goal is to make dmd more powerful while supporting more usages.
October 11, 2009
On Sun, 11 Oct 2009 20:03:16 +0400, BLS <windevguy@hotmail.de> wrote:

> On 11/10/2009 17:43, Denis Koroskin wrote:
>> On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Ellery Newcomer wrote:
>>>> Denis Koroskin wrote:
>>>>> On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
>>>>> <newshound1@digitalmars.com> wrote:
>>>>>
>>>>> If anyone is interested and is willing to test and/or help, I will
>>>>> gladly share my code.
>>>> Oooo.. You should put that on dsource or somewhere. Hacking D sounds
>>>> like a lot more fun than hacking C++. I wouldn't mind helping out on
>>>> this one.
>>>
>>> Guys please use D2 :o).
>>>
>>> Andrei
>>
>> I do, it's written entirely in D2 :)
>
> Which GUI toolkit ?
>

I took the Eclipse way and wrote everything from scratch, including the GUI toolkit. It evolves out of needs of other projects. It's meant to be platform independent, but only Win32 backend is currently supported, although I started implementing a generic (windowless) one, but mostly to test out the design and look into implementing custom rendering and skinning support. I believe it won't take too long to port it to other platforms (GTK in first place), but there are always other things to do first...
October 11, 2009
language_fan wrote:
> Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly 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.
>>
>> They say that the productivity gains of D's improvements are
>> overbalanced by the loss of productivity by moving away from an IDE. And
>> what is it about an IDE that is so productive? Intellisense (Microsoft's
>> word for autocompletion).
>>
>> 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.
>>
>> The nice thing about an xml file is while D is relatively easy to parse,
>> xml is trivial. Furthermore, an xml format would be fairly robust in the
>> face of changes to D syntax.
>>
>> What do you think?
> 
> Well since there is already a project working on an Eclipse plugin, I see little use for other IDEs at the moment. The D community is rather small and only a small amount of people are capable of developing and willing to donate their free time on free IDE development (commercial IDEs have small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market). So why not concentrate on fixing the spec and fixing compiler bugs instead of building a modest IDE support no one will use?

Eclipse is heavy, slow and often unresponsive. I use poseidon myself because it is light and fast and I don't require much more from an IDE at the moment.
October 11, 2009
On Sun, 11 Oct 2009 17:49:52 +0200, BLS <windevguy@hotmail.de> wrote:

>On 11/10/2009 16:54, Lutger wrote:
>> BLS wrote:
>>
>> ...
>>> Our Options :
>>> 1) Force Decent.. (Java/SWT)
>>>
>>> 2) Use gtkD, create the IDE in D. (the only usable platform independent
>>>    GUI atm.)
>>>
>>> 3) Use QT and C++. Let's re-use and adapt QT Creator.
>>>
>>> Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer.
>>>
>>> Bjoern
>>
>> Why not QtD?
>
>See QtD at dsource ... "No Windows support... we have lost the race against the DMD tool chain)

Windows support is back now. Eldar has managed to find a workaround for the codegen bug. But there are still a number of issues to resolve before QtD will be usable for non-trivial applications.

> Further QtD has no OSX support (AFAIK)
>
>I still hope that Walter has an eye on the QtD situation..

Someone has succesfully built QtD on OSX but it doesn't work there out-of-the-box (http://www.dsource.org/projects/qtd/wiki/MacCaseStudy)
October 11, 2009
Denis Koroskin ïèøåò:

> If anyone is interested and is willing to test and/or help, I will gladly share my code.

You can write a note on dprogramming ru about the epic thing you're working on, i'm sure we'll help to test at least.
October 11, 2009
Michel Fortin wrote:
> It's not clear to me how much getting supplementary data from the compiler could help. If I only get what I can see through Ddoc, it's only half useful. I can already parse and get character ranges for the the high-level constructs (classes, tempaltes, functions, etc.). What will be harder is matching each symbol in function code to the correct definition because that depends on the context of the function and doing autocompletion for what you type depending on what's available in a given context.

I agree it's only half useful. But I think it's still a big win over zero useful.


> Also, can DMD accept D files from stdin? That way files wouldn't need to be saved on disk on each keystroke.

No, but it's a good idea.
October 11, 2009
Denis Koroskin wrote:
> In fact, that's what I do right now.

I think that's great. But it requires a lot of work (as of course you know).
October 11, 2009
Robert Clipsham wrote:
> How well will this work with partially parsable files?

Probably not very well. This would work best with getting information from modules other than the one being edited.