Clojurians Log v2

hey, I was wondering how I’d setup clj-kondo to not report unresolved-symbol for things extending clojure.test, e.g. thrown-with-data? here: https://clojureverse.org/t/testing-thrown-ex-info-exceptions/6146/3?

@charliebriggs https://github.com/borkdude/sci/blob/971614de14a6fd00e6991d1afd6c0ce9fbda104c/.clj-kondo/config.edn#L3

wonderful, thank you very much

I’m just getting started with clj-kondo, so please forgive me if I’m missing something obvious. In my test code, I tend to use :refer :all to drag in the namespace that I’m testing, which clj-kondo unsurprisingly warns about. I’ve worked out that I can disable this warning by putting {:linters {:refer-all {:exclude [my.namespace.here]}}} into my config.edn but that disables the warning everywhere. I only want to disable it within test code. Is there any way that I can achieve that?

@paulbutcher you can use namespace local config to achieve that

or an ignore hint

An ignore hint is inside the source code, yes? How do I create namespace local config?

Oh! Is it just a .clj-kondo directory inside the namespace?

(ns foo (:require #_:clj-kondo/ignore [foo.bar :refer :all]))
;; or
(ns foo {:clj-kondo/config {:linters {:refer-all {:level :off}}}}
    (:require [foo.bar :refer :all]))

so both in source

Ah! Got you.

Thanks!

@borkdude sorry to get back to the graal thingie, but clj-kondo can't get native image compiled with graalvm8-20.2

Error: Unsupported features in 5 methods
Detailed message:
Error: Frame states being merged are incompatible: unbalanced monitors - locked objects do not match
 This frame state: [locals: [1,2,3,1,_,_] stack: [7] locks: [] rethrowException]
Other frame state: [locals: [1,2,3,1,_,_] stack: [20] locks: [14 / 5] rethrowException]
Parser context: sci.impl.vars$alter_var_root.invokeStatic(vars.cljc:417) [bci: 11, intrinsic: false]

clj-kondo only supports compiling to native with graalvm jdk11 20.2.0

Ah I see, clj-kondo now includes sci and sci needs Clojure 1.10.2-alpha* to avoid those warnings in graalvm

@b Is there a reason you can't make the uberjar yourself, if you already have graalvm 11 in nixos?

just trying to cut down on the dependencies, because graal8 was based on the src release and that took 24 GB of memory to build which overwhelmed my computer and the build farm computer quite often

but yeah I could try to get leiningen and create the uberjar

That would be easier I think. You could maybe just run the existing script/compile in that case

I haven't yet checked if this is so easily done because NixOS is all about purity and if leiningen grabs a lot of dependencies then it requires network access which is impure

a PR to bring the uberjar build on circleci up to date with jdk11 + the reflector fix is also welcome

I will do that!

I think the sole reason it is published is the nixos builds, unless I forgot

and it's fine if the regular standalone.jar is replaced by the one that includes the java11-reflector-fix?

if it's only used by nixos, then I think so?

let's just do it. we'll change it if someone complains

I didn't know that history, I "just took over" in February because it was pretty much abandoned

I'll open a PR, thanks