Fork me on GitHub
#calva
<
2022-07-21
>
Eugen06:07:12

I'm seeing VSCode freezes with Calva . I'm on

code --version 
1.69.2
3b889b090b5ad5793f524b5d1d39fda662b96a2a
x64
anyone else seeing this ? I jack in, do some work ~5-10 min and then. Just downloaded lsp 2022.05.31-17.35.50 to see if it works.

Eugen07:07:17

some things I noticed: • I had some zombie git processes • Language support for Java ™ for Visual Studio Code was running wiht JDK 17 ?! - I disabled it. Using decompiler suport ?! • git highlight of changed lines was not workin in VSCode

Eugen08:07:12

still happens - I wonder if it's related to the app I am working on

Eugen08:07:30

it is related to git crashing and a zombie git process lingering

Eugen08:07:41

I disabled all git extensions except for edamagit

Eugen08:07:27

it also seems to be related to lots of output in output.calva.repl ?!

Eugen09:07:17

so it is related to lots of data spit at output.calva.repl . I have disabled all extensions except a few

Eugen09:07:16

cc @U0ETXRFEW - is this a known issue / something new ? a function that hanged was returning the app configuration - in edn format and the environment as a stuart siera component I think - which means lots of duplications => large body of text with sprinkled edn

Eugen09:07:51

yep, as soon as I evaluate that function, VSCode / Calva goes to 100% CPU and stays there for some time. In the meantime I can't edit file, can't open lsp menu, can't evaluate other forms

pez09:07:02

Is it a huge edn structure being printed?

pez12:07:24

Then I think that's the problem. Calva is stuck either building or navigating the AST. You could confirm by fiddling with the max depth/length pretty print settings and see what difference that makes.

Eugen12:07:19

cut one 0 from length and depth - to 120 -> 12 and 50 -> 5 . Still the same

Eugen12:07:38

actually, it recovered now

Eugen12:07:42

but took a while

Eugen12:07:53

took around 32 seconds with new values (restarted vscode aftetr change)

pez12:07:52

Is it 32 secs with depth =1 and length = 1?

Eugen12:07:09

"calva.prettyPrintingOptions": {
        "printEngine": "pprint",
        "enabled": false,
        "width": 1,
        "maxLength": 1
    },
trying now the above

pez12:07:52

Width is the print with in characters and shouldn't have any significance for this problem.

Eugen12:07:07

it's 20 seconds now

pez12:07:47

Try with "maxDepth": 1

pez12:07:14

You can leave width at 100 or something.

Eugen12:07:27

ok, second run took 32 seconds

Eugen12:07:54

so I evaluated this code twice:

(let [epar-pdfs (java.io.File. "local-var/EPAR-doc-congress/EPAR_db.json")
        medicines (j/read-value epar-pdfs mapper)]
    (take 3 medicines))
took 20s and then ~32s

pez12:07:15

Maybe the pretty print settings aren't working. Is it still printing a huge strycture?

pez12:07:56

Wait: "enabled": false

pez12:07:26

Pretty printing needs to be enabled for any other setting to take effect.

Eugen12:07:43

ok, so without it, it is bad

Eugen12:07:48

I will activate it

Eugen12:07:17

I think the issue might be in another place

Eugen12:07:02

I just started VSCode with output window open (was open when I closed) and it's having the same behavior

Eugen12:07:19

so I did not manage to jack in or anything

Eugen12:07:39

now I get:

clj꞉dre.importers.epar-medicine.core꞉> 
(# ...)
and it works fast

Eugen12:07:42

this seems to work ok:

"calva.prettyPrintingOptions": {
        "printEngine": "pprint",
        "enabled": true,
        "width": 100,
        "maxLength": 50,
        "maxDepth": 10
    },

Eugen12:07:53

thanks for helping me out with this

Eugen12:07:04

strange that: • with pretty print disabled, performance is bad (on my machine at least) • default value for max length is also causing performace I wonder if there are other people that have this issue

Eugen12:07:29

(I mean I would imagine if no pretty printing needs to be done, it should work faster - since no work)

pez12:07:00

In this case it is a limitation in Calva's AST building/management. It can't cope with huge structures. The pretty printer can help in keeping the structure at a size/depth that can be managed.

👍 1
pez12:07:03

I do think this sometimes bites people. Might be that we can do something like sanity check the structure size before we let Calva croak on it.

seancorfield17:07:35

@U0ETXRFEW What's the default here? I ask because this thread made me curious and when I edited the settings JSON and started typing calva.pretty.. it auto-completed with:

"printEngine": "pprint",
      "enabled": true,
      "width": 120,
      "maxLength": 50
(no maxDepth -- so I went ahead and added "maxDepth": 10) -- I often have very, very long output.calva-repl files since I run VS Code for many days between restarts and I see a lot of Syntax error.. as it tries to read/parse the output -- and I've often wondered if I can turn that off and what benefit it has for Calva to try to read/parse that output file?

seancorfield18:07:18

Somewhat to my surprise, enabling the pprint engine does not stop the Syntax error.. reports when output.calva-repl contains arbitrary text... I'll disconnect and reconnect and recreate the file to see if that works...

seancorfield18:07:49

Even restarting VS Code with pprint doesn't get rid of the syntax error with Calva trying to parse that arbitrary text output. I guess I'm not understanding what you said above @U0ETXRFEW?

pez22:07:15

@U04V70XH6 the default is what you get from auto-complete. We probably should have a default for maxWidth as well.

pez22:07:36

I don't understand what those Syntax error...s come from. Calva is not printing it when parsing the file. Calva's is not really doing a syntax check, it only cares about the structure. Where are those printed? Is there something more printed that might give a clue to where they come from?

pez22:07:04

The reason the output/repl window is parsed by Calva is that it is also an input window and Paredit needs the AST. (It's not really an AST, btw, but anyway, something similar.).

Eugen11:07:21

some feedback, I still had issues with hanging / cpu usage I disabled even more extensions - nearly out of hope 😞 . Thinking I should give emacs a chance to have a backup for situations like this - since it's affecting work. Not sure now if it's Calva or lsp or whatver. I hope I get to the bottom of this soon.

seancorfield16:07:17

@U0ETXRFEW The Syntax error turned out to be an extra ) in my custom REPL snippet. It was hard to diagnose because when I initially removed the last ) in the string, I got an error that tap> could not be resolved, and then other custom REPL snippets stopped working. After a few reloads and restarts and re-editing the settings, it all started working again. So it wasn't related to trying to parse anything -- it was just very confusing that the error referred to the blank line in the REPL! I guess that's where nREPL thinks the custom REPL snippet is being evaluated from...