Fork me on GitHub
#lsp
<
2022-04-02
>
lassemaatta10:04:01

anyone else getting CRC mismatch errors when using the new Java features with a src.zip? (EDIT: was due to zlib 1.2.12)

lassemaatta10:04:09

checking the src.zip archive with unzip -t reports no errors

borkdude10:04:28

Is this on linux?

borkdude10:04:47

I've seen this error when upgrading to zlib 1.12.2. Don't do that, keep using 1.12.1.

borkdude10:04:22

The graal team is aware of this

kokada10:04:58

Just a correction, zlib 1.2.12 is the one causing issues

kokada10:04:04

1.2.11 is fine

borkdude10:04:53

Maybe that's not an issue, since lsp isn't using musl. https://github.com/clojure-lsp/clojure-lsp/issues/868

kokada10:04:19

Arch are generally very fast to provide updates

borkdude10:04:24

ohhhh right

borkdude10:04:34

so you better start using musl so the binary becomes static :)

kokada10:04:42

If you're using a non static compiled version of clojure-lsp, you may hit this issue

lassemaatta10:04:11

I think I have zlib 1.2.12

borkdude10:04:16

yep, that's the issue

borkdude10:04:32

better fix 868 and ship that binary by default I'd say

kokada10:04:36

I don't think it necessary needs to be compiled with musl, maybe the static with dynamic libc should also work

kokada10:04:45

In theory the issue is zlib, not glibc

borkdude10:04:46

yeah, also an option, good point

borkdude10:04:01

you're sharp today, thanks @UFDRD93RR :)

kokada10:04:19

Glad to help 😊

kokada10:04:24

So just to confirm, @U0178V2SLAY you're building clojure-lsp yourself right? Either by AUR or something else

borkdude10:04:49

if you're using a dynamic one, doesn't it just pick the system's zlib?

borkdude10:04:08

unless it has a hardcoded version

kokada10:04:58

Yeah, this should be the case (I didn't confirm though). This is why I think this is a dynamic build of clojure-lsp

kokada10:04:35

(not sure if the releases from GitHub are dynamically linked or something else, maybe @UKFSJSM38 can confirm this)

kokada10:04:57

But I would expect at least it to be static with dynamically linked glibc

kokada10:04:09

Oh yes, this confirm my hypothesis

kokada10:04:19

Try the release binaries from GitHub instead

kokada10:04:38

Ah forget it

borkdude10:04:40

@UFDRD93RR how would those be different?

lassemaatta10:04:51

also, downgrading zlib to `1.2.11` solved the issue

kokada10:04:55

This AUR also downloads from GitHub releases

borkdude10:04:27

I agree with @UFDRD93RR that adding the static-except-glibc would be the easiest and most safe solution

kokada10:04:29

@U04V15CAJ you mean AUR vs GitHub?

borkdude10:04:39

yes, it's clear now

kokada10:04:42

AUR may compile things from source

kokada10:04:53

Actually, most of time it compiled from source

kokada10:04:08

So maybe someone packaged it without activating the static release

borkdude10:04:13

Gentoo-style ;)

kokada10:04:14

Doesn't seem the case though

borkdude10:04:41

There is no static release

kokada10:04:54

Oh ok, this explains it

lassemaatta10:04:16

I don't believe that particular PKGBUILD for clojure-lsp performs any compilation, it's quite fast to install/upgrade. But I may be wrong.

kokada10:04:25

No it doesn't

kokada10:04:39

Now the question is, is there a static release of clojure-lsp

kokada10:04:53

Even the static with dynamic glibc would probably solves the issue

kokada10:04:17

But the best way to go would be to compile everything with musl

kokada10:04:46

I think clojure-lsp doesn't depend on Datalevin anymore, that was the previous issue of using musl

borkdude10:04:51

I think using the static-except-glibc will solve it for all platforms in the short term. Musl only works for amd64

kokada10:04:13

Huh... Yeah, good point

borkdude10:04:26

setup-graalvm supports musl option, so it should be very easy to use that, since lsp uses github actions. I'm afk now.

lassemaatta10:04:40

thanks for the help debugging this 👍

kokada10:04:29

Not sure if this is musl or static with dynamically libc, but it doesn't matter for this issue

kokada10:04:56

This modified PKGBUILD should be sufficient to fix the issue:

