Discussion:
dmd support for IDEs
(too old to reply)
Walter Bright
2009-10-11 01:19:56 UTC
Permalink
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?
digited
2009-10-11 02:19:55 UTC
Permalink
Post by 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.
Lutger
2009-10-11 08:57:40 UTC
Permalink
Post by digited
Post by 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.
Andrei Alexandrescu
2009-10-11 13:57:01 UTC
Permalink
Post by Lutger
Post by digited
Post by 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!
That's a good idea, but traditionally Unix a program that outputs many
files (such as a compiler) outputs them to named files, with "-"
representing stdin/stdout.

Andrei
Leandro Lucarella
2009-10-11 19:03:38 UTC
Permalink
Post by digited
Post by 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.
Jeremie Pelletier
2009-10-11 02:26:29 UTC
Permalink
Post by Walter Bright
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?
I think it would be great, but XML is only one format and a heavy one at
that, JSON for example is much lighter and easier to parse. It shouldn't
be hard to support both.

However I would make the file generation optional, as the IDE might just
want to read from the standard output stream of dmd instead, this would
also be useful for shell scripts.

Support to get the semantics information of multiple files at once would
also be neat, just like dmd can generate one object file from multiple
source files.

Would it even be possible to have the C api behind the xml/json
frontends exported in a dll, so IDEs could just dynamically link to it
and call that API directly instead of parsing an intermediary text format.

Jeremie
Walter Bright
2009-10-11 02:37:53 UTC
Permalink
Post by Jeremie Pelletier
I think it would be great, but XML is only one format and a heavy one at
that, JSON for example is much lighter and easier to parse. It shouldn't
be hard to support both.
I'd never heard of JSON, but looking at it, it makes sense. I don't see
much point in supporting both.
Post by Jeremie Pelletier
However I would make the file generation optional, as the IDE might just
want to read from the standard output stream of dmd instead, this would
also be useful for shell scripts.
Yes, writing it to stdout as an option is a good idea.
Post by Jeremie Pelletier
Support to get the semantics information of multiple files at once would
also be neat, just like dmd can generate one object file from multiple
source files.
Yes.
Post by Jeremie Pelletier
Would it even be possible to have the C api behind the xml/json
frontends exported in a dll, so IDEs could just dynamically link to it
and call that API directly instead of parsing an intermediary text format.
I did that with the C++ compiler, and it's a big pain to support. I
don't think it would be onerous to fork/exec the compiler to do the
work, capture the output, and parse it.
bearophile
2009-10-11 04:22:19 UTC
Permalink
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.<
Welcome to more modern times Walter :-)
You may have noticed that a small army of people in this newsgroup has told you the same things in the last years I've spent around here.
In practice modern statically typed languages aren't designed to be used alone, they are designed to be used with an IDE. So what in the past was a "programming language" today is a "programming language + IDE".
Probably there are ways to overdo this idea (like the idea of programming languages written in XML instead of nornal text), but D isn't risking to fall into this trap yet.
And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion).<
The productivity of modern IDEs is a complex thing, it comes from several tuned features. Intellisense is just one of those parts. Have you tried to program 2-3 days with dotnet C#? If you try, you will see several interesting things you don't know about.

Some form of reflection too helps IDEs, I think.
The file you talk about will help refracting tools, I guess.

In C# you have a syntax for sections of code that tells the IDE how to fold code, it's named:
#region
Some people don't like them, but they are common in C#:
http://www.codinghorror.com/blog/archives/001147.html

Attributes too are food for the IDEs, they add semantic information on the code, and IDEs love such information:
@someattribute(data1, datas2, ...)
I'd never heard of JSON, but looking at it, it makes sense. I don't see
much point in supporting both.
XML is very common, so most tools already support it or have ways to support it. So probably big IDEs are able to read XML files. So supporting XML is good.

JSON is light, easy to parse, so if you want to write a simpler tool it can be good. I like JSON, it's quite common on the web and with dynamic languages. But JSON is less common in some situations, so some existing tools may not be already able to digest it.

That's why supporting both looks like a good idea. The good thing is that I don't think will be hard to generate one when DMD is able to generate the other.

If you really want to support only one of the two, then you have to look at the kind of generated data. XML is better for really complex structures, while JSON is enough if the data ha a low level of nesting. The tools designed to query very complex XML files are more advanced and common.

What kind of data do you want to put in such files?

The optional output to stdout of such data is good.

Bye,
bearophile
Jeremie Pelletier
2009-10-11 05:27:39 UTC
Permalink
Post by Walter Bright
Post by Jeremie Pelletier
I think it would be great, but XML is only one format and a heavy one
at that, JSON for example is much lighter and easier to parse. It
shouldn't be hard to support both.
I'd never heard of JSON, but looking at it, it makes sense. I don't see
much point in supporting both.
XML makes sense when saving as a file and it can be transformed by XSLT
to generate formatted html documentation and whatnot, while JSON is
lightweight and better suited for pipes between dmd and the IDE.
Post by Walter Bright
Post by Jeremie Pelletier
However I would make the file generation optional, as the IDE might
just want to read from the standard output stream of dmd instead, this
would also be useful for shell scripts.
Yes, writing it to stdout as an option is a good idea.
Post by Jeremie Pelletier
Support to get the semantics information of multiple files at once
would also be neat, just like dmd can generate one object file from
multiple source files.
Yes.
Post by Jeremie Pelletier
Would it even be possible to have the C api behind the xml/json
frontends exported in a dll, so IDEs could just dynamically link to it
and call that API directly instead of parsing an intermediary text format.
I did that with the C++ compiler, and it's a big pain to support. I
don't think it would be onerous to fork/exec the compiler to do the
work, capture the output, and parse it.
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.
Walter Bright
2009-10-11 05:57:08 UTC
Permalink
Post by Jeremie Pelletier
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.
I understand and agree, but we are operating under severe manpower
constraints. I don't have a 100 million dollar budget! (I'm sure MS
spends more than that on VS.)

