This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-14
Channels
- # beginners (33)
- # cider (17)
- # clara (13)
- # cljs-dev (7)
- # clojars (1)
- # clojure (47)
- # clojure-brasil (1)
- # clojure-dev (4)
- # clojure-italy (3)
- # clojure-russia (4)
- # clojure-uk (1)
- # clojurescript (4)
- # core-async (4)
- # core-logic (6)
- # cursive (7)
- # datomic (1)
- # emacs (35)
- # fulcro (56)
- # hoplon (7)
- # jobs-discuss (89)
- # lumo (6)
- # numerical-computing (1)
- # onyx (86)
- # parinfer (3)
- # reagent (2)
- # rum (2)
- # specter (5)
- # sql (13)
- # unrepl (2)
@raymcdermott it seems like everything has already been eval’d by the time you start evaluating things? It’s not that great for repl play since you need to eval things in turn.
@lucasbradstreet er, yeah I just took the example and loaded it into the REPL … my point is only that it seems like ZK is started twice and I don’t get that
Ah, this is before you even eval anything?
(manually I mean)
ah … it might be that cursive evals it when starting the REPL and than I load it … so it’s done twice
Right, that’s what I was thinking.
They’d be better off in tests I think.
But this way you can go through line by line and see what happens.
it might just be a timing thing, because it can’t tell whether the media driver was dead or had just been shut down recently.
And not if not?
this is the session window example, right?
k, lemme try
it’s probably just not shutting things down afterwards, since the shutdowns are in the main entry point
but there are none in the repl eval sections
Cool, it’s just stale state then. If you can think of a better way to keep the repl bits while also cleaning up the state, I’m all ears
This is certainly non-ideal
Maybe I could add a (comment) wrapping things and some helpers to start up, and do the final shutdown. It’s really easy to get into a state where you have to reload the repl
That’s why I prefer tests for general dev
thanks @lucasbradstreet also for Onyx 🙂
Of course 🙂
you can do it with trigger/sync, or you can use trigger/emit to emit the window contents to a downstream task (which you could write a simple mongo output plugin for)
output plugins are pretty easy to write
I’ve been meaning to fix up the onyx-plugin template.
Ha, too much to do 😛
It is. Everything below this line is an SQL output plugin https://github.com/onyx-platform/onyx-sql/blob/0.12.x/src/onyx/plugin/sql.clj#L187
yea, shouldn’t be too hard.
sure, any questions let me know.
Well, you can:
1. transform the state in your trigger/emit function before you send it downstream
2. alternatively or additionally batch your outputs via the output plugin (this is mostly for perf optimisation, as you have no guarantees about which segments will batch together)
I’m guessing you want 1
you just need to use the right aggregation for your window
You could either collect via something like conj and transform in trigger/emit, or you can build your document incrementally with your own aggregation
just beware that with sessions you will need to merge sessions together too
I’m reading https://github.com/onyx-platform/onyx/blob/0.12.x/test/onyx/windowing/window_session_merge_test.clj
The conj aggregation will do it for you. It’s just a function that the aggregation has to define
Not unless you want to merge it as you go
With some different logic
Yeah, when two sessions combine, it’ll merge the two states
ok, so you can either conj or have some merge function that is executed when one or more segments are added
in my case I think just using conj and then doing the transform at the session boundary is more straightforward
Agree, since it’s less work