You can now set the FPS goal with `--fps=10` (or whatever) on the command line;
and the current (measured) FPS is displayed in the lower right corner.
During the run, you can bump the FPS goal up and down with `F` and `f` respectively!
The Slipnet itself turns out to be boring to look at.
More interest is found in the Workspace structures, such as bonds,
groups, and correspondences.
The old behavior of `curses_main.py` is still accessible via
python curses_main.py abc abd xyz --focus-on-slipnet
With the new CursesReporter, I'm able to observe groups getting built
and broken; and I observed that sometimes a Bond (between a Letter and
a Group) would apparently survive the Group's breaking.
Reorder the operations in `breakGroup` so that the higher-level ones
("detach this Group from its external bonds") come strictly before
the lower-level ones ("ungroup this Group's members and remove this
Group from the Workspace, thus destroying it").
However, the "buggy" behavior I observed turned out to be due to a bug
in my display code and not due to anything wrong with `breakGroup`.
I suspect this patch is actually purely cosmetic.
This code is already present in `getPossibleDescriptions`... which is
also a terrible function from the philosophical point of view, because
it secretly encodes knowledge about every predicate known to the system.
Before this change, Copycat was unable to formulate more than the empty rule for
abc : abd :: f : f
abc : dbc :: f : f
abc : aac :: f : f
After this change, Copycat strongly prefers
abc : abd :: f : g ("Replace the rightmost letter with its successor")
abc : dbc :: f : d ("Replace the leftmost letter with d")
abc : aac :: f : e ("Replace the middle letter with its predecessor")
I think the change to `workspace.breakRule()` is harmless. In theory, it
should make Copycat less hesitant to come up with rules that conflict with
the already-broken rule.
This isn't terribly useful to the human observer, actually.
It seems like the most useful factors that ought to be displayed
are really the groups/bonds in the workspace and the current
"rule" (if any). Particularly, with the current design of Copycat,
it seems like the "rule" should be part of the displayed output
just the same as the modified target string.
And clean up some logic in `rule.py`. This is the place where the
"brains" of Copycat really live, it seems; Copycat can only succeed
at solving a puzzle if it can take the `Rule` it deduced and apply
it to the target string to produce a new string. And it can only
do that if the necessary *actions* have been programmed into `rule.py`.
Right now, it explicitly can't deal with "rules" that involve more
than one local change; that involve reversal; or more importantly,
IIUC, rules that involve "ascending runs", because the idea of a
successor-group is(?) known to the Slipnet but not to `rule.py`;
the latter deals only in "strings", not in "workspace objects".
This seems like a major flaw in the system... but maybe I'm missing
something.