You're certainly welcome to take the compiler front end and try and make
a dll out of it or integrate it directly into an IDE. But what I
suggested would probably get a lot of results for a minimal investment
in the front end and a minimal investment in existing IDEs.



My experience with making responsive interactive apps on slow machines
suggests that using a multithreaded approach would make the IDE
responsive even if the underlying parsing process is slow. What you do
is, every time the source file changes, fire off a background thread at
a low priority to reparse. If the source changes before it finishes,
restart that thread. When the IDE actually needs the results, it uses
the results of the most recently finished parse.

With this approach, there won't be any hangs where the keyboard is
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.
Walter Bright
2009-10-11 06:06:42 UTC
Permalink
Post by Walter Bright
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.
In particular, if the compiler seg faults (does it ever do that? <g>) it
won't stop the IDE.
bearophile
2009-10-11 06:48:13 UTC
Permalink
Post by Walter Bright
but we are operating under severe manpower
constraints. I don't have a 100 million dollar budget!
And sometimes this is even an advantage, because it forces to keep things simple and not over-engineered :-)

Bye,
bearophile
&quot;Jérôme M. Berger&quot;
2009-10-11 09:14:15 UTC
Permalink
Post by Walter Bright
Post by Jeremie Pelletier
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 at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20091011/fe4a5b3c/attachment.pgp>
Michel Fortin
2009-10-11 12:13:48 UTC
Permalink
Post by Walter Bright
You're certainly welcome to take the compiler front end and try and
make a dll out of it or integrate it directly into an IDE. But what I
suggested would probably get a lot of results for a minimal investment
in the front end and a minimal investment in existing IDEs.
And I've already done so in D for Xcode (with an old version of DMD).

I had to change the error handling to throw exceptions on errors (no
call to exit in my IDE please!). I also added some data to tokens to
get their exact range in the file allowing me to use the DMD lexer for
syntax highlighting. The semantic also did preserve that information
and could tell you in what class, template, or function your insertion
point was on a per-character basis.

And then I stopped there. This is a pain to maintain when DMD gets
updated, so I didn't. It's buggy because if the compiler crashes, the
IDE crashes too (keep in mind that parsing incomplete code every few
seconds has a tendency to cause more crashes than regular compilation).

And finally, Xcode 3 came with a much better syntax definition format
and a complete revamp of syntax highlighting that obsoleted half the
integration work I did. So the next version of D for Xcode will get rid
of DMDFE as an internal component and use Xcode's built-in machinery.

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.
Post by Walter Bright
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.
Indeed, you don't want the compiler to crash your IDE.

Also, can DMD accept D files from stdin? That way files wouldn't need
to be saved on disk on each keystroke.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
Walter Bright
2009-10-11 18:19:52 UTC
Permalink
Post by Michel Fortin
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.
Post by Michel Fortin
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.
Michel Fortin
2009-10-11 19:22:26 UTC
Permalink
Post by Walter Bright
Post by Michel Fortin
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? :-)
Post by Walter Bright
Post by Michel Fortin
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 at michelf.com
http://michelf.com/
Walter Bright
2009-10-11 21:56:07 UTC
Permalink
Post by Michel Fortin
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? :-)
It's one of those things where there may be a lot of unanticipated uses
for it!
Ellery Newcomer
2009-10-11 03:47:53 UTC
Permalink
Post by Walter Bright
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, that's a better solution than reimplementing semantic analysis in
the ide. If you make it, I will stop trying to do the latter.

In the xml, will we see ct stuff and other transformations that DMD
performs on the source expanded?

[very very minor] concerns:

standardized? DMD derivatives will have it, what about hypothetical
other D implementations?

If your ide can't see or doesn't have compiler, it won't be able to do
much (erm duh)

All in all, I think it would be the bomb. I'd even volunteer to help
implementing it if I thought my code contributions would do less harm
than good.
Walter Bright
2009-10-11 04:03:58 UTC
Permalink
Post by Ellery Newcomer
Well, that's a better solution than reimplementing semantic analysis in
the ide. If you make it, I will stop trying to do the latter.
That's what I wanted to hear.
Post by Ellery Newcomer
In the xml, will we see ct stuff and other transformations that DMD
performs on the source expanded?
ct stuff? What is that? Won't see dmd operations on the source expanded.
What you'll see is basically what ddoc generates, but in a machine
readable format. I.e. you'll see function names, with their types, line
number, comment, etc. Essentially what intellisense would pop up.
Post by Ellery Newcomer
standardized? DMD derivatives will have it, what about hypothetical
other D implementations?
It would be part of the dmd front end, so all D compilers based on it
would have it.
Post by Ellery Newcomer
If your ide can't see or doesn't have compiler, it won't be able to do
much (erm duh)
Yeah, but without a compiler why edit D source? <g>
Post by Ellery Newcomer
All in all, I think it would be the bomb. I'd even volunteer to help
implementing it if I thought my code contributions would do less harm
than good.
I don't think it would be hard to implement.

But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.

BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
Ellery Newcomer
2009-10-11 04:52:33 UTC
Permalink
Post by Walter Bright
Post by Ellery Newcomer
Well, that's a better solution than reimplementing semantic analysis in
the ide. If you make it, I will stop trying to do the latter.
I made it to the symbol table ..
Post by Walter Bright
Post by Ellery Newcomer
In the xml, will we see ct stuff and other transformations that DMD
performs on the source expanded?
ct stuff? What is that? Won't see dmd operations on the source expanded.
What you'll see is basically what ddoc generates, but in a machine
readable format. I.e. you'll see function names, with their types, line
number, comment, etc. Essentially what intellisense would pop up.
ctfe. compile time (weird connection?). what do string mixins evaluate
to? can I look at their result from the ide? what do templates expand
to? what does this here alias/typedef represent? what does this here
typeof expand to? what does this here c-style type normalize to (in
d-style)?

