Clojurians Log v2

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

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

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?

@sashton easiest is a query on Object.

It doesn’t necessary perform well though

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

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

> listeners api I was just exploring that path

If you watch the alpha node activations.

And retractions.

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

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

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

And remember to fire rules always before running query

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

Thanks!

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.

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