Getting Started

New Photran contributors are always welcome. Here are some suggestions for getting started.

All Developers

1. Learn Java. Photran is built on top of Eclipse and is written in Java. Obviously, this means you need to know Java. If you have programmed in C or C++, learning the basics of Java should only take a few weeks, and you will find that programming in Java is far less painful than programming in C or C++.
2. Learn to Use Eclipse. Photran is essentially a Fortran add-on for Eclipse. If you have not used Eclipse before, or if you're not quite sure what "perspectives" and "views" are, you should work through a basic Eclipse tutorial before attempting to learn Photran. Start Eclipse, click on the Help menu, and click Help Contents. Expand the Workbench User's Guide, expand Getting Started, and work through the section labeled Basic Tutorial.
3. Learn to Use Photran. If you have not used Photran before, you should become a fluent Photran user before you try to add a new feature or fix a bug in it. See the Documentation page on the Photran web site. Photran reuses many components of the Eclipse C/C++ Development Tool (CDT), so you may want to focus on learning CDT: Once you know how to use CDT, you will know how to use Photran.
4. Learn to use the JDT and PDE to Develop a Simple Plug-in. If you have never developed an Eclipse plug-in before, develop a simple plug-in, perhaps one which adds an item to the menu bar which pops up a "Hello, world!" message box when you click it. For example, work through Chapters 7 through 9 in The Java Developer's Guide to Eclipse, 2/e by D'Anjou et al. This will also require you to learn how to do Java development in Eclipse, although this should be easy if you already know how to do C/C++ and Fortran development in Eclipse.
5. Check Out Photran from CVS and Compile It. Read How to Check Out Photran from CVS and Compile It, and actually do it. Make sure you can compile Photran.
6. Read the Photran Developer's Guide (Chapters 1 & 2). Read the first two chapters of the Photran Developer's Guide. These chapters apply to all developers.
7. Join the Mailing Lists.
   • Join the main Photran Mailing List. This is where Photran users post questions and get answers. If you have problems or questions about how to use Photran, this is a good place to start.
   • Join the Photran Contributors' Mailing List. This is where architectural/design issues are discussed, new releases are planned, conference calls are announced, etc.
