www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - What to do with Descent?

reply Ary Borenszweig <ary esperanto.org.ar> writes:
Descent has a problem: it supports D1 very well (kinda) but good D2 
support is still far away.  The latest dmd versions I ported it to are 
1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many 
front-end changes). Porting from 2.030 to 2.035 is heavy because a lot 
of changes were introduced.

In both cases porting is a slow (and boring) task: checking the diffs 
between each file, finding the matching function if it already exists or 
creating it, copying the code, translating it to Java, then translating 
some bits of code to Descent (it's a bit more than just copy, past, 
change size_t to int, remove stars). Doing it alone is really, really 
slow and boring, but I have no problem doing it from time to time, like 
maybe 10, 15 minutes each day.

Another problem with porting, specially to D2, is that when I'll finish 
porting to 2.035 there will probably be a 2.037. Maybe some changes that 
were applied in 2.035 were roll backed or changed a little, so perhaps I 
should wait for D2 to become frozen and then port. Either way, I'm 
afraid that when I'll finally have good D2 support there will be a D3 in 
the way. When I stabilize Descent more or less (write a lot of tests, 
improve memory and performance, etc.) maybe the situation that exists 
now will repeat itself: D2 will be more or less stable but some people 
will be focused on D3 because it's the new thing, Descent won't support 
D3 because it's a moving target and because it's not backward compatible 
with D2, so I'll start porting to D3 but D4 will appear, etc.

And I think this situation doesn't only affect Descent but many 
libraries and tool suffer from this constant upgrades in D. I think this 
situation sucks. :-P

Finally, D's userbase is not huge so I really can't tell if Descent is 
useful enough (and there are the people that prefer to code without an 
IDE, or with a lighter one).

So... what should I do?

For now I decided to wait, and even maybe abandon the whole idea of 
keeping Descent up-to-date until D becomes more successful (more 
probability of people helping me).
Oct 19 2009
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Ary Borenszweig wrote:

 Descent has a problem: it supports D1 very well (kinda) 


Definitely wait for D2 spec to finalize before incorporating it.

Question: how much of DMDfe do you have in descent? As in how much
effort do you spend keeping each of lexer, parser, and semantic up to date?
Oct 19 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Ellery Newcomer wrote:

 Ary Borenszweig wrote:

 Descent has a problem: it supports D1 very well (kinda) 


 
 Definitely wait for D2 spec to finalize before incorporating it.
 
 Question: how much of DMDfe do you have in descent? As in how much
 effort do you spend keeping each of lexer, parser, and semantic up to date?


