Future of Descent and D Eclipse IDE

[Jacob Carlborg]

On 2010-06-15 21:37, Lutger wrote:
> Bruno Medeiros wrote:
>
>> On 05/06/2010 09:17, Lutger wrote:
>>> 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?
>>
>> Nah. Since DDMD is a direct port of DMD, the situation would not be much
>> different: you would have a lot of C-like code in D, as well as a
>> Walter-like design :P, and you wouldn't be able to change either of
>> those things, because then you would make it significantly hard (if not
>> impractical) to update the DDMD port with new DMD changes.
>> That's exactly the same problem there is with the Java port of DMD.
>>
>> I'm now pretty sure the only good long-term strategy is to have a
>> compiler/engine designed from scratch to work with IDE functionality.
>> Although I didnt realize until now, thanks to your comment, that it
>> might be feasible for this engine to be separate, (either as a process,
>> or as library), from the Java IDE, and thus the engine could be in a
>> different language than Java.
>> Hum, this is quite interesting, one very big reason being that then it
>> could be reused by different D IDEs, or other sorts of projects...
>>
>
> That, and being written in D, would make it more attractive. There is another option with a headstart: dil, if gpl is not a problem.

GPL is generally a problem with Eclipse since the Eclipse license (EPL) 
is incompatible with GPL. The nature of GPL is that you cannot even 
dynamically link to a GPL library without effecting the license of your 
own code and third party code you use. Basically the only way around 
that is inter-process communication. The CDT pluing for Eclipse uses 
this method to communicate with GCC.

-- 
/Jacob Carlborg