Walter Bright <newshound1 digitalmars.com> writes:

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 <digited yandex.ru> writes:

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 <lutger.blijdestijn gmail.com> writes:

digited wrote:

 Walter Bright �����:
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial.

 
 Why file? An IDE can call compiler process and get output with info from
 stdout, that will be much faster, and if IDE will need to store the info,
 it will, or will not, itself.

Yes please make it write to stdout!

This is a very good plan and useful not only for IDE's, but also for example 
to automate bindings to scriptings languages.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lutger wrote:
 digited wrote:
 
 Walter Bright �����:
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial.

 Why file? An IDE can call compiler process and get output with info from
 stdout, that will be much faster, and if IDE will need to store the info,
 it will, or will not, itself.

 
 Yes please make it write to stdout!

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 <llucax gmail.com> writes:

digited, el 10 de octubre a las 22:19 me escribiste:
 Walter Bright ?????:
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial.

 
 Why file? An IDE can call compiler process and get output with info from
 stdout, that will be much faster, and if IDE will need to store the
 info, it will, or will not, itself.

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

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
For a minute there
I lost myself, I lost myself.
Phew, for a minute there,
I lost myself, I lost myself.

Jeremie Pelletier <jeremiep gmail.com> writes:

Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier 
 that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are 
 overbalanced by the loss of productivity by moving away from an IDE. And 
 what is it about an IDE that is so productive? Intellisense (Microsoft's 
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can 
 help. dmd already puts out .doc and .di files. How about putting out an 
 xml file giving all the information needed for an IDE to implement 
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse, 
 xml is trivial. Furthermore, an xml format would be fairly robust in the 
 face of changes to D syntax.
 
 What do you think?

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 <newshound1 digitalmars.com> writes:

Jeremie Pelletier wrote:
 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.

 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.


 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.

 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 <bearophileHUGS lycos.com> writes:

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

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

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.


code, it's named:
#region

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 <jeremiep gmail.com> writes:

Walter Bright wrote:
 Jeremie Pelletier wrote:
 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.

 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.
 
 
 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.
 
 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 <newshound1 digitalmars.com> writes:

Jeremie Pelletier wrote:
 The IDE usually keeps the files in memory and could therefore just call 
 something like getSemantics(char** fileBuffers, int* fileSizes, int 
 nFiles, ParseNode* parseTree) and have its parse nodes already allocated 
 in process memory ready for use.
 
 Considering a lot of IDEs like to re-parse the current file every time 
 the keyboard is idle for a few seconds, this could really help 
 performance, nothing is more annoying than an IDE that feels unresponsive.

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 <newshound1 digitalmars.com> writes:

Walter Bright wrote:
 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 <bearophileHUGS lycos.com> writes:

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

=?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:

Walter Bright wrote:
 Jeremie Pelletier wrote:
 The IDE usually keeps the files in memory and could therefore just=20
 call something like getSemantics(char** fileBuffers, int* fileSizes,=20
 int nFiles, ParseNode* parseTree) and have its parse nodes already=20
 allocated in process memory ready for use.

 Considering a lot of IDEs like to re-parse the current file every time=


=20
 the keyboard is idle for a few seconds, this could really help=20
 performance, nothing is more annoying than an IDE that feels=20
 unresponsive.

=20
 ...

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

e=20
 latter puts everything in one process space, where you've got all the=20
 lovely, time-consuming, hair-pulling concurrency problems. The utter=20
 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=20
be GPL-compatible to use your DLL. With fork/exec there are no such=20
constraints...

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

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-10-11 01:57:08 -0400, Walter Bright <newshound1 digitalmars.com> said:

 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.


 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 michelf.com
http://michelf.com/

Walter Bright <newshound1 digitalmars.com> writes:

Michel Fortin wrote:
 It's not clear to me how much getting supplementary data from the 
 compiler could help. If I only get what I can see through Ddoc, it's 
 only half useful. I can already parse and get character ranges for the 
 the high-level constructs (classes, tempaltes, functions, etc.). What 
 will be harder is matching each symbol in function code to the correct 
 definition because that depends on the context of the function and doing 
 autocompletion for what you type depending on what's available in a 
 given context.

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


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

No, but it's a good idea.

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-10-11 14:19:52 -0400, Walter Bright <newshound1 digitalmars.com> said:

 Michel Fortin wrote:
 It's not clear to me how much getting supplementary data from the 
 compiler could help. If I only get what I can see through Ddoc, it's 
 only half useful. I can already parse and get character ranges for the 
 the high-level constructs (classes, tempaltes, functions, etc.). What 
 will be harder is matching each symbol in function code to the correct 
 definition because that depends on the context of the function and 
 doing autocompletion for what you type depending on what's available in 
 a given context.

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

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


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

 
 No, but it's a good idea.

Great.


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

Walter Bright <newshound1 digitalmars.com> writes:

Michel Fortin wrote:
 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 <ellery-newcomer utulsa.edu> writes:

Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.
 
 What do you think?

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 <newshound1 digitalmars.com> writes:

Ellery Newcomer wrote:
 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.

 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.

 [very very minor] concerns:
 
 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.

 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>

 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 <ellery-newcomer utulsa.edu> writes:

Walter Bright wrote:
 Ellery Newcomer wrote:
 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 ..


 
 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?

 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)

 
 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.

 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 <newshound1 digitalmars.com> writes:

Ellery Newcomer wrote:
 ctfe. compile time (weird connection?). what do string mixins evaluate
 to?

No

 can I look at their result from the ide?

No

 what do templates expand
 to?

No

 what does this here alias/typedef represent?

Yes

 what does this here
 typeof expand to?

No

 what does this here c-style type normalize to (in
 d-style)?

No

 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

 can I find every symbol that
 would follow it in a dot list/exp?

Yes

 when I see a symbol, can I find everywhere it's used?

No, but could be added

 when I see a scope, can I see every symbol that's in it?

Yes

 when I see a module, can I find everywhere it's imported?

Yes

 can I see exactly what symbols are pulled in?

No, but could be added

 Can I perform analysis to
 show me where those dang cyclic dependencies are?

Don't know

 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 <lutger.blijdestijn gmail.com> writes:

Walter Bright wrote:

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

What about file/line/column of the symbol? Is this much work / hard work to 
add? 

Walter Bright <newshound1 digitalmars.com> writes:

Lutger wrote:
 What about file/line/column of the symbol? Is this much work / hard work to 
 add? 

file/line of course, but I don't see a point to column.

"Nick Sabalausky" <a a.a> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:has92u$1vum$1 digitalmars.com...
 Lutger wrote:
 What about file/line/column of the symbol? Is this much work / hard work 
 to add?

 file/line of course, but I don't see a point to column.

So the IDE knows where it is and can actually do things with it, instead of 
just knowing "Well, it's somewhere around here-ish." 

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:has92u$1vum$1 digitalmars.com...
 Lutger wrote:
 What about file/line/column of the symbol? Is this much work / hard work 
 to add?

 file/line of course, but I don't see a point to column.

 
 So the IDE knows where it is and can actually do things with it, instead of 
 just knowing "Well, it's somewhere around here-ish." 
 
 

And what should the tab size be? >:o)

Andrei

Christopher Wright <dhasenan gmail.com> writes:

Andrei Alexandrescu wrote:
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:has92u$1vum$1 digitalmars.com...
 Lutger wrote:
 What about file/line/column of the symbol? Is this much work / hard 
 work to add?

 file/line of course, but I don't see a point to column.

 So the IDE knows where it is and can actually do things with it, 
 instead of just knowing "Well, it's somewhere around here-ish."

 
 And what should the tab size be? >:o)

Let's see, how many characters are in a tab character?

"Nick Sabalausky" <a a.a> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hasodv$dgl$3 digitalmars.com...
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:has92u$1vum$1 digitalmars.com...
 Lutger wrote:
 What about file/line/column of the symbol? Is this much work / hard 
 work to add?

 file/line of course, but I don't see a point to column.

 So the IDE knows where it is and can actually do things with it, instead 
 of just knowing "Well, it's somewhere around here-ish."

 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 <llucax gmail.com> writes:

Walter Bright, el 11 de octubre a las 02:38 me escribiste:
 Lutger wrote:
What about file/line/column of the symbol? Is this much work /
hard work to add?

 
 file/line of course, but I don't see a point to column.

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

That's *nice* =)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ever tried? Ever failed? - Try again! Fail better!

Walter Bright <newshound1 digitalmars.com> writes:

Leandro Lucarella wrote:
 Walter Bright, el 11 de octubre a las 02:38 me escribiste:
 Lutger wrote:
 What about file/line/column of the symbol? Is this much work /
 hard work to add?

 file/line of course, but I don't see a point to column.

 
 See Clang error messages:
 http://clang.llvm.org/diagnostics.html
 
 That's *nice* =)
 

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 <llucax gmail.com> writes:

Walter Bright, el 11 de octubre a las 14:13 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 11 de octubre a las 02:38 me escribiste:
Lutger wrote:
What about file/line/column of the symbol? Is this much work /
hard work to add?

file/line of course, but I don't see a point to column.

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

That's *nice* =)

 
 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.

Yigal Chripun <yigal100 gmail.com> writes:

On 11/10/2009 23:13, Walter Bright wrote:
 Leandro Lucarella wrote:
 Walter Bright, el 11 de octubre a las 02:38 me escribiste:
 Lutger wrote:
 What about file/line/column of the symbol? Is this much work /
 hard work to add?

 file/line of course, but I don't see a point to column.

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

 That's *nice* =)

 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.

You assume everyone who uses DMD also uses DMC which is not necessarily 
the case.
More importantly, while this is a good feature, it is far better to have 
squiggly red lines in the IDE. I for one rely on those lines a lot.

=?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:

Walter Bright wrote:
 Think of what it provides as very similar to what ddoc does, except tha=

t=20
 instead of being in a human-readable format it would be a=20
 machine-readable one.
=20
 In other words, for each module you'll be able to get
=20
 . all the symbols in that module, and the members of those symbols=20
 (recursively)

	Including local variables for functions?

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

Walter Bright <newshound1 digitalmars.com> writes:

Jérôme M. Berger wrote:
 . all the symbols in that module, and the members of those symbols 
 (recursively)

 
     Including local variables for functions?

That seems pointless, as they'll be inaccessible outside of the scope of 
the function.

"Nick Sabalausky" <a a.a> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:has947$1vum$2 digitalmars.com...
 Jérôme M. Berger wrote:
 . all the symbols in that module, and the members of those symbols 
 (recursively)

     Including local variables for functions?

 That seems pointless, as they'll be inaccessible outside of the scope of 
 the function.

void foo()
{
   int bar;
   // big complex func here
}
User: Ok, IDE, Refactor->Rename->foo's "bar" to "baz"

=?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:

Walter Bright wrote:
 J=E9r=F4me M. Berger wrote:
 . all the symbols in that module, and the members of those symbols=20
 (recursively)

     Including local variables for functions?

=20
 That seems pointless, as they'll be inaccessible outside of the scope o=

f=20
 the function.

	The point would be for smart autocompletion: type the beginning of=20
a variable name, hit the autocomplete key and the IDE offers you a=20
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=20
offers you a list of members for foo. This requires knowing its=20
class even if it is a local...

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

BCS <none anon.com> writes:

Hello Walter,

 Jérôme M. Berger wrote:
 
 . all the symbols in that module, and the members of those symbols
 (recursively)
 

 Including local variables for functions?
 

 That seems pointless, as they'll be inaccessible outside of the scope
 of the function.
 

Good auto compleat needs a list of *Every* allowed identifier at any point 
in the code. Basicly the full symbol table.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

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.


Walter Bright wrote:
 Ellery Newcomer wrote:
 ctfe. compile time (weird connection?). what do string mixins evaluate
 to?

 
 No
 
 can I look at their result from the ide?

 
 No

Well I want this feature.

 
 what do templates expand
 to?

 
 No
 
 what does this here alias/typedef represent?

 
 Yes
 

Good.

 what does this here
 typeof expand to?

 
 No
 
 what does this here c-style type normalize to (in
 d-style)?

 
 No
 

Well I want this feature.


 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.

 
 can I find every symbol that
 would follow it in a dot list/exp?

 
 Yes

Good.

 
 when I see a symbol, can I find everywhere it's used?

 
 No, but could be added
 

Good.

 when I see a scope, can I see every symbol that's in it?

 
 Yes
 

Good.

 when I see a module, can I find everywhere it's imported?

 
 Yes

Good.

 
 can I see exactly what symbols are pulled in?

 
 No, but could be added

Good.

 
 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.

 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.

 
 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.

BCS <none anon.com> writes:

Hello Walter,

 
 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.

If that's what you are planning, I can tell you right now it's not enough. 
Much of the things IDEs need is not present in ddoc. Just off hand, I'd say 

than ddoc has. What would be better is a dump of a fully annotated AST from 
just before it's passed off for optimization and code gen.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

BCS wrote:
 Hello Walter,
 
 What would be better is a dump of a
 fully annotated AST from just before it's passed off for optimization
 and code gen.
 
 

To reiterate my offer,

I would be willing to implement this in DMD provided I can then assume
that any modern D compiler will have it.

Jeremie Pelletier <jeremiep gmail.com> writes:

Walter Bright wrote:
 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 <newshound1 digitalmars.com> writes:

Jeremie Pelletier wrote:
 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.

It has a test suite with it!

Christopher Wright <dhasenan gmail.com> writes:

Jeremie Pelletier wrote:
 Walter Bright wrote:
 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.

Tango already has a good JSON parser, but I imagine its license (BSD) 
doesn't meet Walter's requirements.

Moritz Warning <moritzwarning web.de> writes:

On Sun, 11 Oct 2009 09:04:50 -0400, Christopher Wright wrote:

 Jeremie Pelletier wrote:
 Walter Bright wrote:
 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.

 
 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 <moritzwarning web.de> writes:

On Sun, 11 Oct 2009 21:25:57 +0000, Moritz Warning wrote:

 On Sun, 11 Oct 2009 09:04:50 -0400, Christopher Wright wrote:
 
 Jeremie Pelletier wrote:
 Walter Bright wrote:
 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.

 
 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 <newshound1 digitalmars.com> writes:

Moritz Warning wrote:
 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 <moritzwarning web.de> writes:

On Sun, 11 Oct 2009 14:58:06 -0700, Walter Bright wrote:

 Moritz Warning wrote:
 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 <jeremiep gmail.com> writes:

Jeremie Pelletier wrote:
 Walter Bright wrote:
 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.

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 <newshound1 digitalmars.com> writes:

Jeremie Pelletier wrote:
 Jeremie Pelletier wrote:
 Walter Bright wrote:
 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.

 
 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 <jeremiep gmail.com> writes:

Walter Bright wrote:
 Jeremie Pelletier wrote:
 Jeremie Pelletier wrote:
 Walter Bright wrote:
 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.

 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

BCS <none anon.com> writes:

Hello Walter,

 Ellery Newcomer wrote:
 
 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.
 

template Foo (T) { T map(T[]) { ... } }

class Bar { mixin Foo!(int); }

void main()
{
   Bar bar;
   bar. /// will the IDE have to do anything special to see 'map' or will 
it just be listed as another function?
}

 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>
 

My normal setup is running eclipse on a windows box to edit files on a linux 
box (via file share) where I compile things (I need some other stuff from 
linux). For this, I have no need for a compiler on the box with the IDE unless 
the IDE needs it solely for the auto-complete.

Christopher Wright <dhasenan gmail.com> writes:

BCS wrote:
 template Foo (T) { T map(T[]) { ... } }
 
 class Bar { mixin Foo!(int); }
 
 void main()
 {
   Bar bar;
   bar. /// will the IDE have to do anything special to see 'map' or will 
 it just be listed as another function?
 }

Probably it would just work.

On the other hand, if you had this:

T manipulate(T)(T value) { ... }
MyObject foo;
manipulate(foo). // IDE dies here

The compiler wouldn't have completion on the line of code you're 
currently editing, since it's a syntax error. The IDE won't know 
anything about D and so can't determine what the return type of 
manipulate() is.

Jordan Miner <jminer2613 nospam.students.pcci.edu> writes:

