Future of Descent and D Eclipse IDE

[Lutger]

Bruno Medeiros wrote:

> On 25/05/2010 14:06, Jacob Carlborg wrote:
>> 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.
>>
> 
> Nope, the compiler generates a big structure, an AST, which is composed
> of nodes from a complex hierarchy of classes. Transferring such
> sctructure across JNI would be incredibly hard do implement, not to
> mention probably inefficient. JNI (as with most any C interfacing) is
> good mostly just for calling C methods with simple parameters.
> 
> The other option would be for the compiler to expose just a thin API
> (without big data structures), and have the IDE query the semantic
> functionality directly to the compiler. But then the frontend itself
> would have to be extended a lot, which would me a lot of complicated
> coding in C... argh, no way...
> 

Is working with ddmd an option?