This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-31
Channels
- # announcements (16)
- # beginners (52)
- # calva (44)
- # cider (82)
- # clojure (21)
- # clojure-greece (1)
- # clojure-losangeles (1)
- # clojure-spec (8)
- # clojure-uk (3)
- # clojurescript (55)
- # community-development (26)
- # cursive (18)
- # datomic (7)
- # editors (6)
- # events (1)
- # fulcro (19)
- # kaocha (1)
- # klipse (1)
- # off-topic (13)
- # re-frame (1)
- # ring-swagger (2)
- # spacemacs (2)
- # vim (15)
Is there a way to get around the echoing of all evaluated code in the repl? I'd like to see just the results of evaluation.
@pez suppose I have the following in my editor:
(defn foo
[x]
(println "Calling foo with" x)
(+ x 23))
(foo 5)
And I select it all and choose "Run selected text". Here's what currently shows up in the REPL:
clojush.core=> (defn foo
#_=> [x]
#_=> (println "Calling foo with" x)
#_=> (+ x 23))
#'clojush.core/foo
clojush.core=>
clojush.core=> (foo 5)
Calling foo with 5
28
clojush.core=>
Here's what I would prefer to show up in the REPL:
#'clojush.core/foo
Calling foo with 5
28
clojush.core=>
That is, we see only results and explicitly printed stuff, not the code that we evaluated.
This is the behavior that I'm familiar with from other environments, and the current behavior can be problematic especially with large amounts of code, because printed results and also error messages get lost in the flood of echoed source code.
FWIW some environments with which I'm familiar would print only the final result, along with explicitly printed stuff, so you'd end up with just:
Calling foo with 5
28
clojush.core=>
I think I don't have a strong opinion about whether to print all values or just the last, but the echoing of the source code gets in the way and I'd love to get rid of it.I see. Yeah, maybe that could be an option. In the current dev build there is a bug that makes it behave like that. Annoys me, actually. I like to be able to find what I have been evaluating. Maybe there should be a split of output, so that there’s a result output and a logging output.
I guess it wouldn't be a problem for the source code to be echoed somewhere else, as long as it doesn't clutter up the REPL. But really it seems redundant except for debugging the IDE itself, since the source code is already in the editor, where I can see it more easily.
As an example of why this is more than just a taste thing, I spent time with a student trying to debug some of her code, which she was running by selecting all and choosing "Run selected text". It took us a frustratingly long time to figure out that one of her definitions had an error, so later definitions were broken in confusing ways, etc. When the problematic definition was evaluated it produced an error message, but that was buried in hundreds of lines of echoed source code, which we didn't need to see and was particularly messy because of the #_=>
annotations. If only results and printed output was sent to the REPL then the error would have been immediately obvious, but instead I think it took us 15 minutes or so to figure out what was going on.
Relatedly: I had thought that one could use "Run Active File" as a shortcut to selecting all and doing "Run Selected Text", but when I try it I always just get an error like:
Syntax error compiling at (form-init16470894364661837604.clj:1:7884).
No such namespace: Users
I guess I maybe don't understand what this is supposed to do? In any event, "Run Selected Text" suffices, although it would be great to turn off the re-printing of the source code in the REPL.Evaluate current file will load the file and things it requires w/o echoing the whole file. And you should be able to see any errors preventing you from loading the entire file. (I think there is a bug in Calva there that often hides the error, but anyway.)
Also, looking at the description above I see that you are evaluating the selection in the Terminal REPL. There is no way to prevent the echoing there, unfortunately. But we are going to replace those with a whole new REPL window. That window is much better at reporting errors too, so should help in many ways that the current solution doesn’t.
As for the problem your student had. I can recommend evaluating one form at a time, starting at the top. The Calva command Evaluate current top level form - ctrl+alt+v space
- is your friend here. So move the cursor inside the top ns
form and evaluate it, then next form, and so on.
On the error from "Run Active File", the same code works fine when I select all and choose "Run Selected Text", so I don't know where I would be referring to a non-existent namespace. I seem to get the same error when I choose "Run Active File" no matter what is showing in the editor pane. I have a feeling that I don't understand what "active file" means.
Evaluate current file sounds like it may be what I want , but I don't see that anywhere. How does one invoke that? Ooo, maybe it isn't what I want anyway, because I can do Evaluate current top level form using the key sequence you provided (where are those found again? can't find them from poking around, but I know I've seen them before) I see that the results are shown inline in the editor, which is unworkable for a bunch of reasons including the fact that large values become unreadable. What my students and I really need for REPL-based development is a way to evaluate selections/files and have all of the values and printed output (including errors) go to a text output area (possibly the REPL, which is what happens in other environments I know, but any text output area would be fine). It seems like the closest we can get to this for now is sending things to the terminal REPL, and dealing with all of the echoed source code. Is that right?
The inline result display is accompanied with the results being sent to the Calva says output channel.
To see the Calva commands, and their shortcuts, open the command palette. cmd+shift+p
on a Mac.
Ah -- great. And now I see "View > Command Palette..." which is even better for my context since it doesn't require remembering the key combination. But where is the Calva says output channel?
Relatedly, if we're working in Clojurescript following the instructions at https://github.com/PEZ/quil-cljs-calva-template, will all of the "Evaluate" commands evaluate via the attached Clojurescript REPL (sending output to Calva says, once I can find that)?
Aha! First click the "output" tab in the pane that also contains the terminal, and then the popup on the pane changes (which I didn't expect), and then Calva says is an option!
If I have this in a file:
(defn foo
[x]
(println "Calling foo with" x)
(+ x 23))
(foo 5)
This is good. We are revealing a lot of unfounded assumptions. Thing is that Calva used to pop open the Calva says channel on startup.
and I do Evaluate current file, then I see => 28
in Calva says but not the output from println
.
Exactly. You’ll find that output in the terminal where you started the repl. We will fix that problem.
Huh -- I don't actually see the println
output anywhere. Not in Calva says, or in the VSCode terminal, or in the (MacOS) terminal window in which I started up the REPL.
And if I introduce an error into my code, I don't see an error message in any of those places either.
About “will all of the “Evaluate” commands evaluate via the attached Clojurescript REPL“. Yes, for cljs
files that is true. Stuff in clj
files will get evaluated towards the Clojure REPL. And things in cljc
files will be evaluated towards what you have chosen. There is a command for chosing this, and the indicator in the status bar can also be used.
> And if I introduce an error into my code, I don’t see an error message in any of those places either. Sounds like a bug. Please file it as an issue.
On the clj/cljs stuff, that all sounds great (and I assume it will make a little more sense to me once I start really trying to work with cljs more).
I filed an issue; I hope I did so correctly. FWIW this is unfortunately pretty debilitating. If we can't see error messages or even println
output then I don't think it's a viable way to develop code. I think it means we're back to the terminal REPL (and the echoed source code) until there's a fix.