# Maintainer: David Harrigan <dharrigan [@] gmail [dot] com>
# Contributer: Mateen Ulhaq <mulhaq2005+aur at gmail dot com>

pkgname=clojure-lsp-bin
pkgver=2022.03.31_20.00.20
pkgrel=1
epoch=2
pkgdesc="Language Server (LSP) for Clojure"
arch=("x86_64")
url=""
license=("MIT")
depends=('gcc-libs')
provides=("${pkgname%-bin}")
conflicts=("${pkgname%-bin}")

source_x86_64=("${pkgname}-${pkgver}-native-static-linux-amd64.zip::${url}/releases/download/${pkgver//_/-}/clojure-lsp-native-static-linux-amd64.zip")

sha256sums_x86_64=('<PLEASE SET ME>')

package() {
    install -Dm0755 -t "$pkgdir/usr/bin/" "${pkgname%-bin}"
}
Of course, please update the sha256sums_x86_64

lassemaatta10:04:05

thanks, I'll test that later 👍 I don't think I actually need the PKGBUILD, as I can just extract the binary somewhere and instruct lsp-mode to use that instead of the AUR version.

ericdallo14:04:36

Sorry for the delay: • Arch AUR just download the release from GitHub • There is a issue I intend to solve to next release to make static binary use musl for static binary

ericdallo14:04:39

@U11EL3P9U, maybe it'd be nice if the AUR compile clojure-lsp with Graal instead of downloading the release? Not sure, I'm not a AUR user and don't know if that is common

borkdude14:04:52

• Use you can use static except glibc maybe by default to circumvent the zlib issue

dharrigan14:04:33

I don't know if that would be a good choice for AUR, as it would require quite a bit of scaffolding and compilation for the end-user.

borkdude14:04:52

it would not be very user friendly to have to compile a graalvm binary locally

ericdallo15:04:27

Yeah, nix does like that but quite transparent

ericdallo15:04:02

> • Use you can use static except glibc maybe by default to circumvent the zlib issue Using musl would'nt fix that?

borkdude15:04:31

it would fix that but musl doesn't work for every OS or arch

borkdude15:04:51

so defaulting to static without glibc for others is the best you can do there

borkdude15:04:07

others = aarch64 and Windows

ericdallo15:04:09

How can we do that? I suspect we already do

ericdallo15:04:33

How bb does that?

borkdude15:04:39

Use:

-H:+StaticExecutableWithDynamicLibC 

borkdude15:04:47

bb only uses that for aarch

ericdallo15:04:51

Yeah, let me check, I think we already do that

borkdude15:04:30

Aha. Then it is surprising why @U0178V2SLAY had this problem still

lassemaatta15:04:49

I always have surprising problems 🙂

😂 1
borkdude15:04:57

When is "$CLOJURE_LSP_STATIC" enabled?

ericdallo15:04:08

When we compile the static on CI

borkdude15:04:19

And who uses the static?

ericdallo15:04:28

Good question

ericdallo15:04:45

Personally on nix the static works for me

ericdallo15:04:56

Maybe @U11EL3P9U can confirm this on AUR

borkdude15:04:12

yeah, it's safer to default to static where you can

ericdallo15:04:38

Yeah, but I didn't know musl static didn't work everywhere

ericdallo15:04:56

My idea was to always compile the static with the musl option

ericdallo15:04:37

Or for existing static users the musl should work as well?

borkdude15:04:38

The above problem should be already solved if the AUR was using the static binary

☝️ 1
dharrigan08:04:41

I've pushed an update to AUR which favours the static version of clojure-lsp over the native (dynamic) version. Let's see how it goes.

lassemaatta09:04:44

Seems to be working great 👍 I upgraded both clojure-lsp and zlib (to revert the downgrade I made yesterday), cleared the global lsp cache and opened my project -> the source zip was extracted and analyzed ok

ericdallo14:04:59

Great, thank you @U11EL3P9U!

dharrigan14:04:39

No problemo 🙂

borkdude11:04:50

Is anyone using clojure-lsp with Sublime Text?

flowthing12:04:52

I don’t use clojure-lsp at the moment, but if there's something I can help with (testing, documentation, etc), let me know.

ericdallo14:04:03

Yeah, it should work, but docs are pretty outdated

borkdude11:04:21