It's not hard, it's just tedious and long. But I don't think it can be 
automated. :(

But it's the one tasks that is most needed, because with those things 
not up to date users can't fully take advantage of it.
Oct 19 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Ary Borenszweig wrote:

 Ellery Newcomer wrote:

 Ary Borenszweig wrote:

 Descent has a problem: it supports D1 very well (kinda) 


 Definitely wait for D2 spec to finalize before incorporating it.

 Question: how much of DMDfe do you have in descent? As in how much
 effort do you spend keeping each of lexer, parser, and semantic up to
 date?


 
 It's not hard, it's just tedious and long. But I don't think it can be
 automated. :(
 
 But it's the one tasks that is most needed, because with those things
 not up to date users can't fully take advantage of it.


let effort = tediousness and longness

what is the ratio of effort spent keeping lexer vs parser vs semantic up
to date?

I'm exploring whether it would make more sense to use a parser grammar
(e.g. ANTLR) or to keep the lexer and parser that you already have. If
you're spending a lot of time with the lexer and parser, then it might.
(see, I'm using descent as a case study :)

So far my philosophy has been use the parser grammar because it's easier
to maintain, less prone to bugs, and, at least for D1, the only changes
across DMD releases in the parser are bug fixes, most to all of which
don't exist in the generated grammar. Of course, the flip side is error
reporting sucks, performance sucks (seriously, it takes the thing 10
freaking seconds to parse Tango!), and you still have to do something
about semantic.
Oct 19 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ellery Newcomer wrote:

 Ary Borenszweig wrote:

 Ellery Newcomer wrote:

 Ary Borenszweig wrote:

 Descent has a problem: it supports D1 very well (kinda) 


 Definitely wait for D2 spec to finalize before incorporating it.

 Question: how much of DMDfe do you have in descent? As in how much
 effort do you spend keeping each of lexer, parser, and semantic up to
 date?


 It's not hard, it's just tedious and long. But I don't think it can be
 automated. :(

 But it's the one tasks that is most needed, because with those things
 not up to date users can't fully take advantage of it.


 
 let effort = tediousness and longness
 
 what is the ratio of effort spent keeping lexer vs parser vs semantic up
 to date?


semantic >>>>>>>>>>>>>>>> parser = lexer
Oct 19 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Ary,


 So... what should I do?
 
 For now I decided to wait, and even maybe abandon the whole idea of
 keeping Descent up-to-date until D becomes more successful (more
 probability of people helping me).


Pleas do keep working on it. The only reason I don't use it more is because 
1) it doesn't like ultra heavy meta-programming and 2) it doesn't support 
having stuff scattered across several computers and OSes like I have. One 
of these days I'll fix the second issue.
Oct 19 2009
prev sibling next sibling parent reply dolive <dolive89 sina.com> writes:
Ary Borenszweig дµ½:


 Descent has a problem: it supports D1 very well (kinda) but good D2 
 support is still far away.  The latest dmd versions I ported it to are 
 1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many 
 front-end changes). Porting from 2.030 to 2.035 is heavy because a lot 
 of changes were introduced.
 
 In both cases porting is a slow (and boring) task: checking the diffs 
 between each file, finding the matching function if it already exists or 
 creating it, copying the code, translating it to Java, then translating 
 some bits of code to Descent (it's a bit more than just copy, past, 
 change size_t to int, remove stars). Doing it alone is really, really 
 slow and boring, but I have no problem doing it from time to time, like 
 maybe 10, 15 minutes each day.
 
 Another problem with porting, specially to D2, is that when I'll finish 
 porting to 2.035 there will probably be a 2.037. Maybe some changes that 
 were applied in 2.035 were roll backed or changed a little, so perhaps I 
 should wait for D2 to become frozen and then port. Either way, I'm 
 afraid that when I'll finally have good D2 support there will be a D3 in 
 the way. When I stabilize Descent more or less (write a lot of tests, 
 improve memory and performance, etc.) maybe the situation that exists 
 now will repeat itself: D2 will be more or less stable but some people 
 will be focused on D3 because it's the new thing, Descent won't support 
 D3 because it's a moving target and because it's not backward compatible 
 with D2, so I'll start porting to D3 but D4 will appear, etc.
 
 And I think this situation doesn't only affect Descent but many 
 libraries and tool suffer from this constant upgrades in D. I think this 
 situation sucks. :-P
 
 Finally, D's userbase is not huge so I really can't tell if Descent is 
 useful enough (and there are the people that prefer to code without an 
 IDE, or with a lighter one).
 
 So... what should I do?
 
 For now I decided to wait, and even maybe abandon the whole idea of 
 keeping Descent up-to-date until D becomes more successful (more 
 probability of people helping me).



 should not use java to write descent, but should be written about him by the
direct use of d , it's would be more easily.
java is too slow.

Thank you for your jobs !

dolive
Oct 19 2009
parent BCS <none anon.com> writes:
Hello dolive,


 should not use java to write descent, but should be written about him
 by the direct use of d , it's would be more easily.


All/most of eclipse is in Java so decent more or less needs to be in Java. 
The next choice would be the C++ that DMD is already in.


 java is too slow.


Lots of people will debate you on that.
Oct 19 2009
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
Ary Borenszweig Wrote:


 Descent has a problem: it supports D1 very well (kinda) but good D2 
 support is still far away.  The latest dmd versions I ported it to are 
 1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many 
 front-end changes). Porting from 2.030 to 2.035 is heavy because a lot 
 of changes were introduced.
 
 In both cases porting is a slow (and boring) task: checking the diffs 
 between each file, finding the matching function if it already exists or 
 creating it, copying the code, translating it to Java, then translating 
 some bits of code to Descent (it's a bit more than just copy, past, 
 change size_t to int, remove stars). Doing it alone is really, really 
 slow and boring, but I have no problem doing it from time to time, like 
 maybe 10, 15 minutes each day.
 
 Another problem with porting, specially to D2, is that when I'll finish 
 porting to 2.035 there will probably be a 2.037. Maybe some changes that 
 were applied in 2.035 were roll backed or changed a little, so perhaps I 
 should wait for D2 to become frozen and then port. Either way, I'm 
 afraid that when I'll finally have good D2 support there will be a D3 in 
 the way. When I stabilize Descent more or less (write a lot of tests, 
 improve memory and performance, etc.) maybe the situation that exists 
 now will repeat itself: D2 will be more or less stable but some people 
 will be focused on D3 because it's the new thing, Descent won't support 
 D3 because it's a moving target and because it's not backward compatible 
 with D2, so I'll start porting to D3 but D4 will appear, etc.
 
 And I think this situation doesn't only affect Descent but many 
 libraries and tool suffer from this constant upgrades in D. I think this 
 situation sucks. :-P
 
 Finally, D's userbase is not huge so I really can't tell if Descent is 
 useful enough (and there are the people that prefer to code without an 
 IDE, or with a lighter one).
 
 So... what should I do?
 
 For now I decided to wait, and even maybe abandon the whole idea of 
 keeping Descent up-to-date until D becomes more successful (more 
 probability of people helping me).


Ary,

You have done a great job with Descent to date.  Thank you; I've been using
it every day since I started with D about 5 weeks ago.  Part of my
reason for using it happens to be that I'm regularly looking at past
Java projects and trying to get a handle on recoding some of these
in D so having both D and Java editors at hand (via Eclipse) is convenient
for me at the moment.

To be honest though I feel Eclipse is becoming less appealing year after
year .. seeming as though it's now past its prime.  To be honest, Eclipse
is just not a snappy, responsive code editor anymore (if it ever was).

There comes a time, like now since you are asking, when it becomes a
good idea to stand back, have a look around, have a rethink
(where you want to go / what you want to get out of developing Descent)
and then regroup accordingly.

FWIW, try googling on Lua IDE's and see what that throws up.  In some ways
Lua and D have some commonality in trying to achieve big by being little.
Also D and Lua communities are both relatively small (compared with Java,
.Net, C++) so there might well be some mutual sympathies :-)

