Fork me on GitHub
#cider
<
2019-01-30
>
dpsutton05:01:26

someone had asked about an issue here but did they delete it? I'm looking into what is going on

dpsutton06:01:20

if you posted here about oz.core, i think you can fix this issue by adding [org.clojure/tools.reader "1.3.2"] to your project.clj file. CIDER-nrepl is requiring 1.2.2 and causing your issue. I'm surprised that this is an issue as I thought Mr. Anderson would take care of this

hkjels09:01:29

so I’m trying to eval clojurescript blocks in org-mode without having to narrow into them, but cider-read-and-eval does not evaluate on the correct REPL. Any ideas how I would go about this?

hkjels09:01:10

cider-eval-defun-at-point works when I narrow into the code-block

benedek11:01:13

i think nrepl is not inlined/shadowed by mranderson

benedek11:01:43

i suppose you can't really do that due the way messaging is implemented between the nrepl server and client. but can't quite remember the details

dpsutton13:01:55

Yes nrepl is not. But tools reader is and it is resolving to the 1.2.2 version of tools reader from nrepl (which is inline) rather than the 1.3.4 that enlive declares

benedek14:01:48

ah misunderstood

benedek14:01:59

and still confused a bit tbh

benedek14:01:12

let me recheck the github issue

dpsutton14:01:53

i just updated but there's an easy test to show what is going on

benedek14:01:39

hm... checking on clojars

dpsutton14:01:00

