• Robert Fraser <fraserofhenight gmail.com> Sep 28 2007
• BCS <ao pathlink.com> Sep 28 2007
• Ary Manzana <ary esperanto.org.ar> Sep 30 2007
• div0 <div0 users.sourceforge.net> Sep 30 2007
• Robert Fraser <fraserofhenight gmail.com> Oct 01 2007
• div0 <div0 users.sourceforge.net> Oct 01 2007

Robert Fraser <fraserofhenight gmail.com> writes:

BCS Wrote:

 -IDE


You're the first one in the topic to mention this. I agree with you quite a bit
on this, as all the current IDEs, while sufficient for writing code, still have
their faults. For example, no IDE at present can do code completion with this:

mixin(ctFunction());

char[] ctFunction()
{
    return "struct Foo { int bar,baz; }";
}

Foo foo;
foo. // Here's where I'd want code completion to come up and suggest "bar" and
"baz"
}

That's a trivial example, but all the compile-time stuff (templates, CTFE,
mixins, etc.) is hard to debug properly because there's no real way to see the
compile-time results. IDEs that have the compiler's complete semantic knowledge
about these things can provide a whole host of features targeted at a mostly
D-specific problem (I know C++ has templates, too, and I'm not sure what IDEs
do to make working with them easier).

That's why I'm working on Descent (or, at least, will get back to it next week
some time), with the hope that Descent can bridge the gap between very
effective, feature-rich IDEs without full semantic knowledge (Mmrnhrnm or
however you spell it is a really good example of it) and the compiler itself.
Instant problem reporting and quick-fix functionality are also planned, so
another piece to that bridge will be there as well.

BCS <ao pathlink.com> writes:

Reply to Robert,

 BCS Wrote:
 
 -IDE
 


 quite a bit on this, as all the current IDEs, while sufficient for
 writing code, still have their faults. For example, no IDE at present
 can do code completion with this:
 
 mixin(ctFunction());
 
 char[] ctFunction()
 {
 return "struct Foo { int bar,baz; }";
 }
 Foo foo;
 foo. // Here's where I'd want code completion to come up and suggest
 "bar" and "baz"
 }
 That's a trivial example, but all the compile-time stuff (templates,
 CTFE, mixins, etc.) is hard to debug properly because there's no real
 way to see the compile-time results. IDEs that have the compiler's
 complete semantic knowledge about these things can provide a whole
 host of features targeted at a mostly D-specific problem (I know C++
 has templates, too, and I'm not sure what IDEs do to make working with
 them easier).
 


That reminds me of another thing

-compile time debugging

Figuring out what exactly is happening at compile time is a nightmare. Things 
I'd like to see include:
- Breakpoint debugging of template work
- Step through of template selection (list the overload options and list 
why each one did or didn't match)
- visual unrolling of tuple foreach and static ifs
- "what if" mode for templates (select a template, force the parameters to 
different things, and see what happens, all without change code)

These tools would all have to be part of a IDE for them to be useful tools.

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

I've recorded a video that shows what Descent will be able to do in the 
next releases. This shows more or less why me and Robert think a good 
IDE will improve development speed in D.

http://esperanto.org.ar/descent/descent.html

Of course, the functionality is the same as DMD, but being able to 
detect errors without having to compile helps a lot. Also, as you can 
see, you can evaluate compile-time functions on-the-fly by writing 
static asserts that fail.

Enojy!
Ary

P.D.: The video starts with "Let's start by defining a function..." (it 
got cut in the recording).

Robert Fraser escribió:
 BCS Wrote:
 
 -IDE


 You're the first one in the topic to mention this. I agree with you quite a
bit on this, as all the current IDEs, while sufficient for writing code, still
have their faults. For example, no IDE at present can do code completion with
this:
 
 mixin(ctFunction());
 
 char[] ctFunction()
 {
     return "struct Foo { int bar,baz; }";
 }
 
 Foo foo;
 foo. // Here's where I'd want code completion to come up and suggest "bar" and
"baz"
 }
 
 That's a trivial example, but all the compile-time stuff (templates, CTFE,
