Clojurians Log v2
clara
@alex-dixon I made a blog post on the topic of “fact updates” in Clara @ http://www.metasimple.org/2017/12/23/clara-updating-facts.html Perhaps something like it could be added to Clara docs later.
It is basically just reiterating things I’ve discussed before in this Slack channel on the topic. We discussed this a little a day or so ago.
Awesome. Thanks. Will read and share
cool. feel free to let me know if you see problems with it or anything too
Very well written. Really impressed at how quickly you were able to produce that… 🙂
Thanks!
I haven’t figured out a good solution for “default values” of facts. E.g. I have some rules I’m working on now for precept-devtools where I’m trying to allow the user to view history for a rule. When the user first selects “show history”, I want to provide a default (e.g. the first rule firing). After that I want the user to be able to switch through the selected history. I’d like to have one “selected history” fact. If it doesn’t exist because the user hasn’t set it, it should be derived from other facts. If the user sets it though, then “selected history” should be whatever the user says.
That sounds like you could encode that as 2 separate rules that both insert the selected history fact
To get a default I’m writing something like “[:not {SelectedHistory} => (insert-unconditional! [SelectedHistory 0])”
One rule would only fire if some user provided fact is not present.
Yeah. Use a different fact type as the “trigger”
And no need for unconditional
[:not [SelectHistoryEvent]]
=>
(insert! (->SelectedHistory 0))
The other rule would be the same, but would use the event to build the SelectedHistory with the provided value
And if you want the ability to retract/toggle do some sort of external retract like I described in blog perhaps.
Ok. I’ll try that. Thanks
Time to write a “defaulting facts” blog! 😛
Sorry….don’t mean to create work for you. I’m still figuring out patterns. I think UI might be different from the way Clara is normally used? Maybe not but there are facts coming from the outside virtually all the time and I’ve often wondered if that’s significantly different from the use case at Cerner
Oh no not a problem. I want to do things like write more blogs anyways. Hah. But yeah I think the UI usage of Clara pushes new things up to the forefront. But that is a good thing
I’m doing quite a bit of UI things recently and I think some stuff you’ve been doing seems really interesting. I really want to look at it a bit more soon.
Thanks! That means a lot coming from you 🙂. If it’d make things easier or faster maybe we could screenshare or just chat and go over example UI rules. Your feedback on some of the patterns we’ve used in Precept so far would be invaluable
Yeah, that could work. I’ll try to find some time available soon for something like that. I want to do a little bit of a read through of precept to have some insight too. I like to read open-source libs doing interesting things anyways.
Brain bubble: clara and onyx might be a great match for distributed processing.
2🎉Very well written. Really impressed at how quickly you were able to produce that… 🙂
Thanks!
I haven’t figured out a good solution for “default values” of facts. E.g. I have some rules I’m working on now for precept-devtools where I’m trying to allow the user to view history for a rule. When the user first selects “show history”, I want to provide a default (e.g. the first rule firing). After that I want the user to be able to switch through the selected history. I’d like to have one “selected history” fact. If it doesn’t exist because the user hasn’t set it, it should be derived from other facts. If the user sets it though, then “selected history” should be whatever the user says.
That sounds like you could encode that as 2 separate rules that both insert the selected history fact
To get a default I’m writing something like “[:not {SelectedHistory} => (insert-unconditional! [SelectedHistory 0])”
One rule would only fire if some user provided fact is not present.
Yeah. Use a different fact type as the “trigger”
And no need for unconditional
[:not [SelectHistoryEvent]]
=>
(insert! (->SelectedHistory 0))
The other rule would be the same, but would use the event to build the SelectedHistory with the provided value
And if you want the ability to retract/toggle do some sort of external retract like I described in blog perhaps.
Ok. I’ll try that. Thanks
Time to write a “defaulting facts” blog! 😛
Sorry….don’t mean to create work for you. I’m still figuring out patterns. I think UI might be different from the way Clara is normally used? Maybe not but there are facts coming from the outside virtually all the time and I’ve often wondered if that’s significantly different from the use case at Cerner
Oh no not a problem. I want to do things like write more blogs anyways. Hah. But yeah I think the UI usage of Clara pushes new things up to the forefront. But that is a good thing
I’m doing quite a bit of UI things recently and I think some stuff you’ve been doing seems really interesting. I really want to look at it a bit more soon.
After reading this (https://clojurians-log.clojureverse.org/clara/2015-12-11.html) and @mikerod's article (http://www.metasimple.org/2017/02/28/clarifying-rules-engines.html), I think there may be something there. It's all sky pie at this point, but it certainly seems like the network should be translatable to an onyx job. Onyx has fault tolerance for stateful tasks, and has taken a pretty good beating from jepsen.