Here's a random link from stackoverflow that I just pulled up:

http://stackoverflow.com/questions/143939/whats-a-good-ide-to-use-for-lua

Anyway, my main reason for replying to your post is to encourage you
in whatever you decide to do with Descent.  Myself though, I wouldn't
waste too much time on moving targets.

Take care,

Justin Johansson
Oct 20 2009
prev sibling next sibling parent digited <digited yandex.ru> writes:
Ary Borenszweig Wrote:


 So... what should I do?


You've done a great job with Descent!

As long as D2 is not stable, you don't have to support DMD2's latest version -
i doubt that there's a lot of ppl who will develop something serious on an
alpha version of language (maybe except KorDen).

Please, do not drop D1 support for Descent! I've found it the only IDE fully
suitable for D1 crossplatform development, and i'll use it a lot for a couple
of projects. Java may be slower than $LANG, Eclipse may be huge, but Descent
works good and there's really no alternatives for a good IDE for D.
Oct 21 2009
prev sibling next sibling parent Erich <vadrick yahoo.com> writes:
Ary Borenszweig Wrote:


 So... what should I do?


Good question.  The truth is that a lot of new D converts will probably be
coming from Java and Eclipse is the path of least resistance.  I'm done with
Java and I don't really want to go back to C++ or C (or even ASM for that
matter).  However, I don't have the patience to write a "trial program" in
notepad.  If it wasn't for descent, I would have given up on D.  

So, I guess this says two things.  First, thank you.  Second, I think what
you're doing is very important to the eventual success of an excellent
language.  It may be grueling work, but it has made a difference--as least from
my perspective.

Now, what to do?  I think it's ok to skip releases.  I also think it's ok to
leave things broken for 2.X.  I've hit a few so far and I accept them as a
hazard of being on the leading edge.  I just gave the Change Log a scan and my
gut says a new update every six months would be enough to keep us pioneers in
the game.   

