Fork me on GitHub
#cider
<
2018-08-22
>
magnars07:08:00

Any thoughts on why I get No cljs REPL in current session after starting a with C-c C-x j m (`cider-jack-in-clj&cljs`)? (using custom form) - I have two nREPL-buffers (same port number), one with a clj-repl, the other with cljs.

magnars07:08:14

Can I instruct CIDER/sesman to mark the current repl-buffer as a cljs-buffer somehow?

bozhidar07:08:22

Buffers become cljs buffers automatically when piggieback starts up. Even if you mark a buffer manually as a cljs buffer if piggieback’s not running normally this wouldn’t help much.

bozhidar07:08:35

When exactly do you get the error?

magnars07:08:21

I get the error when doing C-c C-z from a cljs-buffer.

magnars07:08:58

Maybe it is not part of the current sesman-session somehow?

magnars07:08:06

the infobar says cider[not connected] in the cljs-buffer (clj-buffers are connected)

magnars07:08:38

sesman-info gives work/trip-trap:localhost:62550 [*cider-repl %s(clj)*<2>, *cider-repl %s(clj)*] linked-to proj(~/work/trip-trap/)

magnars07:08:53

which looks to me like both repl-buffers are linked

magnars07:08:20

it is <2> that is a cljs-buffer

bozhidar08:08:49

Seems to me that the ClojureScript upgrade did go well for you and that’s causing the problem. You should take a look an the nREPL message exchange on startup and see what’s happening with respect to track-state.

magnars08:08:43

will do. How do I look at the nREPL message exchange?

magnars08:08:18

@bozhidar I have now enabled the nREPL-logging, and connected again (fresh emacs). This time, C-c C-z from my clj-buffers go into the cljs-repl. I also found this:

(<--
  id                 "10"
  session            "523c9f17-8533-4cfa-8445-f338ae9b6424"
  time-stamp         "2018-08-22 10:17:50.454340000"
  changed-namespaces (dict ...)
  repl-type          "clj"
  status             ("state")
)
right after figwheel connects to the browser in the log.

magnars08:08:13

of note, I also get the server-side log messages interspersed with cljs-log messages in the cljs-repl-buffer

magnars08:08:48

the custom code to connect to figwheel is basically fw/start-figwheel! followed by fw/cljs-repl

bozhidar08:08:44

Well, it really seems the repl type detection is broken for you for some reason. Are you using the latest piggieback, figwheel, etc?

bozhidar08:08:28

The check in the middleware is pretty trivial - it just checks for some vars being present.

bozhidar08:08:59

If the REPL is truly a cljs repl you can force the type with M-x cider-set-repl-type, but if it’s not that’s going to revert on each eval.

magnars08:08:17

[com.cemerick/piggieback "0.2.2"] and [figwheel-sidecar "0.5.16"] seems to be the latest?

magnars08:08:52

yeah, it reverted after the eval

bozhidar08:08:43

Oh, problem solved then. 🙂

bozhidar08:08:01

It’s now cider/piggieback and it’s something like 0.3.8 🙂

magnars08:08:35

doh, sorry for taking so much of your time on something like that

bozhidar08:08:50

No problem.

magnars08:08:48

thanks for on point and quick help 🙂

bozhidar08:08:00

Btw, I was in Oslo until yesterday. Should have thought of checking up on you for a beer and an Emacs/Clojure chat. 🙂

magnars08:08:35

ooh, yeah! Next time 🙂

bozhidar08:08:39

Definitely!

richiardiandrea18:08:30

@bozhidar is the new nrepl-cmdline writing a .nrepl-file somewhere?

richiardiandrea18:08:35

was trying to connect automagically with cider and/or cursive

richiardiandrea19:08:21

no it looks like it does not

andre.peric19:08:12

Hi. Not sure if this has to do with Cider: Is there any way to make projectile-find-file or something similar include all dependencies from the current lein project?

bozhidar20:08:22

@richiardiandrea No, it’s not. That was on my todo, but I ran out of time.

bozhidar20:08:22

The only reason I didn’t add it was that I wasn’t sure where exactly to write it. I was thinking of the current directory with an option to supply the path to it.

richiardiandrea03:08:29

this is the perfect solution imho, you probably 80% of the times run clojure in the project root and that is where tools like Cursive read it

bozhidar20:08:27

PRs welcome! 😉

bozhidar20:08:51

