[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Introducing the PDOM
|
As far as I know, the Apache and EPL licenses are compatible (vis a vis
Xerces), but IANAL, so do your due dilligence.
___________________________________________
Chris Recoskie
Software Designer
Texas Instruments, Toronto
http://eclipse.org/cdt
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Treggiari, Leo
> Sent: Thursday, September 29, 2005 10:37 AM
> To: CDT General developers list.
> Subject: 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
