[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Introducing the PDOM
|
Write your own eh? I smell a technology sub-project ;-)
___________________________________________
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 Doug Schaefer
> Sent: Thursday, September 29, 2005 11:17 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Introducing the PDOM
>
> That's my understanding as well (and I am similarly qualified :). I
will
> take this through the Eclipse legal guys but my understanding is that
a
> couple of other projects are already using Derby (BIRT I think is
one).
>
> One thing I will do is make sure we can substitute the database engine
> so that people taking the CDT and having licensing issues can
substitute
> a different engine, or have no engine at all in which case you would
> default to the current behavior.
>
> Actually, we need this anyway in case it turns out that we can't get
the
> performance near what we'd need with Derby or SQL. Ideally, I would
> write my own database engine that is customized to our requirements,
> however, that's a lot of work...
>
> Thanks,
> Doug
>
> On Thu, 2005-09-29 at 10:40 -0400, Recoskie, Chris wrote:
> > 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
> > _______________________________________________
> > 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