lein update-in :plugins conj \[cider/cider-nrepl\ \"0.20.0\"\] -- deps :tree | less

achikin14:01:02

I have a little bit confusing behavior with figwheel-main

dpsutton14:01:08

check this for cider-nrepl versus 0.18.0

achikin14:01:21

I have set up figwheel-main as per documentation

benedek14:01:43

it seems to me that since 0.19 the cider-nrepl jar is published on clojars with all its deps

achikin14:01:58

Then I did lein repl and then (figwheel.main.api/start {:mode :server} "dev")

benedek14:01:12

so 0.18 looks ok, it has only nrepl declared as a dep

achikin14:01:19

Then I'm trying to connect to that repl with cider

dpsutton14:01:22

that's what i'm seeing as well

achikin14:01:26

cider-connect-cljs

achikin14:01:36

And I'm getting an exception

benedek14:01:40

as it should if the mranderson ing was done properly when deploying

achikin14:01:47

1. Unhandled clojure.lang.ExceptionInfo
   A build with id "dev" is already running.
   {}
                  core.clj: 4739  clojure.core/ex-info
                  core.clj: 4739  clojure.core/ex-info
                 main.cljc: 1959  figwheel.main$start_STAR_/invokeStatic
                 main.cljc: 1936  figwheel.main$start_STAR_/doInvoke
               RestFn.java:  445  clojure.lang.RestFn/invoke
                 main.cljc: 1939  figwheel.main$start_STAR_/invokeStatic
                 main.cljc: 1936  figwheel.main$start_STAR_/invoke

achikin14:01:35

It looks like figwheel-main is trying to start the figwheel-main repl server by itself...

dpsutton14:01:08

that's what you expect to happen with (figwheel.main.api/start {:mode :server} "dev") correct?

benedek14:01:32

seems to me that 0.19 maybe and 0.20 was not deployed correctly

dpsutton14:01:58

make install should mranderson them correctly

dpsutton14:01:05

i tried that i think and still saw the same behavior

achikin14:01:21

@dpsutton I'm trying to validate that my team members that are using vscode will be able to connect the repl.

dpsutton14:01:12

ok. so your confusion comes from the fact that cider-connect-cljs tries to start another :dev repl is that correct?

benedek14:01:38

yup looking at the makefile

achikin14:01:39

@dpsutton yes, and it fails to connect because of that

benedek14:01:55

looks ok at the first blink

dpsutton14:01:57

ok. so your coworkers are up and running but now you are a little stuck?

achikin14:01:54

@dpsutton no, they haven't tried yet. We were using lein-figwheel previously and I'm changing it to figwheel-main and I want to be sure that everything goes smoothly.

benedek14:01:30

hm.. not at my laptop atm :/ @dpsutton you mean that when you run make install you still see the the full (wrong) dep tree?

dpsutton14:01:50

i thought that was the case. but i will check again

benedek14:01:01

is there a pom in your local dir?

benedek14:01:11

wonder if that is outdated..

benedek14:01:26

does not get cleaned properly or something

benedek14:01:18

i released refactor-nrepl snapshot lately, same mrandeson version. looks ok on clojars

benedek14:01:32

so something should be with that makefile

dpsutton14:01:14

ah i think i was making 0.20.1-snapshot and checking against 0.20.0 so i was not seeing my test

benedek14:01:53

this basically means tho that cider-nrepl 0.19 and 0.20 is broken deps wise in a very subtle way

benedek14:01:03

eg deps are still inlined i guess (have not checked) but these versions are messing with projects' deps trees

dpsutton15:01:44

feasible to cut new release with a corrected deploy pipeline?

benedek15:01:20

yup looking at my 0.19 jar at work. the jar looks ok the pom looks not mrandersoned

Michael Griffiths16:01:12

I will revert and push a new snapshot now

benedek16:01:26

nice one! thanks

benedek16:01:43

how does that causing this issue?

benedek16:01:31

wonder if we should release a 0.20.1 and modify the machinery in cider tho pull that rather than 0.20.0

benedek16:01:44

maybe this needs a cider release too?

benedek16:01:11

tbh this may not cause issues for most of the ppl

Michael Griffiths16:01:06

I’m not sure why it’s causing it, but reverting it fixes it locally

Michael Griffiths16:01:15

Yeah it’ll be a 0.20.1-SNAPSHOT

Michael Griffiths16:01:20

I’m not sure r.e. the cider release. I don’t know how the jack-in deps injection works these days – I only use cider-connect. I’ll take a look at the code

Michael Griffiths16:01:02

Likely it doesn’t affect most people but will get worse as more people bump their tools.reader deps

dpsutton16:01:09

it should affect cider connect as well

dpsutton16:01:26

if you put cider-nrepl in your project you can step on toes with all cider-nrepl toes

Michael Griffiths16:01:35

Yeah, it does, but I mean I don’t know enough about how jack-in works to know if we’ll need to release a 20.1 of the elisp client

Michael Griffiths17:01:06

Looks like we’ll need to bump cider-latest-middleware-version

Michael Griffiths17:01:53

[cider-nrepl "0.20.1-SNAPSHOT"] is built now if you want to test

benedek17:01:54

looks good to me based on what i see on clojars

benedek17:01:14

and bumping the middleware version means we need a release if we want this fixed in stable quickly

benedek15:01:53

yup only not sure how/where the pipeline is broken

dpsutton15:01:09

ah so the jar is fine but we lied and said we had more dependencies than we had

dpsutton15:01:15

(in the pom)

benedek15:01:30

also i guess we would need to release 0.20.1 or something

benedek15:01:39

releases are immutable i guess...

benedek15:01:48

i think so

benedek15:01:14

have not proven this properly but this is how it looks to me

benedek15:01:28

and the pom is distributed with the jar obviously

dpsutton15:01:58

@achikin is it feasible to let your coworkers start up from the console like that and you just cider-jack-in-cljs and let CIDER start the figwheel server itself?

dpsutton15:01:16

i am able to make lein and figwheel main "just work" this way

achikin15:01:15

@dpsutton yes, I usually do like that. Was just wondering if I can just connect without starting anything...

dpsutton15:01:11

ok i've got it

dpsutton15:01:39

i copied the startup that CIDER uses to crank up a repl so it will have the cider nrepl guts in it but made it not a headless repl

dpsutton15:01:50

/home/dan/bin/lein update-in :dependencies conj \[nrepl\ \"0.5.3\"\] -- update-in :dependencies conj \[cider/piggieback\ \"0.3.10\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.20.0\"\] -- repl

dpsutton15:01:11

from there, do your incantation of requiring the api and starting the {:mode serve} (not server)

dpsutton15:01:24

then cider-connect and run (figwheel.main.api/cljs-repl "dev")) or cider-connect-cljs and when it asks you for the init form give it (figwheel.main.api/cljs-repl "dev")

👍 5
dpsutton15:01:04

it looks like there is no good way to do a custom repl with dir locals right now. it just asks the minibuffer for input

dpsutton15:01:23

@achikin this should get you running

eraserhd15:01:08

Does CIDER have middleware to aid in the selection of text objects? e.g. finding top-level form at cursor, finding element at cursor, and so forth? Or is this done all in elisp?

eraserhd15:01:27

I haven't found any, so I assume its elisp

dpsutton15:01:08

what do you mean aid in the selection of text objects?

dpsutton15:01:19

the first one you mean navigate to definition?

dpsutton15:01:44

oh go to beginning of defun kind of thing?

eraserhd15:01:56

More like that, yes.

dpsutton15:01:10

got you. yes emacs has a built in beginning-of-defun

benedek15:01:36

or look at expand-region.el by magnars

dpsutton15:01:57

there's also (thing-at-point 'sexp)

