This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-24
Channels
- # announcements (22)
- # babashka (33)
- # babashka-sci-dev (161)
- # beginners (25)
- # calva (57)
- # cider (6)
- # clara (6)
- # clerk (14)
- # clj-kondo (24)
- # clojars (10)
- # clojure (65)
- # clojure-austin (1)
- # clojure-conj (2)
- # clojure-europe (23)
- # clojure-miami (3)
- # clojure-nl (3)
- # clojure-norway (3)
- # clojure-uk (3)
- # clojurescript (28)
- # cursive (24)
- # datomic (136)
- # emacs (38)
- # graalvm (29)
- # graphql (3)
- # introduce-yourself (8)
- # jackdaw (4)
- # jobs-discuss (9)
- # malli (5)
- # nbb (36)
- # off-topic (11)
- # pathom (58)
- # polylith (2)
- # practicalli (1)
- # re-frame (5)
- # reagent (11)
- # releases (1)
- # remote-jobs (8)
- # sci (15)
- # shadow-cljs (31)
- # slack-help (2)
- # spacemacs (11)
- # sql (7)
- # tools-build (9)
Is there a programmatic way of determining why a rule didn't fire?
in theory, yes. Though it'd likely require knowledge of the rules network structure and a custom listener: https://github.com/cerner/clara-rules/blob/e86dcd4f0224d966c1bd82043e79cf59c96136bf/src/main/clojure/clara/rules/listener.cljc#L5-L27 you have to ascertain the ancestors of a given ProductionNode, from the rulebase retrieved via a components call on the session: https://github.com/cerner/clara-rules/blob/e86dcd4f0224d966c1bd82043e79cf59c96136bf/src/main/clojure/clara/rules/engine.cljc#L2029-L2034 you'd then have to watch for events on the listener for the nodes in question, and the specific elements/token/facts "passing through the nodes". The last node in the subset of nodes for the production, which saw the item in question, could be assumed to be the the reason that it didn't propagate to the ProductionNode(RHS). I use "in theory" because i've never tried doing it... it seems possible given knowledge of the internals, but whether or not its practical is another question...
Not exactly a full answer to that problem, but you might the :condition-matches from session inspection helpful: https://www.clara-rules.org/apidocs/0.21.1/clojure/clara.tools.inspect.html#var-inspect That won’t be able to tell you about whether joins match, but might help some for tests against a single fact only (and that Clara recognizes as such, see http://www.clara-rules.org/docs/hash_joins/ for some discussion of that distinction - that page is in the context of performance but the info applies here. Unfortunately I don’t think that aspect of session inspection is quite as polished an experience as the “what rule inserted this fact” and “what facts did this rule insert” aspects but could be still be useful. If you have a particular set of facts that you expect to trigger a rule and don’t, you could try creating a rules session with just that rule and then removing conditions etc. until it does match - keep in mind that while some examples show bringing in an entire namespace of rules you don’t have to do this. Example usage: https://github.com/cerner/clara-examples/blob/343c54e8c2e7522a168b756bbe1e722937a85c09/src/main/clojure/clara/examples/fact_type_options.clj#L20
Yeah my use case is around debugging after the session is settled, specifically for domain related reasons We expected a rule to fire and we'd like to know why it didn't
@UCJCPTW8J I had same issue, and the inspect api is very helpful. Combine it with portal (djblue) to step through the rules and it makes it much easier to what is going on. see this thread from a couple of weeks ago and the similarly useful advice from @U0KRSVDHR https://clojurians.slack.com/archives/C08TC9JCS/p1673960569948969