Future of Descent and D Eclipse IDE

[Jacob Carlborg]

On 2010-05-25 04.15, Ary Borenszweig wrote:
> On 05/24/2010 08:38 AM, Bruno Medeiros wrote:
>> Hi.
>>
>> I'm now in a position where I can dedicate a lot of free time for an
>> open source project, and I'm seriously considering going back working on
>> the D Eclipse IDE project. I worked on Mmrnmhrm a couple of years ago,
>> as part of my thesis, which led to some restrictions on the kinds of
>> tasks I should work on. Now I don't have that issue, I have (almost)
>> complete freedom on what I can work on, and in particular I would like
>> to unify the two current efforts for a D Eclipse IDE: Descent and
>> Mmrnmhrm, as there is a lot of work being put into both (especially
>> Descent ^^ )
>>
>> Now, Ary has been inactive for quite a while, and he said he wasn't
>> interested in working in Descent any more :(
>
> I know I told you that, but now that I think of it, it's not that I'm
> not interested. The project has grown too big and in the last releases I
> added nice features without thinking much about the design and the
> flexibility of growth... so now I feel the project is kind of a mess and
> it's very hard to continue it. The problems I see are:
>
> * Porting DMD source to Java was done manually and it's a very boring
> and long task, and we need to find a way to automate it if we'd like to
> support really good integration with the language (I mean, real semantic
> value, and because D is not dynamic I think this is worth it).

I have two suggestions for this problem:

1. Could DMD be compiled to a dynamic library and then be used like a 
plugin, using JNI to interact between the compiler and the plugin.

2. Another suggestion is to use 
http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-generator.html 
or http://www.gccxml.org/HTML/Index.html to either port DMD or create 
interfaces to it and then use it as the first suggestion.

> * The DMD source was modified a little bit for performance reasons and
> for integration with Descent so now it contains bugs that are very hard
> to fix.
> * The code is just too big because it has a lot of code from JDT,
> modified a little bit, and that makes it hard for other developers to join.
> . This means I'm currently
>> the only Eclipse developer, so I could just do things in the way I'm
>> thinking of, but Ary, I would still like to get your input, because I
>> hope one day you might be interested in coming back to Descent
>> development. :)
>
> I can program now and then if I have time, but what I'd really like is
> to plan how to start things almost from scratch and think of a plan of
> doing it well. Maybe Descent could be done with IMP, I don't think using
> JDT's source code will be good for the project. The only problem I see
> with IMP (or DLTK) is that they don't support some of the features
> Descent already provides... but as IMP gets better Descent will
> automatically get those updates.
>
>>
>> There a few issues and ideas I would like to establish for the future D
>> Eclipse IDE project. But for now I'll just mention one which I think is
>> quite important:
>>
>> * I think the DMD frontend Java port should be separated into its own
>> plugin/bundle, and not be part of the descent.core plugin. The first
>> reason is for abstraction and modularization: This project is quite
>> distinct on its own, and separation would make it a bit easier for
>> people to understand it, and work on it alone (especially since it would
>> require almost no knowledge about Eclipse), or for it to be used in
>> other projects (like it is now for Mmrnmhrm). Also this allows the
>> plugin to not be a singleton, so there could be several plugin instances
>> with different versions running at the same time.
>
> Yes, I would like that! And I think it's very necessary. Then you can
> plug this module into any IDE implementation you want.
>
>>
>> Separation purely for modularization should be reason enough, but if you
>> are not convinced, there is a more serious issue which regards licenses:
>> descent.core source is (heavily) based on the JDT core, which means this
>> derived code must be licensed under the EPL. Same for the other Descent
>> plugins. But the DMD frontend is licensed under the Artistic License. So
>> unless the frontend port could be relicensed as EPL as well, then it
>> should be in its own plugin. This is so that each plugin has its own
>> license which applies to all its underlying code, to make things clearer.
>
> Ah, um, right. :-P
>
>>
>> Ary, I would like to know if by any chance you are interested in doing
>> that separation in the near future. If not, I can do it myself, but it
>> might take a bit longer.
>
> Yes, I would like to do it, but first I think we need to think if we
> want to a) keep using the Java port and little by little upgrade it to
> the latest dmd versions, b) start another port but build a tool to more
> or less automate that process (Frank Benoit started something in that
> regard but I don't know what happened then) or c) make a less
> semantic-aware IDE like Mmrnmhrm (the good thing is that it might be
> simpler and faster, but the bad thing is that we might not get all the
> features we'd want).

If you refer to the project Tioport by Frank Benoit, it was a project to 
automate porting Java code to D, I don't see how it would help in this case.

> Thanks for bringing this topic! A lot of effort has been put in Descent
> and it would maybe be sad if the project is abandoned... (but I really
> feel I'm stuck now and I don't know how to advance... or at least I know
> I would have to keep porting C++ code to Java, but...
>
> http://www.explosm.net/comics/1804/
>
> )
>
> Cheers!


-- 
/Jacob Carlborg