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

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

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

I disabled all git extensions except for edamagit

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

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

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

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

Is it a huge edn structure being printed?

yes

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.

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

actually, it recovered now

but took a while

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

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

"calva.prettyPrintingOptions": {
        "printEngine": "pprint",
        "enabled": false,
        "width": 1,
        "maxLength": 1
    },

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

it's 20 seconds now

Try with "maxDepth": 1

You can leave width at 100 or something.

ok, second run took 32 seconds

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

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

yes

Wait: "enabled": false

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

ok, so without it, it is bad

I will activate it

I think the issue might be in another place

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

so I did not manage to jack in or anything

now I get:

clj꞉dre.importers.epar-medicine.core꞉> 
(# ...)

this seems to work ok:

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

thanks for helping me out with this

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

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

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.

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.

@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

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

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?

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

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?

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

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.

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

@U011NGC5FFY Any updates on your issue?

on my side this was caused by a plugin (that I had for a loong time). it worked great but some vscode update or plugin update caused the issues. The issues where related to large data structures being parsed by vscode for syntax highlight / analysys

Was this a VS Code extension or a lein plugin, or something else?

vocoder extension