benedek15:01:04

if you want something with brains ;)

eraserhd15:01:15

For context, I'm kind of rebuilding CIDER for kakoune... So I'm trying to figure out what I can reuse.

dpsutton15:01:24

but text interaction you are in emacs for better or worse

dpsutton15:01:35

oh or apparently you aren't

eraserhd15:01:51

:D ... But would this be a good thing to have in middleware, even for emacs?

dpsutton15:01:59

no that is all elisp. possibly

dpsutton15:01:11

there are edge cases that clojure is more aware of than elisp

dpsutton15:01:17

for instance stacked comment readers

eraserhd15:01:47

Yes, that's one that kakoune has trouble with because it's based on regexs.

dpsutton15:01:58

but you'll run into issues of what does the process think the source code looks like versus what are you evaluating

dpsutton15:01:23

ie redefining defuns. if you ask the middleware for the thing at point it would be the last thing that was evaluated and not some potentially unsaved code

eraserhd15:01:56

I mean, the source has to be sent to nREPL for that to work. So you send a 'code' key and an 'op' of 'find-toplevel' or some such.

dpsutton15:01:35

yes. which means the text editor that does the sending needs to be the one that is aware of the bounds of the defun, what is at point, etc

eraserhd15:01:04

Or it just sends the whole file, which isn't actually prohibitive these days :D

eraserhd15:01:14

I mean, the load-file op does that.

dpsutton15:01:21

when you ask to load a file, yes

dpsutton15:01:38

but if there are top level things and you're sending and reading the entire file content every time you have problems

dpsutton15:01:56

you also won't be sending what you are currently seeing but what is currently saved which could be very surprising and frustrating

eraserhd15:01:21

I'm not sure how sending the entire file when the user requests selecting a top-level form is a problem. Seeing vs. saved seems easy to solve, as the editor needs to send what you are seeing to the middleware.

eraserhd15:01:50

Perhaps that's difficult in emacs? Not really a problem for Kakoune.

eraserhd15:01:19

I guess I don't really mean "file", but "buffer contents".

eraserhd15:01:31

(words are hard)

Karol Wójcik21:01:18

I have no freaking idea why the approach described here https://nrepl.org/nrepl/usage/misc.html#_hot_loading_dependencies does not work for me. For instance I can see that indeed the clojure.core.memoize was added to classpath but for some reason when I try to require it I receive an error :thinking_face:

dominicm21:01:31

Maybe you're checking the wrong class loader

dominicm21:01:40

There's a bug report on nrepl

dpsutton21:01:59

that is just a scary phrase to me. "wrong class loader"

dominicm21:01:11

Clojure has this feature where it uses a different class loader than the context one sometimes. Something about the lein environment causes this flag to be true.

dominicm21:01:36

I have hit a bit of a roadblock in figuring it out there.