[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Introducing the PDOM
|
Hi Doug,
> Absolutely. I'm currently looking at Derby, an Apache embedded
> SQL database that has shown some good performance.
Would there any "different" licensing issues with shipping "Derby" with
a product that ships CDT?
Thanks,
Leo
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Sent: Thursday, September 29, 2005 9:45 AM
To: CDT General developers list.; Sumit Sarkar
Subject: Re: [cdt-dev] Introducing the PDOM
Hi Sumit,
This is definitely something else to consider. I know some at IBM have
this requirement as well where the source files reside on a remote
machine. One option was to have the indexer run remotely. With the PDOM,
this should be possible and would provide functionality for all parser
based features (not just the index based ones). Since I'm using SQL for
queries, we should be able to easily handle that on the local side. We
would need to figure out how to package up the remote agent, though.
I'll make sure I document this as a requirement.
Thanks,
Doug
On Thu, 2005-09-29 at 00:31 -0400, Sumit Sarkar wrote:
> Hi Doug,
>
> In our HP Remote Development product, we are facing the problem, that
> "indexer" is reading the local header files (if they exist) to build
> the DOM. In your new architecture, if you consider a way to map the
> local header files with the remote (or from other location), that will
> be great. That way, it will be easier for us to use the remote header
> files to index the remote project. I am not sure whether CDT 3.0 has
> already this feature or not.
>
> Thanks,
> sumit
>
> On 9/28/05, dschaefer@xxxxxxx <dschaefer@xxxxxxx> wrote:
>
>
> Absolutely. I'm currently looking at Derby, an Apache embedded
> SQL database
> that has shown some good performance. I'm still learning SQL
> but I think you
> can merge tables together quickly. So you could create a PDOM
> in one
> project, one containing all your header files for example, and
> package it up
> for delivery, and auto-merge it into the PDOM for users'
> projects.
>
> I'll record it as a requirement and we'll definitely give that
> a try as this
> thing matures over the upcoming weeks.
>
> Cheers,
> Doug
>
> "Treggiari, Leo" <leo.treggiari@xxxxxxxxx> said:
> > Hi Doug,
> >
> > I think it is a GOOD idea. If we have CDT-wide tool-chain
> definitions,
> > then maybe the tool-chain could provide a pre-built PDOM for
> its own
> > header files. So, you might want to consider being able to
> handle
> > multiple PDOMs for a single project.
> >
> > Regards,
> > Leo
> >
> >
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Doug Schaefer
> > Sent: Wednesday, September 28, 2005 5:06 PM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: [cdt-dev] Introducing the PDOM
> >
> > Hey gang,
> >
> > As the next step in the evolution of the CDT DOM, I am
> starting work on
> > a persistence strategy that will allow us to greatly reduce
> the amount
> > of parsing we do in both the indexer as well as the features
> that use
> > the DOM (content assist, open decl/def, etc). The idea is to
> stow away
> > names and bindings from the DOM into a database to allow for
> binding
> > resolution and decl/ref searches to get information from
> this database
> > instead of having to reparse. I am calling this database the
> PDOM, or
> > Persisted DOM.
> >
> > The premise is that database look-ups will be faster than
> building the
> > AST for header files over and over again. That should
> finally solve our
> > indexer performance problems. And if not, I am making it so
> that we can
> > simply toss away the whole thing and take another tact
> without
> > disturbing the status-quo.
> >
> > I am producing a slide package on all this that I will
> present at the
> > CDT developer conference next month. In the meantime, you
> will notice
> > code going into the CVS repository as I start trying out
> these ideas in
> > optional plugins: org.eclipse.cdt.pdom.core and
> org.eclipse.cdt.pdom.ui .
> >
> > If you have any questions, opinions, or even better - would
> like to help
> > out, please let me know. I am certainly open to opinions
> that make me
> > think this is a bad idea and save me all this work :)
> >
> > Cheers,
> > Doug
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
>
>
>
> --
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
