This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-18
Channels
- # announcements (17)
- # babashka (42)
- # beginners (34)
- # calva (78)
- # cherry (1)
- # cider (7)
- # clojure (64)
- # clojure-europe (19)
- # clojure-nl (2)
- # clojure-norway (54)
- # clojure-uk (3)
- # clojurescript (21)
- # cloverage (1)
- # conjure (1)
- # core-async (11)
- # cryogen (16)
- # cursive (1)
- # data-oriented-programming (1)
- # datahike (5)
- # fulcro (2)
- # girouette (1)
- # helix (10)
- # hyperfiddle (1)
- # jobs (1)
- # kaocha (4)
- # nbb (7)
- # off-topic (6)
- # pathom (4)
- # polylith (21)
- # rdf (9)
- # releases (2)
- # shadow-cljs (3)
- # sql (12)
- # squint (68)
- # vim (33)
- # xtdb (29)
Is there some change to Calva and Clojure lsp? I have a babashka project that LSP is not starting on
We had a version of Calva, 290 I think, that failed to start clojure-lsp for people running earlier versions of VS Code. 291 fixes this by requiring the minimum VS Code needed. But if you are on an earlier VS Code then you won't be able to upgrade beyond 290.
Thanks @U0ETXRFEW - did that, all fine now
Manually starting it doesn't seem to start it and there are no messages either
Strange. Now I find an error
Seems to be a version mismatch. Requires a newer version of VS Code
All working again. Strange
If you are using Calva jack-in, it should present Leiningen as a project type option. But maybe I am misunderstanding the question. Can you describe the steps you take and what you expect to happen that doesn't happen?
Great that it works! However, I'm still not quite following what happened, and would like to understand better. Maybe we can improve some messaging/Ux/docs...
Probably not a Calva issue, but I started experiencing this a couple of days ago and wonder if anyone else is having the same issue. Apparently it's related to vscode's git extension. This is the procedure to reproduce the problem. 1. Run nrepl on some Clojure project that has a git repo. 2. Open the project in vscode. 3. Connect to nrepl. 4. Open any file that has uncommitted changes and is staged. 5. Run the "Calva: Load/evaluate current file" command. 6. Verify somehow that the uncommitted version of the file was evaluated. 7. Close the file. 8. Go to Source Control. 9. Click on the file to see the staged diffs. 10. In the top right corner there's an Open File button, click on it. 11. Run the "Calva: Load/evaluate current file" command. What happens is the committed version of the file gets loaded/evaluated instead of the uncommitted version. When I reload vscode, connect and evaluate the file, the uncommitted version gets evaluated correctly.
Can you test with this VSIX and confirm that I have fixed the issue, @U201ZTKHB? https://output.circle-artifacts.com/output/job/872986cf-0cd6-4386-8d37-3f9e13e420a8/artifacts/0/tmp/artifacts/calva-2.0.294-1833-fix-wrong-version-evaluated-4f57de80.vsix
Is the Notebooks stuff written up somewhere?
Thank you!
Just as a test, I opened a pretty large file at and played around with it -- looks very cool!
Thanks, @U04V70XH6! It's very rough in this first shape. But already pretty cool. I really like the direction @U02EMBDU2JU is taking it. When we get some rich result views, maybe even #portal views, in there, I think it will start to be super useful for many people's workflows.

Happy you guys like it 🥳 I’ve already got a bunch of improvements I’d like to add


@U02EMBDU2JU Maybe an option to tap>
the results instead of just display them inline? (i.e., change a setting for that notebook or maybe globally)
Why would you need the notebook at that point instead of tap> evaling in the text view?
I'm just impatient for the Portal views enhancement :rolling_on_the_floor_laughing:
hehe yeah me too 🙂 I’ve been told it’s in the works though 😛 but we’ll probably need some way to be less spammy on the output, but I’m thinking about something like “default collapsed output” or similar
btw a “fun” thing that came out of this is that anyone can write their own renderer for these notebooks. we’re writing the output as ‘x-application/edn’ and @U1G869VNV will “just” add a render for that to the portal extension. it would now be possible to add more types of renderers with other extensions: https://code.visualstudio.com/api/extension-guides/notebook#notebook-renderer

