Git allows developers without SVN access to maintain their own branches and simplifies the task of submitting patches back to the project maintainers.

It allows all users to participate in development on more equal terms with the developers who have SVN access.

Follow these instructions to get your own git tree from the svn.

Install packages like a C compiler, glib-2.0. Older versions (0.20 and older) require flex and bison. TODO: complete this list

Grab yourself a vala to c compiled release of vala. Vala is self-hosting so it needs another vala compiler to compile itself. Since vala compiles to C code, you can use a tarball release of vala to compile the generated C code of such a release into a working Vala compiler, that will compile the Vala compiler which you might have checked out from the repository.

http://live.gnome.org/Vala/Release

Compiling the release which you just grabbed:

tar jxvf vala-x.y.z.tar.bz2
cd vala-x.y.z
./configure --prefix=/opt/vala-release
make && sudo make install
    

Compiling the newest Vala from the repository: Fixme: anon SVN

svn co svn co svn+ssh://[user]@svn.gnome.org/svn/vala/trunk vala
cd vala
export VALAC=/opt/vala-release/bin/vala
./autogen.sh --prefix=/opt/vala
make && sudo make install
    

Maybe you want to compile the new Vala with itself. Then you simply go over it again:

make distclean
export VALAC=/opt/vala/bin/vala
./autogen.sh --prefix=/opt/vala
make && sudo make install
    

The build works, but *.[ch] files are left behind in the source directory.

These are handled in the normal way by the Vala binding to GLib.OptionContext. Most of the instance variables in Vala.Compiler are referenced in the options array. It's not very interesting.

Vala.Compiler plugs together the classes of libvala in a big pipeline. This modular design means that different Vala tools can share their code. Most modules have impressive-sounding names like AlgorithmicFrobnicator.

The individual steps will be explained later, but first Vala.CodeContext, the data structure which holds everything together. It stores the compile options which were specified on the command line, and a list of source files to compile. There is only one CodeContext instantiated and its reference is passed around a lot, so effectively it's a global variable.

Vala.CodeContext is the root of the code tree, because it contains the root Namespace, which holds references to all parsed code nodes. In addition to the code tree, the context contains a reference to a code generator object. This object walks the code tree and generates code.

Vala.CodeContext contains an important method called accept, which initiates a depth-first traversal of the code tree. This method, and the CodeVisitor pattern will be discussed later.

ignore_node method contains the logic for the "Conditional" attribute.

For every one of the 77 (or so) code node types, there is a create_code_node_type method which constructs the code node and links it with the code generator. The parser will use these methods to create code nodes as it parses them, which know how to emit code later.

Figure 2. Data diagram

The Vala code tree is an abstract syntax tree (AST) built by parsing the Vala sources. For example, if you see a class called Vala.Destructor which inherits Vala.Symbol, then it is a part of the AST. Data structures for the AST and the parser which builds it are in the vala directory.

Vala also uses a tree to represent the C code that will be output. Data structures for the C code tree are in the ccode directory.

The machinery which transforms the Vala AST into a C code tree is in the gobject directory. The reason it's there is because Vala outputs "GObject C" rather than plain C. GObject C is arranged in a particular object-oriented way, uses reference counted memory management, signals, data-structures, and links with glib.

Vala is split upon these lines, most probably to break the system into conceptually-related, understandable chunks. However, with suitable modifications, the different modules could be replaced. Conceivably, Vala could produce non-GObject C code. More realistically, Vala could produce intermediate code as a GCC frontend.

CodeVisitor is an abstract base class which provides 75 empty virtual methods for each kind of code node. A class which inherits CodeVisitor is supposed to do some kind of processing of the code tree. Here are all the CodeVisitor classes in Vala:

     public class Vala.CodeVisitor : Object
       public class Vala.AttributeProcessor : CodeVisitor
       public class Vala.CFGBuilder : CodeVisitor
       public class Vala.CodeGenerator : CodeVisitor
       public class Vala.GIdlParser : CodeVisitor
       public class Vala.GIdlWriter : CodeVisitor
       public class Vala.InterfaceWriter : CodeVisitor
       public class Vala.MemoryManager : CodeVisitor
       public class Vala.NullChecker : CodeVisitor
       public class Vala.Parser : CodeVisitor
       public class Vala.SemanticAnalyzer : CodeVisitor
       public class Vala.SymbolResolver : CodeVisitor

