Understanding the Results

Table of Contents

1. Everything Works
2. Things Go Wrong
3. Using Logging Information

Everything Works

If the compilation worked, then the compiler will have produced all of the requested machine profiles and machine dependency files. It will not produce any additional output on the console unless the "verbose" option has been used.

If the "verbose" option was active, then each compilation will end with a summary like the following:

42 templates
441/0/441 compiled, 42/42 built
0/0 obj, 42/42 xml, 42/42 dep
0 errors, 22128 ms, 119 MB/506 MB heap, 12 MB/112 MB nonheap

Each line reports different statistics:

1. The first line shows the number of individual pan templates pass to the compiler for processing.
2. The second line shows the number of templates compiled and the number of machine profiles that were built. The three numbers for the compiled templates are: compiled, loaded, and total. The "loaded" templates are pre-compiled sitting in "*.obj" files on disk.
3. The third line gives the number of serialized files. The "obj" are the number of templates compiled, the "xml" are the number of machine profiles, and the "dep" are the number of dependency files written to disk. The first number is the number of successfully written files; the second, the total number requested.
4. The last line gives the number of errors, total time in milliseconds, maximum used/available heap memory, and the maximum used/available non-heap memory.

These statistics give a good overview of what the compiler has done and provides a good cross-check that the full build was successful.

Things Go Wrong

If something goes wrong with the compilation or build, then one or more errors should be printed to the console. There are four categories of errors:

1. Syntax errors: These include any errors that can be caught during the compilation of a single template. These include lexing, parsing, and syntax errors, but also semantic error like absolute assignment statements appearing in a structure template.
2. Evaluation errors: These are the most common; these include any error that happens during the "execution" phase of processing like mathematical errors, primitive type conflicts, etc.
3. Validation errors: Validation error occur during the "validation" phase and indicate that the generated machine profile violates the defined schema in some way.
4. System errors: These include low-level problems like problems reading or writing to disk.

In general, the errors try to indicate as precisely as possible the problem. Usually the name of the source file as well as the location inside the file (line and column numbers) are indicated. For most evaluation exceptions, a traceback is also provided. Validation errors are the most terse, giving only the element causing the problem and the location of the type definition that has been violated.

There is one further class of errors called "compiler errors". These indicate an error in the logic of the compiler itself and should be accompanied by a detailed error message and a java traceback. All compiler errors should be reported as a bug. The bug report should include the template that caused the problem along with the full java traceback. Hopefully, you will not encounter these errors.

Using Logging Information

If you enable logging during your compilation, panc will output information to a logfile. This can be inspected manually, but analysis tools are also provided in the pan distribution (panc/trunk/scripts):

Build statistics	info
Call tree	info
Compile statistics	info
Memory	info
Profiling	info
Threads	info