This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-02
Channels
- # 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 (46)
- # 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
does clojure-lsp have a 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?
yes I suppose that is the main question
to give npm consumers a cross platform way to run closure-lsp
not sure who those consumers would be though
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
so maybe you could re-test it @filipematossilva on Windows?
about a week ago I tried opening the extension and the changelog said it didn't work on windows yet
the clojure-lsp vscode extension one
trying to find it again, but having trouble... sec
ah no, the clj-kondo vs code extension is working on windows already
it's the clojure-lsp one that doesn't
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.“.
this works:
$ ./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:
updated this issue as well: https://github.com/oracle/graal/issues/1804
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
yeah a transducer might make sense — but probably not worth the effort porting
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
weird that project.clj seems to work for me…
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
maybe related: https://github.com/oracle/graal/issues/1581
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