mixins, etc.) is hard to debug properly because there's no real way to see the
compile-time results. IDEs that have the compiler's complete semantic knowledge
about these things can provide a whole host of features targeted at a mostly
D-specific problem (I know C++ has templates, too, and I'm not sure what IDEs
do to make working with them easier).
 
 That's why I'm working on Descent (or, at least, will get back to it next week
some time), with the hope that Descent can bridge the gap between very
effective, feature-rich IDEs without full semantic knowledge (Mmrnhrnm or
however you spell it is a really good example of it) and the compiler itself.
Instant problem reporting and quick-fix functionality are also planned, so
another piece to that bridge will be there as well.

div0 <div0 users.sourceforge.net> writes:

Ary Manzana wrote:
 I've recorded a video that shows what Descent will be able to do in the 
 next releases. This shows more or less why me and Robert think a good 
 IDE will improve development speed in D.
 
 http://esperanto.org.ar/descent/descent.html
 
 Of course, the functionality is the same as DMD, but being able to 
 detect errors without having to compile helps a lot. Also, as you can 
 see, you can evaluate compile-time functions on-the-fly by writing 
 static asserts that fail.
 
 Enojy!
 Ary
 
 P.D.: The video starts with "Let's start by defining a function..." (it 
 got cut in the recording).


Whilst that is admittedly very cool, I'd rather be able to click:

Project -> Build All

and have that work...

Robert Fraser <fraserofhenight gmail.com> writes:

div0 Wrote:

 Ary Manzana wrote:
 I've recorded a video that shows what Descent will be able to do in the 
 next releases. This shows more or less why me and Robert think a good 
 IDE will improve development speed in D.
 
 http://esperanto.org.ar/descent/descent.html
 
 Of course, the functionality is the same as DMD, but being able to 
 detect errors without having to compile helps a lot. Also, as you can 
 see, you can evaluate compile-time functions on-the-fly by writing 
 static asserts that fail.
 
 Enojy!
 Ary
 
 P.D.: The video starts with "Let's start by defining a function..." (it 
 got cut in the recording).


 Whilst that is admittedly very cool, I'd rather be able to click:
 
 Project -> Build All
 
 and have that work...


It's all integrated. That is to say, that what we're doing now (getting the
errors and what not) is all part of porting in complete (i.e. what the compiler
sees) semantic functionality. Given that we can do incremental building a la
DSSS (even if your import statements are in a CTFE mixin!). We'll also be
getting those oft-requested features like code completion, go-to definition and
refactoring. The error marking shown in that video is just the first step,
since it's being put in with the rest of the semantic code.

So, patience, patience...

div0 <div0 users.sourceforge.net> writes:

Robert Fraser wrote:
 div0 Wrote:
 
 Ary Manzana wrote:
 I've recorded a video that shows what Descent will be able to do in the 
 next releases. This shows more or less why me and Robert think a good 
 IDE will improve development speed in D.

 http://esperanto.org.ar/descent/descent.html

 Of course, the functionality is the same as DMD, but being able to 
 detect errors without having to compile helps a lot. Also, as you can 
 see, you can evaluate compile-time functions on-the-fly by writing 
 static asserts that fail.

 Enojy!
 Ary

 P.D.: The video starts with "Let's start by defining a function..." (it 
 got cut in the recording).



 Project -> Build All

 and have that work...


 It's all integrated. That is to say, that what we're doing now (getting the
errors and what not) is all part of porting in complete (i.e. what the compiler
sees) semantic functionality. Given that we can do incremental building a la
DSSS (even if your import statements are in a CTFE mixin!). We'll also be
getting those oft-requested features like code completion, go-to definition and
refactoring. The error marking shown in that video is just the first step,
since it's being put in with the rest of the semantic code.
 
 So, patience, patience...


Sweet!