Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » DLTK and a D Eclipse IDE
| DLTK and a D Eclipse IDE [message #14921] |
Sun, 26 August 2007 09:07  |
Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
First of all, let me give congratulations for the idea and the effort
put forth into the creation of the DLTK project. I think it is a great
idea to refactor JDT's infrastructure that can be used for other
languages (as well adding more generic infrastructure for Eclipse-based
language IDEs), so I'm quite glad there is an Eclipse project for this.
Me and a few other devs have been working for a while now on a project
(http://www.dsource.org/projects/descent) to create an Eclipse based IDE
for the D programming language (http://www.digitalmars.com/d/). I've
found that there is a lot of common IDE infrastructure that is very
useful to have, but is not provided by the current Eclipse Platform, and
is very hard and worksome to implement from scratch, not to mention
redundant, since it is pretty much reinventing the wheel.
Due to this I was very happy to learn about the DLTK project, and it's
goal (among others) to reuse JDT's code and architecture. I started
integrating a branch of our D IDE with DLTK, to see how it would work
(we have a fully work D parser & AST), and I'm happy to say the results
were good. I didn't so far use DLTK's AST hierarchy, other than using
ASTNode as the root class (but none of the TypeDeclaration, Reference,
etc. classes), so I didn't get all of DLTK's possible functionality.
However what we did get so far was already quite worthwhile:
* A JDT-like language model with caching, several kinds of buildpath
entries, full UI boilerplate code.
* Indexing of model type elements (class, structs, etc.) and a working
Open Type feature.
* Miscellaneous UI boilerplate code, such as full-featured editor (code
folding, quick outline, templates, bracket matching), preference pages
for coloring, code templates & compilers, etc..
I hope this shows that DLTK is quite useful not just for dynamic
languages (D is a statically type, natively compiled language), so maybe
you should take that into consideration. For example, not necessarily
call the common language components "scripts" or "interpreters" :) .
It's not a priority at all for us, since they're just names, but I think
eventually they could be parameterized as well, possibly by
DTLKLanguageToolkit.
I also have a few questions which I was hoping could be clarified:
* I'm using DLTK version 0.9, and for what I understand, the
ScriptSourceElementLabel provider extension point is not implemented
yet, correct? Is there currently any workaround for this, or this will
only be available in the next version?
* What are the consequences of not using the DLTK AST hierarchy in terms
of functionality? Indexing seems to works fine without it, apparently it
only cares about what the DeeSourceElementRequestor reports, which can
be adapted easily. I have examined the DLTK Search code, and understood
how it uses the DLTK AST hierarchy, so I should be able to adapt that
too. But for the hierarchy features, I haven't been able to make it
work, and I didn't yet understand if that feature requires the usage of
a proper DLTK AST hierarchy. Isn't the usage of the superclasses field
of the ISourceElementRequestor.TypeInfo enough? Do the strings of the
superclasses need to be in some special formal, like fully qualified
names, or is it just simple names?
And what other DLTK features are affected by not using the DLTK AST
hierarchy?
* Regarding ISourceModule's there are some concepts that come from JDT
that I wasn't able to fully understand yet. What's the relation of
working copies versus IDocument's, and the platform FileBuffers plugin?
What is a primary working copy? Is there any particular difference
between the reconcile and makeConsistent methods?
Kudos!
--
Bruno Medeiros - MSc in CS/E student
|
|
|
| Re: DLTK and a D Eclipse IDE [message #15808 is a reply to message #14921] |
Mon, 27 August 2007 01:23  |
| Eclipse User |
|
|
|
Thank you for kind words, and I'm happy with your positive experience
adopting DLTK for D language. Sure DLTK technically OK for statically
typed languages too, thanks for mention this.
AFAIK no one tried to adopt DLTK for statically typed languages until
your D efforts, so it looks like we shall think about to reconsider
naming conventions - from my standpoint it's a little bit strange to
work on something like D support dealing with Script* classes/interfaces.
Just out of curiosity, did you considered to reuse CDT infrastructure,
which I believe extensible and having to be a base for all compiled (at
least backed by GNU tools) languages as one of it's goals?
Thanks again, and we're looking forward for new DLTK citizen(s) :)
Kind Regards,
Andrey
Bruno Medeiros wrote:
> First of all, let me give congratulations for the idea and the effort
> put forth into the creation of the DLTK project. I think it is a great
> idea to refactor JDT's infrastructure that can be used for other
> languages (as well adding more generic infrastructure for Eclipse-based
> language IDEs), so I'm quite glad there is an Eclipse project for this.
>
> Me and a few other devs have been working for a while now on a project
> (http://www.dsource.org/projects/descent) to create an Eclipse based IDE
> for the D programming language (http://www.digitalmars.com/d/). I've
> found that there is a lot of common IDE infrastructure that is very
> useful to have, but is not provided by the current Eclipse Platform, and
> is very hard and worksome to implement from scratch, not to mention
> redundant, since it is pretty much reinventing the wheel.
>
> Due to this I was very happy to learn about the DLTK project, and it's
> goal (among others) to reuse JDT's code and architecture. I started
> integrating a branch of our D IDE with DLTK, to see how it would work
> (we have a fully work D parser & AST), and I'm happy to say the results
> were good. I didn't so far use DLTK's AST hierarchy, other than using
> ASTNode as the root class (but none of the TypeDeclaration, Reference,
> etc. classes), so I didn't get all of DLTK's possible functionality.
> However what we did get so far was already quite worthwhile:
>
> * A JDT-like language model with caching, several kinds of buildpath
> entries, full UI boilerplate code.
> * Indexing of model type elements (class, structs, etc.) and a working
> Open Type feature.
> * Miscellaneous UI boilerplate code, such as full-featured editor (code
> folding, quick outline, templates, bracket matching), preference pages
> for coloring, code templates & compilers, etc..
>
> I hope this shows that DLTK is quite useful not just for dynamic
> languages (D is a statically type, natively compiled language), so maybe
> you should take that into consideration. For example, not necessarily
> call the common language components "scripts" or "interpreters" :) .
> It's not a priority at all for us, since they're just names, but I think
> eventually they could be parameterized as well, possibly by
> DTLKLanguageToolkit.
>
> I also have a few questions which I was hoping could be clarified:
>
> * I'm using DLTK version 0.9, and for what I understand, the
> ScriptSourceElementLabel provider extension point is not implemented
> yet, correct? Is there currently any workaround for this, or this will
> only be available in the next version?
>
> * What are the consequences of not using the DLTK AST hierarchy in terms
> of functionality? Indexing seems to works fine without it, apparently it
> only cares about what the DeeSourceElementRequestor reports, which can
> be adapted easily. I have examined the DLTK Search code, and understood
> how it uses the DLTK AST hierarchy, so I should be able to adapt that
> too. But for the hierarchy features, I haven't been able to make it
> work, and I didn't yet understand if that feature requires the usage of
> a proper DLTK AST hierarchy. Isn't the usage of the superclasses field
> of the ISourceElementRequestor.TypeInfo enough? Do the strings of the
> superclasses need to be in some special formal, like fully qualified
> names, or is it just simple names?
> And what other DLTK features are affected by not using the DLTK AST
> hierarchy?
>
> * Regarding ISourceModule's there are some concepts that come from JDT
> that I wasn't able to fully understand yet. What's the relation of
> working copies versus IDocument's, and the platform FileBuffers plugin?
> What is a primary working copy? Is there any particular difference
> between the reconcile and makeConsistent methods?
>
> Kudos!
|
|
|
| Re: DLTK and a D Eclipse IDE [message #15846 is a reply to message #14921] |
Mon, 27 August 2007 02:10 |
| Eclipse User |
|
|
|
Hi Bruno,
We very appreciate that DLTK are useful for you.
Thanks for using DLTK.
> I also have a few questions which I was hoping could be clarified:
>
> * I'm using DLTK version 0.9, and for what I understand, the
> ScriptSourceElementLabel provider extension point is not implemented
> yet, correct? Is there currently any workaround for this, or this will
> only be available in the next version?
Sorry, I did not understand what are you mean by
ScriptSourceElementLabel provider, we have ScriptUILabelProvider and
ScriptElementLabels classes, and they both exist for 1.0 and 0.9
versions. Please could you elaborate?
>
> * What are the consequences of not using the DLTK AST hierarchy in terms
> of functionality? Indexing seems to works fine without it, apparently it
> only cares about what the DeeSourceElementRequestor reports, which can
> be adapted easily. I have examined the DLTK Search code, and understood
> how it uses the DLTK AST hierarchy, so I should be able to adapt that
> too. But for the hierarchy features, I haven't been able to make it
> work, and I didn't yet understand if that feature requires the usage of
> a proper DLTK AST hierarchy. Isn't the usage of the superclasses field
> of the ISourceElementRequestor.TypeInfo enough? Do the strings of the
> superclasses need to be in some special formal, like fully qualified
> names, or is it just simple names?
Unfortunately Type hierarchies feature aren't implemented yet.
> And what other DLTK features are affected by not using the DLTK AST
> hierarchy?
>
> * Regarding ISourceModule's there are some concepts that come from JDT
> that I wasn't able to fully understand yet. What's the relation of
> working copies versus IDocument's, and the platform FileBuffers plugin?
> What is a primary working copy?
FileBuffers are used to synchronize file content across multiple editors.
Non Primary working copies are used if source modules are't on
buildpath, or if source module resource aren't created.
IDocument are used in JFace based text editors.
We have adapter from IBuffer to IDocument.
>Is there any particular difference
> between the reconcile and makeConsistent methods?
ISourceModule.makeConsistent only rebuild model from resource, but
reconcile also builds delta change from old and new model state.
Andrei.
|
|
|
| Re: DLTK and a D Eclipse IDE [message #15863 is a reply to message #15808] |
Mon, 27 August 2007 06:34 |
| Eclipse User |
|
|
|
I'm one of the "few others" who are developing an IDE for the D
language. Let me congratulate you too on this project, this was really
needed.
When I saw the DLTK project I thought about using it for D. Having
ported some of JDT's code I saw you use an ISourceElementParser and some
stuff I've seen in JDT's code, so I thought "well, DLTK should also be
usable for statically typed languages". But... I wasn't really sure,
most because of the project's name: *Dynamic* Languages Tool Kit. So I
dropped the idea (which Bruno didn't, luckily).
Maybe you should write somewhere that although the project is well
suited for dynamic languages, it should also work for statically
languages as well.
About CDT, I don't like it that much as JDT since you don't get exact
error positions, you don't have smart quick fixes or smart refactors...
overall, it feels less powerful. That's why I started with JDT's code base.
Best Regards,
Ary
Andrey Platov escribió:
> Thank you for kind words, and I'm happy with your positive experience
> adopting DLTK for D language. Sure DLTK technically OK for statically
> typed languages too, thanks for mention this.
>
> AFAIK no one tried to adopt DLTK for statically typed languages until
> your D efforts, so it looks like we shall think about to reconsider
> naming conventions - from my standpoint it's a little bit strange to
> work on something like D support dealing with Script* classes/interfaces.
>
> Just out of curiosity, did you considered to reuse CDT infrastructure,
> which I believe extensible and having to be a base for all compiled (at
> least backed by GNU tools) languages as one of it's goals?
>
> Thanks again, and we're looking forward for new DLTK citizen(s) :)
>
> Kind Regards,
> Andrey
>
> Bruno Medeiros wrote:
>> First of all, let me give congratulations for the idea and the effort
>> put forth into the creation of the DLTK project. I think it is a great
>> idea to refactor JDT's infrastructure that can be used for other
>> languages (as well adding more generic infrastructure for
>> Eclipse-based language IDEs), so I'm quite glad there is an Eclipse
>> project for this.
>>
>> Me and a few other devs have been working for a while now on a project
>> (http://www.dsource.org/projects/descent) to create an Eclipse based
>> IDE for the D programming language (http://www.digitalmars.com/d/).
>> I've found that there is a lot of common IDE infrastructure that is
>> very useful to have, but is not provided by the current Eclipse
>> Platform, and is very hard and worksome to implement from scratch, not
>> to mention redundant, since it is pretty much reinventing the wheel.
>>
>> Due to this I was very happy to learn about the DLTK project, and it's
>> goal (among others) to reuse JDT's code and architecture. I started
>> integrating a branch of our D IDE with DLTK, to see how it would work
>> (we have a fully work D parser & AST), and I'm happy to say the
>> results were good. I didn't so far use DLTK's AST hierarchy, other
>> than using ASTNode as the root class (but none of the TypeDeclaration,
>> Reference, etc. classes), so I didn't get all of DLTK's possible
>> functionality. However what we did get so far was already quite
>> worthwhile:
>>
>> * A JDT-like language model with caching, several kinds of buildpath
>> entries, full UI boilerplate code.
>> * Indexing of model type elements (class, structs, etc.) and a working
>> Open Type feature.
>> * Miscellaneous UI boilerplate code, such as full-featured editor
>> (code folding, quick outline, templates, bracket matching), preference
>> pages for coloring, code templates & compilers, etc..
>>
>> I hope this shows that DLTK is quite useful not just for dynamic
>> languages (D is a statically type, natively compiled language), so
>> maybe you should take that into consideration. For example, not
>> necessarily call the common language components "scripts" or
>> "interpreters" :) . It's not a priority at all for us, since they're
>> just names, but I think eventually they could be parameterized as
>> well, possibly by DTLKLanguageToolkit.
>>
>> I also have a few questions which I was hoping could be clarified:
>>
>> * I'm using DLTK version 0.9, and for what I understand, the
>> ScriptSourceElementLabel provider extension point is not implemented
>> yet, correct? Is there currently any workaround for this, or this will
>> only be available in the next version?
>>
>> * What are the consequences of not using the DLTK AST hierarchy in
>> terms of functionality? Indexing seems to works fine without it,
>> apparently it only cares about what the DeeSourceElementRequestor
>> reports, which can be adapted easily. I have examined the DLTK Search
>> code, and understood how it uses the DLTK AST hierarchy, so I should
>> be able to adapt that too. But for the hierarchy features, I haven't
>> been able to make it work, and I didn't yet understand if that feature
>> requires the usage of a proper DLTK AST hierarchy. Isn't the usage of
>> the superclasses field of the ISourceElementRequestor.TypeInfo enough?
>> Do the strings of the superclasses need to be in some special formal,
>> like fully qualified names, or is it just simple names?
>> And what other DLTK features are affected by not using the DLTK AST
>> hierarchy?
>>
>> * Regarding ISourceModule's there are some concepts that come from JDT
>> that I wasn't able to fully understand yet. What's the relation of
>> working copies versus IDocument's, and the platform FileBuffers
>> plugin? What is a primary working copy? Is there any particular
>> difference between the reconcile and makeConsistent methods?
>>
>> Kudos!
|
|
|
| Re: DLTK and a D Eclipse IDE [message #15881 is a reply to message #15846] |
Mon, 27 August 2007 07:39 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Andrei Sobolev wrote:
> Hi Bruno,
>
> We very appreciate that DLTK are useful for you.
> Thanks for using DLTK.
>
>> I also have a few questions which I was hoping could be clarified:
>>
>> * I'm using DLTK version 0.9, and for what I understand, the
>> ScriptSourceElementLabel provider extension point is not implemented
>> yet, correct? Is there currently any workaround for this, or this will
>> only be available in the next version?
> Sorry, I did not understand what are you mean by
> ScriptSourceElementLabel provider, we have ScriptUILabelProvider and
> ScriptElementLabels classes, and they both exist for 1.0 and 0.9
> versions. Please could you elaborate?
>
Well, I was trying to customize the images of some of D's model elements
(like structs, unions, templates, etc. which right now have the same
icon as classes). I tried first the
IDLTKUILanguageToolkit.createScripUILabelProvider() method but it didn't
seem it was used at all in the UI (except for the ScriptEditor error
updater perhaps?)
Then I checked ScriptElementImageProvider which seemingly is what many
UI components use. ScriptElementImageProvider has a method
getContributedLabelProvider which checks an extension
point("org.eclipse.dltk.ui.scriptElementLabelProviders") for label
provider contributions, however that extension does not seem to be defined.
So is there any way do do this in DLTK 0.9, and if not, which of those
two ways should be used in the future to customize language model
elements images?
>> * What are the consequences of not using the DLTK AST hierarchy in terms
>> of functionality? Indexing seems to works fine without it, apparently it
>> only cares about what the DeeSourceElementRequestor reports, which can
>> be adapted easily. I have examined the DLTK Search code, and understood
>> how it uses the DLTK AST hierarchy, so I should be able to adapt that
>> too. But for the hierarchy features, I haven't been able to make it
>> work, and I didn't yet understand if that feature requires the usage of
>> a proper DLTK AST hierarchy. Isn't the usage of the superclasses field
>> of the ISourceElementRequestor.TypeInfo enough? Do the strings of the
>> superclasses need to be in some special formal, like fully qualified
>> names, or is it just simple names?
>
> Unfortunately Type hierarchies feature aren't implemented yet.
>
Ah my mistake. I somehow was thiking that that was one of the features
shown in the DLTK Ruby movie, but that was not the case. That explains
all those NLS missing messages warnings. :)
>> And what other DLTK features are affected by not using the DLTK AST
>> hierarchy?
>
>> * Regarding ISourceModule's there are some concepts that come from JDT
>> that I wasn't able to fully understand yet. What's the relation of
>> working copies versus IDocument's, and the platform FileBuffers plugin?
>> What is a primary working copy?
>
> FileBuffers are used to synchronize file content across multiple editors.
>
> Non Primary working copies are used if source modules are't on
> buildpath, or if source module resource aren't created.
>
I see. But what is the role of the working copy owner in those cases
then? To manage the set of working copies belonging to itself(the owner)?
> IDocument are used in JFace based text editors.
> We have adapter from IBuffer to IDocument.
>
>> Is there any particular difference
>> between the reconcile and makeConsistent methods?
> ISourceModule.makeConsistent only rebuild model from resource, but
> reconcile also builds delta change from old and new model state.
>
> Andrei.
I see, thanks.
--
Bruno Medeiros - MSc in CS/E student
|
|
|
| Re: DLTK and a D Eclipse IDE [message #15900 is a reply to message #15808] |
Mon, 27 August 2007 08:10 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Andrey Platov wrote:
> Thank you for kind words, and I'm happy with your positive experience
> adopting DLTK for D language. Sure DLTK technically OK for statically
> typed languages too, thanks for mention this.
>
> AFAIK no one tried to adopt DLTK for statically typed languages until
> your D efforts, so it looks like we shall think about to reconsider
> naming conventions - from my standpoint it's a little bit strange to
> work on something like D support dealing with Script* classes/interfaces.
>
> Just out of curiosity, did you considered to reuse CDT infrastructure,
> which I believe extensible and having to be a base for all compiled (at
> least backed by GNU tools) languages as one of it's goals?
>
Hum, I never thought much about that, since (even tough I don't know
much about CDT infrastructure) I don't think CDT has much to offer to D.
Mostly because D, even though it is a statically compiled language (and
aiming to replace C++), it has a structured module system, similar to
Java and other modern languages. That is, no need for ".h" files, and
all source files must be placed in a filesystem directory structure
according to the package they are defined.
This means JDT's project model (source folders, package fragments, etc.)
fits much better to D than what C++ IDEs use (whether CDT or others).
As for building D projects, again due to the structured module system,
one doesn't need managing makefiles to build a D project: The
dependencies between modules can be calculated automatically, and there
are tools that do that for D, much like javac, where you only need to
specify the buildpath, and one source file, and the tool will compile
all source files required. So I don't see much use for CDT here too.
But One aspect of CDT that I recall might be useful, is debugger
integration (using GDB), so that might be worth taking a look at. But so
far Ary is the one who has been doing work with debugger integration, I
don't know much about it. :)
> Thanks again, and we're looking forward for new DLTK citizen(s) :)
>
> Kind Regards,
> Andrey
>
We also give thanks, and we hope to release a DTLK-based version of the
D IDE soon. :)
--
Bruno Medeiros - MSc in CS/E student
|
|
|
| Re: DLTK and a D Eclipse IDE [message #15917 is a reply to message #15863] |
Mon, 27 August 2007 08:30 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Ary Manzana wrote:
> I'm one of the "few others" who are developing an IDE for the D
> language. Let me congratulate you too on this project, this was really
> needed.
>
> When I saw the DLTK project I thought about using it for D. Having
> ported some of JDT's code I saw you use an ISourceElementParser and some
> stuff I've seen in JDT's code, so I thought "well, DLTK should also be
> usable for statically typed languages". But... I wasn't really sure,
> most because of the project's name: *Dynamic* Languages Tool Kit. So I
> dropped the idea (which Bruno didn't, luckily).
>
I also didn't realize that at the first time (I had actually heard of
DTLK and seen the Ruby movie, about 1-2 months ago). It was only very
recently, when I realized that a lot of JDT's infrastructure would be
very useful to have in other languages, but impractically worksome to
implement from scratch, that I searched in the Eclipse site if anyone
had similar ideas. The closest I found was the Google SoC project, which
also aims to provide some generic language support, (but so far more at
the parser & AST creation than the rest). But then I rechecked DTLK, and
actually looked into the "building a DLTK-based language IDE" guide in
which I thought - I don't see any reason this wouldn't work for D or
similar languages. To confirm, I then checked the project creation
slides and saw the magic words "Generalizes JDT code and follows its
architecture". I was more than sold. :)
> Maybe you should write somewhere that although the project is well
> suited for dynamic languages, it should also work for statically
> languages as well.
>
The project creation slides state that languages like C++ or Objective C
are a "good fit", but so far I think that is the only place in the DLTK
site that states that it is also usable for compiled languages.
--
Bruno Medeiros - MSc in CS/E student
|
|
|
Goto Forum:
Current Time: Tue Nov 04 00:23:42 EST 2025
Powered by FUDForum. Page generated in 0.06132 seconds |
Home