This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-04
Channels
- # admin-announcements (3)
- # alda (4)
- # beginners (30)
- # boot (116)
- # cbus (5)
- # cider (20)
- # clara (10)
- # cljs-dev (12)
- # cljsjs (41)
- # cljsrn (9)
- # clojars (6)
- # clojure (131)
- # clojure-bangladesh (5)
- # clojure-colombia (2)
- # clojure-dev (9)
- # clojure-ireland (4)
- # clojure-japan (3)
- # clojure-norway (10)
- # clojure-poland (6)
- # clojure-russia (59)
- # clojure-sg (1)
- # clojurebridge (2)
- # clojurescript (76)
- # clojurewerkz (4)
- # css (6)
- # cursive (21)
- # data-science (24)
- # datomic (27)
- # emacs (9)
- # hoplon (68)
- # jobs (2)
- # jobs-rus (1)
- # ldnclj (10)
- # lein-figwheel (9)
- # leiningen (21)
- # off-topic (5)
- # om (232)
- # onyx (63)
- # parinfer (2)
- # proton (25)
- # re-frame (12)
- # reagent (39)
- # untangled (6)
- # yada (122)
I’m running into some behavior that I don’t understand. I have a fact type of which I only ever expect 1 or 0 instances. If the session has 0 instances, I’d like to make a rule which inserts an instance with some reasonable default values. Right now I have this rule:
(defrule default-event-date
"If there is no EventDate, create one far in the future."
[:not [EventDate]]
=>
(clara.rules/insert!
(r/map->EventDate {:date (time.coerce/to-date-time "30000")})))
This correctly does not fire if I start the session with an EventDate fact. If I don’t, however, run-rules
never returns. It seems to just keep firing. I would expect it to fire once.Ah, just found the mailing list thread about this. I guess that the fact gets retracted when the LHS stops being true, which causes it to get re-inserted, which causes the LHS to stop being true, which causes it to get retracted, etc. ad infinitum
The suggestion is to use insert-unconditional!
, but that seems to never fire, even when there are no facts
@enn Hmm, insert-unconditional! should fire in example above if no EventDate facts are in the working memory when fire-rules is called. It might be worth restarting the REPL in case fact types got reloaded (and rules are looking at a different type). If things are still failing and can be narrowed down to a reproducible test I can take a look.
@ryanbrush I was mistaken—it does fire, it just doesn’t show up in explain-activations
. Is that expected?
@enn So explain-activations uses the truth maintenance facility to figure out what is supporting the fact, which wouldn't be used in an unconditional insert. I think one could argue the fact that unconditional inserts aren't seen here is a bug, but there are tradeoffs there. Another use case for unconditional insert is for performance-critical edge cases where users don't want to pay the accounting cost of tracking truth and activation explanation...which we couldn't offer if we tracked truth maintenance/explain-activations for unconditional inserts.
@enn In short, I'd be open to adding unconditional activations to explain-activations, but I'd want to consider the tradeoffs and make sure our performance-critical use cases (some inserting more then 100,000 facts) have a path forward as well.
@enn As for the original problem of an infinite looping rule, this comes up enough that I think we need a better way to expose and explain it to the user. I've seen other engines limit the number of recursive activations to a few thousand and throw an exception with context to explain where the failure is coming from. Tempted to add that to Clara as well.
@ryanbrush: thanks for the explanation. That makes sense. I was just using explain-activations as a debugging tool, so now that I know it has that limitation, it’s not a problem that it’s not showing up.