Fork me on GitHub
#lsp
<
2022-03-16
>
borkdude15:03:45

Just used extract function for the first time! While fixing an issue in clj-kondo for lsp ;)

ericdallo15:03:52

Almost recursive 😂

Lukas Domagala15:03:10

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 🙂

🤯 2
lassemaatta15:03:51

I was just about to suggest that seeing a demo of something like that would be rather cool 🙂

borkdude15:03:29

well, I could share my screen here in a huddle ;)

ericdallo16:03:14

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 🤯 😂

ericdallo16:03:49

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 🤯 :)

Lukas Domagala16:03:29

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…

Lukas Domagala16:03:11

> 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?

borkdude16:03:30

Yes, why not

👍 1
borkdude16:03:14

Hmm, that reminds me, it should be possible to write a VSCode extension in #nbb as VSCode is basically just Node.js right...?

Lukas Domagala16:03:52

I think so, yes

borkdude16:03:42

did you start out with `

npm install -g yo generator-code
?

ericdallo16:03:45

yes, a local-root should work I think

Lukas Domagala16:03:47

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

borkdude16:03:05

I'll try it now partyparrot

Lukas Domagala16:03:58

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 🙂

borkdude16:03:24

and I probably copied that from @U0K592YDP’s VSCode clj-kondo extension

Lukas Domagala16:03:42

open-source is fun 🙂

Marc O'Morain16:03:33

👋 catching up on thread

borkdude16:03:23

I'll wait until vscode properly supports ES6 modules https://github.com/microsoft/vscode/issues/130367

Lukas Domagala16:03:38

Let’s hope that’s not one of those forever lingering infrastructure issues on vscode…

borkdude16:03:14

It might be a forever lingering issue with electron

Lukas Domagala16:03:08

reading the comments it seems electron could do it in theory. But js modules are crazy so I’ll stop wading into that now 🙂

borkdude16:03:52

everything in nbb is prepared for es6 and so it is itself an es6 library

borkdude16:03:36

it will come eventually as more and more libraries will be es6 only

Lukas Domagala16:03:32

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

borkdude16:03:40

I think the dust will settle around esm, it just takes years for every tool to be compatible with it

Max16:03:10

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.

Braden Shepherdson16:03:11

Try a go-to-definition on it? Maybe there is a throw fn in scope?

Max16:03:25

It can’t find a definition or declaration for it

ericdallo16:03:52

I think clj-kondo doesn't classify throw as a macro when inside a test, am I wrong @U04V15CAJ?

Max16:03:36

it’s not in a test either

borkdude16:03:43

dunno, haven't tested it, could be!

dpsutton16:03:54

throw has no defintion static final Symbol THROW = Symbol.intern("throw");

☝️ 2
ericdallo16:03:20

yes, throw is not a macro under the hood, but something else IIRC

Max16:03:47

Here’s the complete repro:

(ns scratch.core)

(throw (ex-info "hi" {:a 1}))
(def a 1)

Braden Shepherdson16:03:04

.clj, .cljs, or .cljc?

ericdallo16:03:22

I can repro on .clj

1
pez16:03:31

Related thread. @U04V15CAJ asked for an issue and we never provided. https://clojurians.slack.com/archives/CBE668G4R/p1643298479004419

👍 1
borkdude16:03:03

"I can repro", but what is the issue you're repro?

ericdallo16:03:06

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

ericdallo16:03:30

@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

borkdude16:03:40

but it isn't a macro? ;)

pez16:03:57

What we concluded last time was that it should be reported as a special form, iirc.

borkdude16:03:57

we should probably introduce :special true

1
ericdallo16:03:01

I think it's not a macro under the hood, but a internal sym

borkdude16:03:05

issue welcome ;)

😂 1
ericdallo16:03:54

@U01EB0V3H39 would you mind opening the issue on clj-kondo asking for :special true for thrown analysis?

Max16:03:21

you got it

dpsutton16:03:44

(keys clojure.lang.Compiler/specials)

👍 1
borkdude16:03:42

also:

user=> (special-symbol? 'throw)
true
which uses that

💯 1
Max16:03:43

Not sure I understand all the details, but I did my best! https://github.com/clj-kondo/clj-kondo/issues/1615

❤️ 1
ericdallo16:03:05

Thank you very much!

dpsutton16:03:02

@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

👍 1
dpsutton16:03:00

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.

borkdude16:03:54

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

ericdallo16:03:02

What a nice TIL 🙂

pez17:03:36

You can learn a bit about this if you run this guide: https://calva.io/get-started-with-clojure/ 😃

pez17:03:43

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.

borkdude17:03:08

a bit of both?

ericdallo17:03:12

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

borkdude17:03:19

I wonder why clj-kondo says this. def isn't a macro

👀 1
pez17:03:36

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.

borkdude17:03:22

for def, are you sure?

pez17:03:28

And Calva's hover reports (macro) (special form) for these (when the REPL is connected.

pez17:03:40

I would have to check for def

borkdude17:03:12

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

pez17:03:30

def, is (unsurprisingly) a pure special form. But fn:

borkdude17:03:40

fn isn't a special form, fn* is

borkdude17:03:00

similar for let and let*

dpsutton17:03:50

i belive the principal differences here are that the macro versions allow for destructuring and then call the special form

pez17:03:45

fn has :special-form true in its metadata, which I translate to it being ”a bit of both”. 😃 (And cider-nrepl too).

borkdude17:03:08

ah, great find

borkdude17:03:07

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"]

❤️ 1
dpsutton17:03:53

#{let fn letfn loop} are all in this manner. interestingly, def is not in the (ns-map 'clojure.core)

borkdude17:03:15

because def isn't a macro

dpsutton17:03:18

(ah nevermind, i got confused about which we were talkign about)

borkdude17:03:14

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

borkdude17:03:21

in clj-kondo analysis I mean

borkdude17:03:42

or does the absence of :macro true mean that it's really really really a special form?

dpsutton17:03:55

just raised it in #clojure. perhaps could be in #clojure-dev as well?

pez17:03:17

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.)

ericdallo17:03:52

I don't know too much about how M1 works, but shouldn't use aarch64 instead of amd64 native binary?

ericdallo17:03:39

Otherwise I have not idea how to fix that :/

ericdallo17:03:47

oh, from the issue, calva is downloading clojure-lsp-native-linux-amd64.zip , so it seems calva is not detecting OS properly

ericdallo17:03:21

Should it download the mac one, right?

pez17:03:43

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

ericdallo17:03:14

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

pez18:03:54

I’ll test that. Afk now, but anyway. 😀

👍 1
pez21:03:28

$ ./clojure-lsp --version
bash: ./clojure-lsp: cannot execute binary file: Exec format error

ericdallo21:03:35

so both mac and linux version give that?