Thanks to kosiakk for the suggestion (via pull request github nwf/dyna#72).
This commit does not us to this theme, merely makes it available. I'll
leave the actual flip to someone with a sense of aesthetics. :)
Notably, build compiler without tests if we're not asked for tests. It's
not quite perfect, since if we are asked for both a compiler and tests we
`cabal configure` again, but so it goes. Additionally, since we
characterize sphinx as an optional dependency, conditionalize building docs.
Juneki Hong [Fri, 13 Sep 2013 22:17:36 +0000 (18:17 -0400)]
updated and cleaned up the boxes.dyna example. Unfortunately, it still does not run any faster, and the gravity updates still kill the performance of the program. I have it commented out by default so that unsuspecting people can still try running the example without dying.
Juneki Hong [Thu, 5 Sep 2013 01:34:08 +0000 (21:34 -0400)]
Made a boxes.dyna example file. It make some boxes and pushes them out of the way if they collide. The command to run it with the post-processor is listed at the top of the file
This tries to focus the search on plans that are nearer to being done,
hopefully reducing the time-to-first-answer dramatically when a rule has a
lot of subgoals.
Juneki Hong [Tue, 20 Aug 2013 21:09:50 +0000 (17:09 -0400)]
Think I got bounding box information from text that has been plotted using Matplotlib. This can help us close a feedback loop, allowing dyna to readjust where the text has been rendered on the screen afterwards.
Factor out all the automata logic from Analysis.Mode.Execution.NamedInst to
its own library (Dyna.Analysis.Automata) and port everything over. I won't
claim it's perfect, but I think it's a good start.
Analysis.Automata.Class is probably the right place to start reading.
Jason Eisner [Mon, 29 Jul 2013 01:53:59 +0000 (21:53 -0400)]
Edited conf.py in Sphinx documentation:
call it Dyna rather than Dyna2
changed primary_domain to dy:
added some commented-out stuff that may be useful in future
Tim Vieira [Sun, 28 Jul 2013 18:33:37 +0000 (14:33 -0400)]
Fixed Issue #66 - "stale backchaining memos when new rules are added"
GBC computation issues proper replacement updates in the case were there was an
old value (i.e. item was non-null).
When rules are recompiled their index stays the same.
Rules which fail to compile are reported as errors, much like rules which fail
to initialize. Rule recompilation is now one rule at a time rather than all in
one go.
Tim Vieira [Sun, 21 Jul 2013 22:36:05 +0000 (18:36 -0400)]
recompile rules on late backchain declaration (Issue #31); requires running
compiler to fixed point; maintaining a set of failed rules.
small tweak (hacky) to make compiler error messages friendlier -- show rule
source instead of `<repl>` (which was the mask for a big sha1+linenumbers).
Tim Vieira [Fri, 19 Jul 2013 18:37:32 +0000 (14:37 -0400)]
Big improvments to memoized BC rule retraction. We now correctly update
transitive dependents (before we didn't refresh the memos, so we were getting
incorrect behavior).
Catch ^C again..
Minor tweak to make fewer replacement updates to $key.
Tim Vieira [Wed, 17 Jul 2013 21:18:29 +0000 (17:18 -0400)]
refactored code, resolved asymmetries between FC and BC (and within each) --
code now has fewer special cases and should have fixed a bunch of bugs we didn't
even know we had :-X
don't show BC items in changes.
(BC retraction has improved, but it's still not 100% correct thanks to stale
memos)
Tim Vieira [Tue, 16 Jul 2013 23:31:01 +0000 (19:31 -0400)]
maintain a coarse dependency graph of head->evals and a map functor->rules (all
rules [not just BC rules] know their head's functor -- i.e. an overestimate of
what they "create"). These changes are nonfunction, but will facilitate
maintenance, retraction and all that.