This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (7)
- # aws (6)
- # babashka (7)
- # beginners (200)
- # calva (49)
- # chlorine-clover (3)
- # cider (24)
- # clj-kondo (115)
- # cljs-dev (5)
- # cljsrn (16)
- # clojure (44)
- # clojure-australia (9)
- # clojure-czech (1)
- # clojure-dev (1)
- # clojure-europe (63)
- # clojure-france (6)
- # clojure-losangeles (1)
- # clojure-nl (2)
- # clojure-spec (27)
- # clojure-uk (77)
- # clojurescript (44)
- # clojurewerkz (3)
- # conjure (5)
- # cryogen (1)
- # cursive (2)
- # datahike (6)
- # datascript (3)
- # datomic (18)
- # fulcro (5)
- # graalvm (55)
- # jobs (3)
- # luminus (4)
- # malli (1)
- # pathom (1)
- # reagent (16)
- # shadow-cljs (67)
- # spacemacs (18)
- # sql (57)
- # testing (6)
- # tools-deps (9)
I tried it, but it doesn't seem to stop the deluge of stuff being written onto the output buffer 😆
Hmm, I think that command may not solve all situations like that. Feel free to create an issue for your situation with repro steps
If it's not completely frozen you can try killing the repl at the terminal. If that doesn't work you can try the "Developer: Reload Window" command to make restarting it easier at least
So, the output window queues up prints and because reasons prints them quite slowly. So it can keep printing for quite long after you have interrupted a command… Maybe there is something we could do about it….
I imagine the printing is throttled so that it doesn't interfere with the responsiveness of the rest of the app. If this were implemented with core async (it probably isn't 😆 ) simply closing the channel should cancel the rest of the queue.
This is TypeScript and promises. 😃 Would be nice to just close a channel. Maybe we can achieve that somehow…
The printing isn't intentionally throttled, it's just that the
applyEdit function of the vs code api is async and a bit slow, and if we don't ensure one prints before the previous, we get issues.
It seems you've put in quite a bit of hammock time on this! Would I be correct in my understanding that repro steps are no longer necessary?
If you wouldn't mind creating an issue about the printing after interruption, that would be great so we can track it for later, and remember who brought it up, in case we can't repro or would like some info/help.
No problem! I'm in no hurry. I'll make the issue, and try to summarize what you've said here.
Here it is! https://github.com/BetterThanTomorrow/calva/issues/978 Please correct me if I made a mistake anywhere
not sure what I broke but I can't send anything to the calva repl; tried all the tricks, downgrade, delete caches, restart...
> console.ts:137 [Extension Host] Unhandled error: e.trim is not a function That pops when I type enter in the repl after a form
> console.ts:137 [Extension Host] (node:11997) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. Can't tell if it's calva where this originates
Buffer stuff is from Calva, by elimination. Disable calva -> no Buffer err Enable calva -> Buffer err
It has been there since forever anyway. 😃 I probably have some other extension that causes it, because disabling Calva does not get rid of it for me. In any case it is probably not what is causing you problems.
Calva works when I disable ego-digital.vscode-powertools extension. These 2 don't get along - they were this morning.
same on 2.0.151; very strange; I'll try to replace powertools with something; most likely make my own extension calva-extras instead these scripts.
Calva version 2.0.152 is released with the following changes 🎉 • Fix: https://github.com/BetterThanTomorrow/calva/issues/959 • https://github.com/BetterThanTomorrow/calva/issues/931