sanhozay / clgen Goto Github PK

Parsing should report an error but not produce a stack trace.

Test case:

item("Parking Brake") {
    state("ON", brake > 0) brake = 1;
}
checklist("Before Starting Engines") {
    check("Parking Brake", "ON");
}

Stack trace:

$ clgen test.clg
CLGen 1.1.1
error at line 2: Alias 'brake' is not defined in item 'Parking Brake'
    state("ON", brake > 0) brake = 1;
                ^
error at line 2: Alias 'brake' is not defined in item 'Parking Brake'
    state("ON", brake > 0) brake = 1;
                           ^
java.lang.NullPointerException
        at org.flightgear.clgen.listener.ItemListener.enterAssignInt(ItemListener.java:258)
        at org.flightgear.clgen.CLGenParser$AssignIntContext.enterRule(CLGenParser.java:1445)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.enterRule(ParseTreeWalker.java:42)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:25)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
        at org.flightgear.clgen.CLGen.buildItems(CLGen.java:170)
        at org.flightgear.clgen.CLGen.run(CLGen.java:126)
        at org.flightgear.clgen.CLGen.main(CLGen.java:80)
Generation failed.

The only thing that really needs an option for the time being is a preference to generate a single XML file or multiple XML files included under a single header. All the code is there, it just needs the option passing through from the invocation scripts to the JVM.

Conditional bindings can only include one binding action, e.g.

if (VARIANT == "pup100") trim = 4.0;
if (VARIANT == "pup150") trim = 5.0;

For multiple-engined aircraft, it could be useful to allow conditional bindings with compound actions, e.g.

if (VARIANT == "777-200") {
    e0 = 0.5;
    e1 = 0.5;
}
if (VARIANT == "777-300") {
    e0 = 0.4;
    e1 = 0.4;
}

DOT labels assign special meaning to {, } and |. If these characters are used in checklist item names and state names, the .dot file cannot be processed by Graphviz.

With hand-written XML checklists, splitting long files into individual checklists can make the files more manageable but if the XML is generated there isn't really a need to do so.

CLGen does not perform any type checking, e.g.

v = "some/property";
state("OFF", p == 0) p = false;
state("ON", p == 1.0) p = "true";

This is no worse than writing XML by hand, but CLGen could check the types and warn of any potential problems during checklist generation.

Subtitles and spacers are reverse-engineered as dummy checks rather than text elements.

Subtitles should stand out more clearly in PDF and DOT output.

PDF and DOT output would benefit from titles and other page elements that reference the aircraft or model for which the checklists are written

Instead of requiring an item definition for plain checks, create an implicit item for easy definition of basic checklists, e.g.

checklist("Before Starting Engines") {
    check("Parking Brake", "ON");
    check("Navigation Lights", "ON");
}

Anything more than simple names like "Parking Brake" or "Magnetos" results in expansion of the nodes and an untidy looking digraph.

Looking at existing checklists, longer check titles are quite common.

It is possible to redefine an alias to a different property without warning, e.g.

item("Some Item") {
    p = "controls/gear/brake-parking";
    p = "controls/engines/engine/throttle";
    ...
}

This is a nonsense example, but redefining an alias should be a semantic error.

Dummy checklist items are commonly used to create subtitles within checklists and for blank lines in the checklist dialog.

These can be created by defining dummy items in CLGen, but it is slightly cumbersome:

item("") {
    state("");
}

item("Subtitle:") {
    state("");
}

Some syntactic sugar could be added to the language to support these, e.g.

checklist("Climb") {
    check("Flaps", "UP");
    subtitle("Above 10,000ft:");
    check("Landing Lights", "OFF");
    check("Seat Belt Signs", "OFF");
}

These elements would create dummy elements in the items table without having to create them as dummy items in the .clg file.

Flightgear developers commonly use dummy checks as spacers or subtitles in checklists, e.g.

<item>
  <name></name>
</item>

<item>
  <name>Subtitle for a section of checks</name>
</item>

The PDF output shows a series of '.' characters for these. The DOT output shows empty boxes.

Flightgear now supports grouped checklists:

http://wiki.flightgear.org/FlightGear_Newsletter_April_2018

The CLGen language needs to be updated to support this additional checklist container.

Items sometimes use the same aliases, e.g.

aero = "sim/aero";

These could be defined outside the scope of an item as global aliases.

For example:

<checklist>
  <title>Start Engines</title>
  <item>
    <name>Mixture</name>
    <value>FULL RICH</value>
  </item>
  <item>
    <name>Throttle</name>
    <value>OPEN 1/4"</value>
  </item>
</checklist>

This produces:

checklist("Start Engines") {
    check("Mixture", "FULL RICH");
    check("Throttle", "OPEN 1/4"");
}

The state name should be "OPEN 1/4"", i.e. the double-quote should be escaped.

The AST walk visits the check (which is an item and state) and the check accepts the visitor for the item marker directly. For consistency, the check should have the item and state accept the visitor.

Given a condition such as:

a && b && c

The generated output follows the structure of the parse tree, which ends up like:

<and>
  <and>
    <property>a</property>
    <property>b</property>
  </and>
  <property>c</property>
</and>

It should probably output the more readable:

<and>
  <property>a</property>
  <property>b</property>
  <property>c</property>
</and>

The nested form is valid and works perfectly well, but the optimized version is what an aircraft developer would write.

When creating a prototype checklist with no items, adding additional values to checklists does not produce output in the XML, PDF or DOT files.

The structure of the AST mirrors the structure of the .xml output so it should be possible to build the AST by parsing existing XML files.

The resulting CLG can be used for further maintenance of the checklists, or the AST can simply be used for visualisation using the PDF and DOT outputs.