This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (21)
- # babashka (1)
- # beginners (67)
- # calva (18)
- # cider (21)
- # clj-kondo (109)
- # cljs-dev (3)
- # clojure (129)
- # clojure-spec (15)
- # clojure-uk (30)
- # clojurescript (3)
- # datomic (2)
- # graalvm (8)
- # graphql (1)
- # juxt (1)
- # malli (28)
- # off-topic (51)
- # reitit (5)
- # rewrite-clj (33)
- # ring-swagger (2)
- # shadow-cljs (199)
- # vim (9)
@snoe @borkdude heya, I wanted to talk to you about making a npm distro of clojure-lsp in the same way I made one for clj-kondo
so the clj-kondo one felt like it made sense because it would be ran standalone in non-server mode
if it doesn't, I wonder if it makes sense to have a npm distribution... because it feels like something that actually runs as a editor extension instead
and from looking at the clj-kondo editor extension, it doesn't seem to need a npm distro
should the focus instead be to provide a clojure-lsp vscode extension similar to the clj-kondo one? would it make sense for them to be the same extension even?
@filipematossilva Let's back up a bit. The clj-kondo.lsp + vscode extension are available from the VSCode marketplace. What would be the added benefit of an npm package?
relevant to note that the closure-lsp vscode extension doesn't work on windows (or didn't, last I checked)
it should work on Windows as it's just running a JVM, nothing native. @pez checked that it worked on Windows
I could see distributing clj-kondo.lsp as a library on clojars being useful, so others can build extensions for other editors if they want. That's something I'm considering
the whole point of clj-kondo.lsp was Windows actually, since the binary already worked on other platforms
about a week ago I tried opening the extension and the changelog said it didn't work on windows yet
clj-kondo.lsp solves more than just the Windows case. It also lets makes the story for vscode clojure linting be the beautifully simple: “Install the cljs-kondo extension”, or even “Install Calva. Oh, you already did that? You have linting.“.
$ ./clj-kondo --lint - <<< '(inc)' exists? false can-read? false <stdin>:1:1: error: clojure.core/inc is called with 0 args but expects 1
but with the large classpath I don't even see those printlns:
$ ./clj-kondo --lint "$(lein classpath)" > /tmp/log.txt java.io.FileNotFoundException: /private/tmp/lock-kondo/.clj-kondo/.cache/2019.10.27-SNAPSHOT/lock
no output, still same exception. weird! https://github.com/borkdude/clj-kondo/blob/3c58801d002beb5295ea26264a73dcda09d4cc98/src/clj_kondo/impl/cache.clj#L58
strangely completely elsewhere in the code than where it was reported, maybe due to laziness or something
@rickmoynihan finally found the cause for an issue you were seeing back in September: https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/clj-kondo/near/174962809 See https://github.com/borkdude/clj-kondo/issues/542 I just merged a fix to master. This binary should fix the problem: https://6819-176829714-gh.circle-artifacts.com/0/release/clj-kondo-2019.10.27-SNAPSHOT-macos-amd64.zip
@rickmoynihan It was the problem with: > I’ve mkdir .clj-kondo and when running `clj-kondo --lint “$(lein classpath)” I get the error:
I'm so happy this weird bug is now solved (at least on my machine, fingers crossed). Thanks a lot for collaborating.
@borkdude 🍾 great news. So was the issue laziness holding jar files open for too long? Also just tried to recreate the issue but no longer can… weird.
Well, because of laziness you can't close a resources, because then you will close it too soon. So I had to make reading sources from a jar strict + close it after reading it.
yeah, I’ve done that myself but with zip files in the past… laziness and resources don’t mix! 😀
@rickmoynihan It depends on the amount of dependencies. Try this project.clj: https://github.com/borkdude/clj-kondo/files/3799357/project.clj.zip
I guess reading all the sources from a jar in memory at once isn't adding up to enough making it worth porting
oh it’s slurping… I guess most clojure projects are pretty small, even with all their transitive deps.
yeah, it's slurp. could make that into a reader-type thing, but I guess even with this classpath size it doesn't even add up
but yeah might be worth porting one day after all… though I don’t see myself maintaining 1m lines of clojure in a project for a while.
also linting the classpath is a thing people do once every so often, the most common use case is linting one file at a time
looks good! also compared output from both and looks good:
> diff native.out jvm.out 4485c4485 < linting took 23197ms, errors: 1582, warnings: 2902 --- > linting took 16499ms, errors: 1582, warnings: 2902
well I’m not sure it’s the same binary I used when I first reported the issue; but I’ve not updated to the binary you posted today.
ok well, thanks for testing. I have two different macOS machines confirming that it's fixed now 🙂
@lee @sogaiu I now updated the GraalVM issue using a pure Java example: https://github.com/oracle/graal/issues/1804#issue-516316985
@borkdude i got:
Exception in thread "main" java.lang.NullPointerException at LockRepro.listFiles(LockRepro.java:13) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.main(LockRepro.java:33)
@sogaiu since you're getting the exception now, my hunge is that the maximum number of open files for a process on macOS is lower than on linux?
got similar result to yours for native:
> ./lockrepro | wc -l Exception in thread "main" java.lang.NullPointerException at LockRepro.listFiles(LockRepro.java:13) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.listFiles(LockRepro.java:25) at LockRepro.main(LockRepro.java:33) 253
they do use "substitutions" as they call it: https://github.com/oracle/graal/blob/519cb180a31c61f7735d64aeabf566236489ddcf/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/PosixUtils.java
I was considering to do parallel linting. I can change mapcat into pmap + cat. But maybe I would also run into "too many open files" with this 🙂
a process must be able to set its own limit no? maybe through
setrlimit... maybe there is a graal option for that?
oh maybe you could do in java? here's some graal code that plays with the limit https://github.com/oracle/graal/blob/519cb180a31c61f7735d64aeabf566236489ddcf/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/PosixNativeLibraryFeature.java#L81