As for other transformations, it seemed like Ary had some neat tricks in
descent that showed things like int i; going to int i = 0; etc. maybe
wistful thinking.

while we're at it,

when I see a symbol, can I find its type? can I find every symbol that
would follow it in a dot list/exp?
when I see a symbol, can I find everywhere it's used?
when I see a scope, can I see every symbol that's in it?
when I see a module, can I find everywhere it's imported?
can I see exactly what symbols are pulled in? Can I perform analysis to
show me where those dang cyclic dependencies are?
when I see source code, can I perform a simple walk over the xml to
format it?
Post by Walter Bright
It would be part of the dmd front end, so all D compilers based on it
would have it.
How about the Intel D compiler? (It's going to happen. You know it will)
Post by Walter Bright
Yeah, but without a compiler why edit D source? <g>
Weird users is the best answer I can offer. It happens.

Also, coming from the java IDEs, I'm feeling apprehensive about
integration on disparate platforms and whatnot. There's multiple ways
the compiler could not be there.
Post by Walter Bright
Post by Ellery Newcomer
All in all, I think it would be the bomb. I'd even volunteer to help
implementing it if I thought my code contributions would do less harm
than good.
I don't think it would be hard to implement.
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
<g> sorry. my target is netbeans.

Although I could probably whip up something quick in ANTLR if I really
needed JSON in D.
Walter Bright
2009-10-11 05:19:08 UTC
Permalink
Post by Ellery Newcomer
ctfe. compile time (weird connection?). what do string mixins evaluate
to?
No
Post by Ellery Newcomer
can I look at their result from the ide?
No
Post by Ellery Newcomer
what do templates expand
to?
No
Post by Ellery Newcomer
what does this here alias/typedef represent?
Yes
Post by Ellery Newcomer
what does this here
typeof expand to?
No
Post by Ellery Newcomer
what does this here c-style type normalize to (in
d-style)?
No
Post by Ellery Newcomer
As for other transformations, it seemed like Ary had some neat tricks in
descent that showed things like int i; going to int i = 0; etc. maybe
wistful thinking.
while we're at it,
when I see a symbol, can I find its type?
Yes
Post by Ellery Newcomer
can I find every symbol that
would follow it in a dot list/exp?
Yes
Post by Ellery Newcomer
when I see a symbol, can I find everywhere it's used?
No, but could be added
Post by Ellery Newcomer
when I see a scope, can I see every symbol that's in it?
Yes
Post by Ellery Newcomer
when I see a module, can I find everywhere it's imported?
Yes
Post by Ellery Newcomer
can I see exactly what symbols are pulled in?
No, but could be added
Post by Ellery Newcomer
Can I perform analysis to
show me where those dang cyclic dependencies are?
Don't know
Post by Ellery Newcomer
when I see source code, can I perform a simple walk over the xml to
format it?
No


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.
Lutger
2009-10-11 09:01:46 UTC
Permalink
Walter Bright wrote:

...
Post by Walter Bright
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?
Walter Bright
2009-10-11 09:38:37 UTC
Permalink
Post by Lutger
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.
Nick Sabalausky
2009-10-11 10:33:17 UTC
Permalink
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
Post by Walter Bright
Post by Lutger
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."
Andrei Alexandrescu
2009-10-11 13:59:50 UTC
Permalink
Post by Nick Sabalausky
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
Post by Walter Bright
Post by Lutger
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."
And what should the tab size be? >:o)

Andrei
Christopher Wright
2009-10-11 16:15:10 UTC
Permalink
Post by Andrei Alexandrescu
Post by Nick Sabalausky
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
Post by Walter Bright
Post by Lutger
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."
And what should the tab size be? >:o)
Let's see, how many characters are in a tab character?
Nick Sabalausky
2009-10-11 20:44:50 UTC
Permalink
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
Post by Andrei Alexandrescu
Post by Nick Sabalausky
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
Post by Walter Bright
Post by Lutger
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."
And what should the tab size be? >:o)
No need to worry about that. It should just be counted as one character.
Granted, that does mean it wouldn't really be "column" in a strict sense,
but it would be very useful.
Leandro Lucarella
2009-10-11 19:15:27 UTC
Permalink
Post by Walter Bright
Post by Lutger
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!
Walter Bright
2009-10-11 21:13:13 UTC
Permalink
Post by Leandro Lucarella
Post by Walter Bright
Post by Lutger
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.
http://clang.llvm.org/diagnostics.html
That's *nice* =)
I agree, it looks good on paper.

In fact, I implemented it in the C and C++ compiler from the beginning
(1982 or so). It's still in dmc, try it - it'll print out the error
message, followed by the source text of the offending line, followed by
a ^ under where things went wrong.

Nobody cared.

Nobody has ever commented on it - and there have been hundreds of
thousands of users of it. No magazine review ever mentioned it. When I
mention it to people as "cool, look at this" they never respond. When
the conversation is about the quality of error messages, that feature
never comes up.

So I dropped it for dmd.

Nobody noticed.

Nobody asked why it was done for dmc, and not for dmd. Nobody asked for
it. Nothing. (Until now.)

