Fork me on GitHub
#clj-kondo
<
2019-10-03
>
borkdude08:10:12

I've merged the final thing I wanted to get in for the next release. If you can give it one more try later today, then I'll make a release if there are no other problems. @mynomoto: Linux: https://6280-176829714-gh.circle-artifacts.com/0/release/clj-kondo-2019.09.23-alpha-SNAPSHOT-linux-amd64.zip

tatut11:10:34

https://github.com/borkdude/clj-kondo/issues/496 <- this may be very tricky because core.match looks like a quite complicated macro

tatut11:10:10

added an issue to track it, couldn’t find previous issues about core.match

borkdude11:10:20

OK. For now you can use the config to turn linting off inside that macro.

tatut11:10:59

well maybe a 1st approximation would be to just consider all non-quoted symbols in the pattern part to be available in the consequent part

borkdude11:10:34

Right. It is possible to implement, no doubt, but just pointing at a workaround for now.

borkdude11:10:48

Thanks for posting the issue.

borkdude12:10:02

I will def. consider it as it's a common thing in the ecosystem.

borkdude12:10:40

If you want you can also start working on a PR.

borkdude12:10:54

But if I don't notice any activity, I will probably do it at some point.

tatut12:10:22

ok, maybe… I’ve been thinking about trying my hand at implementing something to clj-kondo

borkdude12:10:40

I think you can draw some analogies from linting the let macro.

mynomoto12:10:32

@borkdude testing it.

tatut13:10:36

what aliases should I use with cider-jack-in, having trouble running clj-kondo.main-test from cider

borkdude13:10:47

@tatut I start it like clj -A:test:cider-nrepl from the command line. I never use cider-jack-in because I'm old fashioned. I connect with cider-connect.

tatut13:10:29

I got it running and made a new corpus/core_match/match.clj with the failing case and added a test to main_test.clj which now fails

tatut13:10:40

then the harder part of implementing

tatut13:10:21