@andre.peric Include them how? Projectile’s meant to search only within a project’s directory, so likely the answer to your question is no.

andre.peric21:08:03

@bozhidar by listing them, basically. Yeah, I was looking for something similar to Intellij, which can list dependencies files as well

enn21:08:06

After upgrading to the latest Cider snapshot (today’s), I’m getting this when I try to cider-jack-in:

enn21:08:51

Same error if I pick clojure-cli from the list

dpsutton21:08:52

(cider-jack-in-command "lein") returns "lein" for me. what does it say for you?

dpsutton21:08:40

do the same with cider-jack-in-resolve-command, cider-jack-in-global-optionsand cider-jack-in-params to see which one is problematic. or you could set toggle-debug-on-error and see which one is complaining

dpsutton21:08:48

I would guess the resolve command one

enn21:08:07

(cider-jack-in-command "lein") gives the same error

dpsutton21:08:31

interesting

dpsutton21:08:20

that's quite strange. that function is just pattern matching

dpsutton21:08:52

can you navigate to that function and see what's up with it? debugging won't help much but just see what it looks like and maybe re-eval it?

dpsutton21:08:21

ah maybe i'm out of date 🙂

dpsutton21:08:16

ok. pulled changes 🙂

dpsutton21:08:30

do you have dir locals for your project?

enn21:08:55

I’m not sure what that is

dpsutton21:08:18

because errors with 'lein as a symbol show up as > user-error: Unsupported project type ‘lein’ and errors with "lein" as a string show up as > user-error: Unsupported project type ‘"lein"’

dpsutton21:08:45

have you restarted emacs since upgrading?

dpsutton21:08:39

do you know how to evaluate random snippets of emacs lisp?

dpsutton21:08:03

ok. there are so many different levels of emacs comfort

dpsutton21:08:10

didn't mean to sound condescinding

dpsutton21:08:21

can you eval cider-project-type from a buffer in your project

enn21:08:26

No, that’s fine, my level of knowledge is pretty low, but I know how to eval

enn21:08:15

Hmm, maybe I don’t understand how to do that. I know how to eval emacs lisp in emacs lisp buffers and with M-: but I don’t know how to eval an Emacs lisp expr in the context of a Clojure buffer.

dpsutton21:08:07

exactly as you just said. with M-:. We just need it to be rooted in a buffer in the filesystem which that will do

dpsutton21:08:29

it's gonna go searching the directory for build files to identify what type of project you're in so we need it to run from a good starting point.

enn21:08:34

OK. When I do that I get an error: Debugger entered--Lisp error: (void-variable cider-project-type)

dpsutton21:08:04

well that's interesting. CIDER doesn't appear to be loaded

enn21:08:52

I see cider[not connected] in the modeline, if that means anything

dpsutton21:08:28

can you execute `(cider-version) and tell me what you see?

enn21:08:31

CIDER 0.18.0snapshot (package: 20180822.1325)

dpsutton21:08:38

and (cider-project-type) throws that error above about void variable?

bozhidar21:08:14

@enn Are you sure you’re on the latest build? I had made a small mistake that would explain your problem, but I addressed it only a few minutes later and I’d be pretty surprised if MELPA managed to build the package exactly then.

enn21:08:33

@bozhidar that version is the same listed as the latest at https://melpa.org/#/cider. I’m not sure how to check beyond that.

bozhidar21:08:36

Hmm, maybe they really built then. Can you check if the locally installed package looks like the code before or after this commit https://github.com/clojure-emacs/cider/commit/cc458a4b2c1ab3ebd4ff6e955021eb3b12c4be34

enn21:08:20

checking…

enn21:08:33

@bozhidar the package looks like the code after that commit

bozhidar21:08:45

What’s the full backtrace for your error? I simply can’t imagine where is the "lein" string coming from.

enn21:08:16

Hmm, I can’t find a backtrace. *Backtrace* is empty and the minibuffer just has the one line (even with debug-on-error set to true)

bozhidar22:08:38

Yeah, my bad. There should be a backtrace, of course.

bozhidar22:08:15

Seems for some reason the project type for you is detected a string, although this shouldn’t be the case.

bozhidar22:08:12

Ideally you should debug cider--update-jack-in-cmd with Edebug to see what’s exactly is amiss for you.

bozhidar22:08:24

I’ve tested things locally and everything seems to be fine.