So I am hard pressed to believe this is a worthwhile feature. There is a
cost to it in memory consumption and compiler execution time, so it's
not quite free.
Leandro Lucarella
2009-10-11 23:00:04 UTC
Permalink
Post by Walter Bright
Post by Leandro Lucarella
Post by Walter Bright
Post by Lutger
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.
http://clang.llvm.org/diagnostics.html
That's *nice* =)
I agree, it looks good on paper.
In fact, I implemented it in the C and C++ compiler from the
beginning (1982 or so). It's still in dmc, try it - it'll print out
the error message, followed by the source text of the offending
line, followed by a ^ under where things went wrong.
Nobody cared.
Nobody has ever commented on it - and there have been hundreds of
thousands of users of it. No magazine review ever mentioned it. When
I mention it to people as "cool, look at this" they never respond.
When the conversation is about the quality of error messages, that
feature never comes up.
So I dropped it for dmd.
Nobody noticed.
Nobody asked why it was done for dmc, and not for dmd. Nobody asked
for it. Nothing. (Until now.)
So I am hard pressed to believe this is a worthwhile feature. There
is a cost to it in memory consumption and compiler execution time,
so it's not quite free.
Well, I don't know the reasons for that. Maybe bad timing? I don't know
why people didn't like it in the past. I just know it's a damn good
feature.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
So you run and you run to catch up with the sun but it's sinking.
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
&quot;Jérôme M. Berger&quot;
2009-10-11 09:18:48 UTC
Permalink
Post by Walter Bright
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 at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20091011/e9c4a894/attachment.pgp>
Walter Bright
2009-10-11 09:39:18 UTC
Permalink
Post by &quot;Jérôme M. Berger&quot;
Post by Walter Bright
. 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.
Nick Sabalausky
2009-10-11 10:35:42 UTC
Permalink
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
Post by Walter Bright
Post by &quot;Jérôme M. Berger&quot;
Post by Walter Bright
. 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"
&quot;Jérôme M. Berger&quot;
2009-10-11 15:38:10 UTC
Permalink
Post by Walter Bright
Post by &quot;Jérôme M. Berger&quot;
Post by Walter Bright
. 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.
The point would be for smart autocompletion: type the beginning of
a variable name, hit the autocomplete key and the IDE offers you a
choice of the names available at that point, i.e:
- Global symbols (including imported ones);
- Class members if the function is a method;
- Local variables.

It's also useful for member completion: type "foo." and the IDE
offers you a list of members for foo. This requires knowing its
class even if it is a local...

Jerome
--
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20091011/90566154/attachment.pgp>
Ellery Newcomer
2009-10-11 14:33:06 UTC
Permalink
There are several core features that I absolutely must have (because I
want them):

1. autocompletion. everywhere. for everything. including local
variables. And that's not just the *pop* this symbol is a <type> that
does <ddoc>. It includes the completion part. When I type foreach
Ctrl+Space, I get a generic foreach statement (which is consistent with
the current compiler's syntax).

2. usage finding. I'm at a symbol. I want to know everywhere it's used.
If it's a class, I want to know everywhere it's subclassed.

3. code formatting.

4. build system

5. syntax highlight and code folding (easy peasy, but necessary)

6. error reporting aka dem shquiggly red lines

7. import resolution.

On top of these are a bunch of peripheral features:
When you have 1, code navigation should come pretty easy.
When you have 2, renaming any variable should come pretty easy.

When I have problems with those dang cyclic dependencies, I might want
to be able to merge two modules together.

etc


What I wanted out of my semantic analysis was a complete syntax tree and
symbol table that could make all of these things possible. If I can get
this direct from the compiler, it would obviously save me several years
of work and "yeah, this doesn't even try to be compatible" problems.
Post by Walter Bright
Post by Ellery Newcomer
ctfe. compile time (weird connection?). what do string mixins evaluate
to?
No
Post by Ellery Newcomer
can I look at their result from the ide?
No
Well I want this feature.
Post by Walter Bright
Post by Ellery Newcomer
what do templates expand
to?
No
Post by Ellery Newcomer
what does this here alias/typedef represent?
Yes
Good.
Post by Walter Bright
Post by Ellery Newcomer
what does this here
typeof expand to?
No
Post by Ellery Newcomer
what does this here c-style type normalize to (in
d-style)?
No
Well I want this feature.
Post by Walter Bright
Post by Ellery Newcomer
As for other transformations, it seemed like Ary had some neat tricks in
descent that showed things like int i; going to int i = 0; etc. maybe
wistful thinking.
while we're at it,
when I see a symbol, can I find its type?
Yes
Good.
Post by Walter Bright
Post by Ellery Newcomer
can I find every symbol that
would follow it in a dot list/exp?
Yes
Good.
Post by Walter Bright
Post by Ellery Newcomer
when I see a symbol, can I find everywhere it's used?
No, but could be added
Good.
Post by Walter Bright
Post by Ellery Newcomer
when I see a scope, can I see every symbol that's in it?
Yes
Good.
Post by Walter Bright
Post by Ellery Newcomer
when I see a module, can I find everywhere it's imported?
Yes
Good.
Post by Walter Bright
Post by Ellery Newcomer
can I see exactly what symbols are pulled in?
No, but could be added
Good.
Post by Walter Bright
Post by Ellery Newcomer
Can I perform analysis to
show me where those dang cyclic dependencies are?
Don't know
If I have the previous two I think I can do it. I might need a view of
the code after compile time expansions. Oh, and I'd obviously need to
see which modules have static ctors/dtors.
Post by Walter Bright
Post by Ellery Newcomer
when I see source code, can I perform a simple walk over the xml to
format it?
No
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.
Yep, we're thinking of different things.
Post by Walter Bright
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.
Jeremie Pelletier
2009-10-11 05:42:38 UTC
Permalink
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
The official JSON website has tons of bindings, here's the C one:

http://fara.cs.uni-potsdam.de/~jsg/json_parser/

I'm gonna try and get it converted to D over the weekend.
Walter Bright
2009-10-11 06:07:50 UTC
Permalink
Post by Jeremie Pelletier
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
It has a test suite with it!
Christopher Wright
2009-10-11 13:04:50 UTC
Permalink
Post by Jeremie Pelletier
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
Tango already has a good JSON parser, but I imagine its license (BSD)
doesn't meet Walter's requirements.
Moritz Warning
2009-10-11 21:25:57 UTC
Permalink
Post by Christopher Wright
Post by Jeremie Pelletier
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
Tango already has a good JSON parser, but I imagine its license (BSD)
doesn't meet Walter's requirements.
I wrote a JSON parser that is Public Domain and also very fast.
It may be helpful.
http://dsource.org/projects/tango/ticket/1491

There are also a few others around.
Moritz Warning
2009-10-11 21:32:56 UTC
Permalink
Post by Christopher Wright
Post by Jeremie Pelletier
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
Tango already has a good JSON parser, but I imagine its license (BSD)
doesn't meet Walter's requirements.
I wrote a JSON parser that is Public Domain and also very fast. It may
be helpful.
http://dsource.org/projects/tango/ticket/1491
There are also a few others around.
Uh, it says BSD. But I'm fine with PB.
Walter Bright
2009-10-11 21:58:06 UTC
Permalink
Post by Moritz Warning
I wrote a JSON parser that is Public Domain and also very fast.
It may be helpful.
http://dsource.org/projects/tango/ticket/1491
You need to get this added to the list at http://json.org/
Moritz Warning
2009-10-11 22:16:44 UTC
Permalink
Post by Walter Bright
I wrote a JSON parser that is Public Domain and also very fast. It may
be helpful.
http://dsource.org/projects/tango/ticket/1491
You need to get this added to the list at http://json.org/
It would need to write a replacement for the un-/escape routines from
Tango first.
But so far it sounds like a good idea.
Jeremie Pelletier
2009-10-11 23:25:53 UTC
Permalink
Post by Jeremie Pelletier
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
After some digging into the C sources, I decided I didn't like the way
they did it. I wanted the simplicity and elegance of JSON I use with
jQuery ($.toJSON and $.parseJSON). I looked again at the simple graphs
on json.org and decided it was simple enough to write a D parser from
scratch, here's what I have after a few hours of work, both methods
works, although I didn't thoroughly tested them yet.

http://pastebin.com/f25b67726

Let me know what you think and feel free to add it to phobos if you like
it :)

