Fork me on GitHub
#clara
<
2017-12-27
>
amarjeet10:12:15

When i inspect a session, the value of :fact->explanations key is always nil, despite facts being inserted into the session. My goal is to check what all facts are in the session. Help? CC: @mikerod

amarjeet11:12:16

The session->fact-graph too returns nil: {:forward-edges {}, :backward-edges {}}

mikerod14:12:25

@amarjeet I think I’d need more of an example to see what you mean

mikerod15:12:05

However, if you are just doing this for some sort of debugging, you could also add a query that matched any fact and use that to see what is in the session. This query could be a performance issue in a production usage though,.

amarjeet15:12:14

I was debugging basically, so with queries I can test things

amarjeet15:12:52

in the process of debugging, I tried inspect and fact-graph...thats when I came across nil values

amarjeet15:12:58

But, queries clearly shows that facts are there. So, now just wondering if :fact-explanation or fact-graph should be looked at or not?

mikerod15:12:13

@amarjeet your code snipet looks wrong. Perhaps just a typo? You have (insert-all facts base-session) when it should be (insert-all base-session facts) - base-session is first arg

mikerod15:12:10

Also, I only see 2 def in your example. One for base-session and one for mysession. I don’t see what you called to try inspecting and looking at the inspection results. That’d be useful too. Pending the above comment I had was just a typo

mikerod16:12:03

@amarjeet did you call fire-rules on the mysession?

amarjeet16:12:30

no actually

amarjeet16:12:59

I see thats the problem? Because, I just tried with fire-rules, and I see the facts

amarjeet16:12:03

But, without firing the rules, the insertion is happening

amarjeet16:12:03

with fire-rules, only matched facts are being returned under the fact->explanation

amarjeet16:12:31

I thought, with inspect, I could see all inserted facts, not just the matched ones

mikerod16:12:53

@amarjeet I think in general you shouldn’t assume much about the state of working memory prior to fire-rules

mikerod16:12:10

Take that as a general principle. Things are done sometimes “lazily” in some respects

mikerod16:12:36

That doesn’t answer the 2nd part of your question as to what is missing post-rule firing though

amarjeet16:12:38

hmm, understood the issue now regarding 'before fire-rule' part.

amarjeet16:12:59

I re-checked, post fire-rules, I can see only matched facts, not all inserted ones (in that session)

mikerod16:12:28

I’ll have to take a look at things a bit to have a better answer on that

amarjeet16:12:42

cool cool, thanks much

mikerod17:12:14

@amarjeet it seems the purpose of the key :fact->explanations is to explain derived facts within working memory

mikerod17:12:25

not facts explicitly given via an external insert or insert-all

amarjeet17:12:57

okay, that makes sense then

mikerod17:12:00

You can dig out that info in some sense

mikerod17:12:28

Take for example:

:fact->explanations
{#clara.test_rules.B{}
[{:rule {:ns-name clara.test-rules, :lhs [{:type clara.test_rules.A, :constraints []}], :rhs (do (insert! (->B))), :name "clara.test-rules/test-a"},
:explanation #clara.tools.inspect.Explanation{:matches ({:fact #clara.test_rules.A{}, :condition {:type clara.test_rules.A, :constraints []}}), :bindings {}}}]}

mikerod17:12:53

clara.test_rules.B is the derived fact

mikerod17:12:24

the value under it is a list of rules deriving it. There’d be more than one if multiple of these facts were = in working memory.

amarjeet17:12:41

yes, I did got that when I checked with fire-rules

amarjeet17:12:54

understood it now

mikerod17:12:46

(into []
      (comp cat
            (map :explanation)
            (mapcat :matches)
            (map :fact))
      (vals (:fact->explanations inspect-results)))
combined with (keys (:fact->explanations inspect-results)) sort of gets you there

mikerod17:12:14

Also, an important consideration is that Clara doesn’t hold references to any inserted facts that cannot contribute to any rule

mikerod17:12:26

So those effectively are not in working memory at all anymore

amarjeet17:12:57

hmm, yeah, got it

amarjeet17:12:14

makes sense now

mikerod17:12:18

(defrecord A [])

(defrule not-using-a
  [:not-a]
  =>
  (insert! {:not-a true}))

(-> (mk-session [not-using-a])
    (insert (->A))
    fire-rules)

mikerod17:12:29

you’d find no references to A fact instance in working memory at all

mikerod17:12:55

@alex-dixon has done some more interesting things with session inspection I believe. He may have thoughts on this though.

mikerod17:12:49

On the topic of analyzing all facts inserted or that sort of thing. Then again, for dev only, if you are using the typical type hierarchy you could just do

(defquery find-any-fact []
   [?f <- Object])

amarjeet17:12:12

yeah, this testing trick works, I tried testing with different types of queries.

alex-dixon17:12:03

Example of abusing clara.listeners 😊

alex-dixon17:12:42

It’s a tremendously well designed interface. This is just one implementation. We set up a core async pipeline to process insertions from outside the session (see in precept.core if interested). Each time there’s an insert we add and remove a listener and divide the listener ops into additions and removals

alex-dixon17:12:20

From there we apply the ops to an atom that represents “current state”

alex-dixon17:12:04

Part of motivation over a query is that queries become part of the rete network so having one that matches on everything wasn’t performant

alex-dixon18:12:35

@amarjeet Just making sure you saw this in case it might be helpful

amarjeet18:12:51

oh, just saw, gonna look at it

amarjeet18:12:02

thanks 🙂