This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-29
Channels
- # announcements (5)
- # beginners (25)
- # calva (53)
- # clj-kondo (9)
- # clojure (25)
- # clojure-europe (14)
- # clojure-nl (1)
- # clojure-norway (21)
- # clojure-uk (1)
- # conjure (2)
- # data-science (1)
- # datalevin (4)
- # datascript (6)
- # deps-new (5)
- # emacs (5)
- # etaoin (6)
- # figwheel-main (1)
- # fulcro (46)
- # gratitude (3)
- # hyperfiddle (8)
- # introduce-yourself (13)
- # lsp (13)
- # nextjournal (5)
- # off-topic (2)
- # pathom (4)
- # polylith (11)
- # re-frame (16)
- # releases (4)
- # scittle (67)
- # shadow-cljs (38)
- # slack-help (4)
- # specter (13)
- # sql (29)
- # squint (21)
- # test-check (3)
- # vim (13)
- # xtdb (15)
Just wanted to give a small user report: We've been testing out pair-programming via LiveShare and Calva on and off for a few weeks now. It's still not perfect sailing (having issues with client connecting to host repl in a monorepo setup, sometimes the formatter acts weird, etc.) - but, it's in general usable and has been an interesting experience in remote pair-programming. Kudos for the effort! Unfortunately, there is a fly in the ointment: the latest release with Notebook support is generating Notebooks for every file opened by a participant. The only way to avoid it is to ask the host to open the file and use the "Focus Participants" feature. I'm aware this feature is experimental, but just wanted to give a heads up that this is happening over LiveShare. I checked the docs but could not find the correct setting; can we disable the Notebooks feature altogether for now via some settings.json?
Thanks for this report! I'd like to know details about issues with connecting and the formatter. And we want an issue about the Notebooks thing!
Yes, I’d be interested to know what “generating Notebooks” means 🙂
@domagala.lukas when visiting any file as a participant, instead of opening the file as a regular file it opens as if you chose "Open as a Notebook". The participant sees notebook cells instead of a regular Clojure file, and (if I recall correctly) the host sees a changed/unsaved file that must be closed manually.
@U0ETXRFEW sure thing - I'll try to gather more info and we can open some issues tomorrow :)
Interesting, thanks for reporting that. I specifically set the “open in notebook” as non default. You don’t happen to use any other vscode notebooks? Not sure if this is a vscode bug since that feature is pretty new.
I do not, but my colleague may -- I had not considered that! Thanks for the quick response and let me get back to you when I know more.
I submitted an issue - https://github.com/BetterThanTomorrow/calva/issues/1850
Thank you for the detailed bug report!
By the way, I updated the issue to add that after the guest opens a file (and hence sees it as a notebook), the host will then also see that file as a notebook.
I’m going to try and fix this. I reported an issue at the live share repo as well (https://github.com/MicrosoftDocs/live-share/issues/4765). If anyone has more information or hints on this issue, please let me know!
I've added some extra context as comments into the ticket. Hope you have more luck looking into this than I had 🙂
I think that that LS issue might benefit from an attempt to reproduce it with some other Notebook. And if it isn't reproducible like that, it might give some clues as to what we can do in Calva. (Really doesn't seem like there is much we can do in Calva, but anyway.)
Yeah just be careful what kind of notebook. The notebook API is pretty new and most extensions are still using some self built thing instead of using the official notebook API, so you might get “wrong” results
plus a lot of the notebooks use their own file extension, so they wouldn’t have the problem, which is probably why it wasn’t reported until now. if we used .cljnotebook files we wouldn’t have the problem either, but than half the point of our notebooks would go away 😞
Yeah, I also thought about a special extension. But we don't want to go that way with this feature. Quite disappointing with LiveShare acting up on a core VS Code feature like this.
Meanwhile, there is a total lack of activity on the upstream Live Share issue I reported. This problem is prohibiting me (and my colleagues) from updating Calva, which of course is a problem in itself. Can we think of some sort of work-around to move forward? Is VSCode notebooks implementation maybe assuming that notebooks always have different extensions and should we therefore also do that? (bummer) Fork of Calva without notebook support. (Also bummer) Extract notebook support into separate extension that you can choose to install/disable at will? (Maybe…?) Anything else?
We could maybe have a PR that follows the released Calva, with the only difference that it doesn't have the Notebook part of the manifest. Circle Ci builds VSIX:s for us on PRs, so then you and your colleagues could download those. Would that work? (I'm also counting on here that you maintain that PR 😃 )
There’s a proposed notebook api change specifically targeted at LiveShare stuff. If that get’s merged into the main branch we can dynamically register the notebook and thus disable it in options. Let’s hope this happens soon.
can’t find a direct issue. here’s the api: https://github.com/microsoft/vscode/blob/main/src/vscode-dts/vscode.proposed.notebookLiveShare.d.ts
https://github.com/microsoft/vscode/issues/147248#issuecomment-1137773838 > This will be a large, three-part change to the Live Share notebooks architecture, and our goal is to have this done by the fall. Fingers crossed…
upvoted it, let’s hope they manage to fix this. not a fan of any of the hardcoded project.json settings anyway 😞
@U0ETXRFEW I created the PR like you suggested (https://github.com/BetterThanTomorrow/calva/pull/1873). I’ll keep it updated and I’ll remove it once it is no longer needed.
Thanks! I think we should consider adding info about this to the published docs as well. Both on the LiveShare and the Notebook pages. WDYT?
Not sure. I would be OK with it, but it feels like a bit hacky work-around. I don’t think many people are actually using live share support (considering the multiple ways in which it has been broken in Calva over the past year). I’ll let you make that decision 🙂
It's hard to know how many are using it. I'm thinking that for the people who do, and who encounter that problem, they just might choose to check the documentation for help.
New Calva out, dear Calva-friends: https://github.com/BetterThanTomorrow/calva/releases/tag/v2.0.296
• https://github.com/BetterThanTomorrow/calva/issues/1845
• https://github.com/BetterThanTomorrow/calva/issues/1846
• Update deps.clj to version 0.1.1100
So it's the experimental Notebooks feature that continues to develop under the wings of @domagala.lukas. And we're doubling down on deps.clj as the default deps.edn project launcher. I started to write a guide about getting started with Calva and want to cut the step with installing clojure
. And also; generally it makes sense with a launcher that is written in Clojure and thus runs across the same platforms as Calva supports.
deps.clj is currently about 5 months lagging the official Clojure CLI (https://clojure.org/releases/tools), so this actually is a step backward in some ways. any chance @U04V15CAJ could sync and use a newer one? seems like maybe the work has already been done in the repo but not released?
the work is done, bb has always got an up to date deps.clj
, but I'll release a new one now. since the "script" doesn't see much churn, you can actually get the newest tools jar by setting an env var, while keeping the script the same.
it's only fair that I release a new version more often that uses the newest tools jar
Yeah, maybe that is the best option here. Any user who want's to use a specific version of clojure
can just tell Calva to use clojure
instead and control the version that way..
We currently do not update deps.clj on the fly like we do with clojure-lsp. It is a hard bundle together with a particular Calva release.
well, if users start code with DEPS_CLJ_TOOLS_VERSION=... code .
they get the newer jar that way too
I'd complain about this causing a problem for people who update their CLI but don't realize they also now need to update an env var -- except that I don't jack-in to projects, I start my REPL manually 🙂
yeah, I realize it makes it easier to not install clj, but when you do maintain your clj at specific versions, it breaks that expectation that Calva is using what you have at the command line. tradeoffs I guess.
Tricky trade-offs. People who have the CLI working could instead be using that to Jack-in. Calva quite clearly shows what it uses. We could show that even more clearly.
I am glad that it shows it the way it does, that certainly helps debugging mis-expectations
After sleeping on the feedback from @alexmiller and @seancorfield, I've now decided that since it is the requirement to install clojure
in order to get started with Calva that I want to get rid of, it makes sense with a check if clojure
is installed, and if it is, use it, otherwise use deps.clj
. Here's a VSIX implementing that change: https://output.circle-artifacts.com/output/job/75dda536-c0ca-451c-8061-e67287a154df/artifacts/0/tmp/artifacts/calva-2.0.298-1848-check-for-clojure-executable-92f389b8.vsix
It works like so:
1. When Calva starts, it will spawn of a small check if the clojure
executable works. (Check the VS Code dev console for a log on this test.)
2. If the check succeeds, the default executable will be set to clojure
, otherwise it will be set to deps.clj
3. At jack-in, the setting calva.depsEdnJackInExecutable
will be consulted. Of this setting is on its default: clojure or deps.clj
, the default executable (based on the test mentioned) will be used. If this setting actively chooses either clojure
or deps.clj
, that choice will be honored, regardless what the test resulted in.
Would be lovely with some help testing! ❤️
Dear Calva-friends: https://github.com/BetterThanTomorrow/calva/releases/tag/v2.0.297 • Update deps.clj to version 0.1.1155
After sleeping on the feedback from @alexmiller and @seancorfield, I've now decided that since it is the requirement to install clojure
in order to get started with Calva that I want to get rid of, it makes sense with a check if clojure
is installed, and if it is, use it, otherwise use deps.clj
. Here's a VSIX implementing that change: https://output.circle-artifacts.com/output/job/75dda536-c0ca-451c-8061-e67287a154df/artifacts/0/tmp/artifacts/calva-2.0.298-1848-check-for-clojure-executable-92f389b8.vsix
It works like so:
1. When Calva starts, it will spawn of a small check if the clojure
executable works. (Check the VS Code dev console for a log on this test.)
2. If the check succeeds, the default executable will be set to clojure
, otherwise it will be set to deps.clj
3. At jack-in, the setting calva.depsEdnJackInExecutable
will be consulted. Of this setting is on its default: clojure or deps.clj
, the default executable (based on the test mentioned) will be used. If this setting actively chooses either clojure
or deps.clj
, that choice will be honored, regardless what the test resulted in.
Would be lovely with some help testing! ❤️