anchor.diff:  
   Rules  "set a value", "eliminate a value from Cell" and "retract setting" depend on the presence of a `Setting` object.
   The first rule handles the assignment to the cell and the operations for removing the value from the "free" sets of the  cell's three groups.
  -Also, it decrements a counter that, when zero, returns control to the Java application that has called ``fireUntilHalt()``.
  +This group also decrements a counter that, when zero, returns control to the Java application that has called `fireUntilHalt()`.
   The purpose of rule "eliminate a value from Cell" is to reduce the candidate lists of all cells that are related to the newly assigned cell.
   Finally, when all eliminations have been made, rule "retract setting" retracts the triggering `Setting` fact.
   
  
positive.code: Row 8:    34       --- 9 ---     4 6 8   --- 7 ---  --- 1 ---   23456 8     3 56 8     3 56          6 8
  ----
  
  Now, let us load a Sudoku grid that is deliberately invalid.
  Click on "File", "Samples" and "!DELIBERATELY BROKEN!". Note that this grid starts with some issues, for example the value 5 appears twice in the first row.
  
  .Broken initial state
  image::Examples/SudokuExample/sudoku4.png[align="center"]
  
  A few simple rules perform a sanity check, right after loading a grid.
  In this case, the following messages are printed on standard output:
  
  
  ----
  
  cell [0,8]: 5 has a duplicate in row 0
  cell [0,0]: 5 has a duplicate in row 0
  cell [6,0]: 8 has a duplicate in col 0
  cell [4,0]: 8 has a duplicate in col 0
  Validation complete.
  ----
  
  Nevertheless, click on the "Solve" button to apply the solving rules to this invalid grid.
  This will not complete; some cells remain empty.
  
  .Broken "solved" state
  image::Examples/SudokuExample/sudoku5.png[align="center"]
  
negative.code: The Java source code can be found in the /src/main/java/org/drools/examples/sudoku directory, with the two DRL files defining the rules located in the /src/main/rules/org/drools/examples/sudoku directory.
  
  The package `org.drools.examples.sudoku.swing` contains a set of classes which implement a framework for Sudoku puzzles.
  Note that this package does not have any dependencies on the Drools libraries.
  `SudokuGridModel` defines an interface which can be implemented to store a Sudoku puzzle as a 9x9 grid of `Cell` objects.
  `SudokuGridView` is a Swing component which can visualize any implementation of `SudokuGridModel`.
  `SudokuGridEvent` and `SudokuGridListener` are used to communicate state changes between the model and the view: events are fired when a cell's value is resolved or changed.
  If you are familiar with the model-view-controller patterns in other Swing components such as `JTable` then this pattern should be familiar.
  `SudokuGridSamples` provides a number of partially filled Sudoku puzzles for demonstration purposes.
  
  The package `org.drools.examples.sudoku` contains a set of classes implementing the elementary `Cell` object and its various aggregations: the `CellFile` subtypes `CellRow` and `CellCol` as well as `CellSqr`, all of which are subtypes of `CellGroup`.
  It's interesting to note that `Cell` and `CellGroup` are subclasses of `SetOfNine`, which provides a property `free` with the type `Set<Integer>`.
  For a `Cell` it represents the individual candidate set; for a `CellGroup` the set is the union of all candidate sets of its cells, or, simply, the set of digits that still need to be allocated.
  
  With 81 `Cell` and 27 `CellGroup` objects and the linkage provided by the `Cell` properties `cellRow`, `cellCol` and `cellSqr` and the `CellGroup` property `cells`, a list of `Cell` objects, it is possible to write rules that detect the specific situations that permit the allocation of a value to a cell or the elimination of a value from some candidate set.
  
  An object of class `Setting` is used for triggering the operations that accompany the allocation of a value.
  Moreover, the presence of a `Setting` fact is used in all rules that should detect a new situation; this is to avoid reactions to inconsistent intermediary states.
  
  An object of class `Stepping` is used in a low priority rule to execute an emergency halt when a "Step" does not terminate regularly.
  