@volrath @bozhidar I was exploring the spiral project as I was looking for a way to better handle async stuff in emacs (not an emacs guru here, but so like elisp). The state machine approach of spiral is nice and I was wondering if I could include it in inf-clojure. Then I thought...maybe the two can become one? Basically text or unrepl protocol...the operations are the same...of course in case of text you would have only one connection. Probably more things are different, but are the two SO different? Will think more.

@richiardiandrea we started an issue to discuss possible merging of spiral into cider https://github.com/Unrepl/spiral/issues/5, I know it's not exactly what you are talking about, but it can give you an idea of both our perspectives on the subject. My current situation is that I'll be all forward to integrate spiral into a wider used tool like cider (or inf-clojure maybe), although I still feel it's quite a big amount of work that I'm not sure I could commit to. Besides the difference on the protocol, the other big things are: 1. spiral uses parseclj ast data structures to process/handle messages from the running repl, cider uses nrepl-client, inf-clojure I don't know (haven't read the source code, but I'm guessing it's just plain text?), and 2. tooling is handled differently, I've been thinking on using cider-nrepl as a libraryfor certain features in spiral (and that way make it easier for a possible integration later on) but at some points I've felt that cider-nrepl is a big library that I would have to load for a small amount of features that can actually be ported between each other.. this is something that I recently started to look into, so I don't have a well formed opinion on this yet. Besides these, I've been putting thought into certain UI/UX decisions into spiral, that are highly opinionated, and that makes it as a possible alternative to cider.

btw, while I have you here, I took a look at https://github.com/Unrepl/unravel/issues/64 and boot-sources, great work! it's definitely something that could be useful for unravel/spiral.. I haven't really checked on mranderson too much either

Iirc a library like cider-nrepl should be loaded by using sideloading, or we are back again to middleware problems? In any case will read the issues

Yes btw I worked on the compliment blob, which I built using boot, I plan to dig into that as well

Will keep digging and thinking :)

sounds great, I will update the collaboration issue with some thoughts tomorrow, feel free to join there if you have ideas on how to move forward 🙂

re. cider-nrepl, I was thinking on just sideloading it and using it as a library, without really using the middlewares... you can take a look at https://github.com/Unrepl/spiral/blob/master/tools/src/spiral/tools/load_file.clj (which was my first try out at unrepl custom session actions) and compare it to cider-nrepl load middleware

it's basically the same, minus the nrepl middleware stuff

and that code is just sideloaded using the unrepl sideloading feature

Yep that is the approach I had in mind too

For something like this it’d be best if cider-nrepl is split into two - something like`cider` + cider-nrepl. One is just an utility library for Clojure tooling, the other is just an nREPL wrapper around the first one. There’s very little nREPL-specific code in cider-nrepl - just middleware definitions and handlers.

> Besides the difference on the protocol, the other big things are: 1. spiral uses parseclj ast data structures to process/handle messages from the running repl, cider uses nrepl-client, inf-clojure I don’t know (haven’t read the source code, but I’m guessing it’s just plain text?),

parseclj simply didn’t exist at the time. In general EDN didn’t exist when nREPL was created, therefore the decision to use bencode for the communication with the clients - it was something easy to support in many editors.

Even now nREPL can be extended with some EDN adapter if someone wants to work in this direction, and I do plan to use parseclj once the package is released officially for parsing data structures (now we just parse them with the Elisp reader, which is problematic here and there).

What’s the advantage of using boot-sources over mranderson? I’ve seen several source rewriting tools over the years and they all seem to do pretty much the same thing.

Btw, that rewriting is what actually makes cider-nrepl rather big as an artefact - it bundles all of its runtime deps with it. That’s why in the latest version we opted to simply defer the loading of everything until it’s used, otherwise the load time was quite significant. Now it’s around 0.

Also, cider-nrepl is just half of the equation. A lot of extra CIDER features reside in clj-refactor.el and refactor-nrepl. Some of them will eventually be promoted to CIDER, but I haven’t had much time for this lately. And there’s also cljs-tooling where we’ve extracted most of the cljs-related code we have.

Part of the reason cljs support is CIDER is so bad is that the two people who were working on cljs-tooling eventually stopped having time for the project. 😞 I think they were off to a great start.