Jeremie
Walter Bright
2009-10-12 00:49:10 UTC
Permalink
Post by Jeremie Pelletier
Post by Jeremie Pelletier
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not incorporate
dmdscript into your IDE as its extension language?
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
After some digging into the C sources, I decided I didn't like the way
they did it. I wanted the simplicity and elegance of JSON I use with
jQuery ($.toJSON and $.parseJSON). I looked again at the simple graphs
on json.org and decided it was simple enough to write a D parser from
scratch, here's what I have after a few hours of work, both methods
works, although I didn't thoroughly tested them yet.
http://pastebin.com/f25b67726
Let me know what you think and feel free to add it to phobos if you like
it :)
Jeremie
Looks nice! But it needs to be ported to Phobos, and needs unit tests!
Jeremie Pelletier
2009-10-12 02:47:27 UTC
Permalink
Post by Walter Bright
Post by Jeremie Pelletier
Post by Jeremie Pelletier
Post by Walter Bright
But if you want to contribute, how about a JSON parser for phobos?
You'll need one anyway for your IDE.
BTW, JSON parsing comes for free with javascript. Why not
incorporate dmdscript into your IDE as its extension language?
http://fara.cs.uni-potsdam.de/~jsg/json_parser/
I'm gonna try and get it converted to D over the weekend.
After some digging into the C sources, I decided I didn't like the way
they did it. I wanted the simplicity and elegance of JSON I use with
jQuery ($.toJSON and $.parseJSON). I looked again at the simple graphs
on json.org and decided it was simple enough to write a D parser from
scratch, here's what I have after a few hours of work, both methods
works, although I didn't thoroughly tested them yet.
http://pastebin.com/f25b67726
Let me know what you think and feel free to add it to phobos if you
like it :)
Jeremie
Looks nice! But it needs to be ported to Phobos, and needs unit tests!
Here you go: http://pastebin.com/f64b75abb

Compiled on dmd 2.033 against phobos with a unittest and it works great :)

I also needed to port my unicode character handling module to phobos
because the one currently used doesn't have a isUniControl() method:

http://pastebin.com/fe47f274

Jeremie
Jordan Miner
2009-10-11 04:30:03 UTC
Permalink
Post by Walter Bright
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?
This is a great idea. If I every work on an IDE, I would use this. (I don't use IDEs. I like them, but I haven't found one that keeps out of my way enough.)

And this output isn't just useful for IDEs. Once I get time a couple months from now, I am going to finish a program that generates much better documentation files than Ddoc. So far, I have Ddoc generate custom output that I parse, but it still isn't very machine readable. Instead, I would use this provided it has all the information that Ddoc generates.
bearophile
2009-10-11 04:45:39 UTC
Permalink
Post by Walter Bright
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.
An IDE is designed to not just let you explore and understand already written code, but to modify the code too. So such data changes as the programmer writes the code. So it may be positive for the IDE to have ways to query DMD and receive a smaller, faster and more focused amount of data regarding something. Otherwise generating all the data every few moments may slow down things.

Eventually a good thing is to go the route chosen by LLVM, splitting the compiler in parts, so the IDE can use some of those parts in a mode direct way.
Even LDC, that's based on LLVM, follows the monolithic design of GCC and DMD, but I am certain that today a loosely coupled design similar to LLVM is better.

Bye,
bearophile
Walter Bright
2009-10-11 05:07:57 UTC
Permalink
Post by bearophile
An IDE is designed to not just let you explore and understand already
written code, but to modify the code too. So such data changes as the
programmer writes the code. So it may be positive for the IDE to have
ways to query DMD and receive a smaller, faster and more focused
amount of data regarding something. Otherwise generating all the data
every few moments may slow down things.
I know this won't help for syntax highlighting or working within a
source file that may only be partially parsable. But for an easy way to
do autocompletion and throwing up 'tooltip' documentation on library
functions, etc., it should be very powerful.

