Introduce invalidated flag to program producer to control whether to
only process invalidated nodes in incremental mode.
Update validated flag in RulesPlanHandler to reflect the finalized
state, after the plan has been built.
Refactor ProgramProducer/Factory to avoid enumerating the source
root in case no changes have been detected (in incremental mode).
Avoid relaunching program in case the producer did nothing.
BlockingExecutor must not block other helpers from being executed
if a error is detected by one of them.
Since helpers are built in unpredictable order, there can be situations
when an (unrelated) error causes intermittent failures.
The idea to use "tracking" cache to save on typechecking operations is obsolete.
There is conflict of responsibilities with UpdatesRecorder,
which is to be solely relied upon for all things related to tracking changes.
StyledTreeCellRenderer component received wrong bounding box
because of top border's inset to be set to 1 (see DefaultTreeUI.paint()).
This border is the default set by LookAndFeel.installBorder()
in case the border on tree component is set to null,
which is explicitly set to null in TreeTableTree's constructor (go figure).
Some language imports necessary for correct typechecking are obscure.
Example may be a closure type, which requires the type of the operand
(receiver) of the method it serves a parameter to. That, in turn, may
require some type defined in another root and perhaps some other model.
Enable rule index to be updated during rules application.
Make RuleProcessingSession depend on AspectClique.
Enable updating of rule/macro/query indices.
Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
It's important that program that uses occurrences from cache
shouldn't include rules that could produce their duplicates.
So implementation of occurence cache includes 2 parts:
on reactor level & in ProrgramFactory.
When RuleBuilders are produced, cache is queried whether
there're already occurrences associated with the rule template
in question. If so -- then those RuleBuilders are not included
into the program (as well as all RuleBuilders required by it).
Get information on invalidated nodes from EvaluateStep & incr processing
instead of UpdatesRecorder, which has only partial info and can't handle
all cases.
TemplateApplicationSession allows to invoke require with the
input node as the first parameter, which is then forwarded as
a "requirement" (TODO: rename to dependency).
The use of ProgramProducer and other stuff have new requirements.
The program is now produced incrementally, with UpdatesRecorder
playing a major role in keeping track of changes.
Move invalidation logic inside UpdatesRecorder from elsewhere.
Drop type parameters.
Avoid recording dependencies for null input.
ProgramFactory: always process input, not only the first time
Fedor Isakov