Fork me on GitHub
#clara
<
2019-11-05
>
wparker08:11:40

Is this the indentation metadata you’re referring to @dominicm? https://docs.cider.mx/cider/indent_spec.html I’ve generally been satisfied with the default indentation in Cider when writing rules, are there examples of cases where the indentation is strange? My initial instinct if this sort of thing is desired would be to look for/create an extension mechanism for it so various development environments could be supported without everything needing to be in the main codebase (this is orthogonal to whether it would be in the main repo IMO and this could be separately considered).

dominicm08:11:07

Cursive looked at implementing the spec, I'm not sure if it happened though. It hasn't seen much adoption in other editors.

sashton19:11:43

I’m trying out Clara right now. Is there a way to get all the current facts from a session? I’ve tried various inspection functions, and come up short. - inspect/explain-activations - fact-graph/session->fact-graph - inspect/inspect I can get most facts from the above functions. What I am missing is facts inserted directly into the session, which haven’t themselves fired any rules. This would be just for debugging the rules, not for production queries. I don’t want to write a query which includes all Fact types, I’m looking for a simple way to enumerate all current facts in the system. Any ideas?

mikerod20:11:37

@sashton easiest is a query on Object.

mikerod20:11:43

It doesn’t necessary perform well though

mikerod20:11:57

Beyond that, it’s been done with hooking into the listeners Api

mikerod20:11:09

I don’t think anything out of the box for it. I may be forgetting

sashton20:11:26

> listeners api I was just exploring that path

mikerod20:11:44

If you watch the alpha node activations.

mikerod20:11:48

And retractions.

sashton20:11:13

I’ll try out the Object query, thanks for the pointer. This is only for debugging, so I’m not worried about performance

mikerod20:11:27

But there are some complexities involved depending how precise you need it

mikerod20:11:03

Object query is straightforward. It’s slow because it always is activated by all working memory changes

mikerod20:11:11

And remember to fire rules always before running query

mikerod20:11:22

They (can) do some batching/lazy stuff they may delay until fire rules.

wparker22:11:16

On the subject of the query performance, something that may be counterintuitive is that the cost comes from the presence of the query in the rules session, not the query call itself. In essence when fire-rules is called the query results are computed. Agreed that a query on Object is the simplest way to get all facts in the session if the perf hit doesn't matter e.g. in testing.

wparker22:11:04

Assuming we're talking about JVM clojure, not sure offhand what the cljs equivalent would be.