Generating the data on imports should be very fast, and should not be
necessary every few moments (only when those imported source files change).
Post by bearophile
Eventually a good thing is to go the route chosen by LLVM, splitting
the compiler in parts, so the IDE can use some of those parts in a
mode direct way. Even LDC, that's based on LLVM, follows the
monolithic design of GCC and DMD, but I am certain that today a
loosely coupled design similar to LLVM is better.
That's far more complex. I'm looking for ways to cover 90% of the
territory with some simple, straightforward means.
tomqyp
2009-10-11 07:47:17 UTC
Permalink
Post by Walter Bright
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?
See here
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=93086
dolive
2009-10-11 08:04:47 UTC
Permalink
Post by Walter Bright
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?
Hope is that one be able to parse all the relevant d libraries, and dynamically generated xml file, rather than merely dmd parse to an xml file.

bye
dolive
Robert Clipsham
2009-10-11 09:49:10 UTC
Permalink
Post by Walter Bright
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!
Jeremie Pelletier
2009-10-11 16:23:55 UTC
Permalink
Post by Robert Clipsham
Post by Walter Bright
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.
Walter Bright
2009-10-11 18:40:56 UTC
Permalink
Post by Robert Clipsham
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.
Frank Benoit
2009-10-11 09:56:17 UTC
Permalink
Post by Walter Bright
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.
Jacob Carlborg
2009-10-11 10:43:26 UTC
Permalink
Post by Frank Benoit
Post by Walter Bright
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?
- 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.
Jeremie Pelletier
2009-10-11 16:28:00 UTC
Permalink
Post by Jacob Carlborg
Post by Frank Benoit
Post by Walter Bright
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?
- 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.
Walter Bright
2009-10-11 18:45:55 UTC
Permalink
Post by Frank Benoit
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.
language_fan
2009-10-11 10:48:30 UTC
Permalink
Post by Walter Bright
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?
Lutger
2009-10-11 11:19:20 UTC
Permalink
Post by language_fan
Post by Walter Bright
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?
Because people do see the use of other IDEs (counting vim here too as an
IDE) and xml / json output is useful for more than just IDEs.
Jeremie Pelletier
2009-10-11 16:44:08 UTC
Permalink
Post by language_fan
Post by Walter Bright
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.
Nick Sabalausky
2009-10-11 21:01:03 UTC
Permalink
"language_fan" <foo at bar.com.invalid> wrote in message
Post by language_fan
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?
Any editor that is less responsive than notepad is useless to me, and I'm
far from alone on that. Thus, we don't go anywhere near Eclipse, VS.NET, or
anything along those lines (bunch of bloated garbage...and probably designed
to get developers to buy fancier hardware and thus end up develop apps that
require their users to buy fancier hardware).
Christopher Wright
2009-10-11 13:05:39 UTC
Permalink
Post by Walter Bright
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?
The huge things are:
- code navigation (go to definition / find usages)
- reformatting
- refactoring
- autocompletion

Code navigation alone is a huge help, and with reliable autocompletion
would be sufficient for me to switch from vim. What you are suggesting
would make both of those easier, though the IDE might need to duplicate
D's symbol lookup.

I'm not sure whether what you are talking about will help at all with
reformatting or refactoring, and I really have no idea what would be
required for this.
Ary Borenszweig
2009-10-11 13:23:40 UTC
Permalink
Post by Walter Bright
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:



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. :-)
Yigal Chripun
2009-10-11 18:58:46 UTC
Permalink
Post by Ary Borenszweig
Post by Walter Bright
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
http://youtu.be/KQbTT605ags
---
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?
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
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
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?
Jacob Carlborg
2009-10-11 20:42:59 UTC
Permalink
Post by Yigal Chripun
Post by Ary Borenszweig
Post by Walter Bright
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
http://youtu.be/KQbTT605ags
---
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?
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
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
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?
Frank Benoit (who started DWT, the tango version) was think about this.
Quite a big part is already ported, SWT, JFace, Forms, OSGI and so on,
see: http://hg.dsource.org/projects/dwt2/file/88652073d1c2/ .

I think one of the biggest challenge to port is class loading, dynamic
libraries could work for this but we all know how well they work on windows.
Jacob Carlborg
2009-10-11 20:26:51 UTC
Permalink
Post by Ary Borenszweig
Post by Walter Bright
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
http://youtu.be/KQbTT605ags
---
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?
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
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.
I use it almost at a daily base and it works great. I can't remember the
last time it cashed.
Post by Ary Borenszweig
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
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. :-)
Ary Borenszweig
2009-10-11 21:18:00 UTC
Permalink
Post by Jacob Carlborg
Post by Ary Borenszweig
Post by Walter Bright
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?
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.
I use it almost at a daily base and it works great. I can't remember the
last time it cashed.
Wow, that's good news! :)
Denis Koroskin
2009-10-11 14:32:32 UTC
Permalink
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
Post by Walter Bright
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?
I believe it won't work. It will always be slow and incomplete.

Instead, I would make it easier to embed DMD into an IDE: separate DMDFE
from DMDBE, fix memory leaks, remove all the static data (so that code
would be re-intrable and it could work in different threads in parallel),
move most of DMD code into a DLL so that an IDE could dynamically link
with it and whatever it pleases with the source code.

In fact, that's what I do right now.

I'm writing my own D IDE in my spare time (in D, of course). I already
made a lot of progress and now it's time to start implementing source code
analysis.

First thing I did is I made complete D bindings for C++ code. It worked
out quite well but it was leaking so badly that I dropped it.

Instead, I started porting DMD entirely to D (except the backend, of
course), and I already got some great results. A few simple programs
compile and produce byte-perfect binaries. It's still in its early stages
and there is a lot of work to do, but it will be finished soon
(hopefully). It could probably become a part of an official distribution,
eventually. :)

