is there a core function that concatenates keywords? (??? :foo :bar) => :foobar

I have a higher-order function where caching is abstracted into two arguments, fetch and store!. I could check if fetch is not nil and let that represent that there is no value cached, but nil is a valid value and I don't want to recompute nil if it indeed is cached. (The problem is kind of like to how you'd use find instead of get if you need to distinguish between nil value and missing key.) I could require that fetch wraps the return value in a vector or a map, or even any type of reference (e.g. atom). Or I could pass a special value as an extra argument to fetch which represents that the value is missing, and check for that. Which would be your preferred way?

is there a handy way to list all scheduled jobs in quartzite?

@vlaaad Question

in the clj-fx examples there are a few places where you feed the (deref state) into a function and then reset! the result of applying a function to that state

im a bit confused by that

since an atom is supposed to have compare and swap semantics

this kinda feels like we are skipping over that whole step

so if i have another thread updating the state and an action goes off im now no longer certain i wont lose stuff

(i can do it with swap! obviously, but its no longer clear to me how exactly effects should work)

can you point me to example?

@emccue

from the readme

You raise a valid concern, this is actually not ideal. I tried to emulate re-frame, which is cljs, hence, single-threaded.

You can create :swap-state effect:

(fx/wrap-effects handler {:swap-state (fn [f _]
                                        (swap! *state f))})

Your handler then will be like that:

(defn handle [event]
  (let [{:keys [event/type text state]} event]
    (case type
      ::add-todo {:swap-state #(update % :todos conj {:text text :done false})})))

this is what i've done so far

im still a bit fuzzy on how effect handlers should work in general so i might need to read up more

Well I gave you example above 🙂

i know in the simpler model of elm I would get the state as something i could consider when making a decision about effects

you remove deref co-effect and use :swap-state effect

so in this case with the :swap-state that makes sense

but lets say, as a toy example, i wanted to send an http request if my "count" is even

or if a flag is false

yeah flag is some state is better

with the swap-state approach I can have a function that updates my state based on the "current" state of the flag no problem

if i am out of sync i will go through the atom thing

but the state i consider when deciding to make an effect can be out of sync with the state i consider when deciding what my new state will be

since i would end up needing to deref the atom in my event handler to know what to return in that effects map

does that make sense?

yeah

I don't have any easy answers or I would make a PR, but its something to consider

I have somewhat easy answer: don't swap/reset state atom you use in cljfx from different threads

I may be off base here, but this sounds like it might be a fundamental issue in any multi-threaded program where multiple threads wish to sometimes make updates to a centralized state. If they get a snapshot of the current state and compute on it for a while before doing some kind of mutual exclusion to do an update, then that snapshot can in general be "old" by the time you enter the critical section.

how to do it in a thread-safe manner: - wrap event handler using fx/wrap-async - don't use atom, send event maps to wrapped event handler.

wrap-async will make event handling go through agent, so it will happen sequentially, but it will be safe to call from multiple threads

@andy.fingerhut yeah, I think agents are a good solution here

Even update functions given to swap! can be redone N times in general, if other threads finish their swap! calls before you do.

Well more precisely, if they update the state of the atom after you read it, but before attempting your compare-and-swap inside the swap! implementation.

@emccue don't forget to read docs about fx/wrap-async if you don't know how agents work, there are some peculiarities

okay

And just to make it clear: if you use wrap-async and don't use state atom from different threads, it is safe to use deref co-effect/reset effect in event handling

yeah - ill probably have more questions as i get deeper in

im planning to use clojure for a software dev. class this semester and they have a requirement for a desktop gui

at some point down the road

I think #cljfx channel might be more fitting for questions about cljfx, I'm there as well

oh there is a channel - cool