October 11, 2009
Frank Benoit wrote:
> 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.

Eclipse is probably, along with VS, one of the two most powerful IDEs.

But the JSON approach would also make things like Emacs usable with D with a basic level of autocomplete support, as well as the panopoly of simpler, more lightweight editors.

JSON support also will not take away anything from efforts to integrate DMD into IDE front ends. It's more for IDEs that don't have the resources to do that.
October 11, 2009
On 11/10/2009 18:29, Denis Koroskin wrote:
> 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...

sounds awesome. have you considered integrating other existing projects like Dil and dang?
October 11, 2009
On 11/10/2009 15:23, 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. :-)

well put.

btw, given that we have a port of SWT for D, how hard would it be to create our own native D version of eclipse?
October 11, 2009
digited Wrote:

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

I'm all for it.

October 11, 2009
digited, el 10 de octubre a las 22:19 me escribiste:
> Walter Bright ?????:
> > The nice thing about an xml file is while D is relatively easy to parse, xml is trivial.
> 
> Why file? An IDE can call compiler process and get output with info from stdout, that will be much faster, and if IDE will need to store the info, it will, or will not, itself.

And why XML? XML is seriously bloated, I think JSON can be better. With web 2.0 and all, JSON parsers are almost as popular as XML parser, but much easier to implement :)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
For a minute there
I lost myself, I lost myself.
Phew, for a minute there,
I lost myself, I lost myself.
October 11, 2009
Walter Bright wrote:
> 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).

Good things require a lot of work. :)
October 11, 2009
Walter Bright, el 10 de octubre a las 18:19 me escribiste:
> 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).

I think you've got that answer because they are not using D alread. When they start using D, they will start complaining about Phobos vs. Tango, debugger support, librararies, bugs, etc. ;) (maybe not DMD being GPL though, even when I think it's important).

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ah, se va en 1981? Pero por qué? ... Ah, porque ya había sido determinado,
entonces quiere decir que pronto vamos a elegir presidente nuevo nosot...
Ah, nosotros no? Ah, lo van a elegir en la ... Ah! Quiere que le diga? Muy
bien pensado, porque cada vez que lo elegimos nosotros no duran nada!
	-- Tato vs. Tato (1980, Gobierno de Videla)
October 11, 2009
Walter Bright, el 11 de octubre a las 02:38 me escribiste:
> Lutger wrote:
> >What about file/line/column of the symbol? Is this much work / hard work to add?
> 
> file/line of course, but I don't see a point to column.

See Clang error messages: http://clang.llvm.org/diagnostics.html

That's *nice* =)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ever tried? Ever failed? - Try again! Fail better!
October 11, 2009
On 2009-10-11 14:19:52 -0400, Walter Bright <newshound1@digitalmars.com> said:

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

Indeed. And it may be a perfect fit for other tools such as a documentation system that can do cross-references across modules, or... hum perhaps even runtime reflection? :-)


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

Great.


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

October 11, 2009
Ary Borenszweig wrote:
> Walter Bright wrote:
>> 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).
> 
> Good things require a lot of work. :)

Of course. But getting something done and available in a short amount of time is also good!

For example, some people say to me "why should I use D, when C++0x solves my issues with C++?"

And I point out "how many more years are you willing to wait for C++0x, when D is here now?"

[Setting aside for the moment the issue of whether C++0x really is better than D or not!]

The point is, good enough now gets us further down the road of getting a user base large enough to justify the effort for a more comprehensive solution.

For example, if I have many miles to commute to work, the best choice is a car. But if I can't afford a car, or am too young to drive, a bike at least gets me there. Before I was 16 and could drive, a bike was very liberating for me, I rode it everywhere.