If anyone is interested and is willing to test and/or help, I will gladly
share my code.
Ellery Newcomer
2009-10-11 14:39:32 UTC
Permalink
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
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.
Andrei Alexandrescu
2009-10-11 15:10:42 UTC
Permalink
Post by Ellery Newcomer
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
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
Denis Koroskin
2009-10-11 15:43:27 UTC
Permalink
On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Ellery Newcomer
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
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 :)
BLS
2009-10-11 16:03:16 UTC
Permalink
Post by Denis Koroskin
On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Ellery Newcomer
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
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 ?
Denis Koroskin
2009-10-11 16:29:22 UTC
Permalink
Post by BLS
Post by Denis Koroskin
On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Ellery Newcomer
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
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...
Yigal Chripun
2009-10-11 18:50:46 UTC
Permalink
Post by Denis Koroskin
Post by BLS
Post by Denis Koroskin
On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Ellery Newcomer
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
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?
digited
2009-10-11 17:32:49 UTC
Permalink
Post by 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.
Eldar Insafutdinov
2009-10-11 18:59:44 UTC
Permalink
Post by digited
Post by 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.
Walter Bright
2009-10-11 18:39:16 UTC
Permalink
Post by Denis Koroskin
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).
Ary Borenszweig
2009-10-11 19:08:24 UTC
Permalink
Post by Walter Bright
Post by Denis Koroskin
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. :)
Walter Bright
2009-10-11 19:38:51 UTC
Permalink
Post by Ary Borenszweig
Post by Walter Bright
Post by Denis Koroskin
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.
Jacob Carlborg
2009-10-11 20:37:21 UTC
Permalink
Post by Walter Bright
Post by Ary Borenszweig
Post by Walter Bright
Post by Denis Koroskin
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.
I think descent is really good now.
Post by Walter Bright
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.
Nick Sabalausky
2009-10-11 21:15:57 UTC
Permalink
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
Post by Walter Bright
Post by Ary Borenszweig
Post by Walter Bright
Post by Denis Koroskin
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.
It's a good point, but, if I'm reading this group right, it sounds like it
might not be quite as useful as you're expecting it would be.
Walter Bright
2009-10-11 21:58:43 UTC
Permalink
Post by Nick Sabalausky
It's a good point, but, if I'm reading this group right, it sounds like it
might not be quite as useful as you're expecting it would be.
Yes, I can see that.
Jacob Carlborg
2009-10-11 20:27:29 UTC
Permalink
Post by Denis Koroskin
On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
Post by Walter Bright
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?
I believe it won't work. It will always be slow and incomplete.
Instead, I would make it easier to embed DMD into an IDE: separate DMDFE
from DMDBE, fix memory leaks, remove all the static data (so that code
would be re-intrable and it could work in different threads in
parallel), move most of DMD code into a DLL so that an IDE could
dynamically link with it and whatever it pleases with the source code.
In fact, that's what I do right now.
I'm writing my own D IDE in my spare time (in D, of course). I already
made a lot of progress and now it's time to start implementing source
code analysis.
First thing I did is I made complete D bindings for C++ code. It worked
out quite well but it was leaking so badly that I dropped it.
Instead, I started porting DMD entirely to D (except the backend, of
course), and I already got some great results. A few simple programs
compile and produce byte-perfect binaries. It's still in its early
stages and there is a lot of work to do, but it will be finished soon
(hopefully). It could probably become a part of an official
distribution, eventually. :)
If anyone is interested and is willing to test and/or help, I will
gladly share my code.
Sounds interesting, put it online somewhere.
BLS
2009-10-11 14:38:01 UTC
Permalink
Post by Walter Bright
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?
FANTASTIC! Give it a go.

Despite the intention to support a D IDE ...
I would make sense to establish this feature in D1 too.
Imagine XML2D which may help to port D1 code to D2.

I would further suggest to consider to output to Oracle Berkeley DB XML ..
Having an XQuery-based access to D-sources.. I guess you can imagine
what this could mean.

There are a couple of D IDEs around.
I think what people mean with there is no D IDE is simply : "We want a
MS Visual Studio like IDE as part of the D tool chain" One download,
that's it.
I agree. But we need a platform independent IDE.

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
Lutger
2009-10-11 14:54:56 UTC
Permalink
BLS wrote:

...
Post by BLS
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?
BLS
2009-10-11 15:49:52 UTC
Permalink
Post by Lutger
...
Post by BLS
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) Further QtD has no OSX support (AFAIK)

I still hope that Walter has an eye on the QtD situation..
Max Samukha
2009-10-11 16:54:11 UTC
Permalink
Post by BLS
Post by Lutger
...
Post by BLS
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.
Post by BLS
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)
Jacob Carlborg
2009-10-11 20:36:01 UTC
Permalink
Post by BLS
Post by Walter Bright
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?
FANTASTIC! Give it a go.
Despite the intention to support a D IDE ...
I would make sense to establish this feature in D1 too.
Imagine XML2D which may help to port D1 code to D2.
I would further suggest to consider to output to Oracle Berkeley DB XML ..
Having an XQuery-based access to D-sources.. I guess you can imagine
what this could mean.
There are a couple of D IDEs around.
I think what people mean with there is no D IDE is simply : "We want a
MS Visual Studio like IDE as part of the D tool chain" One download,
that's it.
I agree. But we need a platform independent IDE.
1) Force Decent.. (Java/SWT)
I think this the our best option now
Post by BLS
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.
As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on mac.