CodeVisitor works closely with the different Vala.CodeNode classes to traverse the code tree. Here are all the code node types in Vala:

public abstract class Vala.CodeNode : Object
  public interface Vala.Statement : CodeNode
  public class Vala.BreakStatement : CodeNode, Statement
  public class Vala.ContinueStatement : CodeNode, Statement
  public class Vala.DeclarationStatement : CodeNode, Statement
  public class Vala.DeleteStatement : CodeNode, Statement
  public class Vala.DoStatement : CodeNode, Statement
  public class Vala.EmptyStatement : CodeNode, Statement
  public class Vala.ExpressionStatement : CodeNode, Statement
  public class Vala.ForStatement : CodeNode, Statement
  public class Vala.IfStatement : CodeNode, Statement
  public class Vala.LockStatement : CodeNode, Statement
  public class Vala.ReturnStatement : CodeNode, Statement
  public class Vala.SwitchStatement : CodeNode, Statement
  public class Vala.ThrowStatement : CodeNode, Statement
  public class Vala.TryStatement : CodeNode, Statement
  public class Vala.WhileStatement : CodeNode, Statement

  public abstract class Vala.DataType : CodeNode
    public abstract class Vala.ReferenceType : DataType
      public class Vala.ArrayType : ReferenceType
      public class Vala.ClassType : ReferenceType
      public class Vala.ErrorType : ReferenceType
      public class Vala.InterfaceType : ReferenceType
      public class Vala.NullType : ReferenceType

    public class Vala.DelegateType : DataType
    public class Vala.InvalidType : DataType
    public class Vala.MethodType : DataType
    public class Vala.PointerType : DataType
    public class Vala.SignalType : DataType
    public class Vala.TypeParameterType : DataType
    public class Vala.UnresolvedType : DataType
    public class Vala.ValueType : DataType
    public class Vala.VoidType : DataType

  public abstract class Vala.Symbol : CodeNode
    public abstract class Vala.Typesymbol : Symbol

    public class Vala.Block : Symbol, Statement
    public class Vala.Constructor : Symbol
    public class Vala.Destructor : Symbol
    public class Vala.EnumValue : Symbol
    public class Vala.ErrorCode : Symbol
    public class Vala.FormalParameter : Symbol
    public class Vala.Member : Symbol
    public class Vala.Namespace : Symbol
    public class Vala.TypeParameter : Symbol
    public class Vala.VariableDeclarator : Symbol

  public abstract class Vala.Expression : CodeNode
    public abstract class Vala.Literal : Expression
      public class Vala.BooleanLiteral : Literal
      public class Vala.CharacterLiteral : Literal
      public class Vala.IntegerLiteral : Literal
      public class Vala.NullLiteral : Literal
      public class Vala.RealLiteral : Literal
      public class Vala.StringLiteral : Literal

    public class Vala.AddressofExpression : Expression
    public class Vala.ArrayCreationExpression : Expression
    public class Vala.Assignment : Expression
    public class Vala.BaseAccess : Expression
    public class Vala.BinaryExpression : Expression
    public class Vala.CastExpression : Expression
    public class Vala.ConditionalExpression : Expression
    public class Vala.ElementAccess : Expression
    public class Vala.InitializerList : Expression
    public class Vala.InvocationExpression : Expression
    public class Vala.LambdaExpression : Expression
    public class Vala.MemberAccess : Expression
    public class Vala.ObjectCreationExpression : Expression
    public class Vala.ParenthesizedExpression : Expression
    public class Vala.PointerIndirection : Expression
    public class Vala.PostfixExpression : Expression
    public class Vala.ReferenceTransferExpression : Expression
    public class Vala.SizeofExpression : Expression
    public class Vala.Tuple : Expression
    public class Vala.TypeCheck : Expression
    public class Vala.TypeofExpression : Expression
    public class Vala.UnaryExpression : Expression

  public class Vala.LocalVariableDeclaration : CodeNode
  public class Vala.CatchClause : CodeNode
  public class Vala.Attribute : CodeNode
  public class Vala.PropertyAccessor : CodeNode
  public class Vala.MemberInitializer : CodeNode
  public class Vala.SwitchLabel : CodeNode
  public class Vala.UnresolvedSymbol : CodeNode
  public class Vala.NamedArgument : CodeNode
  public class Vala.NamespaceReference : CodeNode

