Fork me on GitHub

@nick.romer if the executable isn’t an option, you could also try the LSP server which uses a regular JVM


Thanks @sogaiu ! @borkdude I see you already asked the arm question to the graal team. So graal is currently not an option. I'll read up on the LSP server.


@nick.romer Can you remind me where I asked this? if this was about cross-compilation, it doesn't necessarily mean ARM is not supported


just that you cannot cross compile


GraalVM offers downloads for mac arm64, linux arm64, but also aarch64 which I think is arm?


oh I see sogaiu mentioned that it might only be there for java11


anyway, yeah, LSP is a great fallback


Is this a false positive? It looks like defining a custom def macro in a namespace (like spec does) doesn't overshadow the special form, but clj-kondo considers it to be the case

(ns foo)

(defmacro def
  [x y z]

(def x 42) ;; -> foo/def is called with 2 args but expects 3


@borkdude here yes I use spacemacs on termux-ubuntu on a Samsung A10 smartphone.


@qythium Correct, that is a false positive. E.g. spec also defines def but a special form is always prioritized over var names:


@qythium This issue already mentions that problem: I'll change the title so it will cover this issue more clearly.


Thanks! I wonder if it's idiomatic to actually do this or deserving of a warning, given the precedent in clojure.spec. After all it's not shadowing anything and can only be referred to in fully qualified form


@qythium yeah. I think a warning would be appropriate (which you can then fine-tune using a config).


Is there any way to get the clj-kondo to exit with status 1 iff errors are present? Ie ignore warnings. I’m currently relying on parsing the output.


Hm did that change recently? I remember looking at exit codes when I started. Still needs a small wrapper but better than parsing output.


no, it's been there all along


well, pretty much since the beginning, maybe a few weeks in


clj-kondo v2020.04.05 - warn about conflicting alias - optional warn on usage of get-in, assoc-in etc. with single keys and other stuff!

❤️ 4

@borkdude Awesome new release -- thank you! With the with-(db-?)-transaction support, it found a couple of places where I accidentally did this

(jdbc/with-db-transaction [t-con db-spec]
    (jdbc/execute! db-spec [,,,]))
instead of this
(jdbc/with-db-transaction [t-con db-spec]
    (jdbc/execute! t-con [,,,]))
so that's a real bug in the code it found!


That's exactly why I asked if you consider API with shadowing 🙂


@U0HJNJWJH Did you ask something to the JDBC maintainers or clj-kondo? I don't follow


In my project I wrote a macros around your macros for shadowing.

(defmacro with-transaction
  "Helper for `jdbc/with-transaction` allowing specify connection
   symbol only once and shading non-transactable name."
  [spec & body]
  (let [spec (if (vector? spec)
               (into [(spec 0)] spec)
               [spec spec])]
    `(jdbc/with-transaction ~spec


@borkdude I asked Sean about with-db-transaction in #sql


I don't recall seeing that come up in #sql but I do remember you asking about (with-transaction con ,,,) as a shortcut for (with-transaction [con con] ,,,) and I said it wasn't a good idea to have two different syntaxes for a macro -- and why I think your with-transaction is a bad idea too.


(he's talking about functions but it applies equally to macros)


@U04V70XH6 My question was not about collection/not collection. My question was about making db-spec not available inside transaction because this name is replaced (shadowed) with t-con inside the block. In case like this even linter will not help (because t-con is already used):

(jdbc/with-db-transaction [t-con db-spec]
    (jdbc/execute! t-con [,,,])
    (jdbc/execute! db-spec [,,,]))


Found my original question in archive Did you consider next.jdbc API for with-transaction where sym shadows name of transactable ?

; Current API
(with-open [conn (jdbc/get-connection my-datasource)]
  (jdbc/with-transaction [tx conn]
    (jdbc/execute! tx ...))) ; what is allowed to do with `conn` here?

; Alternative - the lexical scope of `conn` is changed
(with-open [conn (jdbc/get-connection my-datasource)]
  (jdbc/with-transaction [conn]
    (jdbc/execute! conn ...))) ; outer `conn` not accessible here


(with-transaction [db-spec db-spec]
  (execute! db-spec ,,,))
is that what you're trying to achieve?


This conversation should probably go to #sql at this point.


Also verified my (+ (byte c) i) code is no longer flagged.


Nice, so db-spec was reported as unused?


And the new :single-key-in linter flagged a bunch of stuff in our code too so "yay!" on that as well!


It reported t-con was an unused binding -- correctly -- which is a bug because the wrapped code should use the transaction not the original db spec.

💯 4

Ah right. Nice :-)