Walter Bright Wrote:

 In my discussions with companies about adopting D, the major barrier 
 that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are 
 overbalanced by the loss of productivity by moving away from an IDE. And 
 what is it about an IDE that is so productive? Intellisense (Microsoft's 
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can 
 help. dmd already puts out .doc and .di files. How about putting out an 
 xml file giving all the information needed for an IDE to implement 
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse, 
 xml is trivial. Furthermore, an xml format would be fairly robust in the 
 face of changes to D syntax.
 
 What do you think?

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 <bearophileHUGS lycos.com> writes:

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 <newshound1 digitalmars.com> writes:

bearophile wrote:
 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).

 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 <tomqyp gmail.com> writes:

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 <dolive89 sina.com> writes:

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 <robert octarineparrot.com> writes:

Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier 
 that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are 
 overbalanced by the loss of productivity by moving away from an IDE. And 
 what is it about an IDE that is so productive? Intellisense (Microsoft's 
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can 
 help. dmd already puts out .doc and .di files. How about putting out an 
 xml file giving all the information needed for an IDE to implement 
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse, 
 xml is trivial. Furthermore, an xml format would be fairly robust in the 
 face of changes to D syntax.
 
 What do you think?

How well will this work with partially parsable files? Will it recover 
and continue parsing the rest of the file, so all the gained data is 
still there in the rest of the file, or will it give an error and make 
the rest of the file lack autocompletion? Or is the idea to merge the 
newly parsed output with an old version so everything still has 
autocompletion but the line in question has an error?

Will it be possible to pass individual statements (maybe along with a 
previous symbol table) to dmd to save reparsing the whole file?

Other than that is sounds like a great idea, I can't wait for someone to 
write an omnicompletion plugin for vim using this!

Jeremie Pelletier <jeremiep gmail.com> writes:

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

 It's the IDE.

 They say that the productivity gains of D's improvements are 
 overbalanced by the loss of productivity by moving away from an IDE. 
 And what is it about an IDE that is so productive? Intellisense 
 (Microsoft's word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to 
 parse, xml is trivial. Furthermore, an xml format would be fairly 
 robust in the face of changes to D syntax.

 What do you think?

 
 How well will this work with partially parsable files? Will it recover 
 and continue parsing the rest of the file, so all the gained data is 
 still there in the rest of the file, or will it give an error and make 
 the rest of the file lack autocompletion? Or is the idea to merge the 
 newly parsed output with an old version so everything still has 
 autocompletion but the line in question has an error?
 
 Will it be possible to pass individual statements (maybe along with a 
 previous symbol table) to dmd to save reparsing the whole file?
 
 Other than that is sounds like a great idea, I can't wait for someone to 
 write an omnicompletion plugin for vim using this!

That would be hard, if its a missing } then the entire parse tree will 
be in the wrong scope. The best the compiler can do is report an error 
at line x offset y and let the IDE highlight it, while it keeps on 
working with the info from the last successful analysis.

Walter Bright <newshound1 digitalmars.com> writes:

Robert Clipsham wrote:
 How well will this work with partially parsable files?

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

BCS <none anon.com> writes:

Hello Walter,

 Robert Clipsham wrote:
 
 How well will this work with partially parsable files?
 

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

Ouch. There goes about half of what people will want.

Walter Bright <newshound1 digitalmars.com> writes:

BCS wrote:
 Ouch. There goes about half of what people will want.

Right, it's about half. But it's an easy half to get.

BCS <none anon.com> writes:

Hello Walter,

 BCS wrote:
 
 Hello Walter,
 Probably not very well. This would work best with getting information
 from modules other than the one being edited.

 Ouch. There goes about half of what people will want.
 

 Right, it's about half. But it's an easy half to get.
 

Are you thinking of the partially parsed bit or the only in other modules 
bit? I was looking at the second.

Walter Bright <newshound1 digitalmars.com> writes:

BCS wrote:
 Hello Walter,
 
 BCS wrote:

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

 Ouch. There goes about half of what people will want.

 Right, it's about half. But it's an easy half to get.

 
 Are you thinking of the partially parsed bit or the only in other 
 modules bit? I was looking at the second.
 
 

Right, the second.

Frank Benoit <keinfarbton googlemail.com> writes:

Walter Bright schrieb:
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive?

If you use Eclipse for Java, you have:
- Debugger in place
- Automatic builder, compile on save
* Jump to line from error list
* Jump to declaration
- Show JavaDoc in tooltip, even in autocompletion
- Show hierarchy tree
- Autocompletion
- Quick assist, e.g.
	- assign ctor parameter to new field
	- extract selected text into local variable
	- Mark source portion, extract to method, the IDE evaluates the needed
parameters and return value
	- ...
There is so much more. But the main thing is, you are not only able to
use grep and friends on the pure text level. With an IDE you have
semantic support. This makes refactoring your code so much easier. You
can say "rename this method" and it works, all references to this method
are also altered. "Move this inner class to a top level class in that
package", "Derive from that class, yes add the needed ctors". There is
even an API to automate refactorings.

I think Descent is the right way. But here, a port of DMD is directly
integrated into the plugin. To put more manpower in this project would
be the best way imo.

Jacob Carlborg <doob me.com> writes:

On 10/11/09 11:56, Frank Benoit wrote:
 Walter Bright schrieb:
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive?

 If you use Eclipse for Java, you have:
 - Debugger in place
 - Automatic builder, compile on save
 * Jump to line from error list
 * Jump to declaration
 - Show JavaDoc in tooltip, even in autocompletion
 - Show hierarchy tree
 - Autocompletion
 - Quick assist, e.g.
 	- assign ctor parameter to new field
 	- extract selected text into local variable
 	- Mark source portion, extract to method, the IDE evaluates the needed
 parameters and return value
 	- ...
 There is so much more. But the main thing is, you are not only able to
 use grep and friends on the pure text level. With an IDE you have
 semantic support. This makes refactoring your code so much easier. You
 can say "rename this method" and it works, all references to this method
 are also altered. "Move this inner class to a top level class in that
 package", "Derive from that class, yes add the needed ctors". There is
 even an API to automate refactorings.

 I think Descent is the right way. But here, a port of DMD is directly
 integrated into the plugin. To put more manpower in this project would
 be the best way imo.

I completely agree. I don't know if it would be better to have the parts 
of dmd that descent needs in a separate library to avoid porting half of 
dmd to java.

Jeremie Pelletier <jeremiep gmail.com> writes:

Jacob Carlborg wrote:
 On 10/11/09 11:56, Frank Benoit wrote:
 Walter Bright schrieb:
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive?

 If you use Eclipse for Java, you have:
 - Debugger in place
 - Automatic builder, compile on save
 * Jump to line from error list
 * Jump to declaration
 - Show JavaDoc in tooltip, even in autocompletion
 - Show hierarchy tree
 - Autocompletion
 - Quick assist, e.g.
     - assign ctor parameter to new field
     - extract selected text into local variable
     - Mark source portion, extract to method, the IDE evaluates the 
 needed
 parameters and return value
     - ...
 There is so much more. But the main thing is, you are not only able to
 use grep and friends on the pure text level. With an IDE you have
 semantic support. This makes refactoring your code so much easier. You
 can say "rename this method" and it works, all references to this method
 are also altered. "Move this inner class to a top level class in that
 package", "Derive from that class, yes add the needed ctors". There is
 even an API to automate refactorings.

 I think Descent is the right way. But here, a port of DMD is directly
 integrated into the plugin. To put more manpower in this project would
 be the best way imo.

 
 I completely agree. I don't know if it would be better to have the parts 
 of dmd that descent needs in a separate library to avoid porting half of 
 dmd to java.
 

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

In my opinion, more manpower needs to be put in dmd itself so more third 
party programs and plugins can use it directly, the goal is to make dmd 
more powerful while supporting more usages.

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 I think Descent is the right way. But here, a port of DMD is directly
 integrated into the plugin. To put more manpower in this project would
 be the best way imo.

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

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

JSON support also will not take away anything from efforts to integrate 
DMD into IDE front ends. It's more for IDEs that don't have the 
resources to do that.

language_fan <foo bar.com.invalid> writes:

Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly wrote:

 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.
 
 What do you think?

Well since there is already a project working on an Eclipse plugin, I see 
little use for other IDEs at the moment. The D community is rather small 
and only a small amount of people are capable of developing and willing 
to donate their free time on free IDE development (commercial IDEs have 
small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio 
dominate the market). So why not concentrate on fixing the spec and 
fixing compiler bugs instead of building a modest IDE support no one will 
use?

Lutger <lutger.blijdestijn gmail.com> writes:

language_fan wrote:

 Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly wrote:
 
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.
 
 What do you think?

 
 Well since there is already a project working on an Eclipse plugin, I see
 little use for other IDEs at the moment. The D community is rather small
 and only a small amount of people are capable of developing and willing
 to donate their free time on free IDE development (commercial IDEs have
 small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio
 dominate the market). So why not concentrate on fixing the spec and
 fixing compiler bugs instead of building a modest IDE support no one will
 use?

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 <jeremiep gmail.com> writes:

language_fan wrote:
 Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly wrote:
 
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.

 What do you think?

 
 Well since there is already a project working on an Eclipse plugin, I see 
 little use for other IDEs at the moment. The D community is rather small 
 and only a small amount of people are capable of developing and willing 
 to donate their free time on free IDE development (commercial IDEs have 
 small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio 
 dominate the market). So why not concentrate on fixing the spec and 
 fixing compiler bugs instead of building a modest IDE support no one will 
 use?

Eclipse is heavy, slow and often unresponsive. I use poseidon myself 
because it is light and fast and I don't require much more from an IDE 
at the moment.

language_fan <foo bar.com.invalid> writes:

Sun, 11 Oct 2009 12:44:08 -0400, Jeremie Pelletier thusly wrote:

 language_fan wrote:
 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.

If you turn off all the advanced features of Eclipse (spell checking, 
interactive parsing & type checking etc), it will become a lot more 
responsive. You can even uninstall many of the plugins if you really do 
not need them. I recommend firing up the latest development build with 
the latest 1.6 jvm. It will take couple of seconds for the JIT to spot 
the hot spots after starting up. Of course Poseidon is faster *now* that 
it lacks all the advanced features, but once you start adding more, it 
will eventually grind to a halt.

Michal Minich <michal minich.sk> writes:

 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.


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

http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php
Under "Platform runtime binary"

"Nick Sabalausky" <a a.a> writes:

"language_fan" <foo bar.com.invalid> wrote in message 
news:hasd5u$1fgu$1 digitalmars.com...
 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). 

language_fan <foo bar.com.invalid> writes:

Sun, 11 Oct 2009 17:01:03 -0400, Nick Sabalausky thusly wrote:

 "language_fan" <foo bar.com.invalid> wrote in message
 news:hasd5u$1fgu$1 digitalmars.com...
 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).

Fine, if you are happy with your productivity. For me it was a natural 
choice. I started with notepad like editors, then moved to "programmer's 
editors" like crimson editor and jedit, soon discovered vim and emacs, 
and finally have settled down on Eclipse, Netbeans, Visual Studio, and 
IntelliJ IDEA. The productivity boost is enormous. "Practical" languages 
have lots of boiler-plate, and I can easily generate hundreds of lines of 
code with a couple of key combinations or mouse clicks. Another killer 
feature is the "intellisense" stuff. Having the ability to see a) 
inferred type b) integrated html rendered javadoc c) type correct class 
members etc. saves me hours of work time per day. YMMV

"Nick Sabalausky" <a a.a> writes:

"language_fan" <foo bar.com.invalid> wrote in message 
news:hav02v$2162$4 digitalmars.com...
 Sun, 11 Oct 2009 17:01:03 -0400, Nick Sabalausky thusly wrote:

 "language_fan" <foo bar.com.invalid> wrote in message
 news:hasd5u$1fgu$1 digitalmars.com...
 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).

 Fine, if you are happy with your productivity. For me it was a natural
 choice. I started with notepad like editors, then moved to "programmer's
 editors" like crimson editor and jedit, soon discovered vim and emacs,
 and finally have settled down on Eclipse, Netbeans, Visual Studio, and
 IntelliJ IDEA.

...
 The productivity boost is enormous.

...
 Another killer
 feature is the "intellisense" stuff. Having the ability to see a)
 inferred type b) integrated html rendered javadoc c) type correct class
 members etc. saves me hours of work time per day. YMMV

I've used all that stuff before. I had to use Eclipse back when I was doing 

VS.NET had most of those nice features, but wasn't nearly as bloated and 
sluggigh as it is today). So I'm very familiar with all of that stuff. In 
fact, I love all of it. But with things like Programmer's Notepad 2, I can 
actually get into a "flow" (which sluggishness instantly breaks) and I end 
up far *more* productive (as long as I'm not using some POS language like 
Java, see below).

 "Practical" languages
 have lots of boiler-plate, and I can easily generate hundreds of lines of
 code with a couple of key combinations or mouse clicks.

I disagree very much. For a puritanical anal-retentive language like Java, 
you *have* to have all that fancy stuff just to make the language even 
usable. But with a practical language like D, I have mixins, and I've gotten 
pretty good with regex find and replace, which obviously isn't as good, but 
it's good enough when dealing with any language that's at least somewhat 
sensible. With practical languages I never need to generate hundreds of 
lines of code. If I ever actually needed to do so (and in a way that an IDE 
could actually help with), I'd take that as a very big red flag that I was 
using an incredibly shitty language in the first place (like Java).

Also, Eclipse, even with descent, is still very Java-centric, particularly 
wrt project/target/workspace management, and that gets in the way. And VS 
just doesn't have any D stuff available at all and takes a lot of work, a 
lot of bad documentation, and IIRC, a paid version of VS, to add or use any 
support at all for a new langauge. PN2 has D syntax highlighting built-in, 
which already puts it well ahead of VS for D.

Walter Bright <newshound1 digitalmars.com> writes:

Nick Sabalausky wrote:
 "language_fan" <foo bar.com.invalid> wrote in message 
 "Practical" languages
 have lots of boiler-plate, and I can easily generate hundreds of lines of
 code with a couple of key combinations or mouse clicks.

 
 I disagree very much. For a puritanical anal-retentive language like Java, 
 you *have* to have all that fancy stuff just to make the language even 
 usable. But with a practical language like D, I have mixins, and I've gotten 
 pretty good with regex find and replace, which obviously isn't as good, but 
 it's good enough when dealing with any language that's at least somewhat 
 sensible. With practical languages I never need to generate hundreds of 
 lines of code. If I ever actually needed to do so (and in a way that an IDE 
 could actually help with), I'd take that as a very big red flag that I was 
 using an incredibly shitty language in the first place (like Java).

I think Nick has a point. Java lacks template mixins, and so inserting 
hundreds of lines of code from an IDE "template" is normal. But with D, 
doing such would be abnormal.

"Nick Sabalausky" <a a.a> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hb08gf$2hvq$1 digitalmars.com...
 Nick Sabalausky wrote:
 "language_fan" <foo bar.com.invalid> wrote in message
 "Practical" languages
 have lots of boiler-plate, and I can easily generate hundreds of lines 
 of
 code with a couple of key combinations or mouse clicks.

 I disagree very much. For a puritanical anal-retentive language like 
 Java, you *have* to have all that fancy stuff just to make the language 
 even usable. But with a practical language like D, I have mixins, and 
 I've gotten pretty good with regex find and replace, which obviously 
 isn't as good, but it's good enough when dealing with any language that's 
 at least somewhat sensible. With practical languages I never need to 
 generate hundreds of lines of code. If I ever actually needed to do so 
 (and in a way that an IDE could actually help with), I'd take that as a 
 very big red flag that I was using an incredibly shitty language in the 
 first place (like Java).

 I think Nick has a point. Java lacks template mixins, and so inserting 
 hundreds of lines of code from an IDE "template" is normal. But with D, 
 doing such would be abnormal.

And not only that, but D supports higher-level and non-OOP constructs far 
better than Java, and far less verbosely, so you don't always even need to 
resort to mixins. A lot of the time you can just simply use better features. 
Like delegate literals instead of functors. 

Ary Borenszweig <ary esperanto.org.ar> writes:

language_fan wrote:
 "Practical" languages
 have lots of boiler-plate, and I can easily generate hundreds of lines of 
 code with a couple of key combinations or mouse clicks.

Can you give some examples? I can only think of some that generate some 
lines of code, not hundreds.

Lutger <lutger.blijdestijn gmail.com> writes:

Ary Borenszweig wrote:

 language_fan wrote:
  > "Practical" languages
 have lots of boiler-plate, and I can easily generate hundreds of lines of
 code with a couple of key combinations or mouse clicks.

 
 Can you give some examples? I can only think of some that generate some
 lines of code, not hundreds.

linq-to-sql

language_fan <foo bar.com.invalid> writes:

Tue, 13 Oct 2009 10:33:54 +0200, Ary Borenszweig thusly wrote:

 language_fan wrote:
  > "Practical" languages
 have lots of boiler-plate, and I can easily generate hundreds of lines
 of code with a couple of key combinations or mouse clicks.

 
 Can you give some examples? I can only think of some that generate some
 lines of code, not hundreds.

For instance simple things like setters and getters for an aggregate 
class easily generate tens of lines of code (well, not only code lines, 
but also other kinds of editable lines). Like lutger said, all kinds of 
transformations also come in mind in this context. There could be even 
ORM mapping utilities which generate all the code for accessing the 
database structures.

language_fan <foo bar.com.invalid> writes:

Sun, 11 Oct 2009 10:48:30 +0000, language_fan thusly wrote:

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

BTW totally off-topic, but I just found out that IntelliJ IDEA has been 
jumped on the open source wagon. This probably makes it a bit more 
challenging to make money on the commercial IDE market.

Christopher Wright <dhasenan gmail.com> writes:

Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier 
 that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are 
 overbalanced by the loss of productivity by moving away from an IDE. And 
 what is it about an IDE that is so productive? Intellisense (Microsoft's 
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can 
 help. dmd already puts out .doc and .di files. How about putting out an 
 xml file giving all the information needed for an IDE to implement 
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse, 
 xml is trivial. Furthermore, an xml format would be fairly robust in the 
 face of changes to D syntax.
 
 What do you think?

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 <ary esperanto.org.ar> writes:

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

What I think is that even with an xml representing the parse tree (maybe 
with some semantic stuff resolved) it'll be still incomplete for a real 
IDE (the kind of thing users expect from an IDE). You can see this 
video, for example:

http://www.youtube.com/watch?v=KQbTT605ags

So you have:

---
module one;

class Foo(T) {
   static if (is(T == class)) {
     T property;
   } else {
     T someMethod() { return T.init; }
   }
   mixin(guessWhat!(T)());
}
---

You want to define an xml for that module that'll help IDEs. Can you 
think what it'll look like?

Now the user writes in another module:

class Bar {
}

void x() {
   auto foo = new Foo!(Bar)();
   foo. <-- what does the IDE do here?
}

Now, the correct thing for the IDE to do is to suggest the field "Bar 
property". How can the IDE do that just with an xml? It can't. It need 
to perform some kind of semantic anlysis to Foo's argument to see if 
it's a class, match the static if in the template, replace template 
parameters, etc. It also needs to evaluate the string mixin.

Of course you could say "Bah, just show all the declarations inside the 
template in the autocomplete", but that's wrong. That'll lead to files 
that don't compile. You could ommit supporting autocompletion or other 
nice features, but that's exactly the big features of D. If you don't 

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 <yigal100 gmail.com> writes:

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

 It's the IDE.

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

 What do you think?

 What I think is that even with an xml representing the parse tree (maybe
 with some semantic stuff resolved) it'll be still incomplete for a real
 IDE (the kind of thing users expect from an IDE). You can see this
 video, for example:

 http://www.youtube.com/watch?v=KQbTT605ags

 So you have:

 ---
 module one;

 class Foo(T) {
 static if (is(T == class)) {
 T property;
 } else {
 T someMethod() { return T.init; }
 }
 mixin(guessWhat!(T)());
 }
 ---

 You want to define an xml for that module that'll help IDEs. Can you
 think what it'll look like?

 Now the user writes in another module:

 class Bar {
 }

 void x() {
 auto foo = new Foo!(Bar)();
 foo. <-- what does the IDE do here?
 }

 Now, the correct thing for the IDE to do is to suggest the field "Bar
 property". How can the IDE do that just with an xml? It can't. It need
 to perform some kind of semantic anlysis to Foo's argument to see if
 it's a class, match the static if in the template, replace template
 parameters, etc. It also needs to evaluate the string mixin.

 Of course you could say "Bah, just show all the declarations inside the
 template in the autocomplete", but that's wrong. That'll lead to files
 that don't compile. You could ommit supporting autocompletion or other
 nice features, but that's exactly the big features of D. If you don't

 could use the advanced features but the IDE won't help you. And in your
 discussions with companies adopting D, I'm sure they were talking about
 great IDEs like JDT Eclipse or Visual Studio, not just some tool that
 helps you a little but not anymore when things get interesting.

 Oh, and you need to have some kind of semantic analysis to know the type
 of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
 Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:

 auto b = foo.property;
 b. <-- and here?
 // remember "property" is templated and depends on static analysis
 // or the IDE could need to resolve alias this or other things

 So... my opinion (like some others, I see) is to either ask things to
 the compiler directly (but here the compiler lacks some info, like exact
 source range positions), or to have a compiler (not a full-blown one,
 just the front-end) built into the IDE, and that's what Descent is.
 Unfortunately Descent is sometimes slow, sometimes buggy, but that's
 normal: just a few people develop and maintain it (so I can see a
 similarity with dmd here, where each day I see two or three new bugs
 reported). If more people were into it, more unit tests were written
 into it and, most of all, more people would use it, it'll get better.

 Another problem that people see in Descent (maybe also JDT Eclipse and
 Visual Studio0 is that it's huge, it consumes a lot of memory and they
 don't want to open a huge tool just to hack some lines. My answer is:
 memory performance can be improved (but not a lot), but since an IDE is
 a huge tool it requires a lof from the computer. And an IDE is not meant
 to be used to hack some lines, it's meant to help you write big project,
 huge projects without getting lost in the amount of code.

 So my bet would be to start supporting an existing IDE that integrates a
 compiler into it. Updating it is easy: just port the diffs between DMD
 versions. It's a huge job for one or two people, but if a lot of people
 were involved it's not that much. Of course I'd recommend you to try
 Descent since I'm one of it's creators and I do believe it can get
 pretty good. :-)

well put.

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

Jacob Carlborg <doob me.com> writes:

On 10/11/09 20:58, Yigal Chripun wrote:
 On 11/10/2009 15:23, Ary Borenszweig wrote:
 Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

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

 What do you think?

 What I think is that even with an xml representing the parse tree (maybe
 with some semantic stuff resolved) it'll be still incomplete for a real
 IDE (the kind of thing users expect from an IDE). You can see this
 video, for example:

 http://www.youtube.com/watch?v=KQbTT605ags

 So you have:

 ---
 module one;

 class Foo(T) {
 static if (is(T == class)) {
 T property;
 } else {
 T someMethod() { return T.init; }
 }
 mixin(guessWhat!(T)());
 }
 ---

 You want to define an xml for that module that'll help IDEs. Can you
 think what it'll look like?

 Now the user writes in another module:

 class Bar {
 }

 void x() {
 auto foo = new Foo!(Bar)();
 foo. <-- what does the IDE do here?
 }

 Now, the correct thing for the IDE to do is to suggest the field "Bar
 property". How can the IDE do that just with an xml? It can't. It need
 to perform some kind of semantic anlysis to Foo's argument to see if
 it's a class, match the static if in the template, replace template
 parameters, etc. It also needs to evaluate the string mixin.

 Of course you could say "Bah, just show all the declarations inside the
 template in the autocomplete", but that's wrong. That'll lead to files
 that don't compile. You could ommit supporting autocompletion or other
 nice features, but that's exactly the big features of D. If you don't

 could use the advanced features but the IDE won't help you. And in your
 discussions with companies adopting D, I'm sure they were talking about
 great IDEs like JDT Eclipse or Visual Studio, not just some tool that
 helps you a little but not anymore when things get interesting.

 Oh, and you need to have some kind of semantic analysis to know the type
 of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
 Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:

 auto b = foo.property;
 b. <-- and here?
 // remember "property" is templated and depends on static analysis
 // or the IDE could need to resolve alias this or other things

 So... my opinion (like some others, I see) is to either ask things to
 the compiler directly (but here the compiler lacks some info, like exact
 source range positions), or to have a compiler (not a full-blown one,
 just the front-end) built into the IDE, and that's what Descent is.
 Unfortunately Descent is sometimes slow, sometimes buggy, but that's
 normal: just a few people develop and maintain it (so I can see a
 similarity with dmd here, where each day I see two or three new bugs
 reported). If more people were into it, more unit tests were written
 into it and, most of all, more people would use it, it'll get better.

 Another problem that people see in Descent (maybe also JDT Eclipse and
 Visual Studio0 is that it's huge, it consumes a lot of memory and they
 don't want to open a huge tool just to hack some lines. My answer is:
 memory performance can be improved (but not a lot), but since an IDE is
 a huge tool it requires a lof from the computer. And an IDE is not meant
 to be used to hack some lines, it's meant to help you write big project,
 huge projects without getting lost in the amount of code.

 So my bet would be to start supporting an existing IDE that integrates a
 compiler into it. Updating it is easy: just port the diffs between DMD
 versions. It's a huge job for one or two people, but if a lot of people
 were involved it's not that much. Of course I'd recommend you to try
 Descent since I'm one of it's creators and I do believe it can get
 pretty good. :-)

 well put.

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

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.

Frank Benoit <keinfarbton googlemail.com> writes:

Jacob Carlborg schrieb:
 On 10/11/09 20:58, Yigal Chripun wrote:
 On 11/10/2009 15:23, Ary Borenszweig wrote:
 Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

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

 What do you think?

 What I think is that even with an xml representing the parse tree (maybe
 with some semantic stuff resolved) it'll be still incomplete for a real
 IDE (the kind of thing users expect from an IDE). You can see this
 video, for example:

 http://www.youtube.com/watch?v=KQbTT605ags

 So you have:

 ---
 module one;

 class Foo(T) {
 static if (is(T == class)) {
 T property;
 } else {
 T someMethod() { return T.init; }
 }
 mixin(guessWhat!(T)());
 }
 ---

 You want to define an xml for that module that'll help IDEs. Can you
 think what it'll look like?

 Now the user writes in another module:

 class Bar {
 }

 void x() {
 auto foo = new Foo!(Bar)();
 foo. <-- what does the IDE do here?
 }

 Now, the correct thing for the IDE to do is to suggest the field "Bar
 property". How can the IDE do that just with an xml? It can't. It need
 to perform some kind of semantic anlysis to Foo's argument to see if
 it's a class, match the static if in the template, replace template
 parameters, etc. It also needs to evaluate the string mixin.

 Of course you could say "Bah, just show all the declarations inside the
 template in the autocomplete", but that's wrong. That'll lead to files
 that don't compile. You could ommit supporting autocompletion or other
 nice features, but that's exactly the big features of D. If you don't

 could use the advanced features but the IDE won't help you. And in your
 discussions with companies adopting D, I'm sure they were talking about
 great IDEs like JDT Eclipse or Visual Studio, not just some tool that
 helps you a little but not anymore when things get interesting.

 Oh, and you need to have some kind of semantic analysis to know the type
 of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
 Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:

 auto b = foo.property;
 b. <-- and here?
 // remember "property" is templated and depends on static analysis
 // or the IDE could need to resolve alias this or other things

 So... my opinion (like some others, I see) is to either ask things to
 the compiler directly (but here the compiler lacks some info, like exact
 source range positions), or to have a compiler (not a full-blown one,
 just the front-end) built into the IDE, and that's what Descent is.
 Unfortunately Descent is sometimes slow, sometimes buggy, but that's
 normal: just a few people develop and maintain it (so I can see a
 similarity with dmd here, where each day I see two or three new bugs
 reported). If more people were into it, more unit tests were written
 into it and, most of all, more people would use it, it'll get better.

 Another problem that people see in Descent (maybe also JDT Eclipse and
 Visual Studio0 is that it's huge, it consumes a lot of memory and they
 don't want to open a huge tool just to hack some lines. My answer is:
 memory performance can be improved (but not a lot), but since an IDE is
 a huge tool it requires a lof from the computer. And an IDE is not meant
 to be used to hack some lines, it's meant to help you write big project,
 huge projects without getting lost in the amount of code.

 So my bet would be to start supporting an existing IDE that integrates a
 compiler into it. Updating it is easy: just port the diffs between DMD
 versions. It's a huge job for one or two people, but if a lot of people
 were involved it's not that much. Of course I'd recommend you to try
 Descent since I'm one of it's creators and I do believe it can get
 pretty good. :-)

 well put.

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

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

Sorry, OSGi is just dummy, to make other stuff compile.

Jacob Carlborg <doob me.com> writes:

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

 It's the IDE.

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

 What do you think?

 What I think is that even with an xml representing the parse tree (maybe
 with some semantic stuff resolved) it'll be still incomplete for a real
 IDE (the kind of thing users expect from an IDE). You can see this
 video, for example:

 http://www.youtube.com/watch?v=KQbTT605ags

 So you have:

 ---
 module one;

 class Foo(T) {
 static if (is(T == class)) {
 T property;
 } else {
 T someMethod() { return T.init; }
 }
 mixin(guessWhat!(T)());
 }
 ---

 You want to define an xml for that module that'll help IDEs. Can you
 think what it'll look like?

 Now the user writes in another module:

 class Bar {
 }

 void x() {
 auto foo = new Foo!(Bar)();
 foo. <-- what does the IDE do here?
 }

 Now, the correct thing for the IDE to do is to suggest the field "Bar
 property". How can the IDE do that just with an xml? It can't. It need
 to perform some kind of semantic anlysis to Foo's argument to see if
 it's a class, match the static if in the template, replace template
 parameters, etc. It also needs to evaluate the string mixin.

 Of course you could say "Bah, just show all the declarations inside the
 template in the autocomplete", but that's wrong. That'll lead to files
 that don't compile. You could ommit supporting autocompletion or other
 nice features, but that's exactly the big features of D. If you don't

 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.

I use it almost at a daily base and it works great. I can't remember the 
last time it cashed.

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

Ary Borenszweig <ary esperanto.org.ar> writes:

Jacob Carlborg wrote:
 On 10/11/09 15:23, Ary Borenszweig wrote:
 Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

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

 What do you think?

 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" <2korden gmail.com> writes:

On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

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

 It's the IDE.

 They say that the productivity gains of D's improvements are  
 overbalanced by the loss of productivity by moving away from an IDE. And  
 what is it about an IDE that is so productive? Intellisense (Microsoft's  
 word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to parse,  
 xml is trivial. Furthermore, an xml format would be fairly robust in the  
 face of changes to D syntax.

 What do you think?

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 <ellery-newcomer utulsa.edu> writes:

Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:
 
 If anyone is interested and is willing to test and/or help, I will
 gladly share my code.

Oooo.. You should put that on dsource or somewhere. Hacking D sounds
like a lot more fun than hacking C++. I wouldn't mind helping out on
this one.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Ellery Newcomer wrote:
 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 
 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

Guys please use D2 :o).

Andrei

"Denis Koroskin" <2korden gmail.com> writes:

On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Ellery Newcomer wrote:
 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

  Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

 Guys please use D2 :o).

 Andrei