All CodeNodes except the root have a non-null parent CodeNode. Some specializations of CodeNode may have children. The type and number of children are declared in the specialized class.

The two important methods in a CodeNode are accept and accept_children. accept() lets the node declare to the CodeVisitor what it is, so the CodeVisitor can act on it. For example, Vala.Struct.accept()

         public override void accept (CodeVisitor visitor) {
             visitor.visit_struct (this);  /* I am a struct! */
         }

accept_children() lets the node accept all of its children so they can declare themselves to the CodeVisitor. This is the recursive part of the traversal. For example, a Struct code node has a list of base types, type parameters, fields, constants, and methods. Vala.Struct.accept_children() accepts all of these.

     public override void accept_children (CodeVisitor visitor) {
         foreach (DataType type in base_types) {
             type.accept (visitor);
         }

         foreach (TypeParameter p in type_parameters) {
             p.accept (visitor);
         }

         foreach (Field f in fields) {
             f.accept (visitor);
         }

         foreach (Constant c in constants) {
             c.accept (visitor);
         }

         foreach (Method m in methods) {
             m.accept (visitor);
         }
     }

As you can see, the CodeVisitor is repeatedly asked to visit different code nodes. It can do whatever analysis is necessary and then traverse deeper into the code tree. This is what a hypothetical implementation of XmlGenerator.visit_struct() might look like:

     public override void visit_struct (Struct st) {
         /* Do some processing of this struct. */
         stdout.printf ("<vala:struct name=\"%s\">\n", st.name);

         /* recurse through struct's children */
         st.accept_children (this);

         /* Do some more processing of the struct, now that its
          * children have been accepted. */
         stdout.printf ("</vala:struct>\n");
     }

The visit_ methods of a CodeVisitor needn't call CodeNode.accept_children(), if it isn't necessary to traverse the whole depth of the code tree. It also isn't necessary to write visit_ methods for every kind of code node, because empty implementations are already provided in CodeVisitor.

What does this have to do with ping pong? Well, the flow of control bounces between the CodeVisitor and the CodeNodes: accept, visit, accept, visit, ... When you navigate the code you will probably find yourself bouncing between different classes.

Vala.Parser is a highly specialized CodeVisitor - the only type of code node it visits is a Vala.SourceFile. However the Parser calls back to the context and uses it to create code nodes (mentioned before), then adds these code nodes into the context's root code node.

I don't want to spoil your fun too much by going into the details of the parser, other than that every parse_ function can throw a ParseError. ParseError is caught when parsing a block or the declarations of a namespace, class, struct, or interface. Fixme.

This grammar is hand-generated from Vala.Parser. Sometimes the structure of this grammar diverges slightly from the code, for example optional non-terminal symbols. However the non-terminal symbol names usually match a parse_ method in Vala.Parser.

input ::=
        using_directive* root_declarations

using_directive ::=
        "using" symbol ("," symbol)* ";"

// from parse_symbol_name
symbol_name ::=
        identifier ("." identifier)*

// from parse_identifier, skip_identifier, get_last_string
identifier ::=
        TOKEN

// corresponds to parse_declarations
root_declarations ::=
        namespace_declarations

