Clojurians Log v2

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:

https://www.dropbox.com/s/1lmkbat2n3ex04u/Screen%20Shot%202020-11-08%20at%209.40.52%20PM.png?dl=0

ah is that reveal on the right?

VS Code (macOS), Reveal, Socket REPL. All works beautifully. Also on Windows/WSL!

great to have pieces that work well together 🙂

I am so impressed with what Mauricio has done here!

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!

(with Atom, it isn't quite as slick)

Now all we need is the repl-tooling stuff integrated into a nice Socket client for Emacs, eh? 🙂

i am not sure i understand how that would work

i thought repl-tooling was written in cljs

I know. I'm just "wishful thinking" 🙂

🙂

I just wish there was a serious alternative to CIDER/nREPL.

i get by with my custom spartan stuff 😉

have you ever tried monroe?

What is Monroe?

Oh, still nREPL. Ugh!

I do not want nREPL in my production processes!

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.

Or Unravel. Or telnet/nc/whatever.

No nREPL.

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.

Wow, great to know that everything is working well!

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!

\o/

Why is prepl not so popular? I hardly know any tool that uses it

Olical is a good person to ask

i think he said it's broken in a few ways

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)

These are only my experiences, but it was quite some time ago

thanks for that summary

@mkvlr ^

@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.

ah, you’re using unrepl, great.

so we’re on the same page…

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…

Are you also working on some tooling over unrepl?

yes, nextjournal is using unrepl and prepl

we’re in the process of migrating to prepl…

or rather our own prepl inspired thing but it’s not fully stable yet

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

that’s what I’m talking to @borkdude about

not public yet but happy to add you to our repo, warning: also not pretty yet

@mkvlr Aren't the nREPL folks working on side-loading nREPL itself over a Socket REPL? (the way Unrepl already works)

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 stdout and 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 🙂

Key bindings are identical, so are the commands.

right, it was added in 0.7 it seems https://nrepl.org/nrepl/design/middleware.html#sideloading

still think an edn-based protocol would be simpler than binary

Oh, indeed! Hotreloading the extension and having the REPL is fantastic.

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 🙂

Yeah, I've been reading along and seen your joy. 😃 Very, very cool stuff this all!

@seancorfield Did you also try clj-kondo in vscode?

You can install it as an extension, you don't even need the binary installed

@borkdude Yup, and it's very nice, thank you 🙂

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).

where do I sign in, how?

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 🙂

so where does this thing store the data though?

@borkdude Somewhere on Microsoft's servers, just like the Edge settings sync.

Just like Chrome stores your settings on Google's servers.

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

Anyway, I hope this works, because I wanted this :)

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 assume that's what you're referring to?)

WSL2 yes, but also when connecting to other machines, but that's similar

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

Open issue: https://github.com/microsoft/vscode/issues/48659