Alright, since .117 contains some of the fixes in the repl-window-less build (in a better shape), here's a new one, that I see as a release candidate: https://7278-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.118-711-remove-old-repl-window-7177b7b8.vsix
With that vsix I'm finding the eval results usually disappear a fraction of a second after being displayed. This happened sometimes with earlier builds (I was trying to figure out a pattern before reporting it), but happens nearly every time now.
Generally, or in some context?
It seems to be nearly every time I eval any form after an edit.
(with a 2nd eval in the same spot, the output persists as expected)
Ah, and it's specific to 'eval top-level form'. Doesn't happen with 'eval current'
I've just reproduced this with a minimal deps.edn project (empty map, 1 source file), and using the vanilla 'Clojure CLI' connect sequence.
Does it matter if you use a shortcut, or which shortcut?
Good point. Just tried - invoking the command directly (ie via ctrl-shift-p menu) works as expected. The problem occurs with the default alt-enter. Probably something to do with the alt menu issue (which I wouldn't have considered as I turn the menu bar off, but I think alt still selects it). Have to go now, but I'll have a further dig a bit later.
Then this should be already an issue since .109
(which introduced the alt+enter
shortcut), right? If so I won't regard it as a stopper for this PR.
Yep that makes sense.
The inline display should be dismissed when the document is edited (a decision that could be questioned, but anyway). Can you see if the document is marked dirty when you use the shortcut?
@pez Great job! What gets in the way is the error reporting. Would it be possible to limit the error to just the description, it the first part ?
; Execution error (ArityException) at aws-http-core.fidlle/eval15719 (form-init4379729622409352072.clj:19).
; Wrong number of args (0) passed to: clojure.core/rand-int
[{:file "AFn.java" :line 429 :method "throwArity" :flags [:java]}
{:file "AFn.java" :line 28 :method "invoke" :flags [:java]}
{:file "form-init4379729622409352072.clj" :line 19 :fn "eval15719" :method "invokeStatic" :flags [:project :repl :clj]}
{:file "form-init4379729622409352072.clj" :line 19 :fn "eval15719" :method "invoke" :flags [:dup :project :repl :clj]}
{:file "Compiler.java" :line 7176 :method "eval" :flags [:tooling :java]}
{:file "Compiler.java" :line 7166 :method "eval" :flags [:dup :tooling :java]}
{:file "Compiler.java" :line 7131 :method "eval" :flags [:dup :tooling :java]}
{:file "jar:file:/Users/denis/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar!/clojure/core.clj:3214" :fn "eval" :method "invokeStatic" :flags [:clj]}
{:file "jar:file:/Users/denis/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar!/clojure/core.clj:3210" :fn "eval" :method "invoke" :flags [:clj]}
.. etc
I'd love to see only
; Execution error (ArityException) at aws-http-core.fidlle/eval15719 (form-init4379729622409352072.clj:19).
; Wrong number of args (0) passed to: clojure.core/rand-int
File an issue about it. There might be a way, but it will probably be a fair amount of work.
actually in the Repl window you had this option to show only the Clojure error, which is great )
Yes, the REPL window had some advantages, for sure. π
But if we can solve so that you can bring forward the stacktrace at will, we can probably do some filtering on it as well. Mention that filtering thing in the issue.
Dear Calva friends. I have just released v2.0.118
, which gets rid of 2 kloc (and with them the old REPL window). With your help, we've tested it as best as we can, and removed some bugs. Hopefully there are not many/any left that could have to do with the removal. Please help me be on the alert to fix any issues this release creates. Thanks! π β€οΈ
So, it seems things work differently in clj and cljs.
cljs::cljs.user=>
1
1
cljs::cljs.user=>
2
2
cljs::cljs.user=>
3
3
cljs::cljs.user=>
[*3 *2 *1]
[1 2 3]
cljs::cljs.user=>
I just released .119 which should fix this reliably for both cljs and clj sessions. Please test and confirm, peeps!
Awesome! Will test
I don't have a cljs project for testing right now, but clj works fine! Thank you, @pez! β€οΈ I'll check cljs on the weekend and let you know if something is wrong.
Iβm curious, is there a write-up somewhere about why the old REPL is gone and why the new output-file-driven approach is better?
@pez I love the new experience, this has been wonderful βΒ thank your maintaining such a great project!
Lovely that you tell us! Please consider writing a review. π
I will write one! Cheers
This is what you're looking for: https://clojureverse.org/t/calva-summer-of-bugs-2020/6303
Thank you! π:skin-tone-2:
I think I've found something - it seems to be an interaction with auto-save. I normally have that turned on, but with it switched off (which I just did temporarily to control file dirtiness), the shortcut behaves properly.
This also explains why the problem didn't always occur for me. I had auto save on after a 1s delay. If the eval is done before the 1s is up, the eval results are dismissed. If after, they remain.
This means the problem is easily worked around by switching auto-save to occur on switch editor/window focus rather than after delay.
No idea why this only happens with alt
-based shortcuts. But anyway it's a further clue.
Seems like accessing recent results is broken again.
File as an issue please. We will need to figure this out once and for all.
It works in a previous version .117. Maybe we just need to reopen https://github.com/BetterThanTomorrow/calva/issues/724?
Thinking about this further - unless there's an obvious & riskless fix I don't think you even need to address this. Auto-save after a delay is generally a bad idea, made unnecessary in any case by vscode's hot exit. Perhaps add a note somewhere to docs that you can refer anyone else to who has this issue.
The workaround is just to switch auto-save to onWindowChange
or onFocusChange