Fork me on GitHub
#calva
<
2019-04-02
>
pez04:04:13

@lspector , sure you don't have an error in the file?

pez07:04:05

If you don’t want the files to be evaluated on save, disable that in settings.

lspector13:04:18

Yes! There was an error in the file (which I was also using to test error output). Now I see that it is indeed re-evaluating... which I don't want. I have found and turned off the "Calva: Eval on Save" setting, but it's still re-evaluating on save, including after quitting/restarting VSCode and the REPL

pez13:04:16

Very strange. For me it immediately stops evaluating on save when I untick that option… No restart needed.

lspector13:04:17

My file is just:

(ns calvatest.core)

(def c 25)

c
And the "Calva: Eval on Save" setting is unchecked. Whenever I change the value and save, the new value appears in Calva says.

lspector13:04:54

FYI I'm often working with long-running expressions (hours at 100+% cpu), so it's not great if evaluations happen automatically or on save.

pez13:04:15

No, that’s what the settings is there for. Never heard of it not working though…

pez13:04:32

I hide stuff I don’t want to “run” when loading the file inside (comment) forms. Calva has special top-level semantics for those and evaluating forms inside them is really easy.

pez13:04:29

But why that setting would fail for you, puzzles me.

lspector13:04:15

I've used and like the (comment) approach in some cases, but for using a file and Calva says as a REPL/worksheet you don't want to have to type that for every command (or get re-running of everything if you save).

pez13:04:24

No, just mentioning. The top-level support for comments is something most people don’t know about.

lspector13:04:47

Is there some other setting or approach you can think of to turning off the auto-eval setting?

lspector13:04:42

Or some way to say "Save, really just save"? I'd rather not run tests or do anything else either, just save.

pez14:04:57

Does the run-tests-on-save setting work for you.

pez14:04:50

VS Code does have a “Save w/o formatting” setting, but it will eval on save anyway. I just tested it.

pez14:04:42

Really, switching that setting off should just stop it from evaluating on save. I wonder what is going on….

lspector14:04:20

Tests (of which I have none) appear to run on save:

Running namespace tests…

No tests found. 😱, ns: 0, vars: 0

pez14:04:42

There is a setting for that too. Tried it?

pez14:04:35

I wonder if maybe you have workspace settings overriding your user settings. Or vice versa, I am not sure which has precedence.

lilactown14:04:29

what version of calva are you using

lspector14:04:28

I see settings for running tests, but not on save. Where are separate settings? I'm changing things in Code > Preferences > Settings, in Code 1.32.3 under MacOS 10.14.3.

pez14:04:03

So if you search for calva save in settings?

lspector14:04:15

huh now i do see that setting... was trying to search differently. switched...

lspector14:04:14

exciting news!

lspector14:04:18

If I also turn off "Calva: Test on Save" then it stops either evaluating or running tests on save

lspector14:04:46

So now saving just saves, which is what I want. FWIW I think that'd be a nice default 🙂

lspector14:04:07

Thanks so much!

pez14:04:20

Ah, now I know what was going on.

pez14:04:05

I’ll change the defaults for those on next major release, @lspector. I agree they can cause trouble. I’ll think of some way for Calva to try teach people new to Clojure about the need for evaluating things before other things start working.

lspector14:04:36

Awesome -- thanks!

lspector14:04:59

FYI I'm often teaching people entirely new to programming (not just clojure), and would be more than happy to give feedback on additions/docs on this. FWIW I'm bringing my own gaps and confusions to the table too, not from being new to Clojure but from coding in research/academic/science/art settings mostly rather than traditional software development

pez15:04:51

That would be tremendously helpful, @lspector. We are preparing a new release with dependency injection and a much better REPL window experience. A rewrite on much of the README and Getting Started stuff will be needed and input on how those work for newcomers would help a lot.

👍 4
lspector15:04:25

Will the REPL window be different both from Calva says and from the terminal REPL? It'd be great to have one place that's perfect, but the proliferation is already a bit confusing

lspector15:04:46

And maybe I shouldn't get too deep in documenting how to work with Calva says...

pez15:04:05

I think there will be a “Calva eval results” where those will go. In the first version that will probably still be a plain output channel, but it will later move to a window supporting pretty printing and syntax highlighting.

lspector16:04:23

Will there be a single place where evaluated results and printed output and error messages go? My need is for one such place. It should be plain text that can be copied/pasted. Ideally it should include nothing extraneous like echoed source code or "=>" markers. It's good if it scrolls so that the most recent stuff shows. Pretty printing is nice if it's optional (one can just call a standard function for this, right?) but not otherwise. More or less the same for syntax highlighting (usually it would be a minus)

pez18:04:08

Pretty much like that. But syntax highlighted, of course.

lspector18:04:51

Syntax highlighting on values, printed results, and error messages? Most of that usually won't be code.

pez18:04:43

On results.

pez18:04:42

Printed output and errors do not get syntax highlight.

lspector18:04:33

Would it be possible to turn off syntax highlighting?

pez18:04:06

No. I try to keep the settings to a minimum. Evaluated results are always clojure data, so it makes sense to syntax highlight it.

lspector18:04:10

Hmmm I'd hope that default behavior would be the simplest, plain text output...

lspector18:04:45

Or if not default, that it'd be easy to get this. I guess if I cut and paste into a plain text editor, though, I could recover the plain text?

pez18:04:15