It seems the docs are still based on the .jar file: https://lsp.sublimetext.io/language_servers/#clojure

pesterhazy17:04:25

Howdy! I'm using clojure-lsp with lsp-mode in Emacs in a relatively simple CLJS project but I can't get most of the refactorings to work (clojure-lsp 2022.03.31-20.00.20, clj-kondo 2022.03.10-SNAPSHOT)

pesterhazy17:04:23

What's working: • find references • jump to definition • helm-lsp-code-actions, "Extract function" • remame symbol

pesterhazy17:04:41

But other refactorings don't appear to do anything (I don't see an error message either) • I select [1 2 3] and then helm-lsp-code-actions, "Change coll to set" — no effect • I move my cursor on an expression, then helm-lsp-code-actions, "Move to let" — no effect

pesterhazy17:04:47

In particular the "change coll" refactoring is so simple that I'm wondering if I'm doing something wrong (I've tried these now and then in the last few years and it never worked reliably for me)

pesterhazy17:04:02

lsp-mode-20220315.1736, clojure-mode-20220307.1903 and helm-lsp-20210419.2014 if that helps

ericdallo17:04:28

Do you have a sample repro?

ericdallo17:04:45

Also, could you check server logs for any exception or useful log

pesterhazy19:04:50

I tried to find the log file, but there was no /tmp/clojure-lsp.<TIMESTAMP>.out. However, when configuring the path manually (`{:log-path "/tmp/clojure-lsp.out"}`) the logfile appeared

pesterhazy19:04:32

When I run Convert coll to set, this is what I get 2022-04-02T19:36:38.419Z INFO [clojure-lsp.handlers:385] - :code-actions 2ms 2022-04-02T19:36:40.157Z INFO [clojure-lsp.handlers:338] - :execute-command 2ms 2022-04-02T19:36:40.697Z INFO [clojure-lsp.handlers:237] - :document-highlight 0ms 2022-04-02T19:36:40.699Z INFO [clojure-lsp.handlers:385] - :code-actions 2ms

pesterhazy19:04:16

If it helps, this is the project and line: https://github.com/pesterhazy/shadow-jest/blob/exp/src/main/tdd/infra/cmdline.cljs#L11 (the branch is exp) As an example I'm trying to convert ["x" "x"] into a list

pesterhazy19:04:05

Let me try Calva to see if it works there

ericdallo19:04:53

I will try that project

pesterhazy19:04:33

It seems to work in Calva

pesterhazy19:04:17

All the following seem to be working: convert coll to set, move to let, unwind thread

pesterhazy19:04:45

None of them work on my lsp-mode install though

ericdallo19:04:11

it works for me on lsp-mode :thinking_face:

ericdallo20:04:36

@U06F82LES, I think we need to debug what the client (lsp-mode) is sending to clojure-lsp, could you try get the <https://clojure-lsp.io/troubleshooting/#client-server-log%7Cclient&lt;-&gt;server> log of that executeComand that is sent to clojure-lsp?

ericdallo20:04:35

mine looks like this:

[Trace - 05:01:06 PM] Sending request 'workspace/executeCommand - (87232)'.
Params: {
  "command": "change-coll",
  "arguments": [
    "file:///tmp/clojure-lsp/shadow-jest/src/main/tdd/infra/cmdline.cljs",
    10,
    45,
    "list"
  ]
}


[Trace - 05:01:06 PM] Received response 'workspace/executeCommand - (87232)' in 0ms.
Result: 0

pesterhazy20:04:45

Ok let me try

pesterhazy20:04:31

Ok there's a lot there but I'm picking out the workspace/executeCommand entry

[Trace - 10:10:58 PM] Sending request 'workspace/executeCommand - (87)'.
Params: {
  "command": "change-coll",
  "arguments": [
    "file:///Users/user/pitch/shadow-jest/src/main/tdd/infra/cmdline.cljs",
    10,
    53,
    "set"
  ]
}


[Trace - 10:10:58 PM] Received response 'workspace/executeCommand - (87)' in 7ms.
Result: 0

ericdallo20:04:22

that 53 looks wrong :thinking_face:

pesterhazy20:04:01

I moved the cursor to the beginning of the coll, then I get the same as yours

[Trace - 10:13:54 PM] Sending request 'workspace/executeCommand - (132)'.
Params: {
  "command": "change-coll",
  "arguments": [
    "file:///Users/user/pitch/shadow-jest/src/main/tdd/infra/cmdline.cljs",
    10,
    45,
    "list"
  ]
}


[Trace - 10:13:54 PM] Received response 'workspace/executeCommand - (132)' in 10ms.
Result: 0

ericdallo20:04:07

it seems it's passing the ) position, not the ( one?

ericdallo20:04:15

ah, I see, so it seems the same

pesterhazy20:04:26

yeah, but it doesn't change anything in the editor

ericdallo20:04:28

quite odd.. server is behaving peroperly

ericdallo20:04:34

maybe some lsp-mode bug?

ericdallo20:04:48

maybe try master from melpa unstable?

ericdallo20:04:54

(that's what I use)

pesterhazy20:04:08

I just deleted my elpa folder to get the latest release

pesterhazy20:04:25

that didn't seem to fix it (maybe that's not master though?)

ericdallo20:04:20

not sure how you configure your emacs, do you use doom/spaceemacs or vanilla?

ericdallo20:04:48

Hum, I don't think that is the peroper way, not sure

ericdallo20:04:52

but try follow this:

pesterhazy20:04:08

it's vanilla emacs but I'm using evil-mode and a bunch of other packages to make it feel like spacemacs

ericdallo20:04:12

that should not be a problem

ericdallo20:04:59

oh, wait a sec, this command is async, you should seek what clojure-lsp returns

ericdallo20:04:29

it sends a workspace/applyEdit

ericdallo20:04:54

mine:

[Trace - 05:20:21 PM] Received request 'workspace/applyEdit - (6).
Params: {
  "edit": {
    "documentChanges": [
      {
        "textDocument": {
          "version": 16,
          "uri": "file:///tmp/clojure-lsp/shadow-jest/src/main/tdd/infra/cmdline.cljs"
        },
        "edits": [
          {
            "range": {
              "start": {
                "line": 10,
                "character": 45
              },
              "end": {
                "line": 10,
                "character": 54
              }
            },
            "newText": "[\"x\" \"x\"]"
          }
        ]
      }
    ]
  }
}


[Trace - 05:20:21 PM] Sending response 'workspace/applyEdit - (6)'. Processing request took 32ms
Params: {
  "jsonrpc": "2.0",
  "id": "6",
  "result": {
    "applied": true
  }
}

pesterhazy20:04:24

I don't have any of those

pesterhazy20:04:38

only workspace/executeCommand, never workspace/applyEdit

ericdallo20:04:56

so clojure-lsp maybe didn't send it for some reason

pesterhazy20:04:59

so that seems like it could be the problem—it never sends workspace/applyEdit

pesterhazy20:04:23

is that clojure-lsp's responsibility or lsp-mode's?

ericdallo20:04:29

could you check your emacs buffer *clojure-lsp::stderr* ?

ericdallo20:04:36

clojure-lsp to send that

pesterhazy20:04:00

Apr 02, 2022 10:21:08 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 2
Apr 02, 2022 10:21:08 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 6

ericdallo20:04:38

could you paste your M-x lsp-clojure-server-info ?

pesterhazy20:04:18

sorry I'm stupid but I don't know how to focus that little window ("minibuffer"?) and if I click on it to copy and paste, it disappears

ericdallo20:04:29

just click it :)

