=========================================================
NodeBrain 0.6.1 Change Summary
* Released October 11, 2004
* Theme: Cleaning up bits and pieces.
As a patch release, there is no one grand theme
here. However, there are small enhanecments and
some bug fixes that I found useful in my own
applications. For my own purposes, this release
has been more reliable than 0.6.0.
What's Next?
Starting to look forward to a 0.7.0 release. My
current plan is to focus on three things.
1) Systematic testing
2) Sample application(s)
3) Skill module enhancements
Better testing is needed to achieve the level of
reliability needed before going to a 1.0 version.
It works fine now for my own applications, but I
use it the way it works. It needs to be more
graceful in responding to the random command syntax
a new user might try. And at least one complete
sample application is needed to get people started.
* Documentation:
o At the time of this release, the "NodeBrain User's
Guide" has not been updated to reflect changes in
this release. When updated, the document will be
posted on the webset, www.nodebrain.org. A document
release file will be posted on the SourceForge
project page. Please use the online 0.6.0 document
for now.
* Incompatibilities:
o Nested symbolic substitution for generating terms,
${{a}{b}}, is no longer supported. This feature
had little merit and conflicted with our desire to
support symbolic substitution using cell expressions.
o Expert skill module compute() methods are now
expected to return a grabbed cell. It is unlikely
anyone out there has dabbled with writing skill
modules yet.
o Rule actions are no longer performed when a rule
condition changes after the action is scheduled.
When a change causes multiple rules to fire, the
action of one rule may change the condition of
another. If this happens, NodeBrain now considers
it unsafe to perform a scheduled action whose
condition has changed. This is because actions
often use terms within the condition as parameters.
An "action priority" option has been included to
help avoid this situation.
* Bugs Fixed:
o Multiple bugs related to releasing of objects.
o Corrected the order of symbolic substitution and
reduction. This does not impact commands injected
by rules, but does resolve a problem for user
entered commands starting with a reduction ("$ ").
o Eliminated unnecessary pass through symbolic
substitution logic for rule action commands that
don't need it. Check is made at rule definition time
now instead of every time the command is parsed.
o Symbolic reduction "$ $${..}" to "${..}" is done
for rule action commands at rule definition time
now. Stopped doing every time the command is parsed.
o Rules are no longer allowed to fire more than once
in a given command cycle. This was documented but
not implemented prior to this release.
o Fixed bugs related to the use of rule terms in cell
expressions. A rule term may be used as a name for
the rule condition cell. Notice r1 in this example.
define r1 on(a=1 and b=2):-echo hi
define r2 on(r1 or c=3):-echo ho
o Fixed bugs in the "solve" command. The solve
command may now be used multiple times in the
same context. State changes may cause "solve"
to resolve previously unresolved terms. You may
also assert terms to be unknown, causing solve
to resolve them again if necessary.
o The "show" command reveals context a little better.
A context prefix is included when rules are displayed,
unless the context matches the current context. When
a context terms is shown, it is reduced to ".". A
period may also be used as an abbreviation in the show
command. > show .
o The new form of cache assertion introduced in 0.6.0
was not properly reacting when a threshold was hit.
The has been fixed, but the fix introduces an
unfortunate inconsistency in the assert command. As
"fixed" the following example will cause rFirst to
fire twice, once for 1, and once for 2.
define johnny expert cache(~(5m):x(1));
johnny. define rFirst if(x._hitState);
define rAssert on(a=1) johnny(1),johnny(2);
For the moment, I've designed myself into a corner
here. Previously we have said that all assertions
in a given command are applied "concurrently" and
then rules respond to the collective assertion.
However, when a cache hits a threshold it forces
an immediate response. This means the assertions
on a single command are no longer "always" applied
"concurrently". Here is an example of a situation
that violates our promise of "concurrent" assignment.
define c expert cache(x(1));
define r1 on(a=1);
define r2 on(a=2);
define r3 on(a=3);
assert a=1,c(1),a=2,c(2),a=3,c(3);
In this case, r1, r2, and r3 all respond because
c(1), c(2), and c(3) all hit a threshold and force
an immediate reaction. Had the assertion been as
follows, only r3 whould fire.
assert a=1,a=2,a=3;
In this example, it almost seems like a good thing.
But, when we change the rules a bit, the problem
is exposed. Rules r1 and r2 both fire instead of
just r2.
define c expert cache(x(1));
define r1 on(a=1 and b<>2);
define r2 on(a=1 and b=2);
assert a=0,b=0;
assert a=1,c(1),b=2;
For now we need to be aware of this and avoid coding
rules that are sensitive to this problem. In practice
it will not be difficult to avoid it, but I'm not
comfortable with this as a final solution.
* New Features:
o Symbolic substitution supports cell expressions
define r1 on(a=1) x=${trouble{y)*10+3}
o Show command supports cell expressions enclosed
in parentheses as alternative to a term.
show () [
