From: Devin Steffler <Devin_Steffler@xxxxxxxxxx>
Date: April 29, 2005 7:26:01 AM MDT
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: [cdt-dev] DOM AST View
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
What do you mean by "enter into the DOM"?
I built a test view to help developers test/debug what is in the DOM
AST (aptly called the DOM AST View). It is a simplistic graphical
view of the translation unit that is parsed by the DOM AST and it
should help you better understand what is going on.
To use the DOM AST View:
- make sure you have org.eclipse.cdt.ui.tests package from CVS HEAD
- run/debug CDT
- in the "C/C++ Projects" view, right click on a translation unit (a
C/C++ file with .c/.cpp/.cc/etc), then click "Show in DOM AST"
Helpful hints to work with the DOM AST View:
- set a breakpoint at the start of DOMAST$ASTHighlighterAction#run()
- click on a node in the DOM AST View
- at that breakpoint, you can see the selected DOMASTNodeLeaf, each
DOMASTNodeLeaf wraps an actual IASTNode that has been parsed from the
DOM AST:
Object obj = ((IStructuredSelection) selection).getFirstElement(); //
retrieves the DOMASTNodeLeaf that is selected in the DOM AST View
Let me know if this helps or not. I believe it will really help you
understand the naming convention used in the DOM AST, however I'm not
too sure what you mean by "enter into the DOM".
Note: screenshots attached
Devin Steffler
IBM's Eclipse CDT
Ottawa (Palladium), Ontario, Canada
kesselhaus@xxxxxxx
Sent by: cdt-dev-bounces@xxxxxxxxxxx
04/29/2005 08:35 AM
Please respond to
"CDT General developers list."
To
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject
Re: [cdt-dev] Ada in CDT
>
> On Apr 22, 2005, at 5:53 AM, Douglas Schaefer wrote:
>
> > What I want to see is whether our DOM is extensible enough to
handle
> > additional, not so C-like, languages. We already have extensions
for
> > ANSI
> > C and C++ and then into GNU C and C++. I know Ada enough to give
it a
> > try
> > and see. The follow on step would be ICElement and friends which I
> > would
> > create from the results of a DOM quick parse. Finally, we would
have
> > the
> > index which would be populated by gnatxref which is a ctags kind
of
> > thing
> > that also has cross reference info and should be enough to
satisfy our
> > search engine.
> >
> > The dream is that, if you can extend the DOM and ICElement and
index
> > for
> > your particular language, then you would get the content assist
and
> > navigation features for free, or as free as the gdb integration
seems
> > to
> > be ;). I'm a long way from seeing whether the dream comes true,
though.
>
> I think the dream may be possible. However, the only datapoint I
have
> is
> with a project that uses XML to describe C/C++ and Fortran
interfaces
> (function
> names and parameter types. This meant we had to be able to map the
> language type
> systems to XML. It turned out that C and Fortran share a lot in
common
> so this
> effort went very smoothly.
It's just a thought out of reading this. Why not use an XMI-style
format,
maybe based on EMF?
> On Apr 21, 2005, at 8:26 PM, Jeffrey Overbey wrote:
>
> > If our entire AST needs to comply with some CDT interfaces, um...
I
> > haven't counted, but this thing is on the order of 400-500
> > classes/interfaces, and I don't have all that much interest in
> > changing every one of them. :-) But you might convince us
>
> I've met this week with some colleagues at the University of Oregon
who
> do static analysis
> to instrument user code with performance counters. They have
recently
> created a Java
> plugin to demonstrate the concept using the JST DOM to add a node in
> the AST and then
> unparse to a new file (with performance instrumentation). The goal
is
> to try the same thing
> with the CDT DOM and then move on to the Photran AST.
>
> I think the question will be is how much different the Photran AST
(and
> API) is from the DOM.
> I think it may turn out that it will be useful to move the Photran
AST
> to be more compatible
> with the DOM. It so, then perhaps we at LANL could help.
Btw., do you think someone could make up some docs about how to enter
into
the DOM. I'm trying hard to understand the Eclipse-Plugin stuff, and
how to
hook up something into CDT. Some docs on how to enter the DOM and
what could
be retrieved would be nice (even though, you guys should document your
CDT-source more thoroughly anyway). Most people outside the CDT-core
team do
not have your inside knowledge on what classes/methods do just by
reading
its names.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
X-PMX-Wrap: 60
An executable email attachment called DOMASTView_example.zip,
domastview_example.zip (content_type:application/zip, size:435368
bytes) was removed from this message by LANL network as a security
precaution.
Please see http://network.lanl.gov/email/virus-scan.shtml for
additional information.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