ericdallo20:04:44

try switch to the *messages* buffer

pesterhazy20:04:02

weird I had to click 2x

ericdallo20:04:26

Looks correct, damm

ericdallo20:04:22

so, the issue seems that clojure-lsp is not sending workspace/applyEdit at all, that's why multiple features are not working

ericdallo20:04:51

could you try a non native-image graalvm compiled binary? just download the clojure-lsp one from https://github.com/clojure-lsp/clojure-lsp/releases

ericdallo20:04:22

then on your emacs set like this:

(setq lsp-clojure-custom-server-command '("bash" "-c" "/path/to/clojure-lsp"))

pesterhazy20:04:00

btw when I try the "extract function" action that does work, and it does generate workspace/applyEdit

pesterhazy20:04:15

will try the non-graal binary now

ericdallo20:04:29

really weird indeed

pesterhazy20:04:24

Exception in thread "main" java.lang.UnsupportedClassVersionError: clojure_lsp/feature/test_tree/TestTreeParams has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

pesterhazy20:04:34

haha finally something that doesn't work with my ancient java8

ericdallo20:04:16

I think that binary actually should be compiled with jdk11, something to fix

ericdallo20:04:37

well, you could try download clojure-lsp repo and make , it should create a clojure-lsp at the project root

pesterhazy20:04:03

I'll just upgrade java I think

ericdallo20:04:32

sounds good :)

