Look at :table-fn and :column-fn in the documentation and the quoted namespace.

Docs about this: https://cljdoc.org/d/seancorfield/next.jdbc/1.2.659/doc/getting-started/friendly-sql-functions#table--column-entity-names

Ok, I got it. Thanks.

But there are no apostrophes around "09/22/2018":

(->> [[:a 560] [:b "09/22/2018"]]
     (map (fn [[kw v]] (format "%s = %s" (name kw) v)))
     (s/join ", "))

=> "a = 560, b = 09/22/2018"

I'd pull the anonymous function to its own function. Reads better, easier to isolate, test etc.

thanks @U01RL1YV4P7, it works

Nested destructuring is ugly and hard to read, but it does work.

(let [[[_ a] [_ b]] [[:a 560] [:b "09/22/2018"]]]
  (str "a = " a ", b = '" b "'"))

For questions specifically about shadow, I definitely suggest asking in #C6N245JGG. @U05224H0W is absolutely amazing with providing thorough (and usually very fast) support. Your assumption about {:shared {:entries []} ... } is pretty far off. > You can leave the :entries of the :shared module empty to let the compiler figure out which namespaces are shared between the other modules. -- https://shadow-cljs.github.io/docs/UsersGuide.html#CodeSplitting So with this config, shadow will follow the entry points defined by your other modules in order to calculate for you what is shared. The result of that calculation will be included in the shared module.

you can have a look at https://github.com/clj-commons/claypoole if you want a bit more control the hard part of this problem is usually handling network failures core async's pipeline could help too

pmap doesn't start that many processes. It is "calibrated to suit the number of CPU cores available (https://www.oreilly.com/library/view/clojure-programming/9781449310387/ch04.html)". I have used it a lot as a dirty solution for exactly this use case and it has worked great.

Thanks @U02F0C62TC1 @U02SD8PATK2 — this was helpful!

pmap is simple but suffers from head-of-line blocking

I don't mean a mix but allowing both :foo/foo and :foo. Specifically I would destructure an input map

I think it's generally something to avoid as it's confusing to both callers and in the receiving code

but you can do so like:

(let [{unfoo :foo, :foo/keys [foo]} m
      the-real-foo (or unfoo foo)] ... )

yea thanks

you are correct about the lazy

or some with when:

(some #(when (pred %) %) collection)

user=> (:foo (reify clojure.lang.ILookup (valAt [_ _] (throw (Exception.)))))
Execution error at user$eval1$reify__137/valAt (REPL:1).
null
user=>

heh, is that a kind of value you can read off of a kafka topic without using reify in the consumer?

dunno, my point it is depends on what message is, not so much the keyword

if you want to be safe, use get

I mean, get will do the same thing

destructuring is also ok. using keyword syntax is not the same as get and it has bitten me in the ass a few times.

user=> (get (reify clojure.lang.ILookup (valAt [_ _] (throw (Exception.)))) :foo)
Execution error at user$eval1$reify__137/valAt (REPL:1).
null
user=>

@U0NCTKEV8 try a non ILookup

why?

that part is dynamic, you don't really know the param type being given to :foo or get

my point, for either keywords as functions or using clojure.core/get is that the collection is really in control

yeah

and it can do whatever it likes

so that is what you need to know about if you what to see if it throws or not

what what "message" is in the question is not really specified

I think what matters here may be what the desired behaviour is on the lookup when it's in a fail case. ignore and process message, or throw + do error handling stuff?

doing something like if-let on a get that returns nil is pretty convenient, compared to keyword lookup that throws cus you gave it something like a string or something else bad

but, for the very first question (are there values that make keyword lookups throw), yes, and actually it's most values that do that, but typically you restrict the types you use in a clojure program to just a handful that do work with keyword lookup

user=> (get (reify java.util.Map (get [_ _] (throw (Exception.)))) :foo)
Execution error at user$eval1$reify__137/get (REPL:1).
null
user=> (:foo (reify java.util.Map (get [_ _] (throw (Exception.)))))
Execution error at user$eval140$reify__141/get (REPL:1).
null
user=>

i'm pretty sure (:foo "my string") doesn't work

i'm wrong

i'm not sure what values keyword lookup doesn't like, but i have run into them a few times and they make very weird errors (just because they are unexpected)

there is some complicated stuff with keywords as functions, the compiler will insert inline caches for those because they might be record field lookps

maybe i shouldn't be so worried about them. just tried a lot of different test cases i thought should fail and they didn't. makes me very curious as to the ones i ran into. maybe they are specific to yada or something

that's a function that takes 2 arguments. The first is bound to report-instance inside the function body and the second arg is destructuded (because it's assumed to be a map) so that id is bound to the :account/id key in the map. Is this in clojurescript?

yes it is in cljs. ok so there isn't something special. I've tried to delete a form with a "delete-button". But there are only following functions: form/delete!, form/delete-entity. In form/delete! I have to provide [this id-key entity-id] whereas this is report-instance I guess and id-key is the uuid from my account. But what is entity-id and where to get it?

I'm not sure I know what form/delete-entity is ... you might have better luck asking in #C68M60S4F ?

thanks so far, I will do that!

I added as extra-deps `

{:dev
 {:extra-paths ["src/dev"]
  :extra-deps  {garden-gnome/garden-gnome {:mvn/version "0.1.0"}}}

Looking at the source code, it looks like you can put your config into a garden.edn file in lieu of having a project.clj https://github.com/Otann/garden-gnome/blob/master/src/garden_gnome/watcher.clj#L70

true, I totally forget.

I didn’t use a lot time ago in this way. Thanks!

Happy to help 🙂

I think the former is more direct. The latter is going to gather up all the inputs to make one big function call, which is going to walk through everything anyways. The reduce has a lot of different optimizations built in too depending on what my-sequence is

Clojure 1.11.1
user=> (apply max [])
Execution error (ArityException) at user/eval1 (REPL:1).
Wrong number of args (0) passed to: clojure.core/max
user=> (reduce max [])
Execution error (ArityException) at user/eval3 (REPL:1).
Wrong number of args (0) passed to: clojure.core/max
user=>

user=> (apply max 0 [])
0
user=> (reduce max 0 [])
0
user=>

personally, apart from performance implications, I generally prefer to use reduce when I think of the operation as logically a reduce (typically operating on two items at a time), and apply when using a collection as function arguments (e.g. (apply partition [2 [1 2 3 4]]) )

In #C01ECA9AA74 I switched to apply for examples like this because 1. Certain functions like * that I would usually reduce with can short circuit and stop consuming the sequence if they hit a zero 2. The multi arity version reduces internally anyway But I’m curious about @U064X3EF3 ‘s comment here about gathering up all inputs

Short circuit on zero is intriguing

(defn saturates [f v] (fn [a x] (let [r (f a x)] (if (= r v) (reduced r) r))))

Yup

https://github.com/sicmutils/sicmutils/blob/ce763b31153eb9253f165bd5b4e4e6a6087bf730/src/sicmutils/util/aggregate.cljc#L193

“and” saturates on false, “or” on true