Oh... so the Portal extension itself can expose all of its viewers as notebook renderers and that will make all of that available directly to the notebook view?
One thing I wanted to try out: how does the notebook stuff handle top-level comment
forms, given that Calva treats them as special, as if the enclosed forms were top-level?
Yes. We’ll probably pull that in at some point, just to make it easier to interact from the view into Calva, but for now that’s the easiest / most extensible way
Currently it doesn’t have anything special for them, so just one big thing that evals to nil. I’ll probably add handling that does something similar to Calvas own handling, so one cell per enclosed form in the comment.
Excellent! Thanks!
just not sure about how to “display” that. you’d still have to mark those as being in a comment. maybe a special “comment-clojure” language tag or something 😉
btw there’s a discussion on github to have a kind of keep track of the decisions around the notebooks: https://github.com/BetterThanTomorrow/calva/discussions/1825
I guess it's one thing I've never gotten about this whole notebook thing: how can you use it to write actual production code when it expects to eval every top-level form to produce inline results? The RCF comment
approach comes close if that could be "notebooked".
Mhh, you’re probably right. In my mind, the notebooks were just a way of having a richer inline eval display and I’d remove most of the actual running stuff after I’m done, the same way I do in normal code. But I like the idea of treating the normal code as “incidental” in notebooks and making the actual notebooky stuff out of the rich comments.
I leave a lot of code in RCFs so I don't lose context/history when committing production code. That's my normal workflow. So "notebook mode" only works for me if it can somehow handle RCFs as if they contained notebook cells I guess.
It would also be pretty easy to have two types of notebooks. One that stays in this traditional style and a “rich comment notebook” that puts the whole file into one large code cell and then splits up any rich comments into their own cells.
As an example, when writing a date parsing function, I ended up with this RCF that stayed in the code next to production function:
(comment
(for [fmts [(DateTimeFormatter/ofPattern "M/d/yyyy")
(DateTimeFormatter/ofPattern "MM/dd/yyyy")
(DateTimeFormatter/ofPattern "yyyy-MM-dd")
(DateTimeFormatter/ofPattern "dd MMM yyyy")]
dts ["1962-07-07" "2021-04-14" "7/18/1980" "10/5/1981"]]
(try (LocalDate/parse dts fmts) (catch Throwable _)))
)
Obvs, I don't want that for
executable in the production code but I also don't want to lose it as it was part of how I thought about developing and testing the parsing function. Many of my RCFs have multiple forms, with the first several being setup/`def` forms. Here's an example from today where I was refactoring some very old code and needed a sanity check on how things actually worked:
(comment
(def db-spec {:datasource {:dbtype "mysql" :dbname "worldsingles" :user "root" :password (System/getenv "MYSQL_ROOT_PASSWORD")}})
(def derek (sql/get-by-id (:datasource db-spec) :user 9 {:builder-fn rs/as-unqualified-maps}))
(site-user-key derek)
(get-or-create-cid db-spec derek)
(sql/update! (:datasource db-spec) :user {:siteuserkey nil} {:id 9})
)
(and they don't necessarily get eval'd in order -- I often put setup and teardown first, then a series of explorations)
(comment
(require '[com.stuartsierra.component :as component]
'[ws.application-system.interface :as app])
(def ^:private app (component/start (app/system {:process-id :test})))
(component/stop app)
(wrapped/seed (-> app :caches :site) {})
(lookup-moods (:caches app)
(:pooled-db (:database app)))
)
Like that ☝️:skin-tone-2:That makes sense, my stuff looks similar, at least until my colleagues start hounding me to move more of it into tests 😅
Meh, this stuff is pure REPL-based exploration on a form-by-form basis -- it would look pretty different in test code 🙂
And I really like the idea of using those comments to bridge the gap between actual code and the notebooky stuff, thanks for giving me some new inspirations 🙂
BTW ctrl+alt+enter
does not seem to eval a cell (if the cursor is inside the code)
yeah, there’s a special “Notebook: Execute Cell” hotkey. I still have to get a lot of the normal Calva tooling back up and running in the notebooks 😞
Notebook: Execute Cell
is bound to ctrl+alt+enter
but it doesn't actually work.
(selecting N: E C
from the Command Pallete works, pressing the |>
button next to the cell works, but the hot key doesn't, when the cursor is in the middle of the code in a cell)
ah interesting, it’s bound to ctrl+enter
for me. Haven’t tried it yet though
It seems that Calva intercepts the hot key instead of the notebook.
Keybinding debugger:
[2022-08-18 18:05:01.220] [renderer1] [info] [KeybindingService]: | Resolving ctrl+alt+Enter
[2022-08-18 18:05:01.220] [renderer1] [info] [KeybindingService]: \ From 5 keybinding entries, matched calva.evaluateToCursor, when: calva:connected && calva:keybindingsEnabled && editorTextFocus && editorLangId == 'clojure', source: user extension betterthantomorrow.calva.
[2022-08-18 18:05:01.221] [renderer1] [info] [KeybindingService]: + Invoking command calva.evaluateToCursor.
yeah, we’ll have to extend a bunch of calva hotkeys to not “intercept” in notebooks or to do the correct thing
Ah, OK. So a known WIP.
Yeah, for some of them. I’ll probably forget a bunch at first 🙂
It seems that saving in notebook mode doesn't respect the editor setting to trim trailing spaces -- or is that a Calva-specific setting?
(I was messing with splitting and joining cells and then saved and got a change show up in git
that was just whitespace)
Ah yeah, handling whitespace is one of the harder things about using the same file for notebooks and normal code. I have “format on save”, so I probably missed a bunch of cases. I’ll disable for next time and play with it some more
It's already very cool and impressive -- I can imagine it working really well for documentation with embedded code examples!
I have a big new feature coming up at work -- I can imagine using this for sketching some of that out...
Glad to hear that. Hopefully, I’ll get around to comment handling soon. That seems to be the highest priority to make it into more than a cool toy
My biggest question is how to integrate all the various Portal features without cluttering the ui :thinking_face: I don't want have history/filter/viewer selector/command button/path for every single value.
I've taken to just cycling through all available viewers (I have a hotkey in Calva for it now), and I don't use any UI elements (I do that programmatically) so a way to just cycle the viewers for an active cell would be plenty enough for me.
Another question is how to integrate with the host runtime. Currently everything is based on serialized edn strings so anything that relays on a runtime (datafy/nav) won't work. Also, it looks like the serialized string don't include metadata, so no default viewers.
I think it's still valuable to have Portal as a full view alongside and the ability to tap>
results, not just eval them inline (see my comment above about a per-notebook or global setting to do that).
@U1G869VNV I can provide a different output for different mime type. I’ll have a look to see if the repl result can give us metadata. I could also enclose the actual value with extra info like:
{:value "actual stuff"
:view-options ...
:any-extras ...}
As for the UI: I think the view selector and command should stay while losing the rest, but since we can provide extra data we could make it optional by passing in a config.
Not certain yet what the best way is to get runtime integration, but a “quick” way to get most of the way there would be a portal server in the runtime and passing in the port to the view so that it can connect to that. There’s probably a better/cleaner way to get more interactivity but this would get a bunch of stuff working I think.