(restart-case (analyze-logs '("LOG: Hello, world!"
                              "LOG: This is a second log entry"
                              "LOG: "
                              "LOG: hey"
                              "blah"
                              "ERROR: "))
  ::exit (fn [] (throw (ex-info "exit" {}))))

(binding [*restarts* (merge *restarts*
                            #:user{:exit
                                   (fn [args__14292__auto__]
                                     (make-jump
                                      :semaphore.core/jump-target14766
                                      args__14292__auto__))})]
  (try
    (analyze-logs
     '("LOG: Hello, world!"
       "LOG: This is a second log entry"
       "LOG: "
       "LOG: hey"
       "blah"
       "ERROR: "))
    (catch
        semaphore.signal.Signal
        e__14300__auto__
      (apply
       (condp #(semaphore.proto/is-target? %2 %1) e__14300__auto__
         :semaphore.core/jump-target14766 (fn 
                                            []
                                            (throw
                                             (ex-info "exit" {})))
         (throw e__14300__auto__))
       (semaphore.proto/args e__14300__auto__)))))

Never did the stack tracing, will try to figure it out, thank you.

https://github.com/brunoV/throttler the source here is pretty small and worth checking out even if you don't want to use the library

we have some work in progress towards adding something like this to core.async, @U050ECB92 can probably drop a gist

Thanks @U064UGEUQ and @U064X3EF3

I am using throttler. But I find thst he orchestration code I have is really bad. In javascript there are a ton of libraries that use promises to structure workflows. AndI would like to write clj + cljs code with core.async that has similar functionality.

The actual code that does the work is easy to write in clj + cljs.

But the coordination to structure a workflow is pretty difficult

Iteration is feedback

which is to say, if you have something like clojure.core/iterate, the way it works is it produces a seq by calling a function to get the first element, and then feeding that first element back into the function to get the rest

iteration is what you want for paginated apis, because each page is a page of results + some "next" value that you use to get the next page

with core.async there are sort of two ways to build an interative process

1. take a function and iterate it (lifting a function into a process) 2. take a process and iterate it

iterating a a function to turn it in to a process is pretty straightforward, it looks just like using iterate to build a lazy sequence, but instead of constructing a lazy seq you are sending to a channel

iterating a process involves adding a backward edge (like another channel), that takes data from the output and feeds it back into the input

Thanks @U0NCTKEV8 this is what I need. Do you know where I might get some kind of example for this two approaches?

I do not. https://github.com/clj-commons/useful/blob/master/src/flatland/useful/seq.clj#L129-L148 is a seq version of unfold(or iterate), you can write something similar that sends output to a channel instead of cons'ing up a seq

@U0NCTKEV8 thanks .. very helpful

@UCSJVFV35 https://gist.github.com/ghadishayban/2e81021f0156c017babd460cba1d58d6

step! is a function that given a token, hits the http endpoint to fetch data - returning a channel with that data. when token is nil , that signifies the initial call to step! :vsf the vsf argument is a function taking the result of step! (AKA fetched api data) and extract a collection of the juicy bits :kf would take the fetched page data and produce the token that, when given to step! grabs the next page

in your case @UCSJVFV35, you would put all the retries inside step!

the gist above is a way to consume iterated api patterns generically. it is not a helper for retries

the core operation, the step! argument, is to fetch one page (no matter how many retries it takes)

I admit that the docstring is a bit much

:kf = key function :vsf = values (plural) function

Thank you very much

From the fact that turns a tuple into individual arguments. For example here’s type of curry in haskell:

curry :: ((a, b) -> c) -> a -> b -> c

Though now that I look at it it’s actually uncurrying, not currying 😅

uncurry :: (a -> b -> c) -> (a, b) -> c

in terms of performance the problem is apply not partial ; )

The question is in terms of: (partial some-fn) vs. #(some-fn %)

The only reason I mentioned apply was because that was the construct in the above message from Max

I’m influenced by the fact that Rich has said he considers partial to be less idiomatic than an anonymous function.

I hadn’t heard that. Thank you

(e/qb 1e5
  ((partial tmpfn) nil)
  (#(tmpfn nil)))
;; => [7.33 4.55]

Do you mean?

(e/qb 1e5
  ((partial tmpfn) nil)
  (#(tmpfn %) nil))

An almost verbatim reproduction of the test from that issue:

Clojure 1.10.2
user=> (require '[criterium.core :refer [bench]])
nil


user=> (let [f (partial + 1 1)] (bench (f 1 1)))
Evaluation count : 575498700 in 60 samples of 9591645 calls.
             Execution time mean : 98.891101 ns
    Execution time std-deviation : 1.024939 ns
   Execution time lower quantile : 98.103690 ns ( 2.5%)
   Execution time upper quantile : 100.146501 ns (97.5%)
                   Overhead used : 5.615028 ns

Found 4 outliers in 60 samples (6.6667 %)
	low-severe	 3 (5.0000 %)
	low-mild	 1 (1.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
nil


user=> (let [f (fn [a b] (+ 1 1 a b))] (bench (f 1 1)))
Evaluation count : 6352825620 in 60 samples of 105880427 calls.
             Execution time mean : 3.946144 ns
    Execution time std-deviation : 0.466162 ns
   Execution time lower quantile : 3.811868 ns ( 2.5%)
   Execution time upper quantile : 3.993066 ns (97.5%)
                   Overhead used : 5.615028 ns

Found 1 outliers in 60 samples (1.6667 %)
	low-severe	 1 (1.6667 %)
 Variance from outliers : 77.1883 % Variance is severely inflated by outliers
nil

@U051N6TTC A silly mistake, but the result is basically identical

In my case, the result is quite different. :) 99ns vs 4ns.

This is why I don’t trust myself benchmarking things like this 🙂

Thank you for the comparisons

I imagine, the results may also vary greatly between JVMs. But I'm too lazy to actually check it. Especially since I almost never use partial myself.

@U2FRKM4TW probably because you're declaring the function in let, and #{ wastes time declaring the function on the fly with each iteration of the bench

That lambda ends up being compiled as a class, once. It's not recompiled on each execution.

partial is useful when you have a multi-arity function that you want to curry.

On Cljs the definitions of stuff like partial and comp also generate a lot of JS. But OTOH if some dependency is using them you will get that JS anyway so why not use them directly too...