Clojurians Log v2

I'd like to start a thread about the possibility of adding the ability to go from a cursor position to an analyzer entry. Continuing https://github.com/snoe/clojure-lsp/pull/176#issuecomment-683123972

I imagine the difficulty comes in with macros, and the reticence is because linting may not need it? I think carve shows the utility of the analyzer itself, so I wonder if we think about other tools it could be a useful exercise. Renaming, I think, is right up there beside dead code for utility. A cli tool that could correct any inconsistent aliases, or rename a fully qualified var without resorting to sed and careful diff checking. Is it fair to want the analyzer to grow beyond kondo with some examples like this?

My thinking is that kondo's analyzer feels like the closest thing we have to a tooling analyzer.

Some exciting news! https://www.clojuriststogether.org/news/q3-2020-funding-announcement/

I think I'm fine with this, with the following caveats: 1) Some things are easier to lint while analyzing, this is why clj-kondo intertwines linting with analysis sometimes. So splitting an analyzer into a library is hard because of this. 2) I don't like clj-kondo linting getting slower because of extra work it has to do for other projects. The in-editor experience should be as fast as possible. So if we can prevent that, that's cool. I think we can accomplish that just using some configuration options.

Btw, carve uses clj-kondo analysis but then rewrites the code using rewrite-cljc, not using kondo. So it only uses the data output.

There are some other issues that have to do with analysis here: https://github.com/borkdude/clj-kondo/issues?q=is%3Aissue+is%3Aopen+label%3Aanalysis

Does clj-kondo compile with the following java -version?

openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment GraalVM CE 20.2.0 (build 11.0.8+10-jvmci-20.2-b03)
OpenJDK 64-Bit Server VM GraalVM CE 20.2.0 (build 11.0.8+10-jvmci-20.2-b03, mixed mode, sharing)

it should yes

I just tried it, and got this error:

Error: Already registered: java.util.zip.ZipFile$CleanableResource.get(ZipFile, File, int)
com.oracle.svm.core.util.UserError$UserException: Already registered: java.util.zip.ZipFile$CleanableResource.get(ZipFile, File, int)
...
...
...
Error: Image build request failed with exit status 1
com.oracle.svm.driver.NativeImage$NativeImageError: Image build request failed with exit status 1
	at com.oracle.svm.driver.NativeImage.showError(NativeImage.java:1558)
	at com.oracle.svm.driver.NativeImage.build(NativeImage.java:1308)
	at com.oracle.svm.driver.NativeImage.performBuild(NativeImage.java:1269)
	at com.oracle.svm.driver.NativeImage.main(NativeImage.java:1228)
	at com.oracle.svm.driver.NativeImage$JDK9Plus.main(NativeImage.java:1740)

Ah 20.2, haven't tried it yet, currently using 20.1. But 20.2 should work

Aaah

I know what this is. Just use 20.1 for now

Sure. Thanks!

I'll upgrade soon

Or, if you feel like it, you can do it. The clojure reflector fix should be bumped to 20.2 in project.clj, but also other references in the CircleCI and Github config

this, I assume: https://github.com/borkdude/clj-reflector-graal-java11-fix

yes

Would you rather me make a PR directly, or make an issue first?

Well, https://github.com/borkdude/clj-kondo/pull/979, but added diffs in resources/clj_kondo/impl/cache/built_in/clj/clojure.pprint.transit.json and resources/clj_kondo/impl/cache/built_in/clj/clojure.tools.reader.transit.json. Should I add these to .gitignore?

also, wow native-image takes a lot of RAM (to compile)!

Please don't add resources/* to .gitignore, it's essential to clj-kondo. Also, I wonder how did you end up with a diff in there, it's not relevant to the PR?

So I would rather have you reset that file to the old one

Yeah, GraalVM is quite heavy on the RAM, although for clj-kondo it doesn't go above 2 or 3GB I think?

> So I would rather have you reset that file to the old one Done. > Please don't add resources/* to .gitignore, it's essential to clj-kondo. After reading docs/dev.md, I get this now. > Also, I wonder how did you end up with a diff in there, it's not relevant to the PR? Yeah, it's quite weird. I'm using clojure version 1.10.1.561. Not sure if that can make a difference. I'll see what the actual difference is.

Thanks, merged!

Courtesy of https://cljdoc.org/d/lambdaisland/deep-diff/0.0-47/doc/readme, I was able to find out the differences in the resources. clojure.pprint's cache had the following differences (Addition of :arities):

c-write-char {:col 1,
              :fixed-arities #{2},
              :name c-write-char,
              :ns clojure.pprint,
              :private true,
              :row 47,
              :top-ns clojure.pprint,
              +:arities {2 {:args (nil :nilable/int)}}},


p-write-char {:col 1,
              :fixed-arities #{2},
              :name p-write-char,
              :ns clojure.pprint,
              :private true,
              :row 360,
              :top-ns clojure.pprint,
              +:arities {2 {:args (nil :nilable/int)}}},

read+string {:arities {0 {:ret :vector},
                       +1 {:ret :vector},
                       +2 {:ret :vector},
                       +3 {:ret :vector},
                       -:varargs {:min-arity 1, :ret :vector}}, ;; this got removed the the above 3 arities got added.
             :col 1,
             :fixed-arities #{0 +1 +2 +3},
             :name read+string,
             :ns clojure.tools.reader,
             :row 1008,
             :top-ns clojure.tools.reader,
             -:varargs-min-arity 1}, ;; this got removed as well.

Have you ran any scripts locally that updated these files?

I did run script/built-in. Should have mentioned this beforehand :man-facepalming:

I haven't ran those in a while. It could be that some logic related to that changed.

if you think the changes are correct, then we could add those as well

Yeah, https://github.com/clojure/tools.reader/blob/master/src/main/clojure/clojure/tools/reader.clj#L1009 never had a variadic arity. Seems like the new file is correctly identifying arities 0, 1, 2, 3.

I have a script, script/dump_types that dumps type information in a diff-able manner

So when you run that on master and on your branch, it's easier to spot differences

It could also be that one of the deps in clj-kondo got bumped, and the arities changed?

Got it. Although, apart from having to read with transit, I don't think it's un-diffable

> It could also be that one of the deps in clj-kondo got bumped, and the arities changed? I git-blamed those three functions, and they didn't change in years. So this is unlikely.

then clj-kondo must have had an error before

:man-shrugging:

@jaihindhreddy So I ran script/built-in and script/dump-types. Then made a branch: https://github.com/borkdude/clj-kondo/pull/980/files Now the diff is readable in Github, is what I mean

I get it now. Thanks for clarifying!

I'll just hook script/dump-types into script/built-ins, so we get it automatically

good idea.

Merged. Also updated the script (since now babashka has had transit for a while).

It's funny, you can also run that script using clojure script/dump_types.clj since all the deps are in deps.edn as well. But Clojure prints namespaced maps in script-mode it seems (https://clojuredocs.org/clojure.core/*print-namespace-maps*)

This works: $ clojure -e "(set! *print-namespace-maps* false)" script/dump_types.clj