// corresponds to parse_declarations
other_declarations ::=
        namespace_declarations
           | class_declarations
           | struct_declarations
           | interface_declarations

// corresponds to parse_declarations
declarations ::=
        "{" other_declarations "}"

namespace_declarations ::=
        namespace_member*

// from parse_namespace_member
namespace_member ::=
        namespace_declaration
           | class_declaration
           | interface_declaration
           | struct_declaration
           | enum_declaration
           | error_domain_declaration // ???
           | delegate_declaration
           | method_declaration
           | field_declaration
           | constant_declaration

// from parse_class_member
class_member ::=
         class_declaration
           | struct_declaration
           | enum_declaration
           | delegate_declaration
           | method_declaration
           | signal_declaration
           | field_declaration
           | constant_declaration
           | property_declaration
           | constructor_declaration
           | destructor_declaration

// from parse_declaration and parse_namespace_declaration
namespace_declaration ::=
        attribute* "namespace" symbol_name declarations

// from parse_declaration and parse_class_declaration
class_declaration ::=
        [access_modifier] type_declaration_modifiers
        "class" symbol_name [type_parameter_list] ":" type ("," type)*
        declarations

// from parse_access_modifier
access_modifier ::=
        "private"
	   | "protected"
	   | "public"

// from parse_type_declaration_modifiers
type_declaration_modifiers ::=
        ("abstract" | "static")*

// from parse_member_declaration_modifiers
member_declaration_modifiers ::=
        ("abstract" | "class" | "inline" | "override" | "static" | "virtual")*

// from parse_type_parameter_list
type_parameter_list ::=
        "<" identifier ("," identifier)* ">"

// fixme: complete the grammar, check it

Every expression has a static type. This is computed by the semantic analyser. Vala.DataType is called a "type reference" because it contains a reference to a Vala.Typesymbol (a class, interface, etc) as well as information about the expression's type e.g. if it can be null, if it's an out parameter.

Fixme: expand this section

A Vala.Symbol is a specialization of Vala.CodeNode. All symbols except for the root symbol are contained within another's scope. Types have scope and variables have scope. For types and variables, scope determines their accessibility, subject to access modifiers. For variables, scope also determines their lifetime. As the code tree is traversed, SymbolResolver keeps track of the current scope. For example, when a class is visited, current_scope is set to that class's scope.

When the parser parses a type, e.g. in the statement Gtk.Window main_window;, the type Gtk.Window is initially a Vala.UnresolvedType. In visit_data_type(), the UnresolvedType code node asks its parent to replace it with a new Vala.DataType created with resolve_type().

UnresolvedTypes have UnresolvedSymbols. resolve_type() uses resolve_symbol() to find the Typesymbol referred to, and then wraps it in a new DataType object.

resolve_symbol is a recursive method which looks up an unresolved symbol's name in the current scope and returns the corresponding Typesymbol. The base case is when the UnresolvedSymbol has no qualifiers, e.g. Window. The recursive case is when the symbol looks like Gtk.Window or Gtk.Orientation.HORIZONTAL. In Vala.Parser.parse_symbol_name(), the symbol is built inside-out, so Gtk.Orientation.HORIZONTAL is parsed as

UnresolvedSymbol
    (UnresolvedSymbol
        (UnresolvedSymbol(null, "Gtk"),
         "Orientation"),
     "HORIZONTAL")

This is inside-out because Orientation is the parent scope of HORIZONTAL, but Orientation is the child node of HORIZONTAL.

In the base case, the symbol's name is looked up in current_scope. If the symbol is not found there, then the scope of all imported namespaces is searched. If more than one imported namespace contains the symbol, an "ambiguous reference" error will be reported.

In the recursive case, resolve_symbol() is called on the child node to give a parent scope, in which the symbol is looked up.

One last function of SymbolResolver is in visit_variable_declarator() - to mark a variable type reference as "nullable" if the variable's type is a class, interface, array or error (reference type). This is used later by Vala.NullChecker.