Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [photran-dev] Development directions and thoughts from Superc omputing

That would be way cool :).

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com


> -----Original Message-----
> From: photran-dev-bounces@xxxxxxxxxxx [mailto:photran-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
> Sent: Monday, November 19, 2007 7:46 AM
> To: overbey2@xxxxxxxx; Photran Developer Information
> Cc: Photran Developer Info; photran-dev-bounces@xxxxxxxxxxx
> Subject: Re: [photran-dev] Development directions and thoughts from
> Supercomputing
> 
> The main use cases for this is mixed language projects, where you have
> Fortran code calling C/C++ code, and/or vice versa.  This means that you
> want navigation, content assist, call hierarchy, search, etc. to work
> across language boundaries.
> 
> ===========================
> 
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
> 
> 
> 
> 
>              Jeffrey Overbey
>              <subscribe-photra
>              n-dev@xxxxxxxxx.b                                          To
>              z>                        Photran Developer Info
>              Sent by:                  <photran-dev@xxxxxxxxxxx>
>              photran-dev-bounc                                          cc
>              es@xxxxxxxxxxx
>                                                                    Subject
>                                        Re: [photran-dev] Development
>              16/11/2007 06:46          directions and thoughts from
>              PM                        Supercomputing
> 
> 
>              Please respond to
>              overbey2@xxxxxxxx
>              ; Please respond
>                     to
>              Photran Developer
>                 Information
>              <photran-dev@ecli
>                  pse.org>
> 
> 
> 
> 
> 
> 
> > There are a lot of interesting things we can do if we bring the two
> AST/DOM
> > things together. With the help of Beth and other Eclipsers that cross
> the
> 
> Definitely.  I should elaborate on this a little.
> 
> A large part of my dissertation will focus on program representations
> that make refactoring tools easy to build.  My goal is to do a tutorial
> at EclipseCon 2010 where the participants build an entire
> (well-designed) refactoring engine and two or three refactorings during
> the tutorial.  Without going into detail, though, let's just say that
> requires some flexibility in the AST nodes and a somewhat strange
> program database.  And I want to use Photran as a large-scale test-case.
> 
> On the other hand, though, there's a lot of incentive on the IDE side to
> integrate with CDT.  PDOM will get us search, and for some other things
> (e.g., PLDT) there is an incentive to reuse some aspects of the CDT DOM
> as well.
> 
> It is stupid to build two different ASTs for one IDE, but neither
> approach will serve all of our goals.  So what I would like to do is
> basically build CDT interfaces onto our other representation "on
> demand."  Beth's generic PldtAstVisitor is using these:
> 
> import org.eclipse.cdt.core.dom.ast.IASTDeclaration;
> import org.eclipse.cdt.core.dom.ast.IASTExpression;
> import org.eclipse.cdt.core.dom.ast.IASTFileLocation;
> import org.eclipse.cdt.core.dom.ast.IASTIdExpression;
> import org.eclipse.cdt.core.dom.ast.IASTLiteralExpression;
> import org.eclipse.cdt.core.dom.ast.IASTMacroExpansion;
> import org.eclipse.cdt.core.dom.ast.IASTName;
> import org.eclipse.cdt.core.dom.ast.IASTNode;
> import org.eclipse.cdt.core.dom.ast.IASTNodeLocation;
> import org.eclipse.cdt.core.dom.ast.IASTPreprocessorMacroDefinition;
> import org.eclipse.cdt.core.dom.ast.IASTStatement;
> import org.eclipse.cdt.core.dom.ast.IASTTranslationUnit;
> import org.eclipse.cdt.core.dom.ast.IBinding;
> 
> I hope building these interfaces in will only take a few hours, so I can
> cover that.  If there's a demand for other CDT nodes/interfaces, we can
> discuss that later.
> 
> Which brings me to a question... hypothetically, if we had a 100% CDT
> DOM-compliant AST, what could we do?  (The next question, of course, is,
> How many DOM interfaces would we need to implement on our existing AST
> to achieve the same?)
> 
> Jeff
> 
> _______________________________________________
> photran-dev mailing list
> photran-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/photran-dev
> 
> 
> _______________________________________________
> photran-dev mailing list
> photran-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/photran-dev


Back to the top