However, ultimately, if it's still too much and you need to give it up, all I
have to say is this--thank you.
Nov 02 2009
prev sibling next sibling parent bobef <adsad askdfkasjflaflajf.asdasd> writes:
Why not compile the dmd front end into a C DLL, add some wrappers that you
need, import that in Java. This is what I often do with D, when I don't want to
translate lot of C/C++ code. I guess you lose platform independence this way
though, but I bet it will still spare you a lot of work.
Dec 01 2009
prev sibling next sibling parent dolive <dolive89 sina.com> writes:
Ary Borenszweig дµ½:


 Descent has a problem: it supports D1 very well (kinda) but good D2 
 support is still far away.  The latest dmd versions I ported it to are 
 1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many 
 front-end changes). Porting from 2.030 to 2.035 is heavy because a lot 
 of changes were introduced.
 
 In both cases porting is a slow (and boring) task: checking the diffs 
 between each file, finding the matching function if it already exists or 
 creating it, copying the code, translating it to Java, then translating 
 some bits of code to Descent (it's a bit more than just copy, past, 
 change size_t to int, remove stars). Doing it alone is really, really 
 slow and boring, but I have no problem doing it from time to time, like 
 maybe 10, 15 minutes each day.
 
 Another problem with porting, specially to D2, is that when I'll finish 
 porting to 2.035 there will probably be a 2.037. Maybe some changes that 
 were applied in 2.035 were roll backed or changed a little, so perhaps I 
 should wait for D2 to become frozen and then port. Either way, I'm 
 afraid that when I'll finally have good D2 support there will be a D3 in 
 the way. When I stabilize Descent more or less (write a lot of tests, 
 improve memory and performance, etc.) maybe the situation that exists 
 now will repeat itself: D2 will be more or less stable but some people 
 will be focused on D3 because it's the new thing, Descent won't support 
 D3 because it's a moving target and because it's not backward compatible 
 with D2, so I'll start porting to D3 but D4 will appear, etc.
 
 And I think this situation doesn't only affect Descent but many 
 libraries and tool suffer from this constant upgrades in D. I think this 
 situation sucks. :-P
 
 Finally, D's userbase is not huge so I really can't tell if Descent is 
 useful enough (and there are the people that prefer to code without an 
 IDE, or with a lighter one).
 
 So... what should I do?
 
 For now I decided to wait, and even maybe abandon the whole idea of 
 keeping Descent up-to-date until D becomes more successful (more 
 probability of people helping me).



please update to dmd2.042 , thanks you every much !

dolive
Mar 24 2010
prev sibling parent reply Arlo White <awhite calpoly.edu> writes:
I just played with dmd 2.045 and Descent yesterday for the first time. 
Yes Descent is a bit buggy (couldn't get builds or context-assist 
working), but I still stuck with it because I'm familiar with Eclipse 
and none of the other D editors looked that mature either (or weren't 
available for Linux).

As someone mentioned, it's much easier for people to learn a new 
language if they don't have to learn a new IDE at the same time. Eclipse 
is a pretty solid platform to build on and a lot of people are familiar 
with it. If D expects to be a popular programming language an Eclipse 
plugin is almost a necessity.

True, not many people use Descent now, but if/when D becomes popular a 
lot of people will want a good Eclipse plugin, and you'll want to be 
ready for them, which means having Descent ready when D2 is.

I'm surprised that the language updates can't be automated, but I'm not 
familiar with how Eclipse does language syntax under the hood.

If the task is really that menial maybe it could be automatically 
divided up and farmed out to volunteers?

Could you add a page to your wiki describing the problem you're having 
keeping up with the language and some examples of how a D language 
change translates to a Descent change. Also, show why it's hard to 
automate. Then post a link here and maybe some people can look at the 
problem and give you ideas on how to automate it or divide up the task.

I would be willing help you out if you can describe what I need to do 
and where the code is. I downloaded the descent.core source, but there's 
a lot in there and I'm not even sure where the D language stuff is.


-Arlo
May 05 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 5/5/10 21:29, Arlo White wrote:

 I just played with dmd 2.045 and Descent yesterday for the first time.
 Yes Descent is a bit buggy (couldn't get builds or context-assist
 working), but I still stuck with it because I'm familiar with Eclipse
 and none of the other D editors looked that mature either (or weren't
 available for Linux).