I do, it's written entirely in D2 :)

BLS <windevguy hotmail.de> writes:

On 11/10/2009 17:43, Denis Koroskin wrote:
 On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Ellery Newcomer wrote:
 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

 Guys please use D2 :o).

 Andrei

 I do, it's written entirely in D2 :)

Which GUI toolkit ?

"Denis Koroskin" <2korden gmail.com> writes:

On Sun, 11 Oct 2009 20:03:16 +0400, BLS <windevguy hotmail.de> wrote:

 On 11/10/2009 17:43, Denis Koroskin wrote:
 On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Ellery Newcomer wrote:
 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

 Guys please use D2 :o).

 Andrei

 I do, it's written entirely in D2 :)

 Which GUI toolkit ?

I took the Eclipse way and wrote everything from scratch, including the  
GUI toolkit. It evolves out of needs of other projects. It's meant to be  
platform independent, but only Win32 backend is currently supported,  
although I started implementing a generic (windowless) one, but mostly to  
test out the design and look into implementing custom rendering and  
skinning support. I believe it won't take too long to port it to other  
platforms (GTK in first place), but there are always other things to do  
first...

Yigal Chripun <yigal100 gmail.com> writes:

On 11/10/2009 18:29, Denis Koroskin wrote:
 On Sun, 11 Oct 2009 20:03:16 +0400, BLS <windevguy hotmail.de> wrote:

 On 11/10/2009 17:43, Denis Koroskin wrote:
 On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Ellery Newcomer wrote:
 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

 Guys please use D2 :o).

 Andrei

 I do, it's written entirely in D2 :)

 Which GUI toolkit ?

 I took the Eclipse way and wrote everything from scratch, including the
 GUI toolkit. It evolves out of needs of other projects. It's meant to be
 platform independent, but only Win32 backend is currently supported,
 although I started implementing a generic (windowless) one, but mostly
 to test out the design and look into implementing custom rendering and
 skinning support. I believe it won't take too long to port it to other
 platforms (GTK in first place), but there are always other things to do
 first...

sounds awesome. have you considered integrating other existing projects 
like Dil and dang?

language_fan <foo bar.com.invalid> writes:

Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote:

 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:
 
 If anyone is interested and is willing to test and/or help, I will
 gladly share my code.

 
 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was 
there a good reason to start yet another port of it?

Jeremie Pelletier <jeremiep gmail.com> writes:

language_fan wrote:
 Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote:
 
 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

 
 Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was 
 there a good reason to start yet another port of it?

Maybe learning, porting a library or application from a language to 
another is a great way to learn about it inside out. I used to do that a 
lot too.

"Denis Koroskin" <2korden gmail.com> writes:

On Mon, 12 Oct 2009 12:58:56 +0400, language_fan <foo bar.com.invalid>  
wrote:

 Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote:

 Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 Oooo.. You should put that on dsource or somewhere. Hacking D sounds
 like a lot more fun than hacking C++. I wouldn't mind helping out on
 this one.

 Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was
 there a good reason to start yet another port of it?

I know about DParser, but it's somewhat outdated, incomplete and doesn't  
support code generation. It also diverged from DMD quite a lot so fixing  
it would be quite hard (I, too, plan to make it more D-ish - get rid of  
casts, replace void* "Array"s with type-safe equivalents etc - but not  
until it is 100% ready).

I just believe rewriting it from scratch will be plain faster. I can also  
test the code much easier - if it produces exact same binary then it works  
correct.

Walter Bright <newshound1 digitalmars.com> writes:

Denis Koroskin wrote:
 I just believe rewriting it from scratch will be plain faster. I can 
 also test the code much easier - if it produces exact same binary then 
 it works correct.

The dmd front end is also written in a "D-ish" style which should make 
translation to D easier.

grauzone <none example.net> writes:

Walter Bright wrote:
 Denis Koroskin wrote:
 I just believe rewriting it from scratch will be plain faster. I can 
 also test the code much easier - if it produces exact same binary then 
 it works correct.

 
 The dmd front end is also written in a "D-ish" style which should make 
 translation to D easier.

But some stuff doesn't quite match: for example, Expression is declared 
in expression.h. But not all methods are implemented in expression.c. 
There's at least the interpret() method, which is in interpret.c.

How would you translate this into D? Just mash everything into a single 
.d source file?

Walter Bright <newshound1 digitalmars.com> writes:

grauzone wrote:
 But some stuff doesn't quite match: for example, Expression is declared 
 in expression.h. But not all methods are implemented in expression.c. 
 There's at least the interpret() method, which is in interpret.c.
 
 How would you translate this into D? Just mash everything into a single 
 .d source file?

Oh, I agree that the files would have to be organized differently. One 
giant file is a little extreme, though <g>. Probably one module per 
class would be better.

digited <digited yandex.ru> writes:

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 <e.insafutdinov gmail.com> writes:

digited Wrote:

 Denis Koroskin ïèøåò:
 
 If anyone is interested and is willing to test and/or help, I will
 gladly share my code.

 
 You can write a note on dprogramming ru about the epic thing you're working
on, i'm sure we'll help to test at least.

I'm all for it.

Walter Bright <newshound1 digitalmars.com> writes:

Denis Koroskin wrote:
 In fact, that's what I do right now.

I think that's great. But it requires a lot of work (as of course you know).

Ary Borenszweig <ary esperanto.org.ar> writes:

Walter Bright wrote:
 Denis Koroskin wrote:
 In fact, that's what I do right now.

 
 I think that's great. But it requires a lot of work (as of course you 
 know).

Good things require a lot of work. :)

Walter Bright <newshound1 digitalmars.com> writes:

Ary Borenszweig wrote:
 Walter Bright wrote:
 Denis Koroskin wrote:
 In fact, that's what I do right now.

 I think that's great. But it requires a lot of work (as of course you 
 know).

 
 Good things require a lot of work. :)

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

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

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

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

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

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

Jacob Carlborg <doob me.com> writes:

On 10/11/09 21:38, Walter Bright wrote:
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Denis Koroskin wrote:
 In fact, that's what I do right now.

 I think that's great. But it requires a lot of work (as of course you
 know).

 Good things require a lot of work. :)

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

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

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

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

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

I think descent is really good now.

 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" <a a.a> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hatc8c$277u$1 digitalmars.com...
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Denis Koroskin wrote:
 In fact, that's what I do right now.

 I think that's great. But it requires a lot of work (as of course you 
 know).

 Good things require a lot of work. :)

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

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

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

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

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

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

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 <newshound1 digitalmars.com> writes:

Nick Sabalausky wrote:
 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 <doob me.com> writes:

On 10/11/09 16:32, Denis Koroskin wrote:
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

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

 It's the IDE.

 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE.
 And what is it about an IDE that is so productive? Intellisense
 (Microsoft's word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to
 parse, xml is trivial. Furthermore, an xml format would be fairly
 robust in the face of changes to D syntax.

 What do you think?

 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.

"Phil Deets" <pjdeets2 gmail.com> writes:

On Sun, 11 Oct 2009 09:32:32 -0500, Denis Koroskin <2korden gmail.com>  
wrote:

 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright  
 <newshound1 digitalmars.com> wrote:

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

 It's the IDE.

 They say that the productivity gains of D's improvements are  
 overbalanced by the loss of productivity by moving away from an IDE.  
 And what is it about an IDE that is so productive? Intellisense  
 (Microsoft's word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to  
 parse, xml is trivial. Furthermore, an xml format would be fairly  
 robust in the face of changes to D syntax.

 What do you think?

 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.

I would like it if this went open so I could examine it and possibly  
contribute to it. I have wanted to do something like this, but all I have  
started so far is a GUI toolkit. I am new to D so I have not spent much  
time on it yet. It would be nice to be able to work on something more  
developed.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

"Sableteeth" <sableteeth gmail.com> writes:

	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

"Denis Koroskin" <2korden gmail.com> =
=D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B8=D0=BB/=D1=81=D0=BE=D0=BE=D0=B1=D1=89=
=D0=B8=D0=BB=D0=B0 =D0=B2 =
=D0=BD=D0=BE=D0=B2=D0=BE=D1=81=D1=82=D1=8F=D1=85 =
=D1=81=D0=BB=D0=B5=D0=B4=D1=83=D1=8E=D1=89=D0=B5=D0=B5: =
news:op.u1m30ituo7cclz korden-pc...
 On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright =20
 <newshound1 digitalmars.com> wrote:
=20
 I believe it won't work. It will always be slow and incomplete.
=20
 Instead, I would make it easier to embed DMD into an IDE: separate =

DMDFE =20
 from DMDBE, fix memory leaks, remove all the static data (so that code =

=20
 would be re-intrable and it could work in different threads in =

parallel), =20
 move most of DMD code into a DLL so that an IDE could dynamically link =

=20
 with it and whatever it pleases with the source code.
=20
 In fact, that's what I do right now.
=20
 I'm writing my own D IDE in my spare time (in D, of course). I already =

=20
 made a lot of progress and now it's time to start implementing source =

code =20
 analysis.
=20
 First thing I did is I made complete D bindings for C++ code. It =

worked =20
 out quite well but it was leaking so badly that I dropped it.
=20
 Instead, I started porting DMD entirely to D (except the backend, of =20
 course), and I already got some great results. A few simple programs =20
 compile and produce byte-perfect binaries. It's still in its early =

stages =20
 and there is a lot of work to do, but it will be finished soon =20
 (hopefully). It could probably become a part of an official =

distribution, =20
 eventually. :)
=20
 If anyone is interested and is willing to test and/or help, I will =

gladly =20
 share my code.

Hi, Denis!

I am beginner in D, but this theme is interesting for me - I very much =
would like to take part in creation IDE.=20

I am interesting. I'd like to help.
I hope I'll be able to help you?

Contact me please at sableteeth gmail.com
Sincerelly, Sergey




__________ Information from ESET NOD32 Antivirus, version of virus signatur=
e database 4862 (20100212) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

BLS <windevguy hotmail.de> writes:

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

 It's the IDE.

 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.

 What do you think?

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 <lutger.blijdestijn gmail.com> writes:

BLS wrote:

...
 Our Options :
 1) Force Decent.. (Java/SWT)
 
 2) Use gtkD, create the IDE in D. (the only usable platform independent
   GUI atm.)
 
 3) Use QT and C++. Let's re-use and adapt QT Creator.
 
 Having QT as standard GUI toolkit for D means that we can also reuse the
 QT Designer.
 
 Bjoern

Why not QtD?

BLS <windevguy hotmail.de> writes:

On 11/10/2009 16:54, Lutger wrote:
 BLS wrote:

 ...
 Our Options :
 1) Force Decent.. (Java/SWT)

 2) Use gtkD, create the IDE in D. (the only usable platform independent
    GUI atm.)

 3) Use QT and C++. Let's re-use and adapt QT Creator.

 Having QT as standard GUI toolkit for D means that we can also reuse the
 QT Designer.

 Bjoern

 Why not QtD?

See QtD at dsource ... "No Windows support... we have lost the race 
against the DMD tool chain) Further QtD has no OSX support (AFAIK)

I still hope that Walter has an eye on the QtD situation..

Max Samukha <spambox d-coding.com> writes:

On Sun, 11 Oct 2009 17:49:52 +0200, BLS <windevguy hotmail.de> wrote:

On 11/10/2009 16:54, Lutger wrote:
 BLS wrote:

 ...
 Our Options :
 1) Force Decent.. (Java/SWT)

 2) Use gtkD, create the IDE in D. (the only usable platform independent
    GUI atm.)

 3) Use QT and C++. Let's re-use and adapt QT Creator.

 Having QT as standard GUI toolkit for D means that we can also reuse the
 QT Designer.

 Bjoern

 Why not QtD?

See QtD at dsource ... "No Windows support... we have lost the race 
against the DMD tool chain)

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

 Further QtD has no OSX support (AFAIK)

I still hope that Walter has an eye on the QtD situation..

Someone has succesfully built QtD on OSX but it doesn't work there
out-of-the-box (http://www.dsource.org/projects/qtd/wiki/MacCaseStudy)

Jacob Carlborg <doob me.com> writes:

On 10/11/09 16:38, BLS wrote:
 On 11/10/2009 03:19, Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.

 It's the IDE.

 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).

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

 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.

 What do you think?

 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)

I think this the our best option now

 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.

 Bjoern

"Denis Koroskin" <2korden gmail.com> writes:

On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg <doob me.com> wrote:

 4)
 Port entire eclipse to D, Frank Benoit (who started DWT, the tango  
 version) was thinking of this.

 Bjoern


What's the benefit? I believe it'll become even slower. Much slower.

Jacob Carlborg <doob me.com> writes:

On 10/11/09 22:37, Denis Koroskin wrote:
 On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg <doob me.com> wrote:

 4)
 Port entire eclipse to D, Frank Benoit (who started DWT, the tango
 version) was thinking of this.

 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 <lutger.blijdestijn gmail.com> writes:

Jacob Carlborg wrote:
...
 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 <jeremiep gmail.com> writes:

Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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 <chadjoan __spam.is.bad__gmail.com> writes:

Jeremie Pelletier wrote:
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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 <jeremiep gmail.com> writes:

Chad J wrote:
 Jeremie Pelletier wrote:
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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 <chadjoan __spam.is.bad__gmail.com> writes:

Jeremie Pelletier wrote:
 Chad J wrote:
 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.

 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 :(

 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 ;)

language_fan <foo bar.com.invalid> writes:

Sun, 11 Oct 2009 22:54:39 -0400, Chad J thusly wrote:

 Jeremie Pelletier wrote:
 
 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.


Web 2.0 toolkits are platform neutral. You can define your own GUI with 
javascript & html & css. The interfaces (ajax, javascript, css, html, 
xml) have all been standardized. The objects on the GUI also do not waste 
low level handles like the traditional GUI toolkits do. I am sure that 
more locally usable Web 2.0 desktop applications are coming in the next 
few years.

"Nick Sabalausky" <a a.a> writes:

"language_fan" <foo bar.com.invalid> wrote in message 
news:hav41h$2162$5 digitalmars.com...
 Sun, 11 Oct 2009 22:54:39 -0400, Chad J thusly wrote:

 Jeremie Pelletier wrote:

 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.


 Web 2.0 toolkits are platform neutral. You can define your own GUI with
 javascript & html & css. The interfaces (ajax, javascript, css, html,
 xml) have all been standardized. The objects on the GUI also do not waste
 low level handles like the traditional GUI toolkits do. I am sure that
 more locally usable Web 2.0 desktop applications are coming in the next
 few years.

That stuff is just plain garbage. It inevitably breaks when JS is disabled 
(and there are damn good reasons for doing so), and trying to put web apps 
on the desktop is just plain ass-backwards: web-apps are shit period, people 
should be trying to make desktop apps run on the web instead.

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Mon, Oct 12, 2009 at 04:35:58PM -0400, Nick Sabalausky wrote:
 That stuff is just plain garbage. It inevitably breaks when JS is disabled 
 (and there are damn good reasons for doing so), and trying to put web apps 
 on the desktop is just plain ass-backwards: web-apps are shit period, people 
 should be trying to make desktop apps run on the web instead.

Amen.

One of my personal projects is meant to be a "D Windowing System" with the
hopes of making this happen - when it is usable, I'll post a link to the
newsgroup.

The idea is to take good ideas from Remote Desktop on Windows and X11 on
*nix and combine the best, while cutting out the bad. Then, when you encounter
one of these apps on the web, you just run it locally, like remote X, instead
of in the browser.

Work is going slowly since I'm busy with my paying work the vast majority of
the time, but this is going to be cool.

 

-- 
Adam D. Ruppe
http://arsdnet.net

=?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:

Jeremie Pelletier wrote:
 I agree however that GTK being in C is rather annoying, C is a great=20
 language but GUIs is one area where OOP really shines.

	Note that Gtk *is* object oriented despite being in C...

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

Jeremie Pelletier <jeremiep gmail.com> writes:

Jérôme M. Berger wrote:
 Jeremie Pelletier wrote:
 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.

 
     Note that Gtk *is* object oriented despite being in C...
 
         Jerome

It's a sorry hack, you have to use casts everywhere you'd rely on 
polymorphism in D or C+ and its harder to remember, read, code, 
maintain, and doesn't have any performance gains over C++, the explicit 
struct pointer in C is the implicit 'this' in C++ and non-virtual 
methods can be optimized as direct calls with no vtbl indirections.

I tried gtkD and I don't like using an OOP layer on top of a C interface 
because that adds overhead for the exact same features, most good GUI 
libraries should abstract the platform anyways so GTK is usually only 
seen there and not in user code.

It's still more fun to use than the Windows' windowing API, which 
doesn't even support layout objects such as boxes and grids, now that's 
total pain!

Yigal Chripun <yigal100 gmail.com> writes:

On 12/10/2009 07:33, Jeremie Pelletier wrote:
 Jérôme M. Berger wrote:
 Jeremie Pelletier wrote:
 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.

 Note that Gtk *is* object oriented despite being in C...

 Jerome

 It's a sorry hack, you have to use casts everywhere you'd rely on
 polymorphism in D or C+ and its harder to remember, read, code,
 maintain, and doesn't have any performance gains over C++, the explicit
 struct pointer in C is the implicit 'this' in C++ and non-virtual
 methods can be optimized as direct calls with no vtbl indirections.

 I tried gtkD and I don't like using an OOP layer on top of a C interface
 because that adds overhead for the exact same features, most good GUI
 libraries should abstract the platform anyways so GTK is usually only
 seen there and not in user code.

 It's still more fun to use than the Windows' windowing API, which
 doesn't even support layout objects such as boxes and grids, now that's
 total pain!

what about MS' WPF? It has all the bells and whistles of modern UI, 
doesn't it?

Jeremie Pelletier <jeremiep gmail.com> writes:

Yigal Chripun wrote:
 On 12/10/2009 07:33, Jeremie Pelletier wrote:
 Jérôme M. Berger wrote:
 Jeremie Pelletier wrote:
 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.

 Note that Gtk *is* object oriented despite being in C...

 Jerome

 It's a sorry hack, you have to use casts everywhere you'd rely on
 polymorphism in D or C+ and its harder to remember, read, code,
 maintain, and doesn't have any performance gains over C++, the explicit
 struct pointer in C is the implicit 'this' in C++ and non-virtual
 methods can be optimized as direct calls with no vtbl indirections.

 I tried gtkD and I don't like using an OOP layer on top of a C interface
 because that adds overhead for the exact same features, most good GUI
 libraries should abstract the platform anyways so GTK is usually only
 seen there and not in user code.

 It's still more fun to use than the Windows' windowing API, which
 doesn't even support layout objects such as boxes and grids, now that's
 total pain!

 
 what about MS' WPF? It has all the bells and whistles of modern UI, 
 doesn't it?

Isn't that just a pretty layer on top of win32/com? I now only use 
native toolkits as backends for my gui abstraction layer, using this 
would only add a level of indirection and make no sense.

"Denis Koroskin" <2korden gmail.com> writes:

On Mon, 12 Oct 2009 19:18:41 +0400, Jeremie Pelletier <jeremiep gmail.co=
m>  =

wrote:

 Yigal Chripun wrote:
 On 12/10/2009 07:33, Jeremie Pelletier wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
 Jeremie Pelletier wrote:
 I agree however that GTK being in C is rather annoying, C is a gre=





at
 language but GUIs is one area where OOP really shines.

 Note that Gtk *is* object oriented despite being in C...

 Jerome

 It's a sorry hack, you have to use casts everywhere you'd rely on
 polymorphism in D or C+ and its harder to remember, read, code,
 maintain, and doesn't have any performance gains over C++, the expli=



cit
 struct pointer in C is the implicit 'this' in C++ and non-virtual
 methods can be optimized as direct calls with no vtbl indirections.

 I tried gtkD and I don't like using an OOP layer on top of a C  =



 interface
 because that adds overhead for the exact same features, most good GU=



I
 libraries should abstract the platform anyways so GTK is usually onl=



y
 seen there and not in user code.

 It's still more fun to use than the Windows' windowing API, which
 doesn't even support layout objects such as boxes and grids, now tha=



t's
 total pain!

  what about MS' WPF? It has all the bells and whistles of modern UI, =


 =

 doesn't it?

 Isn't that just a pretty layer on top of win32/com? I now only use  =

 native toolkits as backends for my gui abstraction layer, using this  =

 would only add a level of indirection and make no sense.

No, IIRC, it doesn't rely on Win32 API at all:

Wikipedia quote:
 Designed to remove dependencies on the aging GDI subsystem, WPF is bui=

lt  =

 on DirectX, which provides hardware acceleration and enables modern UI=

  =

 features like transparency, gradients and transforms.

Jeremie Pelletier <jeremiep gmail.com> writes:

Denis Koroskin wrote:
 On Mon, 12 Oct 2009 19:18:41 +0400, Jeremie Pelletier 
 <jeremiep gmail.com> wrote:
 
 Yigal Chripun wrote:
 On 12/10/2009 07:33, Jeremie Pelletier wrote:
 Jérôme M. Berger wrote:
 Jeremie Pelletier wrote:
 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.

 Note that Gtk *is* object oriented despite being in C...

 Jerome

 It's a sorry hack, you have to use casts everywhere you'd rely on
 polymorphism in D or C+ and its harder to remember, read, code,
 maintain, and doesn't have any performance gains over C++, the explicit
 struct pointer in C is the implicit 'this' in C++ and non-virtual
 methods can be optimized as direct calls with no vtbl indirections.

 I tried gtkD and I don't like using an OOP layer on top of a C 
 interface
 because that adds overhead for the exact same features, most good GUI
 libraries should abstract the platform anyways so GTK is usually only
 seen there and not in user code.

 It's still more fun to use than the Windows' windowing API, which
 doesn't even support layout objects such as boxes and grids, now that's
 total pain!

  what about MS' WPF? It has all the bells and whistles of modern UI, 
 doesn't it?

 Isn't that just a pretty layer on top of win32/com? I now only use 
 native toolkits as backends for my gui abstraction layer, using this 
 would only add a level of indirection and make no sense.

 
 No, IIRC, it doesn't rely on Win32 API at all:
 
 Wikipedia quote:
 Designed to remove dependencies on the aging GDI subsystem, WPF is 
 built on DirectX, which provides hardware acceleration and enables 
 modern UI features like transparency, gradients and transforms.


Oh, I need to look into that!

Ary Borenszweig <ary esperanto.org.ar> writes:

Jeremie Pelletier wrote:
 Denis Koroskin wrote:
 On Mon, 12 Oct 2009 19:18:41 +0400, Jeremie Pelletier 
 <jeremiep gmail.com> wrote:

 Yigal Chripun wrote:
 On 12/10/2009 07:33, Jeremie Pelletier wrote:
 Jérôme M. Berger wrote:
 Jeremie Pelletier wrote:
 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.

 Note that Gtk *is* object oriented despite being in C...

 Jerome

 It's a sorry hack, you have to use casts everywhere you'd rely on
 polymorphism in D or C+ and its harder to remember, read, code,
 maintain, and doesn't have any performance gains over C++, the 
 explicit
 struct pointer in C is the implicit 'this' in C++ and non-virtual
 methods can be optimized as direct calls with no vtbl indirections.

 I tried gtkD and I don't like using an OOP layer on top of a C 
 interface
 because that adds overhead for the exact same features, most good GUI
 libraries should abstract the platform anyways so GTK is usually only
 seen there and not in user code.

 It's still more fun to use than the Windows' windowing API, which
 doesn't even support layout objects such as boxes and grids, now 
 that's
 total pain!

  what about MS' WPF? It has all the bells and whistles of modern UI, 
 doesn't it?

 Isn't that just a pretty layer on top of win32/com? I now only use 
 native toolkits as backends for my gui abstraction layer, using this 
 would only add a level of indirection and make no sense.

 No, IIRC, it doesn't rely on Win32 API at all:

 Wikipedia quote:
 Designed to remove dependencies on the aging GDI subsystem, WPF is 
 built on DirectX, which provides hardware acceleration and enables 
 modern UI features like transparency, gradients and transforms.


 
 Oh, I need to look into that!

Yeah, we made a game in WPF in the company I work for, using bindings 
(*the* feature of WPF): it was sluggish. From the start I recommended 
doing it in a lower-level language (I recommended D!) but no one 
listened to me. It runs pretty slow with an amazing computer. I don't 
like WPF (nor Siliveright). :-P

"Nick Sabalausky" <a a.a> writes:

"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:havvl7$1tlv$1 digitalmars.com...
 Yeah, we made a game in WPF in the company I work for, using bindings 
 (*the* feature of WPF): it was sluggish. From the start I recommended 
 doing it in a lower-level language (I recommended D!) but no one listened 
 to me. It runs pretty slow with an amazing computer. I don't like WPF (nor 
 Siliveright). :-P

Is that related to, or the same as, the win forms library from .NET? Because 
I've found that to be horribly broken for anyone that uses a light-on-dark 
color scheme. Certain limitations of it make it impossible to prevent 
certain things from exhibiting invisible-text-syndrome on such a setup, 
which inevitably results in an app that's just horribly unprofessional. 

"Denis Koroskin" <2korden gmail.com> writes:

On Tue, 13 Oct 2009 00:42:51 +0400, Nick Sabalausky <a a.a> wrote:

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message
 news:havvl7$1tlv$1 digitalmars.com...
 Yeah, we made a game in WPF in the company I work for, using bindings
 (*the* feature of WPF): it was sluggish. From the start I recommended
 doing it in a lower-level language (I recommended D!) but no one  
 listened
 to me. It runs pretty slow with an amazing computer. I don't like WPF  
 (nor
 Siliveright). :-P

 Is that related to, or the same as, the win forms library from .NET?  
 Because
 I've found that to be horribly broken for anyone that uses a  
 light-on-dark
 color scheme. Certain limitations of it make it impossible to prevent
 certain things from exhibiting invisible-text-syndrome on such a setup,
 which inevitably results in an app that's just horribly unprofessional.

No, they are not related in any way. They are two completely different GUI  
toolkits.

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Oct 12, 2009 at 1:42 PM, Nick Sabalausky <a a.a> wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message
 news:havvl7$1tlv$1 digitalmars.com...
 Yeah, we made a game in WPF in the company I work for, using bindings
 (*the* feature of WPF): it was sluggish. From the start I recommended
 doing it in a lower-level language (I recommended D!) but no one listened
 to me. It runs pretty slow with an amazing computer. I don't like WPF (nor
 Siliveright). :-P

 Is that related to, or the same as, the win forms library from .NET? Because
 I've found that to be horribly broken for anyone that uses a light-on-dark
 color scheme. Certain limitations of it make it impossible to prevent
 certain things from exhibiting invisible-text-syndrome on such a setup,
 which inevitably results in an app that's just horribly unprofessional.

WinForms is a managed code wrapper around native win32 widgets.  Kinda

WPF doesn't wrap native widgets and uses XML for everything.   But
both are for the CLR.  So if you want to use them with C++ it has to
be managed C++ (aka C++/CLI).  My understanding is that WPF is
supposed to supersede WinForms, but it seems to me like they appeal to
different audiences.  (Like people who want professional
native-looking apps, vs the people who think the Windows Media Player
has a nice  interface).

--bb

"Nick Sabalausky" <a a.a> writes:

"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.177.1255384255.20261.digitalmars-d puremagic.com...
 My understanding is that WPF is
 supposed to supersede WinForms, but it seems to me like they appeal to
 different audiences.  (Like people who want professional
 native-looking apps, vs the people who think the Windows Media Player
 has a nice  interface).

Hee hee hee, I like how you put that :) 

Jacob Carlborg <doob me.com> writes:

On 10/12/09 04:14, Chad J wrote:
 Jeremie Pelletier wrote:
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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 ;)

Why not have a GUI toolkit available on almost all platforms that uses 
native controls just like DWT?

language_fan <foo bar.com.invalid> writes:

Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 04:14, Chad J wrote:
 Too bad we can't just make programs switch between GUI backends at will
 ;)

 
 Why not have a GUI toolkit available on almost all platforms that uses
 native controls just like DWT?

The list of native platforms SWT supports is this:

Win32
  WPF (under development)
AIX, FreeBSD, Linux, HP-UX, Solaris: 
  Motif
  GTK+
Mac OS X: 
  Carbon
  Cocoa
QNX Photon
Pocket PC

As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to 
see how SWT is more native than the ones I develop for. All SWT 
applications look weird, unthemed, and have horrible usability issues in 
the file open/save dialogs. DWT brings another level of cruft above the 
"lightweight" SWT and performs badly.

Jacob Carlborg <doob me.com> writes:

On 10/12/09 14:11, language_fan wrote:
 Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 04:14, Chad J wrote:
 Too bad we can't just make programs switch between GUI backends at will
 ;)

 Why not have a GUI toolkit available on almost all platforms that uses
 native controls just like DWT?

 The list of native platforms SWT supports is this:

 Win32
    WPF (under development)
 AIX, FreeBSD, Linux, HP-UX, Solaris:
    Motif
    GTK+
 Mac OS X:
    Carbon
    Cocoa
 QNX Photon
 Pocket PC

 As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
 see how SWT is more native than the ones I develop for. All SWT
 applications look weird, unthemed, and have horrible usability issues in
 the file open/save dialogs. DWT brings another level of cruft above the
 "lightweight" SWT and performs badly.

As a said previously SWT is more native because it uses the native GUI 
library available on the current platform, for windows (before vista) 
win32, osx cocoa and on linux gtk. It doesn't decide how a button should 
look, it doesn't try do draw a button that is similar to the natives, it 
just call the native library to draw the button.

I don't know what you mean by "unthemed" but if you refer to that 
applications on windows don't get the winxp look you have the same 
problem if you create the application in c++ or c and uses win32. It's 
caused by an older dll is loaded as default and to get the winxp look 
you have to request it to load the newer dll with a manifest file. 
Welcome to dlls.

If you have problems with the open/save dialogs in SWT either you will 
have the same problem in other native applications because it uses the 
native dialogs or there's a bug in SWT.

DWT doesn't add any extra levels that SWT doesn't have. In fact it 
removes one, the jni wrappers. DWT is a complete port of SWT to D, with 
only native code.

language_fan <foo bar.com.invalid> writes:

Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 14:11, language_fan wrote:
 Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 04:14, Chad J wrote:
 Too bad we can't just make programs switch between GUI backends at
 will ;)

 Why not have a GUI toolkit available on almost all platforms that uses
 native controls just like DWT?

 The list of native platforms SWT supports is this:

 Win32
    WPF (under development)
 AIX, FreeBSD, Linux, HP-UX, Solaris:
    Motif
    GTK+
 Mac OS X:
    Carbon
    Cocoa
 QNX Photon
 Pocket PC

 As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
 see how SWT is more native than the ones I develop for. All SWT
 applications look weird, unthemed, and have horrible usability issues
 in the file open/save dialogs. DWT brings another level of cruft above
 the "lightweight" SWT and performs badly.

 
 As a said previously SWT is more native because it uses the native GUI
 library available on the current platform, for windows (before vista)
 win32, osx cocoa and on linux gtk. It doesn't decide how a button should
 look, it doesn't try do draw a button that is similar to the natives, it
 just call the native library to draw the button.

The problem is, 99% of win32 users use the win32 gui toolkit on win32, 
99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It 
is not The native toolkit to use. I do not even have it installed on my 
system.

 I don't know what you mean by "unthemed" but if you refer to that
 applications on windows don't get the winxp look you have the same
 problem if you create the application in c++ or c and uses win32. It's
 caused by an older dll is loaded as default and to get the winxp look
 you have to request it to load the newer dll with a manifest file.
 Welcome to dlls.

I mostly work on *nixen. The unthemed means that I do not have *any* gtk+ 
libraries installed anywhere so it defaults to the ugly default theme. To 
me gtk+ does not have the native feel as I never see any application 
written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing, 
and (forked) Harmonia}. I am sorry if you have trouble reading that. 
Whenever an application comes with its own (statically linked) gtk+ libs, 
it will look bad. I do not have any "control panel" to change the look 
and feel of the gtk+ applications.

 
 If you have problems with the open/save dialogs in SWT either you will
 have the same problem in other native applications because it uses the
 native dialogs or there's a bug in SWT.

Look, this is what I get on Win32:

http://johnbokma.com/textpad/select-a-file-dialog.png

on Linux:

http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
kdefilechooser.png

on Java:

http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
components/FileChooserOpenMetal.png

You can probably see something that I have started to call 'consistency'. 
Almost the same buttons and layouts on every platform. I immediately know 
how it works. The same design has been there since Windows 95, if I 
recall correctly. This is what many people have learned to live with.

Now every time I see a gtk+/swt/dwt application I wonder where the heck 
that unintuitive terrible piece of cr*p came:

http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
graphics/14fig03.gif

Native? It might very well use native binaries on my platform, but the 
native feel ends there.

Jeremie Pelletier <jeremiep gmail.com> writes:

language_fan wrote:
 Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:
 
 On 10/12/09 14:11, language_fan wrote:
 Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 04:14, Chad J wrote:
 Too bad we can't just make programs switch between GUI backends at
 will ;)

 Why not have a GUI toolkit available on almost all platforms that uses
 native controls just like DWT?

 The list of native platforms SWT supports is this:

 Win32
    WPF (under development)
 AIX, FreeBSD, Linux, HP-UX, Solaris:
    Motif
    GTK+
 Mac OS X:
    Carbon
    Cocoa
 QNX Photon
 Pocket PC

 As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
 see how SWT is more native than the ones I develop for. All SWT
 applications look weird, unthemed, and have horrible usability issues
 in the file open/save dialogs. DWT brings another level of cruft above
 the "lightweight" SWT and performs badly.

 As a said previously SWT is more native because it uses the native GUI
 library available on the current platform, for windows (before vista)
 win32, osx cocoa and on linux gtk. It doesn't decide how a button should
 look, it doesn't try do draw a button that is similar to the natives, it
 just call the native library to draw the button.

 
 The problem is, 99% of win32 users use the win32 gui toolkit on win32, 
 99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It 
 is not The native toolkit to use. I do not even have it installed on my 
 system.
 
 I don't know what you mean by "unthemed" but if you refer to that
 applications on windows don't get the winxp look you have the same
 problem if you create the application in c++ or c and uses win32. It's
 caused by an older dll is loaded as default and to get the winxp look
 you have to request it to load the newer dll with a manifest file.
 Welcome to dlls.

 
 I mostly work on *nixen. The unthemed means that I do not have *any* gtk+ 
 libraries installed anywhere so it defaults to the ugly default theme. To 
 me gtk+ does not have the native feel as I never see any application 
 written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing, 
 and (forked) Harmonia}. I am sorry if you have trouble reading that. 
 Whenever an application comes with its own (statically linked) gtk+ libs, 
 it will look bad. I do not have any "control panel" to change the look 
 and feel of the gtk+ applications.
 
 If you have problems with the open/save dialogs in SWT either you will
 have the same problem in other native applications because it uses the
 native dialogs or there's a bug in SWT.

 
 Look, this is what I get on Win32:
 
 http://johnbokma.com/textpad/select-a-file-dialog.png
 
 on Linux:
 
 http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
 kdefilechooser.png
 
 on Java:
 
 http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
 components/FileChooserOpenMetal.png
 
 You can probably see something that I have started to call 'consistency'. 
 Almost the same buttons and layouts on every platform. I immediately know 
 how it works. The same design has been there since Windows 95, if I 
 recall correctly. This is what many people have learned to live with.
 
 Now every time I see a gtk+/swt/dwt application I wonder where the heck 
 that unintuitive terrible piece of cr*p came:
 
 http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
 graphics/14fig03.gif
 
 Native? It might very well use native binaries on my platform, but the 
 native feel ends there.