8. Read about Our Coding Conventions. Read the Eclipse Naming, Coding, and JavaDoc Conventions. Look through some of the classes in org.eclipse.photran.internal.core.refactoring to get a feel for the coding style adopted in Photran (but don't be surprised when you discover that not all of our 60,000 lines of code adhere to our coding standard). In general, we use 120-character lines, 4-column tabs, descriptive variable names, and curly braces on the next line, etc. A copyright notice must appear at the top of every source file, and every API class should be JavaDoc'ed. Vocabulary specific to that class appears in bold in the class documentation, and method comments assume that the reader has already read the class documentation (so that vocabulary can be used freely).

Developers of UI Enhancements

1. Learn the Editor Framework, JFace Text. If you will be working on the Photran editor, read about the JFace Text framework (Chapter 26 in D'Anjou et al.). It may not make sense immediately; that's OK. Use the sample XML editor as a starting point. Try changing the syntax highlighting, or adding auto-indentation, or whatever feature(s) are relevent to the work you want to do. Make sure you can implement them in a simple editor before tackling the Photran editors.
2. If you will be working on dialog boxes, you will need to learn the Standard Widget Toolkit. Depending on what you will be working on--preference pages, project property dialogs, etc.--you may need to learn about other parts of the Eclipse framework as well. Ask if you are not sure.

Developers of Program Analyses, Transformations, and Refactorings

1. Learn Fortran. Work through Fortran 95/2003 Explained by Metcalf, Reid, and Cohen or another book on Fortran 90/95. Depending on what you're writing, you might be able to ignore certain parts of the language. Ask if you are not sure.
2. Read the Photran Developer's Guide (Remaining Chapters). Read the remaining chapters of the Photran Developer's Guide. Spend some time looking at the Fortran parsing grammar (fortran95.bnf) and familiarizing yourself with the AST.
3. JUnit. If you will be working on refactorings or another non-UI part of Photran, you will probably need to write unit tests. This is done in JUnit 3, which is nicely integrated with the Eclipse Java Development Tools (JDT). See junit.org.

Projects for New Developers

Note on Project Difficulty. I [Jeff] have implemented pieces of these projects at one time or another, so these are informed estimates of difficulty based on technical experience. That said, I have obviously not attempted to implement any of these projects in their entirety, and there could be complications that I did not consider or that are not immediately apparent. Conversely, seemingly difficult projects sometimes turn out to be surprisingly easy. For CS427 students, your grade will be based on the actual difficulty of the project, not on how difficult I estimated it to be, so if a project turns out to be easier or harder than anticipated, you should discuss this with the course staff to establish a fair and reasonable set of objectives.

Note that "easy" means "easy relative to some other projects," not "any CS1 student could do this project." Don't be insulted if it takes several frustrating hours to complete the project.

THESE PROJECT DESCRIPTIONS ARE UNDER REVISION.

UI Enhancements

• Semantic highlighting

  Moderate

  Photran currently supports syntactic highlighting: comments, keywords, identifiers, and string literals are colored distinctly. Since this coloring is updated on every keystroke, it is done without using the lexer or parser, instead using a fast but imperfect heuristic algorithm. JDT and newer versions of CDT use semantic highlighting, which uses information from the parser and a subsequent semantic analysis to do even more advanced highlighting. For example, in JDT, fields, local variables, and static variables are colored differently, even though they're all identifiers syntactically. Since it is unreasonable to do a full lexical analysis on every keystroke (we tried), much less a full parse and semantic analysis, only syntactic highlighting is done as the user types. A reconciler runs when the user stops typing (currently after 500 ms) and runs the parser and semantic analysis in a separate thread; subsequently, the highlighting in the editor can be updated in the UI thread.

  This project essentially has two parts. One is identifying what types of semantic highlighting would be done for Fortran (what are the different types of identifiers?); the other is modifying the Fortran editor to support it.

  You will need to implement this in the experimental editor located in the org.eclipse.photran.ui.vpg plug-in (when you run Photran, right-click a file and choose Open With > Fortran Editor (VPG Experimental Features); "EXPERIMENTAL" should be displayed in 36-point letters at the top of the editor window). The JavaDoc and sample code in the org.eclipse.photran.internal.ui.editor_vpg package should be particularly helpful.

  Most of the CDT implementation is in org.eclipse.cdt.internal.ui.editor.Semantic*.java, but be aware that our infrastructure is quite different from theirs, so it will be easier to implement this on your own, working from the sample code.

  Bonus Points. Include a global preference page to allow user-customizable coloring and (more importantly) an option to toggle semantic highlighting on and off.

• Content assist

  Moderate

  Eclipse editors support word completion automatically; content assist is a "smarter," context-sensitive variant of word completion. Although extremely sophisticated variations are possible, only rudimentary support is required for this project.

  This project has two parts and a bonus part which is optional but significantly more useful. Keep your code for each part. Each is useful for a different reason, and any or all could end up in production (in one form or another).

  1. Prototype content assist. Demonstrate what is minimally required to implement content assist in the editor: What classes have to be changed, and how? You can pop up any arbitrary list of words (say, { "Fill", "In", "This", "List" }).
  2. Collect a list of identifiers, and use it to fill in the list. Use the editor's partitioning to collect this list (this divides the text into regions for syntax highlighting, among other things).

  This can be implemented in the main Fortran editor(s)/AbstractFortranEditor.

  Bonus Points (Difficulty: 4). Use the VPG (and a DefinitionMap, which has the infrastructure you need) to collect a list of all of the identifiers in a program and their associated scopes. When the user activates content assist, show only those identifiers that are in scope at the cursor position. You will need to implement this in the experimental editor located in the org.eclipse.photran.ui.vpg plug-in (when you run Photran, right-click a file and choose Open With > Fortran Editor (VPG Experimental Features); "EXPERIMENTAL" should be displayed in 36-point letters at the top of the editor window). The JavaDoc and sample code in the org.eclipse.photran.internal.ui.editor_vpg package should be particularly helpful.

• Matching parenthesis highlighting

  Easy

  If you know how to use Google and Edit > Paste, you can probably do this project (although you should be very careful about intellectual property/licensing issues). Still, it has been requested several times and will be immensely useful. This should be used as a "warm up" project to get acquainted with the editor; if you do this, you should also work on another project (such as the JDT-/CDT-style preference page and/or auto-indent).

• Hover tips containing type/declaration

  Moderate

  If you hover your mouse over an identifier in JDT (or CDT), a tooltip window with the declaration appears. This project would be to implement something similar for Fortran. You will need to decide what to display in the hover tip, based on the type of identifier.

  You will need to implement this in the experimental editor located in the org.eclipse.photran.ui.vpg plug-in (when you run Photran, right-click a file and choose Open With > Fortran Editor (VPG Experimental Features); "EXPERIMENTAL" should be displayed in 36-point letters at the top of the editor window). The JavaDoc and sample code in the org.eclipse.photran.internal.ui.editor_vpg package should be particularly helpful.

• Auto-indent

  Moderate

  Eclipse editors auto-indent automatically (Photran currently uses this default auto-indent strategy), but this behavior can be customized for particular languages. In the case of Fortran, the indentation should be increased, for example, when the user presses Enter to complete a program statement, and an end program statement should be un-indented automatically. (However, the line following the assignment statement program = 3 should not be auto-indented, so this is more complex than looking at the first characters on the line.)

  Customizing auto-indent in an Eclipse editor is fairly straightforward. The difficult part is implementing it in such a way that it "feels natural" and is more useful than the default auto-indent strategy. It is surprisingly easy to make an auto-indent strategy that is more annoying than useful. So while this project is technically easy, a successful project will require some significant usability testing (by "real" Fortran programmers); a half-working implementation will not make it into production.

  This can be implemented in the main Fortran editor(s)/AbstractFortranEditor. The partitioning should be useful in helping determing when particular words (e.g., program or if) are used as identifiers and when they are used as keywords, an essential distinction for determining when to auto-indent..

• Folding

  Easy

  Folding is the ability to collapse several lines of text in the editor. In JDT, for example, there is a plus sign in the left margin of the editor next to each method definition: Clicking on this collapses that function into a single line.

  This project has two parts: One is determining what constructs in the Fortran language should be folded in the editor; the other is actually implementing this.

  You will need to implement this in the experimental editor located in the org.eclipse.photran.ui.vpg plug-in (when you run Photran, right-click a file and choose Open With > Fortran Editor (VPG Experimental Features); "EXPERIMENTAL" should be displayed in 36-point letters at the top of the editor window). The JavaDoc and sample code in the org.eclipse.photran.internal.ui.editor_vpg package should be particularly helpful.

  Bonus Points. C# has a #region directive which can be placed around arbitrary sections of code to make them foldable in the editor. Use Fortran comment lines (perhaps ! region "Some summary text" and ! end region) to achieve a similar effect in Photran. (Hint: Comments are available in the AST, but it is probably faster to scan the editor text line by line using a regular expression, e.g., using Java's Pattern class, and the editor's partitioning.)

• Find all references

  Moderate

  In JDT, clicking on Search > References provides several options for searching for all of the references to a particular entity. (This is also available in the editor context menu.) The goal of this project is to implement this in Fortran. At a minimum, a workspace-wide search should be implemented; searching within a single project and/or working set should be attempted if time permits.

  This will need to be implemented in the VPG UI plug-in. It is probably easiest to contribute these actions to the experimental editor located in the org.eclipse.photran.ui.vpg plug-in (when you run Photran, right-click a file and choose Open With > Fortran Editor (VPG Experimental Features); "EXPERIMENTAL" should be displayed in 36-point letters at the top of the editor window). The JavaDoc and sample code in the org.eclipse.photran.internal.ui.editor_vpg package should be particularly helpful. Performing the search itself is actually quite easy (Hint: Finding all of the references to a variable is an essential part of performing a Rename refactoring).

• Prototype Fortran search

  Moderate

  Both JDT and CDT have Search dialogs specific to their language, which allow you to search for classes, methods, enums, and other types of constructs based on name. The goal of this project is to prototype UI support for Fortran Search and to identify what can and cannot be done easily with Photran's VPG. This project consists of the following parts.

  1. Design and prototype a Fortran Search page, similar to the Java and C/C++ search pages. What types of entities can be searched for in a Fortran program?
  2. Implement a search results page. You do not need to actually perform the search according to the criteria in the dialog box; an arbitrary, fixed list of results is fine (e.g., the first search result will always jump to line 5 in someproject/somefile.f90).
  3. The JDT and CDT both have a program database that is quite different from Photran's VPG. Read the code that computes search results for JDT and CDT, and (in writing) briefly summarize how search results are computed in these tools. How is regular expression matching performed? What sort of API is provided by their program database to facilitate searching? (Photran's VPG was not designed to facilitate searches like this; your "report" from this section should help us identify what sort of API would need to be built to support your search dialogs.)

  This will need to be implemented in the VPG UI plug-in.

  Bonus Points. Instead of a fixed, arbitrary list of search results, implement some search functionality using the VPG. For example, you might perform the search specified by the user, but limit the search to only one particular file (rather than attempting to perform it on an entire project or the entire workspace).

• JDT-/CDT-style preference page for editor coloring

  Easy

  Photran's preference page for setting editor colors is simple and functional; JDT and CDT have a more sophisticated page which displays sample code to illustrate highlighting. Implement a similar page for Photran.

  This project, like matching parenthesis highlighting, is largely copy-and-paste, so you should plan to work on another project as well.

• Declaration view

  Moderate

  Create a Declaration view for Fortran (like the one in JDT). When the user's cursor is moved over a subprogram identifier, display the declaration (function or subroutine statement) and preceding comment for the referenced subprogram. (Hint: Note that CSTNode#printOn(PrintStream) can be used to retrieve the exact text of an AST node, including whitespace and comments.)

  You will need to implement this in the experimental editor located in the org.eclipse.photran.ui.vpg plug-in (when you run Photran, right-click a file and choose Open With > Fortran Editor (VPG Experimental Features); "EXPERIMENTAL" should be displayed in 36-point letters at the top of the editor window). The JavaDoc and sample code in the org.eclipse.photran.internal.ui.editor_vpg package should be particularly helpful.

• Complain about Photran (two sub-projects)

  Moderate

  We might regret this later... this project will make it easy for users to complain about Photran.

  • Contribute a Photran menu to menu bar in the Fortran perspective and the Fortran editors with the following items.
    • Send a Complaint About Photran. This will pop up a dialog box where the user can describe a problem they are having with Photran (e.g., it is running out of memory). They should supply their name and e-mail address. Their operating system, Eclipse version, Photran version, JVM, and similar information should be collected automatically.
    • Submit Code that Highlights Incorrectly. This will allow the user to submit the contents of the active editor. The fields in the above item (name, e-mail, OS, etc.) should be included as well.
    • Submit Code that Does Not Parse But Should. This will allow the user to submit the contents of the active editor so that we can add it to our suite of parser tests. The fields in the above item (name, e-mail, OS, etc.) should be included as well, although no comments are necessary (we can figure out the parse error on our own). It should be verified that the file does not parse; sometimes users confuse syntax highlighting with parsing.
    • (Put a separator in the menu at this point.)
    • View Frequently Asked Questions. This simply opens a browser window on the Photran FAQ.
    • View Photran Web Site. This opens a browser window on http://www.eclipse.org/photran
  • The first three menu items above should submit the information to a script on Photran's web server (see next item).
  • (No Java!) Create a PHP script which can run on Photran's web site and accept these submissions from Photran clients. It should then e-mail the information to an address we will give you. This should be easy to customize; we might eventually modify it to automatically generate a JUnit test and a CVS patch, for example.

  There are lots of ways to communicate the data between Photran and the Web server (a simple HTTP POST or XML-RPC, among others). Be prepared to defend your choice on technical grounds. "We wanted to try this" is not a good justification.

  The PHP work will be heavily scrutinized for security holes. Eclipse.org is a prominent, high-traffic site; running risky or questionable scripts on their servers is unacceptable.

Refactorings & Transformations

Difficulty ratings for these projects assume that you have a basic knowledge of abstract syntax trees and other concepts from an introductory programming languages/compilers course. If you do not, these projects probably aren't appropriate.

• Canonicalize Identifier Capitalization

  Easy

  This is essentially a variant of a Rename refactoring.

  • The user should be able to select whether to apply the refactoring to a particular identifier or all of the identifiers in a scope. This will determine what Definition objects the refactoring will apply to.
  • For each Definition, all of the references are modified so that their capitalization matches that of the declaration.

  This is an easy project, so you should plan to work on another project as well.

  Code from both the Rename and Introduce Implicit None refactorings will be useful in implementing this refactoring.

• Canonicalize Keyword Capitalization

  Moderate

  This is more of a code style modification than a refactoring.

  • The user should be able to select whether to apply the refactoring to a selected statement or range of statements, a particular scope, or an entire file. (It would be nice to be able to apply this to all of the files in a folder or project, but that is not required.)
  • The user should be able to decide whether to convert keywords to upper- or lowercase.
  • All of the keywords in the selected region are capitalized accordingly.

  The Rename refactoring contains code that will be useful in implementing this refactoring.

• Align Identifiers in Declarations

  Challenging

  This is more of a code style modification than a refactoring. Fortran programmers commonly begin subprograms with lists of type declarations in which they align variable names and trailing comments (if any). For example,

                 subroutine s
                   implicit none
                   integer, parameter :: three = 3                     ! A constant
                   real               :: matrix(256,256)               ! The decryption matrix
                   character(len=*)   :: message = "Decryption failed"
                 

  This refactoring simply aligns the double-colons (if any), variable names, and trailing comments (if any) as shown.

  • The user must select the scope for which the refactoring will be applied. Other user-customizable options are possible but not necessary (for example, they could toggle whether double-colons, variable names, and/or comments are aligned).
  • Identify all of the type declaration statements for that scope. Compute the starting columns and lengths of each part of each statement, and use the maximums to determine what columns to align on. (Hint: Use CSTNode#printOn to determine the user's exact text for a particular node in the AST.) Note that there may be line continuations in these statements; you can decide how to deal with those.
  • For each statement, insert spaces as needed to align tokens in the desired columsn. (Note that Token objects contain the token text as well as preceding and trailing whitespace and comments ("whitetext"); these whitetext properties can be modified to perform the alignment.)

  The Rename and Introduce Implicit None refactorings contain code that will be useful in implementing this refactoring.

• Eliminate Specification Statements

  Very Challenging

  In Fortran, attributes such as dimension, intent, etc. can be specified in the type declaration statement for a variable, or they can be given in separate specification statements. This refactoring eliminates these specification statements, moving all of these attributes into the type declaration statement.

  • The user should be able to select whether to apply the refactoring to a particular identifier or all of the identifiers in a scope.
  • Every identifier must have an existing type declaration statement into which these attributes can be moved. (If not, the user should run the Introduce Implicit None refactoring first.) The type declaration statement must be in the same scope as the specification statement.
  • The existing type declaration statement must not have a clause which conflicts with a specification statement. For example, it is illegal to specify the dimension of an array in both the type declaration statement and in a separate dimension statement. Also, there must not be two or more conflicting specification statements (e.g., two dimension statements for the same variable).
  • Specification statements are removed and equivalent clauses inserted into the type declaration statement(s) for the affected variables(s).

  Before implementing this refactoring, you will need to identify (1) what the various specification statements are and (2) what the equivalent type declaration clauses are. (Are there any specification statements which can't be eliminated?) Then you will be able to (1) specify in detail what it means for a specification statement to be in conflict with another specification statement or a type declaration clause, and (2) specify exactly what text must be added to a type declaration statement (and where) to preserve semantics after the specification statement has been removed.

  Code from both the Rename and Introduce Implicit None refactorings will be useful in implementing this refactoring.

• Move Variable/Procedure Between Modules

  Very Challenging

  • The user should select an identifier and a target module into which that variable/procedure should be moved. The target module must be different from the source module.
  • The variable/procedure must not have private visibility.
  • The target module must not contain an entity with the same (canonicalized) name as the variable/procedure to move.
  • If an enclosing scope for the target module contains an entity with the same (canonicalized) name as the variable/procedure to move, then all of the references to that entity must still resolve to that entity even if the moved variable/procedure will shadow it within the scope of the module. (Hint: This check is done in the Rename refactoring.)
  • Consider each scope which imports the target module.
    • If that scope also imports the source module but does not import the variable/procedure being moved (due to an only list)...
      • If there is only list on the use statement for the target module, no action needs to be taken. If there is not an only list for the target module...
        • If the scope containing the use statement or an enclosing scope contains an entity with the same (canonicalized) name as the variable/procedure to move, then all of the references to that entity must still resolve to that entity even if the moved variable/procedure will shadow it within the scope of the module. (Hint: This check is done in the Rename refactoring.) If they do not, an only list must be appended to the use statement for the target module, which explicitly imports all of the publically-visible members of the target module (not including the variable/procedure being moved).
        • Otherwise, no action needs to be taken: Importing the moved variable/procedure into this scope will have no effect.
    • If that scope does not import the source module...
      • If the scope or an enclosing scope contains an entity with the same (canonicalized) name as the variable/procedure to move, then all of the references to that entity must still resolve to that entity even if the moved variable/procedure will shadow it within the scope of the module. (Hint: This check is done in the Rename refactoring.) If they do not, an only list must be appended to the use statement for the target module, which explicitly imports all of the publically-visible members of the target module (not including the variable/procedure being moved).
      • Otherwise, no action needs to be taken: Importing the moved variable/procedure into this scope will have no effect.
  • Consider each reference to the variable/procedure in the source module. There must be a use statement which imports the source module. There may or may not be a use statement which imports the target module,
    • If there is no use statement for the target module, a statement of the form use targetmodule, only: identifier must be added, preferably immediately below the use statement for the source module.
    • If there is already a use statement for the target module, and there is an only list, the variable/procedure must be added to that list.
    • If the use statement for the source module includes an only list, the variable/procedure being imported must be included in this list, and that clause must be removed.
    • If the use statement for the source module renames the variable/procedure, the rename clause must be removed from that use statement, and an identical rename clause must be added to the use statement for the target module.

  Code from both the Rename and Introduce Implicit None refactorings will be useful in implementing this refactoring.

• Make Common Variable Names Consistent

  Challenging

  "COMMON" is a kind of global variable that dates from the earliest versions of Fortran. Often they should be replaced by module variables, and even if they should remain COMMON variables, they should follow certain rules.

  A COMMON block has a name (there is also an unnamed COMMON block) and a list of variables. Different modules, procedures, etc. can use the variables in that COMMON block by giving its name and the list of variables. Different specifications of a COMMON block do not have to list the same variables in the same order.

  For example, suppose we have a program

  program main
      integer :: a, b
      real :: c
      common /d/ a, b, c
  ...
  end main
  

  This defines a common block named "d" with three variables.

  Suppose we also have a subroutine

  subroutine proc(x,y)
     integer :: a,b, x, y
     real :: c
     common /d/ a, b, c
  ...
  end subroutine proc
  

  Variable a in "main" is the same memory location as variable a in "proc". This is a kind of global variable where you have to explicitly state that a subroutine uses the variable. At first, it seems not as bad as regular global variables. But it is actually worse!

  Suppose that the subroutine proc was defined as follows:

  subroutine proc(a,b)
     integer :: a,b, x, y
     real :: c
     common /d/ x, y, c
  ...
  end subroutine proc
  

  This program would behave the same as the previous one (i.e. it is a refactoring) except that the variable called "a" in "main" is called "x" in subroutine "proc". The program might be correct for awhile, but someone is likely to cut an expression using a and b from one part of the program to the other, and cause a bug, because "a" in one part is not "a" in the other.

  Even worse, consider the definition

  subroutine proc(x,y)
     integer :: a,b, x, y
     real :: c
     common /d/ b, c
  

  Now, "b" is the same as "a" in "main", and "c" is not the same as "c". "c" in "proc" overlaps in memory with "b" in "main", but an integer is probably 32 bits while a real is probably 128 bits, so everything will be thrown off. In fact, it is possible to do useful tricks, like having an array of length 10 in one definition of a common block, and then having ten variables in the other. This trick is portable. However, if you decide to have four integer variables in one COMMON definition match a real variable in another, so you can break a 128 bit real number into four 32 bit ints, the code is not portable.

  First, we need to be able to find every use of a COMMON block and to check that they are all the same. Often, people INCLUDE the COMMON block definition to make sure that they are all the same. Sometimes people make them different on purpose. Ick! There should be a way to rename variables to make them the same if the problem can be solved by a simple renaming.

  See http://www.sesp.cse.clrc.ac.uk/Publications/Legacy-Software/Legacy-Software/node8.html

  Here is a great discussion of IMPLICIT NONE http://www.sesp.cse.clrc.ac.uk/Publications/Legacy-Software/Legacy-Software/node11.html

  The top of this interesting report on maintaining Fortran code is at http://www.sesp.cse.clrc.ac.uk/Publications/Legacy-Software/Legacy-Software/legacy.html

Static Analyses

• Enforcement of naming conventions

  Challenging

  • Create either a global preference page or a project property page which allows the user to provide regular expressions for (1) local variables and subprogram parameter names, (2) subprogram names, and (3) module names. In the first case, provide the option to provide a different regex for each type (integer, real, complex, etc.)
  • Add an action to the menu bar which will check if the file in the editor meets these naming conventions. (Essentially, find all of the Definitions in the file, and compare their names against the appropriate regular expression provided by the user.) Ideally, you should use markers to identify the problematic names in the editor.

  Bonus Points. Implement this functionality in a builder.

Large Test Codes (3+ Projects)

Project Description (Difficulty: Easy)

• Parallel Ocean Program
• NWChem
• NSF Scientific Application Benchmarks, most notably WRF and GAMESS (see Section 3.0)
• Various codes listed at http://g95.sourceforge.net/g95_status.html
• LANL has several other codes, but some are export-controlled. If you are interested, we can discuss this.