Fork me on GitHub
#cider
<
2019-08-27
>
manuel06:08:22

hi everyone. Did something change in CIDER when it comes to linking buffer with REPLs? I have been using this setup for while: https://manuel-uberti.github.io/programming/2018/11/14/deps-shadow-cljs/ However, I cannot seem to have my CLJS buffers linked with the CLJS REPL any more. The CLJS REPL works fine, meaning I can interact with the browser from it once the application is running. And everything works just fine on the Clojure side of the project. The only problem seems linking my CLJS buffers with the running REPL.

manuel06:08:30

FWIW, this is the project where I am testing all of this: https://github.com/manuel-uberti/boodle

manuel06:08:32

Also, another info. The CLJS REPL doesn't seem to be "recognised" as such, because in the mode-line I see REPL[clj].

bozhidar06:08:47

@manuel Nothing has been changed there in ages. The only remotely related change I can think of is https://github.com/clojure-emacs/cider/commit/bad9995772c07467c945161552a035f32de66008, but it can’t be affecting session linking.

manuel06:08:29

oh, I see. Could it be something on shadow-cljs side, then? Maybe @thheller has some insights on this.

thheller06:08:46

can't win with nrepl ... fix a bug for one editor and break another ...

thheller06:08:35

I changed a bit how output is handled since previously compiler warnings during require or load-file were dropped and not displayed

thheller06:08:42

results themselves didn't change though?

manuel06:08:07

no, or at least I can't see any relevant change. I can compile/watch with shadow-cljs as usual, and as I said the REPL is interacting with the browser just fine.

manuel06:08:26

another thing: even without jacking-in on the Clojure side, just running a cider-connect-cljs to connect to the nREPL started with npx shadow-cljs watch results in a REPL buffer recognised as REPL[clj].

bozhidar07:08:36

If the buffer is not correctly recognized this would breaking the session linking, causing your problem.

bozhidar07:08:05

The detection mechanism hasn’t changed on cider-nrepl’s side, so I assume something got changed in shadow.

thheller07:08:22

how does it detect?

thheller07:08:43

@manuel only guess I have is that you are still somehow depending on an older nrepl version? I removed some of the old piggieback emulation. the cider.piggieback variant is still supported though.

manuel07:08:33

let me check

thheller07:08:11

maybe also bump cider-nrepl? I have no idea to be honest. thought nobody used the old cemerick.piggieback anymore

manuel07:08:21

I am using 0.22.0-beta12 in shadow-cljs.edn.

pez07:08:36

Does it work with 0.21.1?

manuel07:08:29

I get WARNING: CIDER 0.22.0-snapshot requires cider-nrepl 0.22.0-beta12, but you're currently using cider-nrepl 0.21.1. The version mismatch might break some functionality! if I switch back to 0.21.1.

manuel07:08:56

and I still see REPL[clj] in the REPL buffer modeline

thheller07:08:19

do you maybe still have the old piggieback on the classpath?

manuel07:08:57

I had com.cemerick/piggieback in my .m2 directory. I removed it from there, tried again, same problem. Should I look for the old piggieback elsewhere?

manuel07:08:26

BTW, I am using version 2.8.52 of shadow-cljs.

thheller07:08:08

doesn't matter if the files are .m2. that doesn't add them to the classpath

thheller07:08:25

just run shadow-cljs clj-repl and ( "piggieback/core.clj") or so

manuel07:08:14

[1:0]~shadow.user=> ( "piggieback/core.clj")
nil

bozhidar08:08:17

But there’s no piggieback.core ns currently. It’s cider.piggieback. 🙂 We do plan at some point to change it to piggieback.core and alias the old ns to the new one, but that’s a low prio task for the distant future.

bozhidar08:08:34

Ah, I see what you mean. 🙂 The code in cider-nrepl is just future proofed and checks for the potential new ns if we ever decide to go in this direction.

bozhidar08:08:57

> maybe also bump cider-nrepl? I have no idea to be honest. thought nobody used the old cemerick.piggieback anymore

bozhidar08:08:03

Yeah, I’m pretty sure you’re right about this.

bozhidar08:08:16

Haven’t seen it around in quite a while.

pez08:08:44

Why do we think it might be a cider-nrepl issue? I have not seen these problems in Calva. Not that that means it is not in cider-nrepl, I'm just wondering. Having worked for days with jack-in things I have noticed that I depend a bit too much on certain output messages and stuff and started to worry about that...

bozhidar08:08:52

I see in recent release shadow did some nREPL-related cleanup and perhaps this is some accidental regression. Don’t have time now to go over all the commits.

