I think you could read the file inside a macro, and substitute the reading with actual values you read at compile time. Another approach would be to put the file you’re reading as a resource which is compiles as a part of the final JAR — so it’s always with you the way you compiled it.

If I can somwhow pack it inside of jar?

Yes. With leiningen you do it by putting in resource/ folder in your project, and open the file with this function https://clojuredocs.org/clojure.java.io/resource

yep. The provlem is I am doing exactly same thing by now with

(defmacro compile-time-read-file
  [resource-path]
  (slurp (io/resource resource-path)))

w8 a second

ok. I got it.

In your example above, you’re not calling the start function, you’re returning the function object from -main. Wrap it in parentheses like that (start)

@UKG0SELQY

Yes. I've meant. Sorry. I actually call it with parenthesis.

Ok. In this case, looks like what you need to do is to “wait” for the go-loop thread to finish from the main thread. You can do that by doing this: (async/<!! (start)) @UKG0SELQY

1 min. I'll try

Yep. This seems like the right approach.

go-loop returns a channel from which you can read the result of async code execution when it’s ready (when the loop finishes). By reading for the value in a blocking way, we ensure that the main thread waits for the async loop to finish.

thnx!

still the same error 😕

Interesting. Works for me, and I basically copy and pasted your code to my terminal

Tried it in the older clojure.jdbc and it works, guessing it's a problem with next.jdbc and my system

(def idb {:classname                                  "org.postgresql.Driver"
          :subprotocol                         "postgresql"
          :subname                             "//localhost:7432/foo-dev"
          :user                                "foo"
          :password                            "foo"})

Glad you got it sorted! 🙂

AFAIK that is its primary purpose

NB - don't ever use first / rest / etc. seq operations on a queue, it can quietly turn your fifo into a lifo

only use into, peek, conj, and pop

(and other tools built on those)

To add to @U051SS2EU’s answer, I'll try and illustrate the difference: (apply f coll) will call f once with all elements of given collection supplied to it as arguments; (reduce f val coll) will call the function once for each element in the collection. Consider this:

(vector 1 2)                   ;; => [1 2]
(vector 1 2 3 4 5)             ;; => [1 2 3 4 5]
(apply vector [1 2 3 4 5])     ;; => [1 2 3 4 5]
(reduce vector 1 [2 3 4 5])    ;; => [[[[1 2] 3] 4] 5]

(reduce vector [1 2 3 4 5])    ;; => [[[[1 2] 3] 4] 5]

(reduce #(apply update %1 %2) {:left 0 :right 0} [[:left dec]
                                                  [:right inc]
                                                  [:right inc]])
;; => {:left -1, :right 2}

Can we say reduce is equivalent to apply if f is associative?

that's the word I almost used earlier, yes

Associativity is somewhat different, it is only defined for binary functions (but see below). And yes, reduce in its basic form [1] repeatedly applies a binary function to a sequence. If the function is associative, then the result will be the same for reversed sequence. But apply works with functions of different arities for which associativity makes no sense, e.g. (apply update [{:a 0} :a inc]). [1] https://en.wikipedia.org/wiki/Fold_(higher-order_function)

right, and a foolish person could make a vararg function that is associative for two args, but does something non-associative for a higher arg count

Well, for higher arg count, the function cannot be associative or non-associative -- e.g. above (update :a inc) would make no sense Edit: I think we can translate associativity to variadic functions if we consider them as functions of one argument which operate on finite sequences, i.e. associative then meaning (using common mathematical notation) f((x1, f((x_2, ..., x_n)))) = f((f((x_1, ..., x_{n-1})), x_n)) for all such sequences. For apply and reduce to be equivalent on the other hand would mean that f((f((x_1, f(( ... )), x_{n-1})), x_n)) = f((x_1, x_2, ... x_n))._

a version of plus that took three args would still be "associative" in the loose sense that you could start simplifying anywhere in the expression and get the same answer

sorry, no, that's incoherent, clojure functions based on known associative functions are often varargs, and if so they usually do the same thing under reduce / apply, that's all

I think the reason apply and reduce seem similar is that clojure provides many functions with their reduce'd extensions to higher arities. Consider addition as commonly defined in mathematics: it is a binary operation which can be extended to sequences via formal equivalent of reduce. Since it's associative, it can even be extended to sets. And in many programming languages addition remains just a binary operation, and to get a sum of more than two numbers one has to reduce or fold it. It's just that clojure conveniently provides this already -- if we look at the source of +, we'll see

(defn +
  ;; snip
  ([x y] (. clojure.lang.Numbers (add x y)))
  ([x y & more]
     (reduce1 + (+ x y) more)))

I think it's because it's commutative that you can do that on sets

(ins)user=> (apply / [1 2 3 4])
1/24
(ins)user=> (reduce / [1 2 3 4])
1/24

I think I mixed up associative and commutative above myself

@U9TGHG3LP reduce1 is a less efficient and less flexible version of reduce used before the clojure compiler has implemented reduce

You're right, for the reduction to be well defined on at least some interesting sets, the operation has to both be associative and commutative. But I shouldn't have mentioned it -- we don't want to drift too far I reckon 🙂

Thanks team for the reply, What I understood is apply and reduce both give same result, but acts different for different functions , and the way it handle functions are different