thanks for the explanation, Sean!

i have a dumb question

I’m currently using clojure.core.server to start a socket server that I’m sending some messages back and forth from

works great in my CIDER session. however, when I uberjar it and run it… it just closes after initializing everything

I’m guessing that the socket server was anticipated to be used alongside an already-long-running process. is there a simple way to keep my clojure process alive while the meat and potatoes of my app is just using the socket server?

or should I switch to something that’s meant for more what I’m doing, like aleph or clj-sockets?

or should I just add an http server for giggles lol

when i do lein ring server-headless, i should have an nrepl, right?

how do i connect to that nrepl from emacs?

I found out that in project.clj, i need

:ring {:nrepl {:start? true}}

and then i can do C-c M-c to connect to the nrepl

I'm getting this now:

WARNING: CIDER's version (0.17.0-snapshot) does not match cider-nrepl's version (nil). Things will break!

Hi, having trouble with promises, lazy seqs, and side effects. I wrote this function where 'op' is basically an http-kit call that returns a promise. I believe that the function fails to run the operations concurrently (because the invocation of for returns a lazy seq, only the first one is started, and the second one is started only when @resp of the first one has finished waiting). How can I force the execution of side effects inside the let block? Thanks

(defn mp-update-user-profile
  " Takes zero or more [op user-id args] triples, performs the operations concurrently, and awaits all results"
  [& actions]
  (let [futures (for [[op user-id args] (partition 3 actions)]
                   (op mp-token user-id {:ip 0 :ignore_time true} args))]
    (doseq [resp futures]
      (timbre/debug @resp))))

ok, because I know and have previously used doseq I was expecting some macro that does exactly what I want. I just realized I can just invoke doall on the result of for to force the execution of side effects.

Your problem was that you want to run them in parallel but they were running in sequence or that they didn’t run at all?

wanted to run them in parallel but I believe they were running in sequence (I have no proof, and everything is running so fast that it is difficult to perceive the difference)

OK I've just added some logging inside the for block to find out when the operation is first invoked and now I have proof that before I added doall things were happening in sequence, and after I added the doall I see it's concurrent. Thanks for your help @rdanielo

Actually I didn't helped in any way apart from morally 😄

But I would like to see your final solution

I always call the function with 3 commands, which means I'm expecting 3 requests in parallel. First version is with for:

(defn mp-update-user-profile
  " Takes zero or more [op user-id args] triples, performs the operations concurrently, and awaits all results.
  Awaiting slows things down but ensures mixpanel is notified before we exit the program."
  [& actions]
  (let [futures (for [[op user-id args] (partition 3 actions)]
                  (do
                    (timbre/debug "Before request")
                    (op mp-token user-id {:ip 0 :ignore_time true} args)))]
    (doseq [resp futures]
      (timbre/debug "got response" (:status @resp)))))

18-04-01 13:31:57 point DEBUG [moe.core:15] - Before request
18-04-01 13:31:57 point DEBUG [moe.core:18] - got response 200
18-04-01 13:31:57 point DEBUG [moe.core:15] - Before request
18-04-01 13:31:57 point DEBUG [moe.core:18] - got response 200
18-04-01 13:31:57 point DEBUG [moe.core:15] - Before request
18-04-01 13:31:57 point DEBUG [moe.core:18] - got response 200

(defn mp-update-user-profile
  " Takes zero or more [op user-id args] triples, performs the operations concurrently, and awaits all results.
  Awaiting slows things down but ensures mixpanel is notified before we exit the program."
  [& actions]
  (let [futures (doall
                  (for [[op user-id args] (partition 3 actions)]
                    (do
                      (timbre/debug "Before request")
                      (op mp-token user-id {:ip 0 :ignore_time true} args))))]
    (doseq [resp futures]
      (timbre/debug "got response" (:status @resp)))))

18-04-01 13:34:31 point DEBUG [moe.core:16] - Before request
18-04-01 13:34:31 point DEBUG [moe.core:16] - Before request
18-04-01 13:34:31 point DEBUG [moe.core:16] - Before request
18-04-01 13:34:31 point DEBUG [moe.core:19] - got response 200
18-04-01 13:34:31 point DEBUG [moe.core:19] - got response 200
18-04-01 13:34:31 point DEBUG [moe.core:19] - got response 200

hey, I want to implement a queue for songs in my bot. basically I want to wait until a song stops to play another one. how would I implement this? I don't want to sleep for the duration, because I wouldn't be able to add songs to the queue when a song is playing

@mailmeupinside just putting this out there but I think you might need to provide more context before anyone can say anything useful... some sample code might help.

Update an an atom that holds the state of playing or not playing and change it at the end of song to false which picks up the next song of the queue and flips it to true, and so on?

@akiroz the thing is I don't have any code yet :^) I'm struggling to implement it in another language atm, and thought I'd maybe switch to Clojure if there was an obvious solution for this problem in Clojure

@joshua.d.horwitz there's no "song ended" event, I only know when it started playing and the duration. I feel I need async for that :thinking_face:

@mailmeupinside you can wait for a timeout channel

(But you should reconsider having at least a virtual stop evt because it might stop playing for a variety of other reasons,)