This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-22
Channels
- # beginners (240)
- # boot (23)
- # bristol-clojurians (3)
- # cider (101)
- # cljs-dev (52)
- # cljsrn (17)
- # clojure (212)
- # clojure-dusseldorf (2)
- # clojure-greece (2)
- # clojure-italy (9)
- # clojure-russia (1)
- # clojure-spec (91)
- # clojure-uk (33)
- # clojurescript (164)
- # community-development (23)
- # core-async (24)
- # core-logic (9)
- # cursive (18)
- # datavis (1)
- # datomic (119)
- # emacs (13)
- # events (1)
- # figwheel (2)
- # fulcro (86)
- # graphql (1)
- # immutant (5)
- # jobs-discuss (6)
- # leiningen (19)
- # lumo (46)
- # nyc (7)
- # off-topic (23)
- # parinfer (15)
- # pedestal (3)
- # planck (32)
- # re-frame (48)
- # reagent (75)
- # ring-swagger (13)
- # rum (32)
- # shadow-cljs (402)
- # spacemacs (5)
- # specter (3)
- # tools-deps (11)
- # unrepl (20)
- # vim (135)
- # yada (3)
do i understand that output from threads other than the main thread can go to the nrepl buffer? if I read from a socket on another thread (which is handled by the Jetty websocket library), then any logging that socket read does would go to the nrepl buffer?
@bozhidar you talked about removing gradle. how would I go about adding shadow-cljs
? it supports injection via shadow-cljs -d cider/cider-nrepl:0.16.0 server
?
> do i understand that output from threads other than the main thread can go to the nrepl buffer? if I read from a socket on another thread (which is handled by the Jetty websocket library), then any logging that socket read does would go to the nrepl buffer? At least when dealing with Clojure - what ends up in the nrepl buffer is output that got bound to the server’s stdout/stderr. We’ve got some logic to redirect this to the REPL buffers, so people won’t miss it, but I’m not sure what exactly’s going on in your case.
https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/out.clj
@thheller So, you don’t need lein
, boot
or something like this? You can just spin the nREPL server with all the deps using the shadow-cljs
binary?
And I assume the resulting connection is a cljs connection, which is directly ready to be used?
We’ll need some way to know we’re in a shadow-cljs project. Is there some file marker we can rely on?
OK, so all of this is going to be very easy. I can hack it together myself if you’re afraid of Elisp. 🙂
The only open question is how to convert the resulting repl to cljs - I was told there’s not fixed code snippet you can execute, as you had to pass some project-specific build id.
It’d be nice to have some easy way to spawn a cljs repl without having the user to type anything themselves.
yes shadow-cljs supports multiple builds and you can "select" which REPL you want to talk to
We don’t currently use it, but a parser was implemented recently so we can leverage it.
to switch the nrepl connection to this build you'd first call (shadow.cljs.devtools.api/watch :app)
to start the "worker" which will recompile and all that jazz
then call (shadow.cljs.devtools.api/nrepl-select :app)
to switch the current nrepl to this build and turn it into CLJS
I could add additional helper fns/middleware that lets you query which builds exists and so on
ah I guess this is the relevant code. https://github.com/clojure-emacs/cider/blob/master/cider.el#L547-L563
so the quickfix would be to add a no-args version that just picks a "default" build. which is easy it there is only one.
@bozhidar you can run multiple (shadow.cljs.devtools.api/watch :build1)
(shadow.cljs.devtools.api/watch :build2)
in parallel. they run in the background. (shadow.cljs.devtools.api/nrepl-select :build1)
switches to CLJS of build1. :cljs/quit
switches back to CLJ, then call nrepl-select
again to switch to either
alternatively you could just call (shadow.cljs.devtools.api/browser-repl)
which starts the browser repl, opens a browser, and switches the REPL to CLJS
well technically its just one type, the browser-repl
and node-repl
are just utility fns to just quickly spin up a REPL without having to configure a build first
it sounds like shadow-cljs works the way we want piggieback to eventually work: with suspendable cljs repls in a single repl
maybe make a new workflow for shadow cljs and then migrate piggieback to work like that. without a sibling repl
It looks like everyone is talking about cider integration with shadow, correct?
I’m interested it trying it, and I’ll document it in shadow if someone doesn’t beat me to it.
Let me finish reading the guide, and then I’ll be ready to try it. What’s the quick start so far to connect cider to nREPL with shadow?
@jmckitrick easiest currently should be to run shadow-cljs server
externally in a terminal and use cider-connect
to connect to it
It looks like I’m connected, but jump-to-var
requires op "info"
via cider-nrepl. So I probably needed to start something else first….
I know cider auto-injects stuff for figwheel
Ah, that’s the next logical step.
So I assume I need to pick through my lein dependencies and copy the cljs ones into the shadow.edn to start @thheller
you can also specify :lein true
and just run shadow-cljs
via lein
. https://shadow-cljs.github.io/docs/UsersGuide.html#Leiningen
Hmm. I’m trying to decide if I want to start out with lein integration or not…
Maybe I’ll do that to make it easier for now.
@dpsutton We’ve been hearing a lot about new user experience, so this is good to hear.
I’ve run cider-connect
and I have a REPL running. How do I tell cider to begin using this connection for jump-to-var
etc?
Actually, this might not be a cljs REPL.
Sweet! I’m connected.
I just ran….
(shadow.cljs.devtools.api/nrepl-select :app)
Time to write some docs….
> it sounds like shadow-cljs works the way we want piggieback to eventually work: with suspendable cljs repls in a single repl
I was looking at a coworker of mine who uses intellij's screen yesterday, and saw that apparently his setup puts unused variables (as in, introduced in a let, but then never actually referenced) in a different color; is there a way to do something similar in cider?
I don’t think you can suspend and resume a cljs session with shadow-cljs, but I might be mistaken. At any rate - @bhauman’s latest idea about piggieback would make this irrelevant (most likely), as it would enable using one REPL for both clj/cljs without the need for a second connection at all. I think everyone would agree that’d be quite handy. 🙂
@tanzoniteblack CIDER itself doesn’t support this, but it’s doable. clj-refactor might have some functionality for this, not sure about that.
@bozhidar it can suspend and resume
thheller@beast:.../shadow-cljs$ shadow-cljs cljs-repl browser
[5:1]~cljs.user=> (def x 1)
#'cljs.user/x
[5:1]~cljs.user=> :cljs/quit
thheller@beast:.../shadow-cljs$ shadow-cljs cljs-repl browser
[6:1]~cljs.user=> (inc x)
2
[6:1]~cljs.user=>
@bozhidar I’m willing to help with the cider/shadow integration. I have it working locally. Or have you already started?
I haven’t started, but it’s probably best for me to do this, as I already know exactly what needs to be done. But if you do it by tomorrow morning that’d be fine by me - I’m already super busy as it is. 😄
If it only takes a day, I’ll defer to you. It would take me a bit longer, lol.
@thheller piggieback also has :cljs/quit
but I think this wipes the cljs session clean, therefore the conversation about adding :cljs/pause
and :cljs/resume
there.
@jmckitrick It’s something like an hour of work, but who has an hour these days. 🙂
I do think that this is pretty important, though, so I’ll try to do it as soon as tomorrow.
@bozhidar I know what you mean. I’ll work on documentation, then.
if all supported cljs sessions are suspendable, we could more mimic shadow-cljs. That's why i was saying there might be some benefit in making a custom jack-in-shadow-cljs
and then making the current piggieback workflow work like that. and then unify them into a cider-jack-in-clojurescript
with a single repl
What exactly would be special about jack-in-shadow? After all apart from running different commands you’d be doing exactly the same thing as for piggieback - you start a clj repl and evaluate some expression in it to convert it to a cljs repl. The only difference I see is that with shadow we’ll know definitely in advance what type of REPL to start - with piggieback you can never know if the users wants rhino, nashorn, node, etc. If they have a figwheel dep that’s probably what they want, but you can never be certain. Same for weasel.
so if those mechanics work, if we get piggieback to be suspendable and not require a separate repl, all the other workflows would naturally just then be configuration in the shadow jack in workflow
what if I start build for :build1
then pause it, start build2
, pause that. how do I get back to 1 without going through 2
Yeah, yeah. But those details are not a big deal in the end of the day. To make what you say work we’ll also have to add provisions to all eval commands to toggle the repl type depending on the type of the source buffer (.clj or .cljs). I’m also wondering what are we supposed to do when evaluating code from a .cljc file. Now it’s easy - we send it to both REPLs, but if there’s just one I guess we have to decide if we want to run the clj code, then the cljs code and the quit cljs for each expression.
> Now it’s easy - we send it to both REPLs, I don't like this and I want to remove it
That’s why I generally prefer the idea of being able to send the code type as a parameter to eval
- makes of this “magic” redundant.