This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-19
Channels
- # aatree (33)
- # admin-announcements (70)
- # alda (6)
- # aleph (2)
- # announcements (6)
- # aws (7)
- # beginners (40)
- # bitcoin (1)
- # boot (138)
- # cider (24)
- # cljs-dev (9)
- # cljsjs (18)
- # cljsrn (35)
- # clojars (4)
- # clojure (211)
- # clojure-art (4)
- # clojure-austria (2)
- # clojure-hamburg (8)
- # clojure-russia (66)
- # clojure-sg (3)
- # clojured (1)
- # clojurescript (73)
- # cursive (9)
- # datomic (124)
- # dirac (8)
- # editors (3)
- # emacs (13)
- # euroclojure (10)
- # hoplon (207)
- # jobs (4)
- # ldnclj (27)
- # lein-figwheel (3)
- # leiningen (10)
- # mount (5)
- # music (1)
- # off-topic (9)
- # om (92)
- # onyx (36)
- # perun (30)
- # proton (47)
- # re-frame (11)
- # reagent (11)
- # ring-swagger (7)
- # yada (2)
great work @michaeldrogalis and @lucasbradstreet! this happens to be perfectly timed for us - we’re going multi-instance in the next couple weeks
@robert-stuttaford: it should definitely help ensure the perf impact of going multi-node is smaller :)
@lucasbradstreet, i can update my post too, but you might want to add a redirect http://www.onyxplatform.org/support.html -> http://www.onyxplatform.org/support
thanks. Looks like the cheat sheet path also changed: http://www.onyxplatform.org/docs/cheat-sheet/
fixing both
I’ll get a redirect going. I don’t want to lose all the links we’ve picked up
Thanks
how’s married life?
you fighting over who gets to hold the TV remote, yet? 😁
It's much the same, ha
But it's good. I keep forgetting to wear the ring though :p
Thanks everyone!
question about flow conditions that catch exceptions, do they only regulate flow when an exception is thrown? i.e if i have a workflow from a -> b, and I put a flow condition from a to b that catches exceptions, does that mean, when an exception isn't thrown, that segments still flow from a -> b ?
The docs could be a little clearer there. I believe if it doesn't short circuit because an exception was thrown it'll just use the default behaviour, which is to flow to all outgoing tasks
@greywolve: if you want to control the behaviour there you can add a later flow condition
and i'm assuming flow conditions only apply to their to and from ? if i have a -> b, and a -> c, and i only have one flow condition, which restricts a going to b with a certain predicate, i'm presuming a still flows to c?
i'll be happy to edit the docs for more clarity once i properly got my head around them
Yes, I believe that is the case
It's easier to compose conditions together for the same task as a result
@greywolve: you can see this in effect in https://github.com/onyx-platform/onyx/blob/0.8.x/test/onyx/peer/colors_flow_test.clj
I recommend having a look at some of the tests sometimes when you have some questions about the features. They’re usually pretty straight forward integration tests under test/onyx/peer
We definitely appreciate hearing when the docs are a bit confusing though
no worries
@lucasbradstreet: I modified the flow combine example to test the a -> b, a -> c case above, it seems that if you only have one flow condition, say a -> b, then for a -> c, a never flows to c.
just wondering if that's intended behaviour, and if we can rely on that staying the same?
in the file above i have a -> out, and a -> b, testing a single flow condition active for each. when both flow conditions are there you see the output for both tasks, when one only flow condition is there you only see output for one of the tasks, which would imply that if you do have a flow condition you need to make sure all your out going edges are covered by them, any out going edges you forget, won't be flowed to?
@greywolve: ah, you may be right about that
@greywolve: That is the intended behavior. You can think of it like a pattern matcher, where you can :flow/to
-> :all
if you want to catch all.
Sorry, I always forget how it works. But yeah, all the matching flow/to tasks are unioned unless you use short circuiting.