It'll be plain text. So, yes.

lspector18:04:22

That's good. Probably not a big deal either way then. But out of curiosity, if the output contains the list (map foo bar) is map going to be highlighted as a function?

lspector18:04:15

Also, this will all not be in "Calva says"? That means there'll be 3 sets of commands for evaluating things, with some sending things to the terminal REPL, some sending things to "Calva says" and also showing them inline in the editor, and the third sending things to the new REPL window?

lspector18:04:07

To be clear, my interest is (maybe only) in having one, which shows return values, printed values, and error messages, in as unadulterated a way as possible.

pez18:04:29

Not exactly like that. This will be a window replacing the Calva says.

lspector18:04:43

Ah -- good to be back down to 2 🙂

pez18:04:08

You have the option to use just one. 😃

pez19:04:03

In essence the new window will be like the REPL window, just without the input prompt. So it will be just output.

lspector19:04:12

FYI was just looking at a student's machine, running Windows (I use Mac), and it looked like his Calva commands were slightly different? It wasn't clear to me which would go to the terminal REPL vs. "Calva says"

pez19:04:32

All commands sending stuff to the terminal are named like that. And often with the same default shortcuts as their inline counterparts, only with alt-key added to the final chord.

pez19:04:28

So, to evaluate the top level command inline it is ctrl+alt+v space and to send the current top level command to the terminal it is ctrl+at+v alt+space.

pez19:04:55

He might have changed the shortcuts, but I don’t think he can alter the name of the commands.

lspector19:04:27

I'm more likely to pull up the command palette and choose the command thatn to remember the chord, which is probably true of my students too. It might be nice if the actual command names could be more about the terminal vs. other option, I guess

lspector19:04:59

I might have been confused about his list of commands because it reorders based on usage, so mine is showing up in different order

pez19:04:01

I don’t know how they could be more about that than they are.

pez19:04:52

Yeah, that could be why. Type calva term in the palette and all terminal commands will be filtered out.

pez19:04:04

Using the keyboard shortcuts is entirely voluntary. I have just tried to make it easy to know the terminal shortcut if you know the inline one.

lspector19:04:34

I guess anything that doesn't explicitly say "in terminal REPL" is implicitly "in Calva says (or REPL window that replaces it) and maybe inline"... Is that right?

pez19:04:57

Yeah, that’s right. The terminal was added later so it got special names. 😃

pez19:04:24

The inline ones are mostly named just Evaluate.

lspector19:04:04

Good to know! FWIW that won't be so obvious to newcomers

lspector19:04:45

Maybe nice if there was just one option (the one I like 🙂), or if the naming was more explicit both ways

pez19:04:53

I don’t really see them as equivalent. The Terminal commands are there to make it easy to experiment with them at the prompt. I’ll have a think about the naming.

lspector19:04:13

I think of them as two superficially different ways to accomplish the same thing: try some code and see what it does

lspector19:04:09

So from my perspective it's a bit confusing that there's more than one, that they behave differently, and that neither quite shows me everything in the most simple way

lspector20:04:06

A little extra confusing when it's not super clear which commands and/or setup steps are required for one vs. the other.

lspector20:04:54

Whether code to be evaluated is typed/pasted at a prompt or in an editor seems like a minor difference, but in any case I'm interested in having all results and printed outputs and error messages go to the same plain text (and select/copyable) place, unadulterated (so without any annotations, and if someone wants it pretty-printed they could use clojure.pprint/pprint)

pez20:04:21

I mostly work in the files. But others like to do their experiments more often at the prompt. So Calva supports both.

lspector20:04:23

I see supporting both is good! But clarity between them is good too, and getting all and only results/printed-stuff/errors to show up in a plain text place is key for me.

pez20:04:47

I hear you about the getting all results and stuff in one file. It will be syntax highlighted, that’s the only thing you won’t get rid of. 😃

lspector20:04:36

I'll live 🙂

lspector21:04:48

I want to share a concrete example. With this code in a file:

(ns calvatest.core)

(defn foo [x]
  (println x))

(foo 13)

(foo 17)
If evaluate all of the expressions individually with "Evaluate selection or current form" then this ends up in "Calva says":
=> nil
=> #'calvatest.core/foo
out: 13
=> nil
out: 17
=> nil
In addition, the return values (only, without the printed values) appear inline in the editor. On the other hand, "Evaluate current file" puts only the following in "Calva says":
=> nil
On the third hand, selecting all and using the "Evaluate selection or current form" puts the following in "Calva says":
out: 13

17
=> nil
Plus, the last "=> nil" appears inline in the editor. This last one is particularly puzzling for a couple of reasons. But I want to jump to what I hope to be able to get, via one method or another. What I'd like to see is either:
nil
#'calvatest.core/foo
13
nil
17
nil
Or:
13
17
nil
That is, I want to see all explicitly printed text (unadulterated), and either all return values or just the last one. I've seen different approaches to the question of printing all or only the last value, and I think either could be fine. But I wouldn't want anything else in there (like => or out:).

lspector21:04:49

(Plus there should be error messages if one introduces errors.)

pez21:04:24

The first one will be a bit like what will happen in the case of selecting all and evaluating it. The loading of a file is an nREPL op that behaves like it behaves so it will just print the last evaluated result (which I think is awesome for that op to do).

pez21:04:13

FYI. This will take a while before it gets fixed though. We have a demanding backlog to wade through first.