Clojurians Log v2

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

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

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

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,.

I was trying to inspect mysession.

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

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

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

@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

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

My bad on the mistake in mysession def. Modified the code snippet. Added the inspect fun call.

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

no actually

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

But, without firing the rules, the insertion is happening

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

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

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

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

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

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

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

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

cool cool, thanks much

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

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

okay, that makes sense then

You can dig out that info in some sense

yeah

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 {}}}]}

clara.test_rules.B is the derived fact

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.

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

understood it now

(into []
      (comp cat
            (map :explanation)
            (mapcat :matches)
            (map :fact))
      (vals (:fact->explanations inspect-results)))

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

So those effectively are not in working memory at all anymore

hmm, yeah, got it

makes sense now

(defrecord A [])

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

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

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

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

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])

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

https://github.com/CoNarrative/precept/blob/master/src/cljc/precept/listeners.cljc

Example of abusing clara.listeners 😊

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

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

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

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

oh, just saw, gonna look at it

thanks 🙂