rbrush/clara-tools

Experimental tools for working with Clara

clara-tools's Issues

When using accumulators, show-session not working

Any pointers? I'm down to fix this, but am not quite sure where to begin.

Also, FWIW -- I created a #clara slack channel at http://clojurians.net/. Would be great to have you in there, if that's the sort of thing you're interested in.

Cheers,
Devin

Conj talk

Hello,

The demo you showed at Clojure/conj was interesting, being able to inspect rules and sessions. Will any of that work make it into clara-tools?

Thanks,
Devin

clara-tools not working with 0.8.9

Hi Ryan,

I know this repo is considered experimental, but I think it'd be a shame to let it succumb to bit rot.

It looks like show-logic-graph works, but show-session does not:

IllegalArgumentException No implementation of method: :components of protocol: #'clara.rules.engine/ISession found for class: clojure.lang.PersistentVector  clojure.core/-cache-protocol-fn (core_deftype.clj:554)

What would it take to get this working again with 0.8.9? I've spent a little bit of time looking through source, trying to figure out what broke, but I must admit I'm having some trouble given the delta in versions.

Connect only to localhost by default

The server that clara-tools starts up appears to be configured to be accessible from outside the machine it runs on.
I validated this by starting it up on a personal machine and hitting the URL with my IP address substituted for localhost on another device.

Based on the API elsewhere here it looks to me like this is intended to be used locally
(for example https://github.com/rbrush/clara-tools/blob/clara-tools-0.1.1/src/main/clojure/clara/tools/ui.clj#L21 ).
It seems to me that the default should be to not accept outside connections and to require that users specifically opt in if they want other behavior.

I have created a pull request that changes the default to not accept external connections and adds a new arity to start-server! that accepts
Jetty options. You can find the docs for the :host option I used at https://ring-clojure.github.io/ring/ring.adapter.jetty.html

I'd be happy to add test(s) for this; I don't know what your thinking here would be on the value of the test vs the bloat.
I can see an argument that testing here would just be re-testing Ring. Some options I see are:

1. Starting the server and hitting the clara-tools URL by both localhost and the IP address and validating that the latter fails.
   This is dependent on the network configuration of the machine running the build and any sandboxing (for example on a CI server) seems like it could be problematic.
2. Validate that the host field is set in the underlying Jetty classes. I believe http://download.eclipse.org/jetty/9.3.6.v20151106/apidocs/org/eclipse/jetty/server/AbstractNetworkConnector.html#getHost-- is the field such a test would look at. This is basically re-testing Ring, but I can see some value in making sure that the option was passed correctly although it wouldn't be a particularly strong test.
3. Mock ring.adapter.jetty/run-jetty and validate the arguments it receives.

Current status of 0.2 branch

It isn't an immediate concern, since I don't plan to work on it immediately, but I was wondering if you could give a brief rundown of the current state of the 0.2 branch, what you want to add before a 0.2 release, etc. I have other priorities right now (such as performance of clara-rules itself and some internal initiatives), but longer term explainability of rules is something that's been weighing on my mind, and it would be nice to know what the status of this project is. No rush.

Should this be marked as unmaintained

As discussed at oracle-samples/clara-rules#318 the clara-tools project has not been maintained (note that clara-rules is maintained, it is clara-tools that we are discussing here).

@rbrush , you suggested there that clara-tools should have some indication of this fact. I've logged this issue to track on adding such a notice so that we can close out oracle-samples/clara-rules#318.