I get an entirely different file dialog on win7, and my gnome dialog on 
ubuntu looks nothing like the screenshot you linked.

This is the win7 dialog:
http://i.msdn.microsoft.com/Dd758094.Libraries_CommonFileDialog%28en-us,VS.85%29.png

This is close to what I have on ubuntu:
http://blogs.gnome.org/mortenw/wp-content/blogs.dir/26/files/2009/02/file-dialog2.png

I have no Qt or KDE on both my linux installs (ubuntu 9 and a cross 
linux from scratch), the GUI looks smooth and works great, using the 
latest gnome 2.6 libraries.

Why don't you install GTK+? You can't whine about applications built for 
gnome looking ugly if you don't have gtk installed, it can live pretty 
well alongside Qt, I used to do that until i switched to gnome after 2.6 
was released.

language_fan <foo bar.com.invalid> writes:

Mon, 12 Oct 2009 13:54:53 -0400, Jeremie Pelletier thusly wrote:

 language_fan wrote:
 I get an entirely different file dialog on win7, and my gnome dialog on
 ubuntu looks nothing like the screenshot you linked.
 
 This is the win7 dialog:
 http://i.msdn.microsoft.com/Dd758094.Libraries_CommonFileDialog%28en-

us,VS.85%29.png

This is pretty good in my book.

 This is close to what I have on ubuntu:
 http://blogs.gnome.org/mortenw/wp-content/blogs.dir/26/files/2009/02/

file-dialog2.png

Yuck.

 
 I have no Qt or KDE on both my linux installs (ubuntu 9 and a cross
 linux from scratch), the GUI looks smooth and works great, using the
 latest gnome 2.6 libraries.
 
 Why don't you install GTK+? You can't whine about applications built for
 gnome looking ugly if you don't have gtk installed, it can live pretty
 well alongside Qt, I used to do that until i switched to gnome after 2.6
 was released.

I have little desire to embrace inferior technologies. Attempting OOP on 
C is ridiculous, it should be called POOP. It is a personal choice. 
Besides FLTK2/Qt work pays well enough. I also have no time for desktop 
environment wars, tyvm. GTK+ != Gnome, as you well might know. I simply 
have no reason to install libgtk* since no package depends on them.

Jeremie Pelletier <jeremiep gmail.com> writes:

language_fan wrote:
 Mon, 12 Oct 2009 13:54:53 -0400, Jeremie Pelletier thusly wrote:
 
 language_fan wrote:
 I get an entirely different file dialog on win7, and my gnome dialog on
 ubuntu looks nothing like the screenshot you linked.

 This is the win7 dialog:
 http://i.msdn.microsoft.com/Dd758094.Libraries_CommonFileDialog%28en-

 us,VS.85%29.png
 
 This is pretty good in my book.
 
 This is close to what I have on ubuntu:
 http://blogs.gnome.org/mortenw/wp-content/blogs.dir/26/files/2009/02/

 file-dialog2.png
 
 Yuck.
 
 I have no Qt or KDE on both my linux installs (ubuntu 9 and a cross
 linux from scratch), the GUI looks smooth and works great, using the
 latest gnome 2.6 libraries.

 Why don't you install GTK+? You can't whine about applications built for
 gnome looking ugly if you don't have gtk installed, it can live pretty
 well alongside Qt, I used to do that until i switched to gnome after 2.6
 was released.

 
 I have little desire to embrace inferior technologies. Attempting OOP on 
 C is ridiculous, it should be called POOP. It is a personal choice. 
 Besides FLTK2/Qt work pays well enough. I also have no time for desktop 
 environment wars, tyvm. GTK+ != Gnome, as you well might know. I simply 
 have no reason to install libgtk* since no package depends on them.

I don't know if you're talking about gtk 1 or 2, I don't have gtk1 
installed but gtk2 is always one of the first package i build when I 
create a linux from scratch, so many things depend on it.

I never had any issues using gnome without qt, yet I had plenty using 
KDE without gtk. Its just a matter of what software you build, I usually 
don't like the feel of KDE applications, its a matter of preferences there.

I agree that gnome being coded in C is plain ugly in the code, but the 
results are still very convenient to use. Oh and I know gtk != gnome, 
but its been a while since it left gimp to become part of the gnome set 
of libraries.

grauzone <none example.net> writes:

language_fan wrote:
 I have little desire to embrace inferior technologies. Attempting OOP on 
 C is ridiculous, it should be called POOP. It is a personal choice. 


model as base: http://live.gnome.org/Vala

Jacob Carlborg <doob me.com> writes:

On 10/12/09 19:41, language_fan wrote:
 Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 14:11, language_fan wrote:
 Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:

 On 10/12/09 04:14, Chad J wrote:
 Too bad we can't just make programs switch between GUI backends at
 will ;)

 Why not have a GUI toolkit available on almost all platforms that uses
 native controls just like DWT?

 The list of native platforms SWT supports is this:

 Win32
     WPF (under development)
 AIX, FreeBSD, Linux, HP-UX, Solaris:
     Motif
     GTK+
 Mac OS X:
     Carbon
     Cocoa
 QNX Photon
 Pocket PC

 As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
 see how SWT is more native than the ones I develop for. All SWT
 applications look weird, unthemed, and have horrible usability issues
 in the file open/save dialogs. DWT brings another level of cruft above
 the "lightweight" SWT and performs badly.

 As a said previously SWT is more native because it uses the native GUI
 library available on the current platform, for windows (before vista)
 win32, osx cocoa and on linux gtk. It doesn't decide how a button should
 look, it doesn't try do draw a button that is similar to the natives, it
 just call the native library to draw the button.

 The problem is, 99% of win32 users use the win32 gui toolkit on win32,
 99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It
 is not The native toolkit to use. I do not even have it installed on my
 system.

 I don't know what you mean by "unthemed" but if you refer to that
 applications on windows don't get the winxp look you have the same
 problem if you create the application in c++ or c and uses win32. It's
 caused by an older dll is loaded as default and to get the winxp look
 you have to request it to load the newer dll with a manifest file.
 Welcome to dlls.

 I mostly work on *nixen. The unthemed means that I do not have *any* gtk+
 libraries installed anywhere so it defaults to the ugly default theme. To
 me gtk+ does not have the native feel as I never see any application
 written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing,
 and (forked) Harmonia}. I am sorry if you have trouble reading that.
 Whenever an application comes with its own (statically linked) gtk+ libs,
 it will look bad. I do not have any "control panel" to change the look
 and feel of the gtk+ applications.

 If you have problems with the open/save dialogs in SWT either you will
 have the same problem in other native applications because it uses the
 native dialogs or there's a bug in SWT.

 Look, this is what I get on Win32:

 http://johnbokma.com/textpad/select-a-file-dialog.png

 on Linux:

 http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
 kdefilechooser.png

 on Java:

 http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
 components/FileChooserOpenMetal.png

 You can probably see something that I have started to call 'consistency'.
 Almost the same buttons and layouts on every platform. I immediately know
 how it works. The same design has been there since Windows 95, if I
 recall correctly. This is what many people have learned to live with.

 Now every time I see a gtk+/swt/dwt application I wonder where the heck
 that unintuitive terrible piece of cr*p came:

 http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
 graphics/14fig03.gif

 Native? It might very well use native binaries on my platform, but the
 native feel ends there.

Of course it will look strange when you use an application built on a 
toolkit it isn't built for. Will have to wait for a Qt version.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

language_fan wrote:
 
 Look, this is what I get on Win32:
 
 http://johnbokma.com/textpad/select-a-file-dialog.png
 
 on Linux:
 
 http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
 kdefilechooser.png
 
 on Java:
 
 http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
 components/FileChooserOpenMetal.png
 
 You can probably see something that I have started to call 'consistency'. 
 Almost the same buttons and layouts on every platform. I immediately know 
 how it works. The same design has been there since Windows 95, if I 
 recall correctly. This is what many people have learned to live with.
 
 Now every time I see a gtk+/swt/dwt application I wonder where the heck 
 that unintuitive terrible piece of cr*p came:
 
 http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
 graphics/14fig03.gif
 
 Native? It might very well use native binaries on my platform, but the 
 native feel ends there.

Um.  It's even worse for me.  Yours may not look native, but at least it
doesn't look like the sh*t gtk gives me:

http://post-boredom.net/filedialog/lolwut.png



By comparison, my native look and feel (kde4):

http://post-boredom.net/filedialog/muchbetter.png

Qt gets this right.

Christopher Wright <dhasenan gmail.com> writes:

language_fan wrote:
 Now every time I see a gtk+/swt/dwt application I wonder where the heck 
 that unintuitive terrible piece of cr*p came:
 
 http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
 graphics/14fig03.gif

2002, maybe?

"Nick Sabalausky" <a a.a> writes:

Jeremie Pelletier" <jeremiep gmail.com> wrote in message 
news:hats2b$as0$1 digitalmars.com...
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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. 

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Oct 12, 2009 at 12:22 AM, Nick Sabalausky <a a.a> wrote:
 Jeremie Pelletier" <jeremiep gmail.com> wrote in message
 news:hats2b$as0$1 digitalmars.com...
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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.

..huh? What OS are you on? It looks perfectly native on XP, Ubuntu,
and Kubuntu for me..

Jeremie Pelletier <jeremiep gmail.com> writes:

Jarrett Billingsley wrote:
 On Mon, Oct 12, 2009 at 12:22 AM, Nick Sabalausky <a a.a> wrote:
 Jeremie Pelletier" <jeremiep gmail.com> wrote in message
 news:hats2b$as0$1 digitalmars.com...
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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.

 
 ..huh? What OS are you on? It looks perfectly native on XP, Ubuntu,
 and Kubuntu for me..

Same here, Firefox/Thunderbird looks great in 7 and Ubuntu. Of course if 
you are using KDE and build firefox against GTK you won't have the look 
you're expecting, you need to build firefox against Qt for that :)

"Nick Sabalausky" <a a.a> writes:

"Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message 
news:mailman.164.1255324638.20261.digitalmars-d puremagic.com...
 On Mon, Oct 12, 2009 at 12:22 AM, Nick Sabalausky <a a.a> wrote:
 Jeremie Pelletier" <jeremiep gmail.com> wrote in message
 news:hats2b$as0$1 digitalmars.com...
 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.

 ..huh? What OS are you on? It looks perfectly native on XP, Ubuntu,
 and Kubuntu for me..

XP

Don <nospam nospam.com> writes:

Nick Sabalausky wrote:
 Jeremie Pelletier" <jeremiep gmail.com> wrote in message 
 news:hats2b$as0$1 digitalmars.com...
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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. 

Are you talking about FF 3.5? It's a really poor product. Crashes all 
the time, has some terrible UI misfeatures. I'm really amazed they 
shipped it in that condition.

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Oct 12, 2009 at 3:39 AM, Don <nospam nospam.com> wrote:
 Are you talking about FF 3.5? It's a really poor product. Crashes all the
 time, has some terrible UI misfeatures. I'm really amazed they shipped it in
 that condition.

I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY
unresponsive, uses 3-4 times as much memory as FF3, flash videos don't
play without hiccuping every five seconds, and it would just go into
infinite loops or something and become completely unresponsive. I
actually downgraded to 3.0 and it was like a new browser again! :P

Ary Borenszweig <ary esperanto.org.ar> writes:

Jarrett Billingsley wrote:
 On Mon, Oct 12, 2009 at 3:39 AM, Don <nospam nospam.com> wrote:
 Are you talking about FF 3.5? It's a really poor product. Crashes all the
 time, has some terrible UI misfeatures. I'm really amazed they shipped it in
 that condition.

 
 I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY
 unresponsive, uses 3-4 times as much memory as FF3, flash videos don't
 play without hiccuping every five seconds, and it would just go into
 infinite loops or something and become completely unresponsive. I
 actually downgraded to 3.0 and it was like a new browser again! :P

Me too. And when clicking a tab sometimes it will make a whole new 
window out of it. There's even an extension to fix that! :-P

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Oct 12, 2009 at 3:23 PM, Ary Borenszweig <ary esperanto.org.ar> wrote:
 Jarrett Billingsley wrote:
 On Mon, Oct 12, 2009 at 3:39 AM, Don <nospam nospam.com> wrote:
 Are you talking about FF 3.5? It's a really poor product. Crashes all the
 time, has some terrible UI misfeatures. I'm really amazed they shipped it
 in
 that condition.

 I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY
 unresponsive, uses 3-4 times as much memory as FF3, flash videos don't
 play without hiccuping every five seconds, and it would just go into
 infinite loops or something and become completely unresponsive. I
 actually downgraded to 3.0 and it was like a new browser again! :P

 Me too. And when clicking a tab sometimes it will make a whole new window
 out of it. There's even an extension to fix that! :-P

Yes OMG I hate that. Sometimes I don't even have to click the tab,
just middle-click-scrolling will do that. I wasn't aware there was
even an extension :P

Ary Borenszweig <ary esperanto.org.ar> writes:

Jarrett Billingsley wrote:
 On Mon, Oct 12, 2009 at 3:23 PM, Ary Borenszweig <ary esperanto.org.ar> wrote:
 Jarrett Billingsley wrote:
 On Mon, Oct 12, 2009 at 3:39 AM, Don <nospam nospam.com> wrote:
 Are you talking about FF 3.5? It's a really poor product. Crashes all the
 time, has some terrible UI misfeatures. I'm really amazed they shipped it
 in
 that condition.

 I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY
 unresponsive, uses 3-4 times as much memory as FF3, flash videos don't
 play without hiccuping every five seconds, and it would just go into
 infinite loops or something and become completely unresponsive. I
 actually downgraded to 3.0 and it was like a new browser again! :P

 Me too. And when clicking a tab sometimes it will make a whole new window
 out of it. There's even an extension to fix that! :-P

 
 Yes OMG I hate that. Sometimes I don't even have to click the tab,
 just middle-click-scrolling will do that. I wasn't aware there was
 even an extension :P

Here it is: https://addons.mozilla.org/en-US/firefox/addon/12276

But I eventually uninstalled it because Firefox started working very 
weired. But maybe that's just FF and not the extension.

I think they are trying to copy Chrome's features, I don't know why... I 
always want to have my tabs in a single window, why would I want to go 
back to IE6?

"Nick Sabalausky" <a a.a> writes:

"Don" <nospam nospam.com> wrote in message 
news:haumhk$1oet$1 digitalmars.com...
 Nick Sabalausky wrote:
 Jeremie Pelletier" <jeremiep gmail.com> wrote in message 
 news:hats2b$as0$1 digitalmars.com...
 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.

 Are you talking about FF 3.5? It's a really poor product. Crashes all the 
 time, has some terrible UI misfeatures. I'm really amazed they shipped it 
 in that condition.

Never touched FF3.5, I tried FF3 and it was such a worthless POS I went back 
to FF2, which is still a total POS, or course, but at least this way I have 
separate back/forward dropdowns, winestripe actually works, and I have no 
awfulbar *without* needing an anti-awfulbar addon (mozilla's standard 
strategy: force idiotic ill-conceived changes on everyone and rely on 
third-party add-on hacks for anyone who wants it fixed).

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:haumhk$1oet$1 digitalmars.com...
 Nick Sabalausky wrote:
 Jeremie Pelletier" <jeremiep gmail.com> wrote in message 
 news:hats2b$as0$1 digitalmars.com...
 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.

 Are you talking about FF 3.5? It's a really poor product. Crashes all the 
 time, has some terrible UI misfeatures. I'm really amazed they shipped it 
 in that condition.

 
 Never touched FF3.5, I tried FF3 and it was such a worthless POS I went back 
 to FF2, which is still a total POS, or course, but at least this way I have 
 separate back/forward dropdowns, winestripe actually works, and I have no 
 awfulbar *without* needing an anti-awfulbar addon (mozilla's standard 
 strategy: force idiotic ill-conceived changes on everyone and rely on 
 third-party add-on hacks for anyone who wants it fixed).


Um, so why are you still using FF at all? :)

-Lars

"Nick Sabalausky" <a a.a> writes:

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:hb05lr$2bv5$2 digitalmars.com...
 Nick Sabalausky wrote:
 Never touched FF3.5, I tried FF3 and it was such a worthless POS I went 
 back to FF2, which is still a total POS, or course, but at least this way 
 I have separate back/forward dropdowns, winestripe actually works, and I 
 have no awfulbar *without* needing an anti-awfulbar addon (mozilla's 
 standard strategy: force idiotic ill-conceived changes on everyone and 
 rely on third-party add-on hacks for anyone who wants it fixed).


 Um, so why are you still using FF at all? :)

Very good question actually. In short: As badly as FF sucks, everything else 
sucks even more.

The main reason: For me, the web would be completely unusable without 
AdBlock Plus, NoScript and BetterPrivacy (For the record, I don't have a 
problem with ads on web pages, as long as they're 100% static, zero 
animation, zero sound, zero DHTML, zero of those 
ads-that-look-like-links-embedded-into-the-actual-text-content, and don't 
take up half the page.) Repagination, Linkification, DownloadHelper, 
DownThemAll, BugMeNot and TabMix Plus are...not strictly essential...but 
still things I'd rather not have to go without. This stuff rules out IE 
(very limited in customization and available add-ons), Opera (the alleged 
add-on system is a pathetic joke), and Safari (Customization in an Apple 
app? Ah ha ha ha ha ha!).

Plus there's a *lot* of other details on how I like to have things set up 
that nothing but FF allows me to do (even though it often requires an addon, 
such as TabMix Plus). This rules out all the ones aboves, plus Chrome. So 
for all practical purposes, that only leaves FF.

Secondary reason: I *HATE* apps that force a skin down my throat, even more 
than I hate GTK apps (at least GTK makes a small token effort to look 
vaguely like my system is supposed to look). This provides further strikes 
against Chrome and Safari.

Chrome also forces an extra always-resident process onto my system whether I 
want it or not. (I don't. And I don't give a crap what feature it may 
provide.)

And Safari, of course, has even more strikes against it, but Safari's such a 
joke anyway its not even worth mentioning any further.

Jacob Carlborg <doob me.com> writes:

On 10/12/09 02:08, Jeremie Pelletier wrote:
 Lutger wrote:
 Jacob Carlborg wrote:
 ...
 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.

In the Mac version for a long time they used the older tabs from Mac OS 
X 10.4 or even older. That's the problem not using native controls, if 
the operating system change them it's a lot of more work to update your 
application.

Jason House <jason.james.house gmail.com> writes:

