View mode: basic / threaded / horizontal-split · Log in · Help
October 11, 2009
Re: dmd support for IDEs
digited wrote:

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

Yes please make it write to stdout!

This is a very good plan and useful not only for IDE's, but also for example 
to automate bindings to scriptings languages.
October 11, 2009
Re: dmd support for IDEs
Walter Bright wrote:

...
> 
> Think of what it provides as very similar to what ddoc does, except that
> instead of being in a human-readable format it would be a
> machine-readable one.
> 
> In other words, for each module you'll be able to get
> 
> . all the symbols in that module, and the members of those symbols
> (recursively)
> . the file/line of the source location of each symbol
> . the ddoc comment for each symbol
> . the type of each symbol
> 
> Things could be added over time, I was just thinking of this for starters.

What about file/line/column of the symbol? Is this much work / hard work to 
add?
October 11, 2009
Re: dmd support for IDEs
Walter Bright wrote:
> Jeremie Pelletier wrote:
>> The IDE usually keeps the files in memory and could therefore just 
>> call something like getSemantics(char** fileBuffers, int* fileSizes, 
>> int nFiles, ParseNode* parseTree) and have its parse nodes already 
>> allocated in process memory ready for use.
>>
>> Considering a lot of IDEs like to re-parse the current file every time 
>> the keyboard is idle for a few seconds, this could really help 
>> performance, nothing is more annoying than an IDE that feels 
>> unresponsive.
> 
> ...
>
> Experience also suggests that using fork/exec rather than a shared dll 
> approach is much more robust and easier to develop. The reason is that 
> the former uses separate processes, which cannot step on each other. The 
> latter puts everything in one process space, where you've got all the 
> lovely, time-consuming, hair-pulling concurrency problems. The utter 
> failure of the parse process also cannot bring down the IDE.

	Plus, with a DLL you're contaminated by the GPL: the IDE *has* to 
be GPL-compatible to use your DLL. With fork/exec there are no such 
constraints...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr
October 11, 2009
Re: dmd support for IDEs
Walter Bright wrote:
> Think of what it provides as very similar to what ddoc does, except that 
> instead of being in a human-readable format it would be a 
> machine-readable one.
> 
> In other words, for each module you'll be able to get
> 
> . all the symbols in that module, and the members of those symbols 
> (recursively)

	Including local variables for functions?

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr
October 11, 2009
Re: dmd support for IDEs
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.
October 11, 2009
Re: dmd support for IDEs
Jérôme M. Berger wrote:
>> . all the symbols in that module, and the members of those symbols 
>> (recursively)
> 
>     Including local variables for functions?

That seems pointless, as they'll be inaccessible outside of the scope of 
the function.
October 11, 2009
Re: dmd support for IDEs
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!
October 11, 2009
Re: dmd support for IDEs
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.
October 11, 2009
Re: dmd support for IDEs
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:has92u$1vum$1@digitalmars.com...
> 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.

So the IDE knows where it is and can actually do things with it, instead of 
just knowing "Well, it's somewhere around here-ish."
October 11, 2009
Re: dmd support for IDEs
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:has947$1vum$2@digitalmars.com...
> Jérôme M. Berger wrote:
>>> . all the symbols in that module, and the members of those symbols 
>>> (recursively)
>>
>>     Including local variables for functions?
>
> That seems pointless, as they'll be inaccessible outside of the scope of 
> the function.

void foo()
{
  int bar;
  // big complex func here
}
User: Ok, IDE, Refactor->Rename->foo's "bar" to "baz"
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home