4)
Port entire eclipse to D, Frank Benoit (who started DWT, the tango
version) was thinking of this.
Post by BLS
Bjoern
Denis Koroskin
2009-10-11 20:37:28 UTC
Permalink
Post by Jacob Carlborg
4)
Port entire eclipse to D, Frank Benoit (who started DWT, the tango
version) was thinking of this.
Post by BLS
Bjoern
What's the benefit? I believe it'll become even slower. Much slower.
Jacob Carlborg
2009-10-11 20:45:28 UTC
Permalink
Post by Denis Koroskin
Post by Jacob Carlborg
4)
Port entire eclipse to D, Frank Benoit (who started DWT, the tango
version) was thinking of this.
Post by BLS
Bjoern
What's the benefit? I believe it'll become even slower. Much slower.
Maybe we could try to slim it down, remove things that aren't needed.
Lutger
2009-10-11 21:25:00 UTC
Permalink
Jacob Carlborg wrote:
...
Post by Jacob Carlborg
As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on mac.
Qt used to try and look like native controls, but now it uses them directly.
Jeremie Pelletier
2009-10-12 00:08:51 UTC
Permalink
Post by Lutger
...
Post by Jacob Carlborg
As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on mac.
Qt used to try and look like native controls, but now it uses them directly.
It has pros and cons, Firefox too has the native look and feel without
using the native controls, so it saves on the overhead of tons of GDI
handles and can render the entire GUI in cairo.
Chad J
2009-10-12 02:14:46 UTC
Permalink
Post by Jeremie Pelletier
Post by Lutger
...
Post by Jacob Carlborg
As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on mac.
Qt used to try and look like native controls, but now it uses them directly.
It has pros and cons, Firefox too has the native look and feel without
using the native controls, so it saves on the overhead of tons of GDI
handles and can render the entire GUI in cairo.
I actually rather dislike GTK from a user standpoint. It doesn't mesh
well at all on my KDE linux setup. The file dialog is also a frequent
source of annoyance, as it is different then everything else and seems
to want to fight with me. Qt is much better at these things.

Too bad we can't just make programs switch between GUI backends at will ;)
Jeremie Pelletier
2009-10-12 02:25:32 UTC
Permalink
Post by Chad J
Post by Jeremie Pelletier
Post by Lutger
...
Post by Jacob Carlborg
As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on mac.
Qt used to try and look like native controls, but now it uses them directly.
It has pros and cons, Firefox too has the native look and feel without
using the native controls, so it saves on the overhead of tons of GDI
handles and can render the entire GUI in cairo.
I actually rather dislike GTK from a user standpoint. It doesn't mesh
well at all on my KDE linux setup. The file dialog is also a frequent
source of annoyance, as it is different then everything else and seems
to want to fight with me. Qt is much better at these things.
Too bad we can't just make programs switch between GUI backends at will ;)
I use gnome myself on Ubuntu, I don't really like KDE :)

We can make programs that switch between GUI backends, most just don't
go in that direction. Its as easy as graphics engines having GL and DX
backends for their render system.

I agree however that GTK being in C is rather annoying, C is a great
language but GUIs is one area where OOP really shines.
Chad J
2009-10-12 02:54:39 UTC
Permalink
Post by Jeremie Pelletier
Post by Chad J
I actually rather dislike GTK from a user standpoint. It doesn't mesh
well at all on my KDE linux setup. The file dialog is also a frequent
source of annoyance, as it is different then everything else and seems
to want to fight with me. Qt is much better at these things.
Too bad we can't just make programs switch between GUI backends at will ;)
I use gnome myself on Ubuntu, I don't really like KDE :)
Right. Personal preferences make it unlikely for people to realize the
shortcomings of a library on systems that aren't their own. Thus my
purpose isn't to start a silly Desktop Environment debate, but to point
out hidden deficiencies in software.

If Qt has deficiencies on Gnome or Windows or Mac OS or some other
system I don't use regularly, it'd be swell to have that in the open so
I know what to look for when developing my GUI apps.

I'm actually curious about some of the less prominent ones like
wxWidgets and FLTK in this regard.
Post by Jeremie Pelletier
We can make programs that switch between GUI backends, most just don't
go in that direction. Its as easy as graphics engines having GL and DX
backends for their render system.
It was sort-of a joke. A cross platform gui library is, in principle,
supposed to be the final abstraction. Once you target a gui lib, that
should be it, you are done and it works on every system in an intuitive
way. Too bad life isn't perfect. So now we talk of things like a
cross-gui-library gui library. An abstraction of abstractions. That
such a thing is potentially useful is, in and of itself, quite
unfortunate and slightly comical :(
Post by Jeremie Pelletier
I agree however that GTK being in C is rather annoying, C is a great
language but GUIs is one area where OOP really shines.
True words.

(dunno about immediate mode though... but that's another discussion)

C makes for easier bindings at least ;)
Nick Sabalausky
2009-10-12 04:22:25 UTC
Permalink
Jeremie Pelletier" <jeremiep at gmail.com> wrote in message
Post by Jeremie Pelletier
Post by Lutger
...
Post by Jacob Carlborg
As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on mac.
Qt used to try and look like native controls, but now it uses them directly.
It has pros and cons, Firefox too has the native look and feel without
using the native controls, so it saves on the overhead of tons of GDI
handles and can render the entire GUI in cairo.
I use FF a lot and umm...no it doesn't. Not remotely. It's always stood out
as every bit of a blatant GTK app as GAIM, GIMP, or Thunderbird. As soon as
I can find a browser with equivilents too all my essential hacks (*cough*
extensions) and *real* controls (which rules out IE and Opera. And
Chrome/Safari... AH HA HA HA!), then I'm ditching this garbage.

Jason House
2009-10-11 16:24:00 UTC
Permalink
Post by Walter Bright
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...
Leandro Lucarella
2009-10-11 19:07:44 UTC
Permalink
Post by Walter Bright
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)
Walter Bright
2009-10-11 19:40:41 UTC
Permalink
Post by Leandro Lucarella
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).
I've heard this from D fans as well, who are unable to get D adopted at
work because of the lack of IDE.
Leandro Lucarella
2009-10-11 19:46:53 UTC
Permalink
Post by Walter Bright
Post by Leandro Lucarella
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).
I've heard this from D fans as well, who are unable to get D adopted
at work because of the lack of IDE.
I can't because of the other issues =(

(we don't use an "IDE" at my work, not at least if you don't consider VIM
an IDE =)
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
So?? que tenia un caballo
Que me trataba mejor que vos
Tenia tan buena onda con ella
Era mi yegua, mucho mas que vos
Continue reading on narkive:
Loading...