bozhidar08:08:19

@thheller In general I think it might be better to drop the piggieback emulation at some point and integrate natively with shadow’s middleware in cider-nrepl at some point, as if I recall correctly most problems we’ve encountered were due some problems with the emulation.

bozhidar08:08:08

I mean, I appreciate you doing this to make it easier for client libs, but perhaps the native integration will actually turn out to be simpler and more robust.

erwinrooijakkers09:08:43

Hi all, is there a way to run lein sass4clj auto on cider-jack-in-cljs?

thheller09:08:18

@bozhidar I thought about that but honestly the entire piggieback things seems entirely like the wrong approach to me. It jumps through so many extra hooks only to piggyback off of "eval" instead of just adding a dedicated "cljs/eval" that skips all that crap. there are also some implementation details that would make things a bit difficult given that it already reads the code and doesn't pass an actual string to let shadow-cljs read it.

thheller09:08:02

I also couldn't find any explanation why it does this https://github.com/nrepl/piggieback/blob/master/src/cider/piggieback.clj#L236 instead of just letting the cljs REPL do that since that is the first thing it does.

thheller09:08:36

I just have too many questions when reading the entire code. most of it seems still seems to work around bugs in the cljs.repl that have been fixed for years

bozhidar10:08:12

@thheller Well, I’m totally open to simplifying piggieback - my main issue is that my knowledge of ClojureScript is very basic and I’ve mostly relied on contributors to patch the code now and then. I’m reasonably certain that someone who knows their way around ClojureScript can come up with something better.

bozhidar10:08:58

Generally a safe approach would be to create an alternative simpler middleware and just market it as an alternative to piggieback and auto-load it when present.

bozhidar10:08:04

But yeah - I really need some help with all the ClojureScript-related things, as for me that’s just black magic and I don’t have enough time to dive deep into it.

thheller10:08:10

I'd be happy to help but have no clue of the cider side of things. there might be reasons it is using the same nrepl ops for CLJ/CLJS instead of dedicated ops for each. seems to me like most of the trouble comes from figuring out what the op was actually supposed to do

thheller10:08:48

would seem clearer to me to have ops for cljs/complete or cljs/eval and not make them look like CLJ with a bunch of conditional logic

👍 1
pez10:08:33

That's interesting. If it makes things simpler underneath, I don't think it would be too much needed to change at the client end. At least not in Calva. (And I haven't really thought that through, but anyway.)

thheller10:08:36

well I don't know either. don't know much about the editor side of things. might make sense to let the backend figure all that stuff out instead of the client.

pez10:08:35

How do you mean let the backend figure it out? The client API stays similar to the current one?

thheller10:08:00

backend = nrepl server+middleware

thheller10:08:01

client = the editor connected to the server. is it easier for it to just always send eval messages or is it aware of the differences in CLJ/CLJS and would benefit from directly telling the server that it wants to eval CLJS

thheller10:08:24

instead of that being some kind of server state dependent on previous messages/evals and so on

thheller10:08:28

right now my understanding is that a clone is done first. the session remains CLJ. then an eval is done (eg. cider.piggieback/cljs-repl) that sets a magic binding and turning the session to CLJS

pez10:08:56

Yeah, that's how I see the process too. It would be reasonably simple to let Calva add the cljs or clj info to the messages.

bozhidar10:08:58

> right now my understanding is that a clone is done first. the session remains CLJ. then an eval is done (eg. cider.piggieback/cljs-repl) that sets a magic binding and turning the session to CLJS

bozhidar10:08:34

Yeah, that’s true. All sessions start their lives as Clojure sessions and via a dynamic binding they are changed to ClojureScript sessions.

thheller10:08:03

would it not be reasonable to have a cljs/clone or so that just starts the session as CLJS from the start?

bozhidar10:08:11

I’m not sure why it was done in this manner, as it happened before I was involved with tooling/nREPL. I assume that the idea was to be able to implement more functionality transparent in terms of just sending code to eval (this was pretty popular before the cider-nrepl era).

thheller10:08:24

and you then knowing that this session is CLJS forever instead of having to figure it out all the time

thheller10:08:00

yeah a lot of the nrepl design doesn't account for CLJS at all

bozhidar10:08:17

Exactly - nREPl predates ClojureScript by a couple of years.

thheller10:08:17

things are quite different and they are made to look like CLJ

bozhidar10:08:17

And ClojureScript changed quite a lot in the past 3-4 years, while piggieback has been around since the first release of ClojureScript.

cider 1
thheller10:08:53

yeah exactly