This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-16
Channels
- # aleph (1)
- # announcements (16)
- # babashka (36)
- # beginners (62)
- # calva (15)
- # cider (21)
- # cljsrn (5)
- # clojure (84)
- # clojure-dev (3)
- # clojure-europe (22)
- # clojure-italy (2)
- # clojure-nl (2)
- # clojure-uk (3)
- # clojurescript (36)
- # core-async (2)
- # cursive (4)
- # datomic (8)
- # emacs (14)
- # events (1)
- # fulcro (4)
- # hyperfiddle (6)
- # introduce-yourself (3)
- # jobs (1)
- # leiningen (4)
- # lsp (100)
- # nrepl (3)
- # off-topic (36)
- # pathom (17)
- # podcasts-discuss (1)
- # polylith (4)
- # portal (14)
- # react (1)
- # reagent (3)
- # reitit (8)
- # releases (3)
- # remote-jobs (1)
- # reveal (7)
- # shadow-cljs (19)
- # sql (16)
- # web-security (3)
Just used extract function for the first time! While fixing an issue in clj-kondo for lsp ;)
It’s such a funny feeling to be hooked into the running LSP repl that powers the editor I’m using to change its running code. Reminds me of the magical metacircular evaluator at the end of SICP 🙂
I was just about to suggest that seeing a demo of something like that would be rather cool 🙂
I think @U0178V2SLAY meant what @U02EMBDU2JU mentioned, that when developing on clojure-lsp, you can jack-in on the REPL of the clojure-lsp running in your editor, so you can eval something and check that already working in your own editor that you are developing clojure-lsp 🤯 😂
It'd be cool if we could eval the clj-kondo running that clojure-lsp is using while developing clj-kondo itself, that would be even more 🤯 :)
our vscode plugin at work is written (well currently its tiny…) in clojurescript. So I can now change the running lsp and the running extension while working on both inside that editor…
> It’d be cool if we could eval the clj-kondo running that clojure-lsp is using while developing clj-kondo itself, that would be even more 🤯 🙂 That’s actually possible, isn’t it? I can just use a local-root clj-kondo dependency and change the files and eval them?
Hmm, that reminds me, it should be possible to write a VSCode extension in #nbb as VSCode is basically just Node.js right...?
I think so, yes
but take it with a grain of salt, I haven’t used nbb yet and my vscode extension doesn’t do much more then start the LSP connection
It was initially actually based on your typescript for clj-kondo.lsp vscode extension and I threw out the typescript bit, so we’re kind of coming full circle 🙂
and I probably copied that from @U0K592YDP’s VSCode clj-kondo extension
open-source is fun 🙂
👋 catching up on thread
I'll wait until vscode properly supports ES6 modules https://github.com/microsoft/vscode/issues/130367
Let’s hope that’s not one of those forever lingering infrastructure issues on vscode…
reading the comments it seems electron could do it in theory. But js modules are crazy so I’ll stop wading into that now 🙂
Let’s hope so. It feels so crazy that js is now running the whole world and still doesn’t have a fully working module/namespace system
I think the dust will settle around esm, it just takes years for every tool to be compatible with it
I’m seeing an odd issue on one of my computers where LSP doesn’t recognize throw
as a macro. Anyone ever seen this behavior before? Strangely it works fine on my other computer.
Try a go-to-definition on it? Maybe there is a throw fn in scope?
I think clj-kondo doesn't classify throw as a macro when inside a test, am I wrong @U04V15CAJ?
.clj, .cljs, or .cljc?
Related thread. @U04V15CAJ asked for an issue and we never provided. https://clojurians.slack.com/archives/CBE668G4R/p1643298479004419
so, we could solve the issue in 2 places: • clojure-lsp, explicitly setting handling throw as a macro for what we do like semantic tokens, not sure I liked this way as we would need to harcode it in multiple places • change clj-kondo, make it return as a throw if that makes sense, or classify it as some other thing where we could check on clojure-lsp
@U04V15CAJ the issue is that kondo doesn't return throw
as a :macro true
, making clojure-lsp color it as a function and not as a macro
@U01EB0V3H39 would you mind opening the issue on clj-kondo asking for :special true
for thrown
analysis?
Not sure I understand all the details, but I did my best! https://github.com/clj-kondo/clj-kondo/issues/1615
@U01EB0V3H39 (keys clojure.lang.Compiler/specials)
is just a list of all special forms for Clojure. aka, other forms that will have the same issue as throw
. Many of them don’t appear in regular clojure usage but others like new
, do
, and finally
do appear with regularity
special forms are forms that don’t have a definition in Clojure but in the runtime. That is, when you evaluate a form, the actual runtime emits the bytecode to do that action and there is no definition in Clojure code.
another way to put it: special forms are the most low level building blocks of the language, they do not expand into something else and need special support in the compiler
You can learn a bit about this if you run this guide: https://calva.io/get-started-with-clojure/ 😃
As for how to report these. I think we can take a lot of inspiration from cider-nrepl which for instance reports both macro
and special form
for some forms that are a bit of both.
I think @U0ETXRFEW meant for example def
which clj-kondo say it's a macro and it's also a special from clojure compiler eyes, so it's probably both? :macro true
and :special true
Basically special forms for which there is also a macro in Clojure core.clj. (I think) We can navigate to the source of these using Calva, for instance.
I incorrectly did this when I first started clj-kondo:
https://github.com/clj-kondo/clj-kondo/blob/aa734107429416f663c1fdcd4df5df2b36da4e8e/src/clj_kondo/impl/overrides.clj#L16
I should remove :macro true
and change it to :special true
i belive the principal differences here are that the macro versions allow for destructuring and then call the special form
fn
has :special-form true
in its metadata, which I translate to it being ”a bit of both”. 😃 (And cider-nrepl too).
I think the difference between fn
and fn*
(the latter being a really special form), is that you cannot every override that symbol in call position by a var name or local
user=> (special-symbol? 'fn)
false
user=> (special-symbol? 'fn*)
true
user=> (let [fn* 1] (fn* []))
#object[user$eval146$fn__147 0x4f8b4bd0 "user$eval146$fn__147@4f8b4bd0"]
#{let fn letfn loop}
are all in this manner. interestingly, def
is not in the (ns-map 'clojure.core)
but this raises the question: should we distinguish :special-form
from special-symbol
? ,as in fn
isn't a special symbol, although the metadata marks it as something special
or does the absence of :macro true
mean that it's really really really a special form?
Calva fails to choose the right lsp when running in a docker container on Mac M1. See https://github.com/BetterThanTomorrow/calva/issues/1598#issuecomment-1069367672 Is there something we can do about it, or does something need to happen on the clojure-lsp side? (Well, we will need to improve our download logic regardless, but anyway.)
I don't know too much about how M1 works, but shouldn't use aarch64 instead of amd64 native binary?
oh, from the issue, calva is downloading clojure-lsp-native-linux-amd64.zip
, so it seems calva is not detecting OS properly
It is running in a docker container. I am honestly not sure what it should be downloading or running. But also from the issue:
$ uname -s
Linux
$ uname -m
aarch64
I see, it looks like a linux, so it makes sense to run using the linux binary, but just for curiosity, could you try running the mac binary on that container and check if it works? just a clojure-lsp --version
probably would be enough to know if it works