This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-27
Channels
- # announcements (10)
- # bangalore-clj (1)
- # beginners (130)
- # calva (8)
- # cider (66)
- # circleci (2)
- # clojure (197)
- # clojure-europe (2)
- # clojure-italy (8)
- # clojure-nl (5)
- # clojure-spec (14)
- # clojure-uk (35)
- # clojurescript (46)
- # code-reviews (5)
- # cursive (4)
- # datomic (88)
- # duct (1)
- # emacs (2)
- # figwheel-main (15)
- # fulcro (20)
- # graalvm (1)
- # graphql (3)
- # jackdaw (2)
- # leiningen (2)
- # off-topic (64)
- # pathom (53)
- # re-frame (52)
- # reagent (12)
- # reitit (43)
- # rewrite-clj (1)
- # shadow-cljs (38)
- # spacemacs (3)
- # sql (17)
- # tools-deps (6)
- # vim (30)
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.
FWIW, this is the project where I am testing all of this: https://github.com/manuel-uberti/boodle
Also, another info. The CLJS REPL doesn't seem to be "recognised" as such, because in the mode-line I see REPL[clj]
.
@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.
oh, I see. Could it be something on shadow-cljs side, then? Maybe @thheller has some insights on this.
I changed a bit how output is handled since previously compiler warnings during require
or load-file
were dropped and not displayed
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.
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]
.
If the buffer is not correctly recognized this would breaking the session linking, causing your problem.
The detection mechanism hasn’t changed on cider-nrepl’s side, so I assume something got changed in shadow.
@thheller See https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/track_state.clj#L185
@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.
maybe also bump cider-nrepl? I have no idea to be honest. thought nobody used the old cemerick.piggieback
anymore
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
.
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?
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.
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.
> maybe also bump cider-nrepl? I have no idea to be honest. thought nobody used the old cemerick.piggieback
anymore
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...
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.
@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.
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.
Hi all, is there a way to run lein sass4clj auto
on cider-jack-in-cljs
?
@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.
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.
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
@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.
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.
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.
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
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
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.)
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.
How do you mean let the backend figure it out? The client API stays similar to the current one?
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
instead of that being some kind of server state dependent on previous messages/evals and so on
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
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.
> 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
Yeah, that’s true. All sessions start their lives as Clojure sessions and via a dynamic binding they are changed to ClojureScript sessions.
would it not be reasonable to have a cljs/clone
or so that just starts the session as CLJS from the start?
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).
and you then knowing that this session is CLJS forever instead of having to figure it out all the time