[alicebot-archcomm] 4.1.3 Release

[Noel Bush]

Rich wrote:
> Glad to see that some form of targeting made the final cut.

Yes, and I think that building on top of this will be a piece of cake.
I guess that the Targeting Tool should be separated from Program D at
some point as a separate build, since these two things will probably
move at different paces.

I or someone else should re-introduce the category and input ranking
panels soon.  There are also some basic configuration possibilities that
should be made easier with the targeting scheme.

Running the bot separately from the targeting tool means that the issue
of activations has to be handled differently.  Instead of being updated
directly from Graphmaster.checkpoint(), these have to be counted by the
targeting tool when it receives them.  So "TargetMaster" (which gets the
targets created by Graphmaster) just writes out each target anew, even
if the pattern is the same, but when loading it looks for targets with
the same pattern:that:topic combination and merges them.  A Target
object has only one each of pattern, that, topic, but it can have an
unlimited number of input text, input that and input topic.

One thing I immediately noticed that I forgot to do with the
TargetWriter (which writes the targets) is include the template content
of the selected category.  (This is included in the Target object, just
not written at present).  I think this will be useful in the targeting
tool, since someone may want to judge whether or not to create a new
category by looking at whether the response given by the bot was
probably adequate.

I also extended the extension mechanism to create a new that pattern if
the matched pattern is already "complete", and a new topic pattern if
the that pattern is already complete.  This results in many more targets
popping up, but it seems to me necessary to support building more
"contextual" targets.

> > * ...cryptic variables renamed
> 
> You mean my "intuitive" algebraic variable names like a, b, y, and z?

Well, I should have also said "cryptic method names" :-), since some
things had grown up in a way that was a little confusing.  For instance,
for anyone to understand the difference between doRespond() and
doResponse() in Classifier took quite a while, so I tried to clean up
that structure a bit.  I renamed the methods and arranged them in a more
"cascading" fashion.

I am worried about the Multiplexor scheme that I implemented.  Since an
interface cannot specify static methods, but static methods are
desirable (to discourage the use of multiple Multiplexors?), I made
static "access methods" that call underlying non-static methods....but
the whole thing looks a little overdone to me.  If someone could take a
look at Multiplexor, ActiveMultiplexor, AbstractClassifier, and (one of)
Classifier, DBMultiplexor, FlatFileMultiplexor and give comments about
whether the scheme makes any sense at all, it would be great.