If I understand this correctly, I would add to the (case [resolved-as-namespace resolved-as-name] case in analyzer.clj

tatut13:10:15

ok, I’ll see what I can do

borkdude13:10:25

as I've already mentioned, the let linting is probably similar. maybe also the core.async alt macro

borkdude13:10:45

(I can never remember if that should be plural and with or without exclamation marks and how many)

tatut13:10:40

I’m unclear what I should return, but I’ll fire up the cider debugger and inspect things

tatut13:10:57

and look at what let and others are doing

borkdude13:10:20

what you should do to prevent false positives: extract the bindings from the form that introduces them, add them to the ctx under :bindings and then lint the children nodes using that ctx

tatut13:10:27

cider debugger ❤️ is good for this sort of “exploring an unfamiliar codebase” thing

tatut13:10:58

just eval some existing linter impl in debug mode, run the test and see the values flowing

borkdude13:10:36

great. if you're implementing this like the other macros, then you should also get "unused bindings" in your match macro

borkdude13:10:43

when you don't use those of course

tatut13:10:28

oh yes, so if you introduce a binding in pattern but don’t use it… I’ll make a test case for that as well

borkdude14:10:45

@mynomoto still good?

mynomoto14:10:51

@borkdude got lost doing some fixes for a project, all good on my tests.

borkdude14:10:16

alright. I'll make a release either tonight or tomorrow

tatut14:10:44

the :bindings is a map in ctx, from symbol to ?

borkdude14:10:28

symbol to map with row and col. this is typically produced by the function extract-bindings

tatut14:10:54

ok, I’ll look into that

tatut14:10:03

but got to go and continue later, thanks for the advice so far

borkdude14:10:12

no problem, take your time

sammikko15:10:33

hi.. i'm trying to get clj-kondo working on Windows.. found this https://github.com/borkdude/clj-kondo/issues/276 .. is there anything to do to help with this or is it basically that GraalVM folks need to sort something out?

borkdude15:10:45

@sammikko The issue is like this. You need to install a C++ redistributable on the system where the binary is compiled. Also you need to install from the command prompt that comes with this, so certain dlls are in scope (if I understand correctly). But these dlls are not statically linked (afaik that's not possible yet with GraalVM on Windows). So when you copy the resulting binary to a different system, then it will crash because of a missing dll.

borkdude15:10:32

@sammikko There is some documentation here for building on Windows: https://github.com/borkdude/clj-kondo/blob/master/doc/build.md#windows

borkdude15:10:53

Also there is an appveyor Windows build that runs along each commit.

borkdude15:10:48

If you can find out a solution for Windows users, this is welcome. You might also be able to find out of you can just run the linux binary with WSL2.

borkdude15:10:29

There is an issue on Graal for the dll stuff, but there hasn't been any news there for a while.

sammikko15:10:52

right ok.. I managed to build the exe using the instructions.. but there is no output.. also tried to copy msvcr100.dll in the same dir as exe, but no luck.. it starts but there is no output.. without --lint it does display the usage instructions tho

sammikko16:10:15

ok, ill try to look into it.. new to GraalVM too..

borkdude16:10:16

FWIW you can always run clj-kondo on the JVM as a lib or uberjar, but that won't be pleasant in an editor.

sammikko16:10:03

yeah.. ive tried it on osx.. its nice that its so fast.. good work 🙂

borkdude16:10:06

Might also be worth looking into GraalVM documentation around Windows. Maybe things have changed meanwhile.

borkdude16:10:54

It would be easiest from a maintenance standpoint if WSL2 was an option.

borkdude16:10:46

Not sure about this. I'm not using Windows frequently and don't know a lot about the OS internals.

borkdude16:10:59

What could also work is writing an nREPL integration for clj-kondo, so you run it as a lib inside your editor REPL.

borkdude16:10:41

This would be editor specific and up to contributors to step in.

sammikko16:10:21

right.. do you mean like starting up the clj-kondo on JVM but keeping the process alive and feeding it the "files" with some protocol ?

borkdude16:10:09

like cider-nrepl which is also a development-time library which lives in your REPL process

borkdude16:10:13

maybe you don't even need nREPL, haven't thought this through a lot

sammikko16:10:02

well its good to have options 🙂 ill need to do some reading on GraalVM etc.. thanks for the help!

nate_clojurians20:10:54

how does clj-kondo compare with joker for linting?

borkdude20:10:31

I started doing clj-kondo because I wanted additional linters to joker. But in time I think it caught up with joker pretty well.

borkdude20:10:13

I have a hard time coming up with a feature that's not already in clj-kondo.

nate_clojurians20:10:40

I was using joker for a while with flycheck in emacs and got pretty annoyed with false positives

nate_clojurians20:10:52

and iirc it stopped processing the file when it found the first issue

borkdude20:10:07

that's for unresolved symbols I guess

nate_clojurians20:10:26

and known-macros

nate_clojurians20:10:49

oh and :refer :all was a pain

borkdude20:10:15

clj-kondo has a slightly different take on macros: you can teach it to lint custom macros as clojure.core macros. for example: lint manifold.deferred/let-flow as clojure.core/let

borkdude20:10:43

I would say: spend 20 minutes watching my talk at ClojuTRE to learn what it can do and then decide if you want to install it.

borkdude20:10:55

It also helps you with getting rid of refer :alls.

nate_clojurians20:10:28

oh I have it installed right now and it seems fine, I was just wondering if there were major differences in use or issues or philosophy that I'm not seeing

borkdude20:10:17

I have only done one recorded talk on it, so yes 🙂

borkdude20:10:54

I explain about the difference with other linters in the talk as well

robertfrederickwarner21:10:52

I'm seeing a false positive being caused by clj-kondo not ignoring a defn that I have tucked away in a (comment) block. I took a look through the issues on github but didn't spot anything similar, is this a known issue? Would you like me to create an issue?

borkdude21:10:29

it's a design choice: comments often contain example code that I still want to have linted

borkdude21:10:18

if you want to ignore comments there's an option for that. but you can also choose to use uneval to comment out the defn.

robertfrederickwarner21:10:05

That makes sense, though in this specific case of defning a function, it seems like the linter picking up the commented out function signature could cause other false positives in non-commented code

borkdude21:10:59

true. personally I don't put defns in comments though, just calls (like a REPL session that could become a unit test)

robertfrederickwarner21:10:43

yeah, my next comment would be that I probably should be leaving this in here like this. It's an unfinished bit of code that I want to record but come back to later

robertfrederickwarner21:10:04

I'll just prefix the fn name with _ for now

sogaiu23:10:10

@sammikko fwiw, my last understanding of the situation was that one significant issue was this: https://github.com/oracle/graal/issues/1469. i'm not as confident as others regarding whether there isn't something one can do about the dll as i got some private assembly clj-kondo working to deal with the dll part. also, i think there's a chance at an ugly work-around: > using an additional program that can handle stdin / stdout communications properly to have it act as an intermediary / wrapper around Windows native-image programs generated from Clojure source. (see https://github.com/borkdude/clj-kondo/issues/276#issuecomment-517900704) the additional program would write what it receives from the invoker to disk and clj-kondo would read from disk -- after processing, clj-kondo would write the results to disk and the additional program would read them back and send them back to the invoker appropriately. the additional program could be written in rust, go, nim, etc. i got wiped out working on this before and have not seen any activity on oracle's side. i also think it would all-around be better to not be using dlls when you don't have to (see: https://github.com/oracle/graal/issues/1407#issuecomment-508688008 for details)

sogaiu23:10:10

@sammikko fwiw, my last understanding of the situation was that one significant issue was this: https://github.com/oracle/graal/issues/1469. i'm not as confident as others regarding whether there isn't something one can do about the dll as i got some private assembly clj-kondo working to deal with the dll part. also, i think there's a chance at an ugly work-around: > using an additional program that can handle stdin / stdout communications properly to have it act as an intermediary / wrapper around Windows native-image programs generated from Clojure source. (see https://github.com/borkdude/clj-kondo/issues/276#issuecomment-517900704) the additional program would write what it receives from the invoker to disk and clj-kondo would read from disk -- after processing, clj-kondo would write the results to disk and the additional program would read them back and send them back to the invoker appropriately. the additional program could be written in rust, go, nim, etc. i got wiped out working on this before and have not seen any activity on oracle's side. i also think it would all-around be better to not be using dlls when you don't have to (see: https://github.com/oracle/graal/issues/1407#issuecomment-508688008 for details)

sammikko20:10:11

good work digging into this.. I tried your patch where in was changed to System/in and out to System/out... It seems to work different if I have .clj-kondo directory in effect with config.edn... even with the patched version, it crashes if I lint my project directory having .clj-kondo. If I try the same dir without .clj-kondo, it works and outputs the same warnings as in OSX..

sammikko20:10:48

I'm trying to "debug" it using Sysinternals Process Monitor tool.. it seems that it processes all the files, but then in the end it tries to call QueryAllInformationFile for .clj-kondo\.cache\2019.09.23-alpha-SNAPSHOT\lock resulting in BUFFER OVERFLOW

sammikko20:10:38

I didn't find any difference with msvcr100.dll, tried putting in same dir as .exe (dir is in PATH), current directory etc..

sammikko21:10:50

I'm not really familiar with windows internals... know the basics..

sammikko21:10:06

it just crashes in the end, probably when trying to output something...

sammikko21:10:49

how did you get the stack trace for the crash? maybe i can try the same..

sogaiu23:10:30

it may take me a bit to recreate the context due to various factors including an aging brain 🙂 if you didn't see it already, here's a repository documenting what i think is a native-image issue: https://github.com/sogaiu/constdin -- it should have instructions on ending up with a stacktrace. for the dll side of things, i don't have anything written up, but i can dig up the sxs private assembly stuff that seemed to work if you think that might help. let's see if i can attach it here -- the version of clj-kondo is from a bit back, but iirc, the important bits are the specific manifest files along with things being consistent with what's described within them.

sogaiu23:10:05

ok, that seemed to work...

sogaiu00:10:37

if you do build your own clj-kondo.exe on windows successfully, you may find that it works better when launched from within the special console "Windows SDK 7.1 Command Prompt" setup provided by windows 7 sdk. i think we found that the built executable tended to work better on the machine / environment where it was built. i got hard-to-explain varying behavior depending on which shell the executable was launched from. the 4 shells i tested among are mentioned at the constdin repository linked above. regarding the build process, i had a lot of difficulty getting the build environment set up appropriately -- a straight-forward install of the windows 7.1 sdk just would not work. fwiw, here are my notes: https://gist.github.com/sogaiu/e079cd770051685c46ab24b6658effcf -- but may be you have this all working already 🙂

sogaiu00:10:34

i'm not really familiar with windows internals either. regarding "buffer overflow", i reached a similar conclusion that in this case what process monitor is telling us is not what security-conscious folks usually are concerned with.