pesterhazy20:04:36

ok that works now with java 18 (went up 10 versions today - you can tell I'm conservative)

😂 1
pesterhazy20:04:41

is this expected?

~/Downloads/clojure-lsp
WARNING: abs already refers to: #'clojure.core/abs in namespace: medley.core, being replaced by: #'medley.core/abs

pesterhazy20:04:12

probably related to clojure 1.11's new clojure.core/abs?

ericdallo20:04:42

good, now you just need to make emacs use that clojure-lsp

pesterhazy20:04:38

omg that worked

pesterhazy20:04:13

moved the binary to /usr/local/bin, uninstalled the native binary just to be sure

ericdallo20:04:20

you mean the cycle-coll code action worked?

ericdallo20:04:37

good, so it's a graal issue :thinking_face:

ericdallo20:04:44

odd there is no exception anywhere

ericdallo20:04:21

Please open a issue with those details so we can investigate it later, it doesn't seems that easy to fix/find the root issue

ericdallo20:04:30

we only know it only doesn´t work on graal images

pesterhazy20:04:13

hm! it only worked the first time. If I try again, it fails

pesterhazy20:04:56

I can change it into a set, but not back to a vector. wtf?

ericdallo20:04:19

even with the graal one? maybe try other code actions that were not working before

pesterhazy20:04:47

well ok, so if I lsp-workspace-restart, then I get one workingg refactoring again - after that it stops working

ericdallo20:04:14

that doesn't make much sense, are you sure your are using the download non graal binary right?

pesterhazy20:04:44

I just tried again with the graal binary, that doesn't work at all (even the first time)

ericdallo20:04:39

pretty weird, could you check if with the non graal one clojure-lsp just send the first workspace/applyEdit?

pesterhazy20:04:33

ok I'm back to non-graal now

pesterhazy20:04:49

yeah so first time I get workspace/applyEdit (-> works), second time no such message (-> fails)

pesterhazy20:04:57

(just to be sure, I don't need to save the buffer between code actions, right?)

ericdallo20:04:07

you don't need

pesterhazy20:04:15

right that's what I thought

ericdallo20:04:40

yeah, that's a new weird issue I never saw 😅 , it could be a new behavior from recent releases, could you try a older release?

ericdallo20:04:09

maybe try the release from feb and from jan

pesterhazy21:04:01

I can see similar behavior with unwind-thread-all - it works but then stops working

pesterhazy21:04:45

lsp-workspace-restart then makes it work again

pesterhazy21:04:50

OK I tried a January release (non-graal) and that doesn't show the problem https://github.com/clojure-lsp/clojure-lsp/releases/tag/2022.01.22-01.31.09

pesterhazy21:04:29

let me bisect releases...

ericdallo21:04:39

yeah, that would help a lot

pesterhazy21:04:45

FWIW download size went down from 32.9M (GOOD) to 26.2M (BAD)

ericdallo21:04:16

Maybe related: > • Bump Graalvm from 21.3.0 to 22.0.0.2 improving binary performance/size >

ericdallo21:04:43

need to be AFK for some time, but feel free to open a issue or try bisecting those commits (I know it's annoying :/)

pesterhazy21:04:42

well, given that I'm using the non-graal version in both cases, the problem shouldn't be related to graal right?

ericdallo21:04:01

yes, makes sense

ericdallo21:04:16

Probably one of the commits in that release introduced that behavior

pesterhazy21:04:54

@UKFSJSM38 created an issue and tried my best to find a minimal repro https://github.com/clojure-lsp/clojure-lsp/issues/903

pesterhazy21:04:13

interestingly with the January release, even the graal binary works perfectly

pesterhazy21:04:04

Let me know if you need any additional info (or if you want me to bisect more granularly)

pesterhazy21:04:19

As always, thanks for the great work on clojure-lsp!

ericdallo21:04:27

Thank you!! I'll take a look and try to find a commit that could probably introduced the issue