You can build a project (with external tools). Context-assist should work.


 As someone mentioned, it's much easier for people to learn a new
 language if they don't have to learn a new IDE at the same time. Eclipse
 is a pretty solid platform to build on and a lot of people are familiar
 with it. If D expects to be a popular programming language an Eclipse
 plugin is almost a necessity.

 True, not many people use Descent now, but if/when D becomes popular a
 lot of people will want a good Eclipse plugin, and you'll want to be
 ready for them, which means having Descent ready when D2 is.

 I'm surprised that the language updates can't be automated, but I'm not
 familiar with how Eclipse does language syntax under the hood.


For Java Eclipse uses the built in incremental java compiler as far as I 
know. For D the DMD frontend is translated into Java and somewhat 
modified, adding caches and similar, the DMD frontend is not made for 
this kind of things. Then the frontend also needs to integrated with the 
existing Eclipse APIs


 If the task is really that menial maybe it could be automatically
 divided up and farmed out to volunteers?

 Could you add a page to your wiki describing the problem you're having
 keeping up with the language and some examples of how a D language
 change translates to a Descent change. Also, show why it's hard to
 automate. Then post a link here and maybe some people can look at the
 problem and give you ideas on how to automate it or divide up the task.


I've answer most of this in the above answer, you can also look at: 
http://www.dsource.org/projects/descent/wiki/Development


 I would be willing help you out if you can describe what I need to do
 and where the code is. I downloaded the descent.core source, but there's
 a lot in there and I'm not even sure where the D language stuff is.


 -Arlo
May 06 2010
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jacob Carlborg wrote:

 On 5/5/10 21:29, Arlo White wrote:

 I just played with dmd 2.045 and Descent yesterday for the first time.
 Yes Descent is a bit buggy (couldn't get builds or context-assist
 working), but I still stuck with it because I'm familiar with Eclipse
 and none of the other D editors looked that mature either (or weren't
 available for Linux).


 
 You can build a project (with external tools). Context-assist should work.


Not sure it works with dmd 2.025, though.


 

 As someone mentioned, it's much easier for people to learn a new
 language if they don't have to learn a new IDE at the same time. Eclipse
 is a pretty solid platform to build on and a lot of people are familiar
 with it. If D expects to be a popular programming language an Eclipse
 plugin is almost a necessity.

 True, not many people use Descent now, but if/when D becomes popular a
 lot of people will want a good Eclipse plugin, and you'll want to be
 ready for them, which means having Descent ready when D2 is.

 I'm surprised that the language updates can't be automated, but I'm not
 familiar with how Eclipse does language syntax under the hood.


 
 For Java Eclipse uses the built in incremental java compiler as far as I 
 know. For D the DMD frontend is translated into Java and somewhat 
 modified, adding caches and similar, the DMD frontend is not made for 
 this kind of things. Then the frontend also needs to integrated with the 
 existing Eclipse APIs


Yes, exactly. The tasks when a new D version comes out are:
  - Update the lexer/parser and basically port the diff between the 
version to Java and Descent.
  - Update the public AST (read below...)
  - Check which small features the IDE can provide with these new 
features. For example if there's a new keyword, autocompletion of it 
must be checked. Another example: when alias this was introduced 
autocompleteion offered completions of the aliased symbol.

That's basically it. The problem is, the last ported version is like 2.030

http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/internal/compiler/parser/port.txt

And diffs between each version are huge, it takes a lot of time to do 
it. Frank Benoit started working on a tool to more or less automate this 
process, but I don't knnow what happened with that.

But the real problem is that I don't want to do it. I don't want to 
spend time on it. I'm a little tired of it.

Maybe another problem is that Descent want to do a lot of things, but 
it's very hard to do it (specially if not many people are working on the 
project)


 

 If the task is really that menial maybe it could be automatically
 divided up and farmed out to volunteers?




Yes, the diff can be splitted into several people.


 Could you add a page to your wiki describing the problem you're having
 keeping up with the language and some examples of how a D language
 change translates to a Descent change. Also, show why it's hard to
 automate. Then post a link here and maybe some people can look at the
 problem and give you ideas on how to automate it or divide up the task.


 
 I've answer most of this in the above answer, you can also look at: 
 http://www.dsource.org/projects/descent/wiki/Development