Walter Bright Wrote:

 In my discussions with companies about adopting D, the major barrier 
 that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are 
 overbalanced by the loss of productivity by moving away from an IDE. And 
 what is it about an IDE that is so productive? Intellisense (Microsoft's 
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can 
 help. dmd already puts out .doc and .di files. How about putting out an 
 xml file giving all the information needed for an IDE to implement 
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse, 
 xml is trivial. Furthermore, an xml format would be fairly robust in the 
 face of changes to D syntax.
 
 What do you think?

Which phases of compilation must finish for the generated information? How
error tolerant will this process be? If a statement is incompletely typed, will
there be useful output? etc...

Leandro Lucarella <llucax gmail.com> writes:

Walter Bright, el 10 de octubre a las 18:19 me escribiste:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are
 important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE.
 And what is it about an IDE that is so productive? Intellisense
 (Microsoft's word for autocompletion).

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

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ah, se va en 1981? Pero por qué? ... Ah, porque ya había sido determinado,
entonces quiere decir que pronto vamos a elegir presidente nuevo nosot...
Ah, nosotros no? Ah, lo van a elegir en la ... Ah! Quiere que le diga? Muy
bien pensado, porque cada vez que lo elegimos nosotros no duran nada!
	-- Tato vs. Tato (1980, Gobierno de Videla)

Walter Bright <newshound1 digitalmars.com> writes:

Leandro Lucarella wrote:
 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 <llucax gmail.com> writes:

Walter Bright, el 11 de octubre a las 12:40 me escribiste:
 Leandro Lucarella wrote:
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

language_fan <foo bar.com.invalid> writes:

Sun, 11 Oct 2009 16:07:44 -0300, Leandro Lucarella thusly wrote:

 Walter Bright, el 10 de octubre a las 18:19 me escribiste:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE.
 And what is it about an IDE that is so productive? Intellisense
 (Microsoft's word for autocompletion).

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

What can I say, the larger the enterprise, the larger the expectations 
and need for stability. You can try it yourself, any Java 1.4 code from 
2003 can be compiled, debugged, profiled etc. nicely with the most recent 
version of jdk and 3rd party tools. It's also nicely compatible with new 
code. OTOH take some D 1.0 code from 2003 (e.g. the free dool/dui or aba 
games code available online) and try to do *something* with it. Basically 
nothing works. You even have problems with new code as some project 
depends on a specific svn version of tango trunk. There is a lot to be 
done before D is ready for large scale enterprise use.

breezes <wangyuanzju gmail.com> writes:

Ary Borenszweig Wrote:

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

 
 What I think is that even with an xml representing the parse tree (maybe 
 with some semantic stuff resolved) it'll be still incomplete for a real 
 IDE (the kind of thing users expect from an IDE). You can see this 
 video, for example:
 
 http://www.youtube.com/watch?v=KQbTT605ags
 
 So you have:
 
 ---
 module one;
 
 class Foo(T) {
    static if (is(T == class)) {
      T property;
    } else {
      T someMethod() { return T.init; }
    }
    mixin(guessWhat!(T)());
 }
 ---
 
 You want to define an xml for that module that'll help IDEs. Can you 
 think what it'll look like?
 
 Now the user writes in another module:
 
 class Bar {
 }
 
 void x() {
    auto foo = new Foo!(Bar)();
    foo. <-- what does the IDE do here?
 }
 
 Now, the correct thing for the IDE to do is to suggest the field "Bar 
 property". How can the IDE do that just with an xml? It can't. It need 
 to perform some kind of semantic anlysis to Foo's argument to see if 
 it's a class, match the static if in the template, replace template 
 parameters, etc. It also needs to evaluate the string mixin.
 
 Of course you could say "Bah, just show all the declarations inside the 
 template in the autocomplete", but that's wrong. That'll lead to files 
 that don't compile. You could ommit supporting autocompletion or other 
 nice features, but that's exactly the big features of D. If you don't 

 could use the advanced features but the IDE won't help you. And in your 
 discussions with companies adopting D, I'm sure they were talking about 
 great IDEs like JDT Eclipse or Visual Studio, not just some tool that 
 helps you a little but not anymore when things get interesting.
 
 Oh, and you need to have some kind of semantic analysis to know the type 
 of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new 
 Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:
 
 auto b = foo.property;
 b. <-- and here?
 // remember "property" is templated and depends on static analysis
 // or the IDE could need to resolve alias this or other things
 
 So... my opinion (like some others, I see) is to either ask things to 
 the compiler directly (but here the compiler lacks some info, like exact 
 source range positions), or to have a compiler (not a full-blown one, 
 just the front-end) built into the IDE, and that's what Descent is. 
 Unfortunately Descent is sometimes slow, sometimes buggy, but that's 
 normal: just a few people develop and maintain it (so I can see a 
 similarity with dmd here, where each day I see two or three new bugs 
 reported). If more people were into it, more unit tests were written 
 into it and, most of all, more people would use it, it'll get better.
 
 Another problem that people see in Descent (maybe also JDT Eclipse and 
 Visual Studio0 is that it's huge, it consumes a lot of memory and they 
 don't want to open a huge tool just to hack some lines. My answer is: 
 memory performance can be improved (but not a lot), but since an IDE is 
 a huge tool it requires a lof from the computer. And an IDE is not meant 
 to be used to hack some lines, it's meant to help you write big project, 
 huge projects without getting lost in the amount of code.
 
 So my bet would be to start supporting an existing IDE that integrates a 
 compiler into it. Updating it is easy: just port the diffs between DMD 
 versions. It's a huge job for one or two people, but if a lot of people 
 were involved it's not that much. Of course I'd recommend you to try 
 Descent since I'm one of it's creators and I do believe it can get 
 pretty good. :-)

A lot of people like me have been waiting for a good IDE for D for a long time.
In the field of IDE of D, Descent has already have a good baseline. So I think
the community should put more effort in make Descent better, other than create
another IDE. 

For this reason, I think Ary Borenszweig's opinion on in which way can dmd help
in building a better IDE may be more valuable than Water's, for he is the
author of the currently most advanced IDE of D.

Sorry for my poor English.

BLS <windevguy hotmail.de> writes:

On 12/10/2009 11:41, breezes wrote:
 Ary Borenszweig Wrote:

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

 It's the IDE.

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

 What do you think?

 What I think is that even with an xml representing the parse tree (maybe
 with some semantic stuff resolved) it'll be still incomplete for a real
 IDE (the kind of thing users expect from an IDE). You can see this
 video, for example:

 http://www.youtube.com/watch?v=KQbTT605ags

 So you have:

 ---
 module one;

 class Foo(T) {
     static if (is(T == class)) {
       T property;
     } else {
       T someMethod() { return T.init; }
     }
     mixin(guessWhat!(T)());
 }
 ---

 You want to define an xml for that module that'll help IDEs. Can you
 think what it'll look like?

 Now the user writes in another module:

 class Bar {
 }

 void x() {
     auto foo = new Foo!(Bar)();
     foo.<-- what does the IDE do here?
 }

 Now, the correct thing for the IDE to do is to suggest the field "Bar
 property". How can the IDE do that just with an xml? It can't. It need
 to perform some kind of semantic anlysis to Foo's argument to see if
 it's a class, match the static if in the template, replace template
 parameters, etc. It also needs to evaluate the string mixin.

 Of course you could say "Bah, just show all the declarations inside the
 template in the autocomplete", but that's wrong. That'll lead to files
 that don't compile. You could ommit supporting autocompletion or other
 nice features, but that's exactly the big features of D. If you don't

 could use the advanced features but the IDE won't help you. And in your
 discussions with companies adopting D, I'm sure they were talking about
 great IDEs like JDT Eclipse or Visual Studio, not just some tool that
 helps you a little but not anymore when things get interesting.

 Oh, and you need to have some kind of semantic analysis to know the type
 of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
 Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:

 auto b = foo.property;
 b.<-- and here?
 // remember "property" is templated and depends on static analysis
 // or the IDE could need to resolve alias this or other things

 So... my opinion (like some others, I see) is to either ask things to
 the compiler directly (but here the compiler lacks some info, like exact
 source range positions), or to have a compiler (not a full-blown one,
 just the front-end) built into the IDE, and that's what Descent is.
 Unfortunately Descent is sometimes slow, sometimes buggy, but that's
 normal: just a few people develop and maintain it (so I can see a
 similarity with dmd here, where each day I see two or three new bugs
 reported). If more people were into it, more unit tests were written
 into it and, most of all, more people would use it, it'll get better.

 Another problem that people see in Descent (maybe also JDT Eclipse and
 Visual Studio0 is that it's huge, it consumes a lot of memory and they
 don't want to open a huge tool just to hack some lines. My answer is:
 memory performance can be improved (but not a lot), but since an IDE is
 a huge tool it requires a lof from the computer. And an IDE is not meant
 to be used to hack some lines, it's meant to help you write big project,
 huge projects without getting lost in the amount of code.

 So my bet would be to start supporting an existing IDE that integrates a
 compiler into it. Updating it is easy: just port the diffs between DMD
 versions. It's a huge job for one or two people, but if a lot of people
 were involved it's not that much. Of course I'd recommend you to try
 Descent since I'm one of it's creators and I do believe it can get
 pretty good. :-)

 A lot of people like me have been waiting for a good IDE for D for a long
time. In the field of IDE of D, Descent has already have a good baseline. So I
think the community should put more effort in make Descent better, other than
create another IDE.

 For this reason, I think Ary Borenszweig's opinion on in which way can dmd
help in building a better IDE may be more valuable than Water's, for he is the
author of the currently most advanced IDE of D.

 Sorry for my poor English.

What I definitely don't like is that Decent is just a Eclipse plugin. I 
don't want a Java IDE plus D.
I would prefer a pure D IDE.

Being a Netbeans guy but I am pretty sure that it is possible to remove 
all the Java related things. side effects : less bloat more speed.

my 2 euro cents

Ary Borenszweig <ary esperanto.org.ar> writes:

BLS wrote:
 On 12/10/2009 11:41, breezes wrote:
 Ary Borenszweig Wrote:

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

 It's the IDE.

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

 What do you think?

 What I think is that even with an xml representing the parse tree (maybe
 with some semantic stuff resolved) it'll be still incomplete for a real
 IDE (the kind of thing users expect from an IDE). You can see this
 video, for example:

 http://www.youtube.com/watch?v=KQbTT605ags

 So you have:

 ---
 module one;

 class Foo(T) {
     static if (is(T == class)) {
       T property;
     } else {
       T someMethod() { return T.init; }
     }
     mixin(guessWhat!(T)());
 }
 ---

 You want to define an xml for that module that'll help IDEs. Can you
 think what it'll look like?

 Now the user writes in another module:

 class Bar {
 }

 void x() {
     auto foo = new Foo!(Bar)();
     foo.<-- what does the IDE do here?
 }

 Now, the correct thing for the IDE to do is to suggest the field "Bar
 property". How can the IDE do that just with an xml? It can't. It need
 to perform some kind of semantic anlysis to Foo's argument to see if
 it's a class, match the static if in the template, replace template
 parameters, etc. It also needs to evaluate the string mixin.

 Of course you could say "Bah, just show all the declarations inside the
 template in the autocomplete", but that's wrong. That'll lead to files
 that don't compile. You could ommit supporting autocompletion or other
 nice features, but that's exactly the big features of D. If you don't

 could use the advanced features but the IDE won't help you. And in your
 discussions with companies adopting D, I'm sure they were talking about
 great IDEs like JDT Eclipse or Visual Studio, not just some tool that
 helps you a little but not anymore when things get interesting.

 Oh, and you need to have some kind of semantic analysis to know the type
 of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
 Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:

 auto b = foo.property;
 b.<-- and here?
 // remember "property" is templated and depends on static analysis
 // or the IDE could need to resolve alias this or other things

 So... my opinion (like some others, I see) is to either ask things to
 the compiler directly (but here the compiler lacks some info, like exact
 source range positions), or to have a compiler (not a full-blown one,
 just the front-end) built into the IDE, and that's what Descent is.
 Unfortunately Descent is sometimes slow, sometimes buggy, but that's
 normal: just a few people develop and maintain it (so I can see a
 similarity with dmd here, where each day I see two or three new bugs
 reported). If more people were into it, more unit tests were written
 into it and, most of all, more people would use it, it'll get better.

 Another problem that people see in Descent (maybe also JDT Eclipse and
 Visual Studio0 is that it's huge, it consumes a lot of memory and they
 don't want to open a huge tool just to hack some lines. My answer is:
 memory performance can be improved (but not a lot), but since an IDE is
 a huge tool it requires a lof from the computer. And an IDE is not meant
 to be used to hack some lines, it's meant to help you write big project,
 huge projects without getting lost in the amount of code.

 So my bet would be to start supporting an existing IDE that integrates a
 compiler into it. Updating it is easy: just port the diffs between DMD
 versions. It's a huge job for one or two people, but if a lot of people
 were involved it's not that much. Of course I'd recommend you to try
 Descent since I'm one of it's creators and I do believe it can get
 pretty good. :-)

 A lot of people like me have been waiting for a good IDE for D for a 
 long time. In the field of IDE of D, Descent has already have a good 
 baseline. So I think the community should put more effort in make 
 Descent better, other than create another IDE.

 For this reason, I think Ary Borenszweig's opinion on in which way can 
 dmd help in building a better IDE may be more valuable than Water's, 
 for he is the author of the currently most advanced IDE of D.

 Sorry for my poor English.

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

No, but that's the good thing about it: it's just a plugin. You don't 
need the Java IDE to run Descent.

Michal Minich wrote somewhere else:

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

http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php
Under "Platform runtime binary"
---

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

Don <nospam nospam.com> writes:

Ary Borenszweig wrote:

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

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

Ary Borenszweig <ary esperanto.org.ar> writes:

Don wrote:
 Ary Borenszweig wrote:
 
 Michal Minich wrote somewhere else:

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

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

 Under "Platform runtime binary"
 ---

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

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

I put it on the "Installing the plugin" page as soon as I saw it here. 
Thanks Michal Minich!

Michal Minich <michal.minich gmail.com> writes:

Hello Ary,

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

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

 I put it on the "Installing the plugin" page as soon as I saw it here.
 Thanks Michal Minich!
 

You are welcome :)

I use it this way from the beginning on both Windows and Ubuntu. I first 
installed Descent into Java Eclipse, but it was also first time I saw Java 
and Eclipse :) so I was quite overwhelmed by the lot functionality available 
and could not find which is for D and which for Java. This way it is more 
beginner friendly.

Thank you for your hard work on Descent.

BLS <windevguy hotmail.de> writes:

On 12/10/2009 15:49, Ary Borenszweig wrote:

 Michal Minich wrote somewhere else:

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

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

 Under "Platform runtime binary"
 ---

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

I tried it too. works fine, feels good.

dolive <dolive89 sina.com> writes:

Ary Borenszweig :


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


    if  Descent is written in d so is very good !

dolive <dolive89 sina.com> writes:

Ary Borenszweig :


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


    if  Descent is written in d so is very good !

language_fan <foo bar.com.invalid> writes:

Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly wrote:

 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.
 
 What do you think?

Another point not mentioned here is that modern IDEs use incremental and 
interactive compilation model. The compiler should be run as a persistent 
background process and parsing should happen perhaps on the level of the 
current scope. Re-compiling a million line project after each key stroke 
simply makes no sense. Even compiling the current module once per key 
stroke is too slow.

Specifying an intermediate json/xml file format is a huge task 
considering the amount of language constructs, types etc. available in D.

I'm all for good tool support but as many have already mentioned, the 
support would only bring marginal improvements to small scale tools like 
vim and emacs. Usually small scale D projects (< 10000 lines of code) are 
written with those tools (feel free to prove me wrong). These are not the 
kinds of projects large enterprises would use D for, they use scripting 
languages for smaller tasks. Thus the overall improvement is minimal. 
Spending the time on critical compiler bugs on the other hand would help 
everyone in the community.

Walter Bright <newshound1 digitalmars.com> writes:

language_fan wrote:
 Another point not mentioned here is that modern IDEs use incremental and 
 interactive compilation model. The compiler should be run as a persistent 
 background process and parsing should happen perhaps on the level of the 
 current scope. Re-compiling a million line project after each key stroke 
 simply makes no sense.

This would not require recompiling a million lines with every key 
stroke, unless you are editing a million line module.

 Even compiling the current module once per key 
 stroke is too slow.

As you say, it should be done as a background process.

 Specifying an intermediate json/xml file format is a huge task 
 considering the amount of language constructs, types etc. available in D.

It isn't. It's far less work than ddoc is, for example.

 I'm all for good tool support but as many have already mentioned, the 
 support would only bring marginal improvements to small scale tools like 
 vim and emacs. Usually small scale D projects (< 10000 lines of code) are 
 written with those tools (feel free to prove me wrong). These are not the 
 kinds of projects large enterprises would use D for, they use scripting 
 languages for smaller tasks. Thus the overall improvement is minimal.

I think the bang for the buck on this is large.


 Spending the time on critical compiler bugs on the other hand would help 
 everyone in the community.

That hasn't been shorted, look at the changelog!

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Oct 12, 2009 at 11:32 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Specifying an intermediate json/xml file format is a huge task considering
 the amount of language constructs, types etc. available in D.

 It isn't. It's far less work than ddoc is, for example.

 I'm all for good tool support but as many have already mentioned, the
 support would only bring marginal improvements to small scale tools like vim
 and emacs. Usually small scale D projects (< 10000 lines of code) are
 written with those tools (feel free to prove me wrong). These are not the
 kinds of projects large enterprises would use D for, they use scripting
 languages for smaller tasks. Thus the overall improvement is minimal.

 I think the bang for the buck on this is large.

Even if this turns out to be useless for IDEs, it'll still be good for
creating external documentation generators that go beyond what DDoc is
capable of providing.   I think the subject of DDoc's limitations has
come up more than once here.   Put in another light, it sounds like
this would basically be the D equivalent of GCC-XML.  Which I think
has been found to have many interesting uses.   For instance Gregor
used GCC-XML to put together a D bindings generator for C code.   With
this XML/JSON output, someone could do similar and write a <your
language here> bindings generator for D code.   That could be handy if


But it doesn't sound to me like it will be that much use to serious IDEs.

--bb

Walter Bright <newshound1 digitalmars.com> writes:

Bill Baxter wrote:
 But it doesn't sound to me like it will be that much use to serious IDEs.

Possibly not, but for lightweight IDEs I think it would be of much use. 
It would also make things very accessible to Emacs and Vim, two very 
widely used programmers' editors.

(One thing I like about Vim is I can run it remotely via putty. A 
graphical gui IDE is impractical to use remotely, and yes, I've tried 
remote desktops. Unusable.)

Yigal Chripun <yigal100 gmail.com> writes:

On 12/10/2009 23:00, Walter Bright wrote:
 Bill Baxter wrote:
 But it doesn't sound to me like it will be that much use to serious IDEs.

 Possibly not, but for lightweight IDEs I think it would be of much use.
 It would also make things very accessible to Emacs and Vim, two very
 widely used programmers' editors.

 (One thing I like about Vim is I can run it remotely via putty. A
 graphical gui IDE is impractical to use remotely, and yes, I've tried
 remote desktops. Unusable.)

I agree with Bill's post. I can't see any benefir for IDEs but a better 
documentation tool based on this would be great.

regarding working on a remote machine:
you can mount a remote file system through ssh and work localy on that 
remoted filesystem.

eclipse provides a similar concept with a plugin (search for RSE or TM 
for eclipse)
in addition eclipse provides better integration with the remote machine: 
executing remote commands straight from the GUI, remote debugging 
integration, etc..

in the latest version the CDT integration was improved a lot. it still 
isn't perfect (the C++ indexer needs more work) but I think by the next 
release they'll fix the remaining issues.

Bill Baxter <wbaxter gmail.com> writes:

On Mon, Oct 12, 2009 at 3:20 PM, Yigal Chripun <yigal100 gmail.com> wrote:
 On 12/10/2009 23:00, Walter Bright wrote:
 Bill Baxter wrote:
 But it doesn't sound to me like it will be that much use to serious IDEs.

 Possibly not, but for lightweight IDEs I think it would be of much use.
 It would also make things very accessible to Emacs and Vim, two very
 widely used programmers' editors.


That could be true, but you said the thing that prompted this idea was
enterprise-y customers looking for an enterprise-y IDE.  Vim ain't on
that roster.

--bb

Walter Bright <newshound1 digitalmars.com> writes:

Bill Baxter wrote:
 That could be true, but you said the thing that prompted this idea was
 enterprise-y customers looking for an enterprise-y IDE.  Vim ain't on
 that roster.

This thread makes it fairly clear that this idea won't fill the bill for 
a full featured IDE. But I think supporting a lightweight one is still 
getting us closer.

Jeremie Pelletier <jeremiep gmail.com> writes:

Walter Bright wrote:
 Bill Baxter wrote:
 That could be true, but you said the thing that prompted this idea was
 enterprise-y customers looking for an enterprise-y IDE.  Vim ain't on
 that roster.

 
 This thread makes it fairly clear that this idea won't fill the bill for 
 a full featured IDE. But I think supporting a lightweight one is still 
 getting us closer.

I completely agree, nobody will code a monster IDE like Eclipse or 
Visual Studio dedicated to D anytime soon.

I have only respect for Descent, I use it on linux and it is really 
great. But Eclipse is killing me, there is no reason for an IDE to be 
that heavy, slow and unresponsive. How come a database server can pull 
off any data query from a multi-gigabyte database on disk in half a 
millisecond yet Eclipse can't seem to feel responsive when working with 
less than a hundred megabytes in system memory. (On that note, D needs a 
b-tree module among others :x)

I really feel we need a dedicated D IDE to promote the language, and 
such an IDE needs to start somewhere, most only do syntax highlighting 
so far, which is trivial to implement. A compiler interface to at least 
get semantics information from the source files is therefore a *big* 
plus in that direction.

XML output can also be used in so many different ways, for 
documentation, bindings, analysis and more. And JSON output can be used 
directly from any language with a very lightweight parser.

Besides, this doesn't mean Walter is going to put everything on hold to 
implement this feature, I think he only wanted to get feedback on an 
idea he had so when he gets time to implement it, he knows what the 
community wants.

Jeremie

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Tue, Oct 13, 2009 at 12:20:01AM +0200, Yigal Chripun wrote:
 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on that 
 remoted filesystem.

Eh, sshfs leaves a lot to be desired. There is a noticeable lag when
performing basic operations on it - it really kills the flow when doing
a rapid edit/compile loop.

It sounds cool on paper, but in practice is rather disappointing.

-- 
Adam D. Ruppe
http://arsdnet.net

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Adam D. Ruppe wrote:
 On Tue, Oct 13, 2009 at 12:20:01AM +0200, Yigal Chripun wrote:
 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on that 
 remoted filesystem.

 
 Eh, sshfs leaves a lot to be desired. There is a noticeable lag when
 performing basic operations on it - it really kills the flow when doing
 a rapid edit/compile loop.
 
 It sounds cool on paper, but in practice is rather disappointing.

I've had positive results with sshfs. Sure, it could probably stand a
lot of improvements, but overall my experience has been good.

The Phobos remote build on the machine you donated access to (thanks!)
uses sshfs.

One cool thing is combining sshfs with autofs. That way the connection
is automatically made when you first open a dir. For example, if I write:

ls /ssh/erdani.com/

an sshfs session is automatically opened to erdani.com.

What are the issues that you encountered? My problems invariably involve
suspending the laptop to RAM or changing wireless connections, to then
find sshfs blocked. I need to "killall ssh" and then whenever I resume
reestablish connection(s). This is a considerable, but not major,
annoyance.


Andrei

"Adam D. Ruppe" <destructionator gmail.com> writes:

Sorry for the slow reply here; I keep getting sidetracked.

On Mon, Oct 12, 2009 at 08:05:06PM -0500, Andrei Alexandrescu wrote:
 One cool thing is combining sshfs with autofs. That way the connection
 is automatically made when you first open a dir. For example, if I write:

That looks cool. I'll have to look into it.

 What are the issues that you encountered?

My big problem is just one of speed. I've been able to work around some of it
by changing my editor config (moving vim's swap file to a local dir made the
biggest difference), but there is still an annoying noticeable lag when
reading and writing the file.

I often edit files in a rapid way: make a small change, save, recompile+run
or refresh the page if a web app - I want to see the changes as instantly
as possible.

The sshfs lag isn't much, but it adds up quickly when doing several
small changes. I find that if any given task takes hours, I can be very
patient, but if it takes milliseconds, I get annoyed easily!

 My problems invariably involve
 suspending the laptop to RAM or changing wireless connections, to then
 find sshfs blocked.

I haven't encountered that, but I also work from my desktop. (Even when
on my laptop, I tend to run most programs remotely from the desktop - this
is one of the driving forces behind my "D Windowing System" project described
in the other thread. (That, and I just want an easy, simple API for my common
tasks in D - kill two birds with one stone, I figure.)

 
 Andrei

-- 
Adam D. Ruppe
http://arsdnet.net

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Adam D. Ruppe wrote:
 The sshfs lag isn't much, but it adds up quickly when doing several
 small changes. I find that if any given task takes hours, I can be very
 patient, but if it takes milliseconds, I get annoyed easily!

I agree. I coquetted with the idea of passing sshfs the option of doing 
writing in background, but I'm too scared :o).

Andrei

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Andrei Alexandrescu wrote:
 One cool thing is combining sshfs with autofs.

A cool thing I'd seriously never thought of.  Time to autofs half my /mnt...

-- Chris Nicholson-Sauls

Yigal Chripun <yigal100 gmail.com> writes:

On 13/10/2009 01:55, Adam D. Ruppe wrote:
 On Tue, Oct 13, 2009 at 12:20:01AM +0200, Yigal Chripun wrote:
 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on that
 remoted filesystem.

 Eh, sshfs leaves a lot to be desired. There is a noticeable lag when
 performing basic operations on it - it really kills the flow when doing
 a rapid edit/compile loop.

 It sounds cool on paper, but in practice is rather disappointing.

that's a quality of implementation issue. eclipse caches the files 
locally and keeps things synced. this removes any lag while editing the 
file.

I use this at work and it's quite good.

Walter Bright <newshound1 digitalmars.com> writes:

Yigal Chripun wrote:
 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on that 
 remoted filesystem.

I do that sometimes, but it's a problem when trying to run the 
compiler/debugger, as they need to run on the remote machine, not just 
locally <g>.

Also, mounting a remote filesystem fails on Windows. I know, that really 
sux. At least putty works.

(10 years ago, I wired up every room in the house with two RG6 cables 
and two Cat5 cables while it was under construction. Did it myself 
because the electrical contractor had no idea how to handle high 
frequency wires, I had to rip all his stuff out and do it over. I had no 
use for it at the time. I'm sure glad now it was done, everything I have 
seems to want to plug in to it! Anyhow, I have several machines with 
different OSs on them on the lan, and ssh to run them from a central 
location.)

Yigal Chripun <yigal100 gmail.com> writes:

On 13/10/2009 07:07, Walter Bright wrote:
 Yigal Chripun wrote:
 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on that
 remoted filesystem.

 I do that sometimes, but it's a problem when trying to run the
 compiler/debugger, as they need to run on the remote machine, not just
 locally <g>.

Eclipse has integration for that. it can execute remote commands and has 
remote debugging - the local eclipse debugger UI speaks with a remote 
gdb session. and if you really prefer command-line, you can always use 
the terminal view.
 Also, mounting a remote filesystem fails on Windows. I know, that really
 sux. At least putty works.

this requires a 3rd party tool on windows. iirc, WebDrive is free, and 
for 30$ you can get sftpDrive.

 (10 years ago, I wired up every room in the house with two RG6 cables
 and two Cat5 cables while it was under construction. Did it myself
 because the electrical contractor had no idea how to handle high
 frequency wires, I had to rip all his stuff out and do it over. I had no
 use for it at the time. I'm sure glad now it was done, everything I have
 seems to want to plug in to it! Anyhow, I have several machines with
 different OSs on them on the lan, and ssh to run them from a central
 location.)

BCS <none anon.com> writes:

Hello Yigal,

 On 13/10/2009 07:07, Walter Bright wrote:
 
 Yigal Chripun wrote:
 
 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on
 that
 remoted filesystem.

 I do that sometimes, but it's a problem when trying to run the
 compiler/debugger, as they need to run on the remote machine, not
 just locally <g>.
 

 Eclipse has integration for that. it can execute remote commands and
 has remote debugging - the local eclipse debugger UI speaks with a
 remote gdb session. and if you really prefer command-line, you can
 always use the terminal view.
 

Darn I so want this. Do you have links? Does the GDB thing work from from 
a Win client and a running GDB on Linux?

Yigal Chripun <yigal100 gmail.com> writes:

On 14/10/2009 03:54, BCS wrote:
 Hello Yigal,

 On 13/10/2009 07:07, Walter Bright wrote:

 Yigal Chripun wrote:

 regarding working on a remote machine:
 you can mount a remote file system through ssh and work localy on
 that
 remoted filesystem.

 I do that sometimes, but it's a problem when trying to run the
 compiler/debugger, as they need to run on the remote machine, not
 just locally <g>.

 Eclipse has integration for that. it can execute remote commands and
 has remote debugging - the local eclipse debugger UI speaks with a
 remote gdb session. and if you really prefer command-line, you can
 always use the terminal view.

 Darn I so want this. Do you have links? Does the GDB thing work from
 from a Win client and a running GDB on Linux?

http://www.eclipse.org/dsdp/tm/

language_fan <foo bar.com.invalid> writes:

Mon, 12 Oct 2009 22:07:34 -0700, Walter Bright thusly wrote:

 Yigal Chripun wrote:
 regarding working on a remote machine: you can mount a remote file
 system through ssh and work localy on that remoted filesystem.

 
 I do that sometimes, but it's a problem when trying to run the
 compiler/debugger, as they need to run on the remote machine, not just
 locally <g>.
 
 Also, mounting a remote filesystem fails on Windows. I know, that really
 sux. At least putty works.
 
 (10 years ago, I wired up every room in the house with two RG6 cables
 and two Cat5 cables while it was under construction. Did it myself
 because the electrical contractor had no idea how to handle high
 frequency wires, I had to rip all his stuff out and do it over. I had no
 use for it at the time. I'm sure glad now it was done, everything I have
 seems to want to plug in to it! Anyhow, I have several machines with
 different OSs on them on the lan, and ssh to run them from a central
 location.)

Lucky you. Couple of friends of mine chose the 'data cabling' option from 
the electrical contractor for their new homes (maybe 2-3 years ago) when 
they were under construction. The rails on the wall were equipped with 
RJ11 connectors! Totally useless for LAN, but ok for phone cables and 
thus xDSL. Another note -- I would use virtualization these days when 
several OSs are needed.

Walter Bright <newshound1 digitalmars.com> writes:

language_fan wrote:
 Lucky you. Couple of friends of mine chose the 'data cabling' option from 
 the electrical contractor for their new homes (maybe 2-3 years ago) when 
 they were under construction. The rails on the wall were equipped with 
 RJ11 connectors! Totally useless for LAN, but ok for phone cables and 
 thus xDSL.

What my electrical contractor did was install Cat 3, daisy chain them 
together, run them through the same holes as the AC wiring, have them 
touching the heating ducts, sharp bends, cable so cheap the insulation 
was already cracking on it, etc. He did everything wrong.

But that probably wouldn't be a problem today.

 Another note -- I would use virtualization these days when 
 several OSs are needed.

I tried that and gave up on it:

1. virtual box wouldn't work, until I downloaded the sun version

2. upgrading Ubuntu cause them to all cease functioning

"Nick Sabalausky" <a a.a> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hb05cv$2bru$1 digitalmars.com...
 Bill Baxter wrote:
 But it doesn't sound to me like it will be that much use to serious IDEs.

 Possibly not, but for lightweight IDEs I think it would be of much use. It 
 would also make things very accessible to Emacs and Vim, two very widely 
 used programmers' editors.

 (One thing I like about Vim is I can run it remotely via putty. A 
 graphical gui IDE is impractical to use remotely, and yes, I've tried 
 remote desktops. Unusable.)

A different branch of the this topic started taking about (or rather, 
bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt that 
was ass-backwards and that the focus should be the other way around: making 
desktop apps work on the web.

What you say here is actually hinting at what I meant: What we need is a 
proper GUI equivalent to something like TTY or telnet. Not remote desktops, 
which really just act like streaming video, but something that'll say "Hey 
client, host here, talking through something much more appropriate than 
XML/HTTP, I want a button that says 'Ok' at (7,14) with size (50,20) on the 
form 'FooForm', and if the user wants a skin, may I suggest (but not insist) 
the 'buttonSkinFoo' that I already sent you earlier, plus I need a 
user-editable textbox over here...etc." (In fact, I think X11 already 
provides something like this in a slightly more low-level form)

I actually tried doing code-editing through remote desktop a few weeks ago 
and noticed just how poorly-suited (not to mention unusable) the whole 
approach was for anything more than clicking around on a few buttons. A 
fully-loaded Eclipse is vastly more responsive! And why? The client system I 
was using was perfectly capable of handling a text-box on it's own, and I 
really didn't need everything to look exactly as it does on the client 
machine.

Video game developers don't make multiplayer games by sending a compressed 
video stream of the fully-rendered frame - they know that would be unusable. 
Instead, they just send the minimum higher-level information that's actually 
needed, like "PlayerA changed direction 72 degrees" (over-simplification, of 
course). And they send it to a client that'll never insist on crap like 
interpreted JS or open-for-interpretation standards. And when there's a 
technology that's inadequate for their needs, like TCP, they make a proper 
replacement instead of hacking in a half-assed "solution" on top of the 
offender, TCP. And it works great even though those programs have visuals 
that are *far* more complex than a typical GUI app. So why can't a windowing 
toolkit be extended to do the same? And do so *without* building it on top 
such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.?

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Mon, Oct 12, 2009 at 07:09:11PM -0400, Nick Sabalausky wrote:
 What you say here is actually hinting at what I meant: What we need is a 
 proper GUI equivalent to something like TTY or telnet. Not remote desktops, 
 which really just act like streaming video, but something that'll say "Hey 
 client, host here, talking through something much more appropriate than 
 XML/HTTP, I want a button that says 'Ok' at (7,14) with size (50,20) on the 
 form 'FooForm', and if the user wants a skin, may I suggest (but not insist) 
 the 'buttonSkinFoo' that I already sent you earlier, plus I need a 
 user-editable textbox over here...etc." (In fact, I think X11 already 
 provides something like this in a slightly more low-level form)