I think rewriting will continue to be a requirement for unrepl.

Some refactorings are part of clojure-mode these days, right?

Ideally they shouldn’t require a real connection at all. If that’s feasible...

@dominicm what do you mean by rewriting?

> For something like this it’d be best if cider-nrepl is split into two - something like`cider` + cider-nrepl. One is just an utility library for Clojure tooling, the other is just an nREPL wrapper around the first one. There’s very little nREPL-specific code in cider-nrepl - just middleware definitions and handlers. 100%. Lately I've started looking at writing support for eldoc in spiral, and i feel like I would end up reusing lots of cider-nrepl's code, but it be easier if it were split like you say. Splitting cider-nrepl would be one of the things that I think we should add to a TODO list for a possible integration of spiral into cider.

> parseclj simply didn’t exist at the time. In general EDN didn’t exist when nREPL was created, therefore the decision to use bencode for the communication with the clients - it was something easy to support in many editors. yes, parseclj started this year, around June if I remember correctly, but the project is a bit stalled right now, hopefully it will pick up soon.

@bozhidar I haven't looked at the latest changes in cider-nrepl, with the deferred loading and all, but isn't that a step forward to splitting the library? how difficult would it be to actually do the split, in your opinion?

and I also don't understand what's the meaning of "rewriting"

Rewriting the namespace. 🙂 Guess I could have used a different word, but basically such tools just copy the original source code with a different namespace, as a simple way to avoid conflict with a different version of the same library being loaded by the user.

> @bozhidar I haven’t looked at the latest changes in cider-nrepl, with the deferred loading and all, but isn’t that a step forward to splitting the library? how difficult would it be to actually do the split, in your opinion?

Should be much. Probably a few days of focused work, something like this. The hardest part would likely be to define the right API for the shared library, although obviously you don’t have to get this right from day 1.

> Rewriting the namespace. 🙂 Guess I could have used a different word, but basically such tools just copy the original source code with a different namespace, as a simple way to avoid conflict with a different version of the same library being loaded by the user. I see. then @dominicm is right, unrepl clients also need this. I haven't used mranderson yet, I will check it out

Some people call it "vendoring"

Shading is what maven calls it I believe.

> This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. From maven-shade-plugin

> then @dominicm is right, I usually am

From Rich's talk the Value of Value >>> [...] just listen to Paulus [...]

If anyone is on macOS, please give the new homebrew formula a spin: https://github.com/Unrepl/unravel#simple-installation

@pesterhazy bash: line 29: exec: clojure: not found

Not sure if you didn’t want to use clj. I don’t recall ever seeing a clojure script.

> with the deferred loading and all, but isn’t that a step forward to splitting the library?

I forgot about this question. No, it’s mostly a workaround for nREPL eagerly loading all middleware instead of loading them when they are first needed. This makes the process of inspecting the server capabilities easier, but affects the server’s boot time when you have some big dependencies. Ideally something like this would land in nREPL itself after 0.3, but it was relatively easy for us to cook a something don’t requiring upstream changes - we just define some dummy middlewares that load the real ones on their first usage.

@bozhidar

$ brew list clojure
/usr/local/Cellar/clojure/1.9.0.273/bin/clj
/usr/local/Cellar/clojure/1.9.0.273/bin/clojure

haha

clj is just a wrapper around clojure that adds rlwrap (which we don't want)

OK, now I know what went wrong. Seems you didn’t add a dependency to the clojure recipe.

have you installed the clojure tool some other way?

brew list clojure
Error: No such keg: /usr/local/Cellar/clojure

hm that's a good point, I should add that!

@bozhidar do you know how to remove a tap?

homebrew is not the most logical package manager

brew untap

😄

@bozhidar, ok brew upgrade unrepl/bin/unravel should pull in clojure as well

I feel I am always late to the party :) Another big thing to consider is different repl types. Inf-clojure supports potentially many because we detect and dispatch accordingly. This makes things really flexible. I can hack on a new repl just with a setq.

Plus support for new repls is trivial

Cider supports only Clojure basically, a bit of cljs..

It would be awesome if we followed inf-clojure's very flexible and pluggable way to treat different Repls

It is 2018 on this side of the world, so happy new year to everyone!! 🎉 let's make this a great year for clojure tooling =)