That page is a little outdated, but most of what it says is correct. The 
implementation details defer (for example there's no IModule, that was a 
first approach).


 

 I would be willing help you out if you can describe what I need to do
 and where the code is. I downloaded the descent.core source, but there's
 a lot in there and I'm not even sure where the D language stuff is.




The port is here:

http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/internal/compiler/parser/

This is the public AST (different from the port in that it contains more 
useful information for the IDE, and in a homogeneous way):

http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/core/dom

Thanks for wanting to help! I can give info on how to modify the project 
and make it grow, coding a little, but I'm not sure I will spend lots of 
time on it from now on.
May 06 2010
parent Jacob Carlborg <doob me.com> writes:
On 5/6/10 17:10, Ary Borenszweig wrote:

 Jacob Carlborg wrote:

 On 5/5/10 21:29, Arlo White wrote:

 I just played with dmd 2.045 and Descent yesterday for the first time.
 Yes Descent is a bit buggy (couldn't get builds or context-assist
 working), but I still stuck with it because I'm familiar with Eclipse
 and none of the other D editors looked that mature either (or weren't
 available for Linux).


 You can build a project (with external tools). Context-assist should
 work.


 Not sure it works with dmd 2.025, though.


 As someone mentioned, it's much easier for people to learn a new
 language if they don't have to learn a new IDE at the same time. Eclipse
 is a pretty solid platform to build on and a lot of people are familiar
 with it. If D expects to be a popular programming language an Eclipse
 plugin is almost a necessity.

 True, not many people use Descent now, but if/when D becomes popular a
 lot of people will want a good Eclipse plugin, and you'll want to be
 ready for them, which means having Descent ready when D2 is.

 I'm surprised that the language updates can't be automated, but I'm not
 familiar with how Eclipse does language syntax under the hood.


 For Java Eclipse uses the built in incremental java compiler as far as
 I know. For D the DMD frontend is translated into Java and somewhat
 modified, adding caches and similar, the DMD frontend is not made for
 this kind of things. Then the frontend also needs to integrated with
 the existing Eclipse APIs


 Yes, exactly. The tasks when a new D version comes out are:
 - Update the lexer/parser and basically port the diff between the
 version to Java and Descent.
 - Update the public AST (read below...)
 - Check which small features the IDE can provide with these new
 features. For example if there's a new keyword, autocompletion of it
 must be checked. Another example: when alias this was introduced
 autocompleteion offered completions of the aliased symbol.

 That's basically it. The problem is, the last ported version is like 2.030

 http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/internal/compiler/parser/port.txt


 And diffs between each version are huge, it takes a lot of time to do
 it. Frank Benoit started working on a tool to more or less automate this
 process, but I don't knnow what happened with that.


If you refer to Tiport then it has been abandoned. It was developed to 
port SWT to D but eventually it turned out that you basically need to 
port almost the whole Java API.


 But the real problem is that I don't want to do it. I don't want to
 spend time on it. I'm a little tired of it.


That is too bad. I really like descent, using it almost every day.


 Maybe another problem is that Descent want to do a lot of things, but
 it's very hard to do it (specially if not many people are working on the
 project)


 If the task is really that menial maybe it could be automatically
 divided up and farmed out to volunteers?




 Yes, the diff can be splitted into several people.


 Could you add a page to your wiki describing the problem you're having
 keeping up with the language and some examples of how a D language
 change translates to a Descent change. Also, show why it's hard to
 automate. Then post a link here and maybe some people can look at the
 problem and give you ideas on how to automate it or divide up the task.


 I've answer most of this in the above answer, you can also look at:
 http://www.dsource.org/projects/descent/wiki/Development


 That page is a little outdated, but most of what it says is correct. The
 implementation details defer (for example there's no IModule, that was a
 first approach).


 I would be willing help you out if you can describe what I need to do
 and where the code is. I downloaded the descent.core source, but there's
 a lot in there and I'm not even sure where the D language stuff is.




 The port is here:

 http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/internal/compiler/parser/


 This is the public AST (different from the port in that it contains more
 useful information for the IDE, and in a homogeneous way):

 http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/core/dom


 Thanks for wanting to help! I can give info on how to modify the project
 and make it grow, coding a little, but I'm not sure I will spend lots of
 time on it from now on.
May 06 2010