This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (6)
- # babashka (17)
- # beginners (70)
- # calva (6)
- # chlorine (88)
- # cider (9)
- # cljs-dev (9)
- # clojure (66)
- # clojure-australia (3)
- # clojure-czech (5)
- # clojure-europe (73)
- # clojure-nl (5)
- # clojure-spec (62)
- # clojure-uk (38)
- # clojurescript (30)
- # crux (21)
- # cursive (10)
- # datomic (16)
- # events (1)
- # figwheel-main (1)
- # fulcro (6)
- # graphql (21)
- # helix (4)
- # jackdaw (1)
- # jobs-rus (1)
- # kaocha (3)
- # luminus (11)
- # malli (28)
- # pedestal (3)
- # re-frame (2)
- # reagent (3)
- # sci (2)
- # shadow-cljs (21)
- # spacemacs (2)
- # sql (25)
- # timbre (2)
- # tools-deps (9)
- # tree-sitter (1)
And I just set it all up on my Windows Surface Laptop: very slick! VS Code + WSL extension so all the code / REPL / etc live on the Linux side, but the editor lives on the Windows side, which is nicer than what I was doing for Atom (running it on WSL via Xlaunch).
haven't tried any custom things, but clover 0.2.1 seems to be working fine here via a socket repl with a deps.edn project :thumbsup:
VS Code (macOS), Reveal, Socket REPL. All works beautifully. Also on Windows/WSL!
On Windows, with WSL, where VS Code native on Windows can talk to WSL and have all the files and the REPL and everything running on Ubuntu... so slick!
Now all we need is the repl-tooling stuff integrated into a nice Socket client for Emacs, eh? 🙂
With Socket REPL, I have no additional deps. I can choose to start any process with a REPL. I can connect to it from Atom/VS Code.
ah ok. well i don't usually use nrepl either (my custom stuff is socket-repl based) and am grateful that chlorine and clover provide the option of using a socket repl.
i can appreciate not having additional things in my clojure processes, but it seems that for practical reasons it is hard to avoid if one uses rebl or similar.
CLJS is a great language for editor plug-ins, really. VSCode's API is incredibly limited (specially the "webview API" that I use for the console) but even-then, hot-reload works- it's almost magic!
There are some issues with reader conditionals, tickets that are not being addressed that makes it hard for tooling to work with, the same problems with old "contrib" tools (release cycles that are too long, tied to the Clojure releases, hard to contribute), and I had some problems with concurrency (you send a command and it becomes confused on what to print)
@mauricio.szabo but does that invalidate the whole idea of an edn-based protocol that can be upgraded at runtime? Can still do all those things in user-land to work around the contribution/release problems? Imo being able to upgrade a plain socket repl like unrepl without requiring extra deps is a clear win.
Yes, that's one of the reasons I'm using UNREPL for now - it upgrades over a plain socket repl
But unrepl also only works for Clojure, so there is some detection I do before upgrading things.
Yes, but unfortunately unrepl is quite complex... I'm having a hard time trying to fix a bug on it when you evaluate Datahike's transact functions
I'm thinking about an easier "EDN-based upgradable REPL" that could be easier and also work with other clojure implementations like CLR, Magic, Arcadia, Lumo and Clojerl.
yes, we’ve been struggling there, too. Would be 💯 to have a version of this idea that we could settle and depend on…
That's great news! Is the code already available somewhere? I want to take a look (I'm also looking to migrate away from unrepl, but I don't want to re-re-reinvent the wheel)
I was even looking at making the "Babashka nREPL" upgradable over a plain socket-repl
@mkvlr Aren't the nREPL folks working on side-loading nREPL itself over a Socket REPL? (the way Unrepl already works)
right, it was added in 0.7 it seems https://nrepl.org/nrepl/design/middleware.html#sideloading
Rich seems fairly strongly against a REPL that doesn't work as a pure streaming REPL -- which means that if you go over the wire, rather than being in-process, you have all the associated issues of large values and interruptible execution etc.
@seancorfield to be honest, nREPL is streaming~ish. You can parse the payload as it comes, and newer versions of nREPL also allow you to receive evaluation results as "chunks" of string.
There are strange things on nREPL, like a
stderr message being associated with an evaluation ID, but I mostly ignore it
https://github.com/seancorfield/vscode-clover-setup in case anyone wants to use my
Chlorine Clover setup with VS Code 🙂
Oh, hey @pez -- I've switched to the "dark side" over the weekend, now that I can have custom tasks in VS Code so my REPL/Reveal workflow is identical to Atom 🙂
I also have the sync settings stuff enabled between my Win/WSL setup and my Mac setup -- so I didn't even need to add any extensions on Windows: it sync'd all of them automatically from my Mac, which was pretty slick!
is this the sync extension for syncing settings? I tried it but I could not figure out where it stored stuff
You sign in via either a Microsoft or GitHub account and it uses those credentials to store it in the cloud (just like browser stuff gets sync'd in Chrome/Edge/etc).
oh I see something now. this is probably new. I was trying out a third party extension a while ago which didn't work for me
Yeah, this is all built-in but with lots of caveats about reading the docs and it being experimental 🙂
That's kind of the whole point of sync: keeping all your devices in sync via centralized storage of the settings/data/etc.
it's all open source though, so I wonder where they keep the vendor-specific things. reading this now: https://github.com/microsoft/vscode/blob/master/src/vs/platform/userDataSync/common/extensionsStorageSync.ts Maybe the vendor-specific parts are in proprietary extensions
VSCode merges the "open source part" with some private repository, so probably is not publicly available...
VS Code vs VS Codium, right? The latter is all open source, the former is Codium plus some MS proprietary stuff?
The most interesting stuff, like the SSH extensions, are proprietary it seems ;) Have you tried this (the remote ssh stuff) Sean? It was really shocking to me how well it works.
Yes, the VSCode is the source available on GitHub (the repository is marked as Microsoft/VSCode but the product itself is called code-oss) merge with a "mix-in repository" and some private extensions: https://github.com/microsoft/vscode/blob/6d36470eb8c12724a4de7f6cae07b9bd5007ef91/build/azure-pipelines/linux/product-build-linux.yml#L50 The codium project is a code-oss without most of the telemetry, compiled in a binary format ready to use (but without the proprietary mix-in and extensions)
@borkdude Yup, part of why I've switched to VS Code is because of the WSL2 integration. It's very slick.
I have no need to work against remote servers otherwise, although I guess if I could use it to edit stuff on QA/production, that would be a bonus 🙂
Most of our SSH setup assumes you go into the box as a low-priv user and then sudo -- does it support that workflow?
That's something I wanted to do recently to, I logged in as root eventually which might not be so good... I need to find this out