X11 is too low level - it works on windows and drawing commands, but that's
about it. Windows Remote Desktop is actually in a much better position, but
it is still fairly slow for its own reasons.

My DWS project aims to work up on a widget level. It isn't quite as visually
fancy as what you are describing (though it could grow into it later), but
works on a high enough level of abstraction to be fast - and cross platform.

One of the things that makes X feel slow is that it needs to make a lot of
round-trips to the server to get anything done. (And the modern toolkits make
this *worse* by shoehorning in features the low level protocol wasn't really
meant to support.)

To solve this, I want to hand off as much processing as possible to the client.
And to make that happen, I say you shouldn't be too concerned about the
specifics. Tell what widgets you want, but leave the specifics to the viewer.

This also gives a bonus for cross platform: when using an app on Windows,
the little details should feel like a Windows program, not a Linux one, even
if the app itself is running on a Linux server somewhere.


One the apps I already have running on it is a notepad program. The code
looks like this:

---
auto app = new DWSApp;

auto  window = new MainWindow;
window.title = "My notepad";

auto editBox = new TextEdit(window);

auto menu = new Menu("File");
menu.addItem(new Action("Save", { std.file.write("file.txt", editbox.text); }));

window.addMenu(menu);

window.show;

app.exec();
---


Most the lines turn into network calls pretty directly. The protocol is
binary, so no wasted time parsing text and no wasted bandwidth on bloated
stuff like XML. It works on an always open connection, so no annoying lag
from stupid nonsense like HTTP polling.


The window, menu, and edit box are created however the viewer wants to do it.
Currently, I have a Qt/C++ viewer that uses Qt widgets for the actual
implementation, but this can be anything - I want to do a MS-DOS text mode
viewer eventually to demonstrate the flexibility.



A network session would look something like this (each function name is just
one byte show down the wire and the arguments are mostly plain ints):

createWindow(0); // the argument is the window ID - you tell the server, so you
	// can use it immediately without waiting on the lag of a response
	// the D language API hides this from you though as a private member
createWidget(TEXT_EDIT, 0);
createMenu(0, "File"); // strings are sent across as length ~ data
createAction(0, "Save");
addActionToMenu(0, 0); // menuId, actionId
showWindow(0);


That's just 24 bytes of payload to create the window, no round trip required
(except for the ACK from TCP).


Now, the user starts typing. His text appears instantly - the computer he is
in front of handles the text widget all on its own. The only thing it sends
back on the wire:

widgetTextUpdate(0, /* description of text changes since last update */);

It doesn't need to wait on the program's response - it doesn't care. It just
sends this update back to boost speed on future operations and to provide
crash protection. (If the viewing computer crashes, or if the network link
suddenly dies, the app knows its state, so it can recreate the window when
the network comes back. Also useful for migrating the app display to another
machine.)

You don't have an X11 style

 keyEvent('a');

 < drawText('a');

back and forth.


What if the user clicks the menu item? Easy:

  widgetTextUpdate(); // it flushes updates to ensure the app sees the most
  			// recent text
  actionTriggered(0); // the D API sees these 2 bytes on the wire and calls
  			// the delegate I passed in the code.



That's it!

The entire session to edit a quick text file might have only two required 
round trips to the server - it sips bandwidth and is latency tolerant.



More complex programs that can't be built on the ~20 standard widgets will
be slower, since they'll have to actually subscribe to the low level key
events, etc., but I have a plan (not yet implemented at all) to fix that too
by caching event paths.

Basically, your app tells the viewer as much as it can to handle little things
on its own. "When the user presses 'A', go ahead and draw the letter A at
the cursor, but then tell me so I can do fancier processing too."

This, not being written in any code at all, however, is subject to change.
I'm not sure how well it will actually work in real apps.




Nevertheless, even if there is a requirement for special widgets to be
slow and talk to the server for everything, the majority of cases should
be covered by the standard widgets, giving a big boost overall.



In addition to GUI components, I also want to support local file and
sound access, along with a few other things. It sucks when you are using
an X program and it decides to blare sound out of your home computer when
you are using the app from your work computer!

Or it is a real pain in the ass to have to save the file in X, then scp
it over to open it in a local program.

These things should Just Work, and it isn't hard to implement, so I'll be
setting that up too.

-- 
Adam D. Ruppe
http://arsdnet.net

"Nick Sabalausky" <a a.a> writes:

"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.179.1255391198.20261.digitalmars-d puremagic.com...
 My DWS project aims to work up on a widget level. [big snip]

Excellent! Sounds exactly like what I had in mind. I'll definately want to 
keep an eye on this. Any webpage or svn or anything yet?

Couple questions:

Have you given any thought to security? The stuff about local file/etc 
access sounds great, but it also makes me think a little of Adobe's FLEX 
(but with a much more professional appearance and sensible language) which 
is notorious for, first, opening the door for no-install cross-platform 
malware and then not caring one whit about the fact that they've done so 
(sort of like how they don't care about the evils of flash super-cookies, 
but I digress...).

