Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-04-05

Channels

#clj-kondo
<
2020-04-05
>
borkdude07:04:53

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

niveauverleih07:04:42

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.

borkdude07:04:31

@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

borkdude07:04:36

just that you cannot cross compile

borkdude07:04:02

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

borkdude07:04:36

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

borkdude07:04:46

anyway, yeah, LSP is a great fallback

yuhan08:04:05

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

niveauverleih08:04:24

@borkdude here https://github.com/oracle/graal/issues/1329 yes I use spacemacs on termux-ubuntu on a Samsung A10 smartphone.

borkdude10:04:23

@qythium Correct, that is a false positive. E.g. spec also defines def but a special form is always prioritized over var names: https://github.com/clojure/spec.alpha/blob/5a4834eeb2967b2eca382efe0afcb3f590bdb3c2/src/main/clojure/clojure/spec/alpha.clj#L349

borkdude10:04:00

@qythium This issue already mentions that problem: https://github.com/borkdude/clj-kondo/issues/639 I'll change the title so it will cover this issue more clearly.

yuhan10:04:41

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

borkdude10:04:06

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

orestis11:04:04

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.

orestis11:04:33

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

borkdude11:04:10

no, it's been there all along

borkdude11:04:26

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

borkdude12:04:29

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! https://github.com/borkdude/clj-kondo/releases/tag/v2020.04.05

❤️ 4
seancorfield17:04:18

@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!

serioga17:04:09

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

borkdude17:04:01

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

serioga17:04:23

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
       ~@body)))

serioga17:04:22

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

seancorfield18:04:35

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.

seancorfield18:04:02

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

serioga18:04:12

@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 [,,,]))

serioga18:04:23

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

seancorfield18:04:50

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

seancorfield18:04:12

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

seancorfield17:04:02

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

borkdude17:04:35

Nice, so db-spec was reported as unused?

seancorfield17:04:37

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

seancorfield17:04:15

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
borkdude17:04:37

Ah right. Nice :-)