I thought about that

thank, that’s what I needed

DM me with any Qs. Happy to help.

The template project is horribly minimal right now. I need to expand it.

but the placeholder substitution is kind of a bear

Essentially if you copy bits of the app template into your generated template project, you'll be close.

@U04V70XH6 hi, I finished my template: https://github.com/green-coder/vrac-template

I have a request for improving clj-new: do not force the user to have a multi-segment project-name.

In many cases, the users don’t want it.

clj -A:new app foo.core is the same as lein new app foo

I will not drop the requirement for qualified or multi-segment names.

thank you^_^

Can you give an example input+output you’d want to see?

Like

(f [1 2 3])
;;=> [1 2 3]

I have a list with 3 maps on it, but i want to get those 3 values

I'll get some code to visualize better my request

👍

i have this function (map #:( {name %}) (range 1 4)

And this returns what i want, but inside a list

The values that this function generates needs to be in a vector that i previously build

But i cannot be able to do it inside this list

So, what i'm trying to ask is: is there any function or strategy that give me this, but wihout being on a list?

Is the issue that map produces a list but you want a vector?

You could use mapv to produce a vector, or (into [] (map f coll)) or (vec (map f coll)) to produce vectors from functions operating on collections.

into would let you append your new items into an existing vector:

(into my-vector (map #(hash-map :name %)) (range 1 4))

Let me test that

It really worked!! Thanks for the insights, friends!

also - most of the time vector vs. list shouldn't matter, clojure thinks a vector and list with the same elements are =, so you only need a specific implementation if you are counting on insertion order or using indexed lookup

I don't think there is any kind of "first in first out queue" in the implementation between threads, so the same thread T1 could lose repeatedly to another thread T2 if T2 was repeatedly doing swap! calls, yes?

One could certainly imagine modifying the implementation to enforce a bound like the number of threads, but that isn't what Clojure has now.

oh - that's a good point, in a pathological though unlikely case two threads could ping-pong indefinitely

not sure if this is what you mean by ping-pong, but the pathologically bad case would be T2 repeatedly succeeding in its swap! calls, causing T1 to keep retrying inside of one swap! call, and never returning from that call.

My actual situation is I want to assoc in a new value at :key only if it isn’t already there inside the atom. But creating my new value has side effects / is expensive … so I only want to do it once.

And I don’t want to create it ahead of time if there is something already at :key

@U0CMVHBL2 but after one iteration, you can't have a forced retry on one side without a success on the other, and that means you need at least one attempted swap by another thread per retry in the current thread - because one or the other will always win

which makes me think the number of swap! / thread combos is a limiting factor, unless I'm missing something

If T2 keeps doing swap! on the same atom in a loop, changing the value inside on each call, and always "wins the race", then T1 can be starved. I agree it is pathological. Just not provably impossible.

Some kind of internal FIFO queue of competing threads that was auto-created when there was contention, or something like that, could guarantee all threads make progress. The pathological behavior is so unlikely that I doubt anyone has seen more than a few retries before success in practice.

@fappy with your case, foo-fn is always called, before swap - you can use @ / deref to check for the key before attempting ot swap, but there's always the narrow chance of a race where foo-fn gets called twice

no way to avoid that race condition?

if you need strict ordering without retries, agent is the only clojure mutable that has that behavior

Well, and if. you check if :key is absent, then call foo-fn , then try to add the as the value of :key you might find :key is present after returning from foo-fn , even though it was absent before.

So seems like I should use an agent to hold this instead.

You can use a plain old Java lock to make larger transactions. In this case, though, a Clojure agent might fit your needs, since the function you send to the agent can do arbitrary things inside of a change, with no starvation, and no interruption by other threads.

agents never retry, but they do have different consequences - eg send! / send-off! return immediately and asynchronously take effect

well, not quite arbitrary, but it can do the "check :key is absent, only then call foo-fn, then add :key with that value", and guarantee foo-fn is never called twice.

await exists and can be useful if you need to know that a sent action is done, although if @U051SS2EU is correct (and I have no reason to doubt him, as I haven't dug into the agent code to check myself), the await might not return until not only after your thread's sent actions are complete, but also perhaps some other thread's actions, too, so await might wait a bit longer than you wish.

clojure.core/await
([& agents])
  Blocks the current thread (indefinitely!) until all actions
  dispatched thus far, from this thread or agent, to the agent(s) have
  occurred.  Will block on failed agents.  Will never return if
  a failed agent is restarted with :clear-actions true or shutdown-agents was called.

so it waits for only the actions dispatched from my thread

no

from this thread or agent ?

It says that, but apparently it might mean "at least that long", not necesarily "exactly that long, but no longer"

it's an inclusive or

sure but it seems the part I quoted is there to say it’s not intentionally waiting for all actions from all theads sent to these agents finish before unblocking …

so you wait for all pending operations on that agent

I’m reading it as all pending operations on the agents sent from the thread who called await

from all threads

Even if it is an inclusive or, if it meant "exactly that long, but no longer", then the actions sent by other threads would not matter, I would think.

await explicitly cannot be nested

the source throws if you attempt

I don't know how you could attempt to nest them, since it is a blocking call.

actions you send could themselves contain a call to await

So by "cannot be nested" you mean "cannot be called inside of a function you send to an agent"?

@U0CMVHBL2 I might be misunderstanding you, but here I prove that regardless of which thread calls send, await waits for all actions to be fully processed if they were queued before await was called

(cmd)user=> (def a (agent nil))
#'user/a
user=> (future (send a (fn [_] (println 1 'start) (Thread/sleep 10000) (println 1 'done))))
#object[clojure.core$future_call$reify__8454 0x1bc715b8 {:status :pending, :val nil}]
user=> 1 start
(future (send a (fn [_] (println 2 'start) (Thread/sleep 10000) (println 2 'done))))
#object[clojure.core$future_call$reify__8454 0x3e8f7922 {:status :pending, :val nil}]
(cmd)user=> (do (await a) (println 'OK))
1 done
2 start
2 done
OK
nil

Thanks for the example -- I never really did doubt you -- more it made me wonder why the implementation might be that way, and yet be documented with its current doc string.

yeah, I wonder what nuance "thread" is offering in "this thread or agent"

(defn await
  "Blocks the current thread (indefinitely!) until all actions
  dispatched thus far, from this thread or agent, to the agent(s) have
  occurred.  Will block on failed agents.  Will never return if
  a failed agent is restarted with :clear-actions true or shutdown-agents was called."
  {:added "1.0"
   :static true}
  [& agents]
  (io! "await in transaction"
    (when *agent*
      (throw (new Exception "Can't await in agent action")))
    (let [latch (new java.util.concurrent.CountDownLatch (count agents))
          count-down (fn [agent] (. latch (countDown)) agent)]
      (doseq [agent agents]
        (send agent count-down))
      (. latch (await)))))

oh - I did the three ops in the wrong order!

nothing you send can call await

got it

It isn't the first time reasonable people have wondered at the wording of Clojure doc strings. clojure.set/union simply doesn't say anything about what happens if you pass it non-sets, which is taken by the implementers as "promises nothing whatsoever if you pass it non-sets". This doc string might be "it will not return before time X, but we don't promise when after time X it might return"

("This doc string" == "doc string for await ")

If actions a and b were sent from different threads to agent foo and I (await foo) and prior to my await, my thread sent b I think await will stop blocking some time after b is complete … either before or after a runs which is the nondeterministic part

Sure, some time after your functions sent to the agent, await will return, not before.

meanwhile a and b will be run in exactly the order they were sent, which is unknown to me

@U0CMVHBL2 but my point is it could unblock before a if indeed a got sent after b by some thread other than me

The part the doc string isn't promising anything explicit about, but it is really easy to draw the wrong conclusion about, is that it returns as soon as the last action that the calling thread sent to the agent is complete, regardless of other thread actions sent to the same agent.

I think the discussion is that if your thread sends b , then await will block until at least b is complete, but experiments show that in some cases the implementation will block longer.

If that doesn't bother you, then great. If you somehow want to write code that needs await to unblock you the moment that your thread's sent actions are done, then don't use await

what would unblock immediately? delivery on a promise?

I think so, but haven't necessarily thought through it as thoroughly as someone whose livelihood and sanity rests upon a correct answer 🙂

my above example was sloppy - I think this demo is much better

(defn agent-action
  [n]
  (fn [_]
    (println n :start)
    (Thread/sleep 1000)
    (println n :end)))

(defn agent-test
  []
  (let [a (agent nil)]
    (future (send a (agent-action 1))
            (await a)
            (println "wait over"))
    (future (send a (agent-action 2)))
    nil))

sometimes "wait over" prints after 1, sometimes in the middle of 2, sometimes after 2

where I use futures in case the thread calling send had some effect

No guarantees, but any problems if I grab your demo code and publish it in an article some time? Happy to give you credit by name if you don't mind.

no problem at all

Brilliant! I wonder if the possible slow return of await has ever bothered anyone. If not, I shouldn’t let it bother me 😛

Thanks for taking the time to discuss!

it's much more interesting than my current JIRA ticket :D