1. Website registration
  2. Mailing list registration
  3. Suggested projects for contributors
  4. Test suite
  5. Repository access
    1. Writing to the repository
    2. Coding conventions
    3. Commit rules
    4. Test programs
    5. Using Mercurial to manage your own work
    6. Using Subversion branches to manage your own work
  6. All about the Trac project management software

Anyone who wants to can look around the site; there's no need to register.

Website registration

Anyone who registers, which requires that you read, understand, and agree to the Terms of use, may create or modify wiki content or tickets (bug reports). If you can register, please do, we welcome your questions, your code samples, your requests for enhancement and bug reports, and so on.

Mailing list registration

You can also sign up on the Project Fortress mailing lists. These are separate from the website.

Suggested projects for contributors

There are a number of ways you can contribute to Project Fortress:

Test suite

Running ./ant test in your Fortress root directory will start off a series of JUnit tests to verify that the Fortress interpreter is working correctly. If you see BUILD SUCCESSFUL at the end of the test suite output then you are ready to begin programming in Fortress! However, if you see BUILD FAILED then you should submit a bug report to us. It would be helpful to go to the ProjectFortress/TEST-RESULTS directory and use the following command to determine which log files contain the error information: 

grep -l "Errors: [1-9]" *; grep -l "Failures: [1-9]" *

Please attach the offending files to your bug report.

Repository access

There is also a repository associated with this Trac project. It currently contains the most up-to-date version of the Fortress interpreter, tests, and demos. Anyone can check out from the repository, but commits will be limited to people who have completed a Sun Contributor Agreement and had it approved. To check out the repository, say 

svn checkout https://projectfortress.sun.com/svn/Community/trunk PFC

If a web proxy interferes, edit ~/.subversion/servers to include lines similar to these 

[groups]
projectfortress = projectfortress.sun.com

[projectfortress]
http-proxy-host = webcache.east
http-proxy-port = 8080

(substituting your server and port for webcache.east and 8080).

Writing to the repository

Sun employees and people who have an approved SCA may commit to the repository. To do this, you will need to supply a --username parameter to svn on the first commit (svn caches this afterwards). In the unlikely event that you access the same repository with two different identities, the memory of your username is sticky, and will persist unless you explicitly change it.

Here's a forbidden commit: 

dr2chase$ svn commit -m "Another test commit" testSerialization
svn: Commit failed (details follow):
svn: MKACTIVITY of '/svn/Community/!svn/act/992...451': 403 Forbidden (https://projectfortress.sun.com)

Here's a successful commit: 

dr2chase$ svn commit -m "Another test commit" testSerialization --username dr2chase
Sending        testSerialization
Transmitting file data .
Committed revision 586.

Subversion will also request your password if it has not cached it from a previous operation.

Coding conventions

We don't disagree with much in The Elements of Java Style, but there's not much controversial in that book.

We have several local coding conventions.

  • Code should compile under JDK 5.0.
  • Please don't use tab characters; use 4 spaces for indentation. Source text should generally fit horizontally in 80-90 columns.
  • The abstract syntax tree (AST), implemented by a large class hierarchy defining immutable objects, is a basic form of data representation throughout system. These class declarations are automatically generated by the ASTGen tool, accompanied by a collection of abstract visitor classes for walking over the AST. Where it makes sense, extending one of these visitors is the best way to manipulate an AST node. See the Fortress AST source file and ASTGen documentation for further information.
  • There's a kitchen-sink package (com.sun.fortress.useful) containing useful, general-purpose code. Some of this duplicates packages from elsewhere; however, we are wary of excess generality because of the constraints of a scalable, work-stealing environment.
  • Additional general-purpose classes are provided by the PLT Utilities library (packages prefixed by edu.rice.cs.plt; javadocs and sources are available for further information). Particularly pervasive are uses of the classes IterUtil and Option. Developers should be familiar with our option type conventions.
  • We care very much about error messages. Source locations should be preserved, and presented in an appropriate way when an error occurs. This is an ongoing effort; if you encounter a bug in some Fortress code that is diagnosed with a confusing error message, that's a bug in our implementation, too.
  • The internals of the interpreter are unusual because the interpreter is supposed to scale to very many processors and use work-stealing to efficiently generate concurrency. If you use a lock in a data structure, it could easily be a mistake. We make frequent use of applicative data structures updated with a either a CAS at the root or synchronized write (using the volatile-double-checked-locking pattern).
  • The interpreter uses caches for various operations; notably, the dispatch of an overloaded function potentially performs multiple rounds of type inference (this should disappear when static type inference is available).
  • We are trying to structure the interpreter so it takes an input similar to what a compiler would take. This is intended both to keep the interpreter simple (it usually does) and it to ease the transition to a compiler.
  • JUnit 3.8 is used for testing. Test classes have names like FooJUTest. A number of Fortress programs are also used as tests of static and runtime behavior, managed by a few JUnit tests that act as drivers (see below).

Commit rules

Before any commit, be sure to first

  • svn update at the top level.
  • ant clean test at the top level.
  • Check that the tests passed.

Test programs

The directory trunk/ProjectFortress/tests/ contains some Fortress programs to test the interpreter. Test programs that are supposed to fail (for example, storing a String into a ZZ32-typed mutable) have names that are prefixed with XXX.

The directory trunk/ProjectFortress/static_tests/ contains some Fortress programs to test the static end. Test programs that are supposed to fail have names that are prefixed with XXX. Test programs that are supposed to pass the static disambiguation then fail have names that are prefixed with DXX.

The directory trunk/ProjectFortress/not_passing_yet/ contains some Fortress programs that should pass, but do not. For example, if we had a test file containing an error that should be detected, but it isn't, that would be contained in trunk/ProjectFortress/not_passing_yet with a name prefixed with XXX.

Using Mercurial to manage your own work

Mercurial is version control system with a user interface similar to Subversion, but a different way of organizing dependences between repositories. It is possible to overlay Subversion and Mercurial repositories on the same directory tree, which provides a more strutured way to push and pull changes between independent subversion repositories, or to perform local version control on your own work. The ProjectFortress Subversion repository includes .hgignore files to make this easy. Here's how.

Using Subversion branches to manage your own work

Here is a brief description of how to use Subversion branches to manage your own work.

All about the Trac project management software

This site is built using Trac, which includes an integrated Wiki, subversion integration, a ticket system, and various views that make it easier to figure out what is going on. If you want to learn more, explore the links below.

  • Playground -- a local sandbox, where you can play with Trac, submit bogus tickets, close them, and so on. If you're a little unsure about how this all behaves, go noodle around here. Registration at any project works for all projects, though you'll need to log in to each one separately.
  • AboutThisInstallation -- Log/tutorial on how to configure a site like this. If you see something that interests you, but the explanation isn't clear, (please) file a bug. If you see a way to do something better, (please) file a bug.
  • TracGuide -- Built-in Documentation
  • The Trac project -- Trac Open Source Project
  • Trac FAQ -- Frequently Asked Questions
  • TracSupport -- Trac Support