How do you have the client-side working from the perspective of a new user? 
Ie, Do they still need to install each app (or at least each app's client) 
individually, or is it just a one-time install of the DWS library? If the 
latter, how do they find/launch a remote program? I ask because one of the 
things that web-app fans like about web-apps is that they're "no-install", 
at least beyond the installation of the platform (ie, browser) itself. But 
I've always felt there's no technical reason why it shouldn't be possible to 
have a link to, for instance, 
"dws://www.somedomain.com/apps/someGUIApp?cmdlineparams" and have that 
launch the client's remote-GUI toolkit on that "someGUIApp".

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote:
 Excellent! Sounds exactly like what I had in mind. I'll definately want to 
 keep an eye on this. Any webpage or svn or anything yet?

Not yet. I've discussed it on random forums (in various states of development)
but haven't written up anything cohesive at all. I'd tar up my code as it
is right now, but it is a huge mess with outdated notes and my real passwords
just hardcoded in there.... it isn't suitable to go public at all, sadly.

I'll try to fit in a few hours to clean it up over the weekend though.

 Have you given any thought to security? 

A little bit, but not a lot. I was thinking the viewer could be as locked
down as it wants*, but I've just been considering it an implementation detail
so far.

* Any app should be able to gracefully handle permission denied errors on
  file writing, so it shouldn't be hard to code up.

The viewer could also run as a restricted user, using the operating system's
protections to keep it in check.

 How do you have the client-side working from the perspective of a new user? 
 Ie, Do they still need to install each app (or at least each app's client) 
 individually, or is it just a one-time install of the DWS library?

It is just a one time install of the viewer, if you want to run remote
programs. If you want to run programs on your local box, you need to get
the library (well, not really, since it is statically linked, but conceptually)
and the app manager, which runs in the background.

The manager seems like an unnecessary step, but it abstracts the app and
the viewer from each other. The app connects to the manager on localhost
and gives it the instructions to forward to the viewer.

Next, the viewer also connects to the manager. The manager presents it with
a list of active tasks. The viewer selects a task to attach, and then the
manager shoots its current state down to the viewer, allowing the user
to use the program.

If the viewer crashes, no big deal - just restart it and pick up where you
left off.


But anyway, from the end user perspective, he just needs to grab the viewer
and connect to the right server.

 If the 
 latter, how do they find/launch a remote program? I ask because one of the 
 things that web-app fans like about web-apps is that they're "no-install", 
 at least beyond the installation of the platform (ie, browser) itself. But 
 I've always felt there's no technical reason why it shouldn't be possible to 
 have a link to, for instance, 
 "dws://www.somedomain.com/apps/someGUIApp?cmdlineparams" and have that 
 launch the client's remote-GUI toolkit on that "someGUIApp".
 

Exactly. The way my current implementation works is you just run the
viewer and connect it to the server, using plain old TCP (tunneled over
SSH for auth and encryption right now, but that might change)


The process looks something like this:

 Connect



 The user can view this in a variety of ways. My Qt implementation gives a
 list widget, which the user double clicks the one he wants.



 < CreateWindow, Create text widget, set text widget contents, etc.

 The user now sees the program and interacts with it. Or, he can launch a 
 new program -

 Exec app "/app/notepad"
 CreateWindow, .....


While my implementation currently uses a GUI list, it could just as well
be a command line or a URL.

Eventually, I'd like to make it Just Work on hyperlinks - it should be easy
enough to rig something up so it downloads the viewer and connects all
transparently to the user.


-- 
Adam D. Ruppe
http://arsdnet.net

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote:
 Excellent! Sounds exactly like what I had in mind. I'll definately want to 
 keep an eye on this. Any webpage or svn or anything yet?

I wrote up some of a webpage for it over the weekend:

http://arsdnet.net/dws/

I haven't had a chance to clean up my code yet, so it isn't posted, but
there's some overview text there, including some implementation details that
I haven't discussed yet here, but the document still has a long way to go.

But there it is, becoming more organized than anything I've written on it
before.

Thanks for your interest and to the rest of the group for letting me
go off topic like this!

-- 
Adam D. Ruppe
http://arsdnet.net

"Nick Sabalausky" <a a.a> writes:

"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.208.1255923114.20261.digitalmars-d puremagic.com...
 On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote:
 Excellent! Sounds exactly like what I had in mind. I'll definately want 
 to
 keep an eye on this. Any webpage or svn or anything yet?

 I wrote up some of a webpage for it over the weekend:

 http://arsdnet.net/dws/

 I haven't had a chance to clean up my code yet, so it isn't posted, but
 there's some overview text there, including some implementation details 
 that
 I haven't discussed yet here, but the document still has a long way to go.

 But there it is, becoming more organized than anything I've written on it
 before.

Great!

 Thanks for your interest and to the rest of the group for letting me
 go off topic like this!

The offtopics are some of the most interesting bits! 

Nick B <nickB gmail.com> writes:

Nick Sabalausky wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:mailman.208.1255923114.20261.digitalmars-d puremagic.com...
 On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote:
 Excellent! Sounds exactly like what I had in mind. I'll definately want 
 to
 keep an eye on this. Any webpage or svn or anything yet?

 I wrote up some of a webpage for it over the weekend:

 http://arsdnet.net/dws/

 I haven't had a chance to clean up my code yet, so it isn't posted, but
 there's some overview text there, including some implementation details 
 that
 I haven't discussed yet here, but the document still has a long way to go.

 But there it is, becoming more organized than anything I've written on it
 before.


Adam.  What you written at your web site is a very interesting read.

Re your use of a binary protocol.

Perhaps instead of re-inventing the wheel, you may want to look at what
Google has done with the design of their  Google Protocol Buffers, which 
also implements a very fast binary protocol.  See here for a overview:

http://code.google.com/apis/protocolbuffers/docs/overview.html

It is also worthwhile reading the section called "A bit of history".

Note that there is also D implementation.

http://256.makerslocal.org/wiki/index.php/ProtocolBuffer

I don't know how current this is, though.

One more point. What, if any, library to you plan to use ?

cheers
Nick B

Adam D. Ruppe <destructionator gmail.com> writes:

On 10/20/09, Nick B <nickB gmail.com> wrote:
 Re your use of a binary protocol.

 Perhaps instead of re-inventing the wheel,

 
 Eh, my code is already written and works. One of the advantages to my
 code generator reading a C like syntax is that I might be able to
 fully automate porting some existing APIs down the wire - I'm
 particularly looking at OpenGL, or at least a subset of it, to work
 with ease. Another one is porting my generator to a new language is easy
- I already know the code and it is fairly simple anyway.
 
 Anyway, quickly skimming through the google page, their system isn't
 bad (Coincidentally, it and I encode unsigned ints and strings in
 exactly the same way! Cool.), but I don't think there's much to gain
 by me switching to it. Though, their signed varint algorithm is pretty
 elegant; I might have to use that.
 
 And it reminds me that I didn't even consider optional arguments on
 functions. Trivial to implement though, even compatible with my
 current protocol: if message length is shorter than what you expect,
 use default values for the rest of the arguments. This means they'd
 have to be at the end, but you expect that from C like functions
 anyway.
 
 It is also worthwhile reading the section called "A bit of history".

 
 I thought about future compatibility, which is why my protocol has a
 length field on every message. If you read the length and the function
 number and find it isn't something you know, you can simply skip past
 the whole message and carry on.
 
 The ugliness might be that future functions deprecate old functions...
 if this took off and was widely used, it might end up looking like
 Win32 in 10 years (CreateWindow() nope, CreateWindowEx()!), but I'm ok
 with that.
 
 
 One more point. What, if any, library to you plan to use ?

 
 The D side is all custom code (I've written various libraries and
 helper tools over the years for myself - the big one used here is a
 network manager thing that handles incoming connections and output
 buffering) and Phobos - nothing third party there. I'm using D2, but
 there's nothing preventing it from being backported to D1 at some
 point. I actually want to do a DMDScript port that speaks it too, but
 that's way down the line.
 
 For the viewer, my current implementation is C++ with Qt. I'd like to
 actually do various viewers, including ones with less fat dependencies
 (asking users to download Qt just to run it is a bit heavy), but for
 now, I just wanted something I could start using immediately without
 too much trouble for me. Qt on C++ works pretty well across platforms,
 and I already know how to use it, so it was an easy choice for early
 stages.
 
 cheers
 Nick B

 
 Thanks!
 -Adam

language_fan <foo bar.com.invalid> writes:

Mon, 12 Oct 2009 19:53:32 -0400, Adam D. Ruppe thusly wrote:

 In addition to GUI components, I also want to support local file and
 sound access, along with a few other things. It sucks when you are using
 an X program and it decides to blare sound out of your home computer
 when you are using the app from your work computer!
 
 Or it is a real pain in the ass to have to save the file in X, then scp
 it over to open it in a local program.
 
 These things should Just Work, and it isn't hard to implement, so I'll
 be setting that up too.

Nomachine NX does pretty much what you are describing here. It is not 
equivalent technically but very similar and backwards compatible. 

"Nick Sabalausky" <a a.a> writes:

"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.179.1255391198.20261.digitalmars-d puremagic.com...
 My DWS project aims to work up on a widget level. It isn't quite as 
 visually
 fancy as what you are describing (though it could grow into it later), but
 works on a high enough level of abstraction to be fast - and cross 
 platform.

Here's another thought I've had that I forgot to mention before. Just 
tossing it out there, don't know if you've looked into it or not: Instead of 
(or, better yet, in addition to) a special network-GUI toolkit, what about a 
server (kind of like a modified version of remote desktop) that actually 
queries the OS to find out about all the GUIs running on the system, and 
details about all their controls, relays that info to the client to 
reproduce, and accepts input back from the client like a softwareKVM would?

It probably wouldn't work quite as well as a special network-GUI toolkit (it 
would probably have to detect and handle Win32/GTK/Delphi apps seperately, 
it probably wouldn't be able to do everything 100%, and it wouldn't be able 
to do any of the "smart" client tricks you have up your sleeve), but it 
would allow for at least some basic compatibility with apps that weren't 
specifically coded for a special network-GUI toolkit.

Regarding the technical feasability of gaining information on all the 
controls of the running processes, I could swear I've seen some Windows 
program (some dev tool IIRC) that was able to detect that stuff from Win32 
and Delphi apps, although I have no recoloction what what in the world that 
program was... I have no idea as to the feasability on Mac or Unix. 

Nick B <nickB gmail.com> writes:

Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hb05cv$2bru$1 digitalmars.com...
 Bill Baxter wrote:
 But it doesn't sound to me like it will be that much use to serious IDEs.

 Possibly not, but for lightweight IDEs I think it would be of much use. It 
 would also make things very accessible to Emacs and Vim, two very widely 
 used programmers' editors.

 (One thing I like about Vim is I can run it remotely via putty. A 
 graphical gui IDE is impractical to use remotely, and yes, I've tried 
 remote desktops. Unusable.)

 
 A different branch of the this topic started taking about (or rather, 
 bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt that 
 was ass-backwards and that the focus should be the other way around: making 
 desktop apps work on the web.
 
 What you say here is actually hinting at what I meant: What we need is a 
 proper GUI equivalent to something like TTY or telnet. Not remote desktops, 
 which really just act like streaming video, but something that'll say "Hey 
 client, host here, talking through something much more appropriate than 
 XML/HTTP, I want a button that says 'Ok' at (7,14) with size (50,20) on the 
 form 'FooForm', and if the user wants a skin, may I suggest (but not insist) 
 the 'buttonSkinFoo' that I already sent you earlier, plus I need a 
 user-editable textbox over here...etc." (In fact, I think X11 already 
 provides something like this in a slightly more low-level form)
 

[snip]
 
 Video game developers don't make multiplayer games by sending a compressed 
 video stream of the fully-rendered frame - they know that would be unusable. 
 Instead, they just send the minimum higher-level information that's actually 
 needed, like "PlayerA changed direction 72 degrees" (over-simplification, of 
 course). And they send it to a client that'll never insist on crap like 
 interpreted JS or open-for-interpretation standards. And when there's a 
 technology that's inadequate for their needs, like TCP, they make a proper 
 replacement instead of hacking in a half-assed "solution" on top of the 
 offender, TCP. And it works great even though those programs have visuals 
 that are *far* more complex than a typical GUI app. So why can't a windowing 
 toolkit be extended to do the same? And do so *without* building it on top 
 such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.?


It sounds like you are talking about Immediate Mode Graphical User 
Interface ?

Have you checked out Hybrid (IMGUI) developed by team0xf  ?

See
http://hybrid.team0xf.com/wiki/

Nick B

David Gileadi <foo bar.com> writes:

Nick Sabalausky wrote:
 Video game developers don't make multiplayer games by sending a compressed 
 video stream of the fully-rendered frame - they know that would be unusable. 
 Instead, they just send the minimum higher-level information that's actually 
 needed, like "PlayerA changed direction 72 degrees" (over-simplification, of 
 course). And they send it to a client that'll never insist on crap like 
 interpreted JS or open-for-interpretation standards. And when there's a 
 technology that's inadequate for their needs, like TCP, they make a proper 
 replacement instead of hacking in a half-assed "solution" on top of the 
 offender, TCP. And it works great even though those programs have visuals 
 that are *far* more complex than a typical GUI app. So why can't a windowing 
 toolkit be extended to do the same? And do so *without* building it on top 
 such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.?

This is generally true, although see OnLive (http://www.onlive.com/).  I 
hear it works better than you'd expect, but don't have much interest in 
actually trying it.

"Nick Sabalausky" <a a.a> writes:

"David Gileadi" <foo bar.com> wrote in message 
news:hb24km$pm8$1 digitalmars.com...
 Nick Sabalausky wrote:
 Video game developers don't make multiplayer games by sending a 
 compressed video stream of the fully-rendered frame - they know that 
 would be unusable. Instead, they just send the minimum higher-level 
 information that's actually needed, like "PlayerA changed direction 72 
 degrees" (over-simplification, of course). And they send it to a client 
 that'll never insist on crap like interpreted JS or 
 open-for-interpretation standards. And when there's a technology that's 
 inadequate for their needs, like TCP, they make a proper replacement 
 instead of hacking in a half-assed "solution" on top of the offender, 
 TCP. And it works great even though those programs have visuals that are 
 *far* more complex than a typical GUI app. So why can't a windowing 
 toolkit be extended to do the same? And do so *without* building it on 
 top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, 
 etc.?

 This is generally true, although see OnLive (http://www.onlive.com/).  I 
 hear it works better than you'd expect, but don't have much interest in 
 actually trying it.

Yea, I've heard of that. I'm extremely skeptical though. Even at *absolute* 
best, I still can't imagine it having less lag than one of those laggy 
HDTVs, which I already consider entirely inadequate for gaming. Plus they'd 
essentially have to have a whole high-end gaming rig (plus all the 
higher-end-than-usual video-capture/compression and network needs) for each 
simultaneous user, which I'd imagine would either make the subscription fee 
absurdly high, lead to 90's-AOL-style too-many-connection issues, or send 
them right into bankruptcy. It's just unnecessary bandwidth/latency bloat.

language_fan <foo bar.com.invalid> writes:

Mon, 12 Oct 2009 19:09:11 -0400, Nick Sabalausky thusly wrote:
 A different branch of the this topic started taking about (or rather,
 bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt
 that was ass-backwards and that the focus should be the other way
 around: making desktop apps work on the web.
 

[snip]

 And do so *without* building it on
 top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax,
 etc.?

You have probably lived under a rock these days. This is the way the 
world is moving. If something can be made Web 2.0 compatible, it is also 
what will happen. A new platform might come up in 201x or 202x, but 
nowadays the best we have got is Web 2.0. Ever used twitter, facebook, 
google wave (or any google's services) etc. ? Large part of the online 
enterprises have already jumped on the wagon, not only early adopters. 
Modern browsers such as opera 10, firefox 3.5, safari, and chrome already 
support the latest standards.

"Nick Sabalausky" <a a.a> writes:

"language_fan" <foo bar.com.invalid> wrote in message 
news:hb2ov1$1jd8$3 digitalmars.com...
 Mon, 12 Oct 2009 19:09:11 -0400, Nick Sabalausky thusly wrote:
 A different branch of the this topic started taking about (or rather,
 bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt
 that was ass-backwards and that the focus should be the other way
 around: making desktop apps work on the web.

 [snip]

 And do so *without* building it on
 top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax,
 etc.?

 You have probably lived under a rock these days. This is the way the
 world is moving. If something can be made Web 2.0 compatible, it is also
 what will happen. A new platform might come up in 201x or 202x, but
 nowadays the best we have got is Web 2.0. Ever used twitter, facebook,
 google wave (or any google's services) etc. ? Large part of the online
 enterprises have already jumped on the wagon, not only early adopters.
 Modern browsers such as opera 10, firefox 3.5, safari, and chrome already
 support the latest standards.

You're misunderstanding me.  All of that is stuff that is either A. made for 
the web using web technologies and then brought to the desktop, still using 
those god-awful web technologies (twitter, facebook, anything flex), or B. 
started on the desktop and then completely reimplemented for the web using 
those same web technologies (google's stuff). But what I'm talking about is 
taking desktop apps made using nice solid desktop app technologies and 
making them internet-accessible without ever even touching crap like DHTML, 
Flash, or even HTTP.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Walter Bright wrote:
 language_fan wrote:
 Another point not mentioned here is that modern IDEs use incremental 
 and interactive compilation model. The compiler should be run as a 
 persistent background process and parsing should happen perhaps on the 
 level of the current scope. Re-compiling a million line project after 
 each key stroke simply makes no sense.

 
 This would not require recompiling a million lines with every key 
 stroke, unless you are editing a million line module.
 
 Even compiling the current module once per key stroke is too slow.

 
 As you say, it should be done as a background process.
 
 Specifying an intermediate json/xml file format is a huge task 
 considering the amount of language constructs, types etc. available in D.

 
 It isn't. It's far less work than ddoc is, for example.
 
 I'm all for good tool support but as many have already mentioned, the 
 support would only bring marginal improvements to small scale tools 
 like vim and emacs. Usually small scale D projects (< 10000 lines of 
 code) are written with those tools (feel free to prove me wrong). 
 These are not the kinds of projects large enterprises would use D for, 
 they use scripting languages for smaller tasks. Thus the overall 
 improvement is minimal.

 
 I think the bang for the buck on this is large.

For each snippet of code that doesn't currently compile, I generate a 
red warning in the TDPL draft. Currently there are 28 such red warnings, 
and each may be arbitrarily difficult to fix. There are other issues 
that we know need to be done as soon as yesterday.

IMHO it would be frivolous to spend time on anything else but the 28 
bugs. This XML/JSON generation is like combing one's hair before leaving 
the burning house. Just run! (I'm not saying I don't like combed hair or 
XML/JSON parsing, but the latter is absolutely nothing you need to work 
on now.) Please understand that TDPL is on a crash course and we can't 
have a book without a language (I'm also assuming we can't have a 
language without a book).

Walter, please avoid all distractions and make bringing D in sync with 
the book your sole preoccupation. I am working *extremely* hard on the 
book, and I wish I were seeing the same level of commitment in you.


Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Andrei Alexandrescu wrote:
 Walter Bright wrote:
 language_fan wrote:
 Another point not mentioned here is that modern IDEs use incremental 
 and interactive compilation model. The compiler should be run as a 
 persistent background process and parsing should happen perhaps on 
 the level of the current scope. Re-compiling a million line project 
 after each key stroke simply makes no sense.

 This would not require recompiling a million lines with every key 
 stroke, unless you are editing a million line module.

 Even compiling the current module once per key stroke is too slow.

 As you say, it should be done as a background process.

 Specifying an intermediate json/xml file format is a huge task 
 considering the amount of language constructs, types etc. available 
 in D.

 It isn't. It's far less work than ddoc is, for example.

 I'm all for good tool support but as many have already mentioned, the 
 support would only bring marginal improvements to small scale tools 
 like vim and emacs. Usually small scale D projects (< 10000 lines of 
 code) are written with those tools (feel free to prove me wrong). 
 These are not the kinds of projects large enterprises would use D 
 for, they use scripting languages for smaller tasks. Thus the overall 
 improvement is minimal.

 I think the bang for the buck on this is large.

 
 For each snippet of code that doesn't currently compile, I generate a 
 red warning in the TDPL draft. Currently there are 28 such red warnings, 
 and each may be arbitrarily difficult to fix. There are other issues 
 that we know need to be done as soon as yesterday.
 
 IMHO it would be frivolous to spend time on anything else but the 28 
 bugs. This XML/JSON generation is like combing one's hair before leaving 
 the burning house. Just run! (I'm not saying I don't like combed hair or 
 XML/JSON parsing, but the latter is absolutely nothing you need to work 
 on now.) Please understand that TDPL is on a crash course and we can't 
 have a book without a language (I'm also assuming we can't have a 
 language without a book).
 
 Walter, please avoid all distractions and make bringing D in sync with 
 the book your sole preoccupation. I am working *extremely* hard on the 
 book, and I wish I were seeing the same level of commitment in you.
 
 
 Andrei

I ammend the above: s/commitment/focus/. Of course Walter is motivate 
and committed more than anyone else to make D successful, but it's time 
to force ourselves to absolutely focus on the important _and_ urgent 
matters.

Andrei

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Oct 12, 2009 at 3:31 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Walter, please avoid all distractions and make bringing D in sync with the
 book your sole preoccupation. I am working *extremely* hard on the book, and
 I wish I were seeing the same level of commitment in you.

You're writing a book about a language that doesn't exist and then
complaining that Walter isn't writing it for you?

Wow.



Just wow.

I'm out of here.

Walter Bright <newshound1 digitalmars.com> writes:

Jarrett Billingsley wrote:
 I'm out of here.

Andrei is addressing one of the critical shortcomings of D - lack of a 
comprehensive book. So while he has a large ego (don't we all!) I 
actually enjoy working with people who have large egos, and Andrei gets 
things done.

I've also found that while some people I only know from online dealings 
that I found infuriating, when I meet the person in 3D land things are 
very different, and they're very engaging and fun to work with.

I suppose we really need another D conference.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

Walter Bright wrote:
 In my discussions with companies about adopting D, the major barrier
 that comes up over and over isn't Tango vs Phobos, dmd being GPL,
 debugger support, libraries, bugs, etc., although those are important.
 
 It's the IDE.
 
 They say that the productivity gains of D's improvements are
 overbalanced by the loss of productivity by moving away from an IDE. And
 what is it about an IDE that is so productive? Intellisense (Microsoft's
 word for autocompletion).
 
 So, while I'm not going to be writing an IDE, I figure that dmd can
 help. dmd already puts out .doc and .di files. How about putting out an
 xml file giving all the information needed for an IDE to implement
 autocompletion? There'd be one .xml file generated per .d source file.
 
 The nice thing about an xml file is while D is relatively easy to parse,
 xml is trivial. Furthermore, an xml format would be fairly robust in the
 face of changes to D syntax.
 
 What do you think?

Next question: what about conditional compilation?

Kagamin <spam here.lot> writes:

Walter Bright Wrote:

 What do you think?

moving ddoc to xml will also fix bug 2060