Fork me on GitHub
#cider
<
2021-06-30
>
chadharrington02:06:53

I am working on a project which has both a Clojure client and a Clojure server. I want to run two REPLs, one for the server and one for the client. I can start and connect to the two REPLs just fine. When I evaluate code in the server.clj buffer, I want it to go to the server REPL. When I evaluate code in the client.clj buffer, I want it to go to the client REPL. Unfortunately, this seems to be hit and miss. The "Manging Connections" docs (https://docs.cider.mx/cider/usage/managing_connections.html) talk about sessions and various commands, but don't understand how to associate a specific REPL with a specific code buffer. I have tried to use the "recency" concept discussed in the docs, by switching to the appropriate REPL and evaluating a trivial expression. I assume this means that REPL is now the most recent REPL. Then I switch to the appropriate code buffer and hit C-c M-z. Sometimes, the code is evaluated in the "recent" REPL and sometimes it's evaluated in the other REPL. This is very frustrating to me. It seems like there should be a simple command to define the desired association; I am probably just not understanding how this is supposed to work. Has anyone done this? Any examples?

dpsutton02:06:48

I'm not familiar with two repls of the same type. The recency thing is usually for when the repls are clj and cljs, and CIDER gets confused. I'm not familiar with what happens when there are two repls of the same type. If you could file an issue ideally with a repro it would be helpful. I think bozhidar has mentioned he's not a fan of the session management code in CIDER at the moment (lovingly called sesman). I suspect that that will be gutted sooner or later

bozhidar07:06:35

With two REPLs of the same type, the most recently used will be preferred.

bozhidar07:06:44

(or at least it should be)

bozhidar07:06:58

There's currently no way to map a buffer a REPL like it was possible to do in the past - buffers are mapped to sessions and within the sessions source buffers are mapped to connections (REPLs) using sesman's logic (most relevant type, then most recent).

bozhidar07:06:24

As for the future of sesman - that mostly depends on whether I'll find the time and the desire to tackle bigger changes. I don't think that the idea of sessions is fundamentally bad (especially if you have both types of connections for some project), I mostly want to remove the complex session mapping that sesman does with something more straightforward (or at the very least restore static session mapping as an option).

chadharrington16:06:24

Thanks for the replies. Unfortunately, as mentioned, the recency concept is unreliable with two clj repls. I am in the middle of a big project w/ a deadline, so I can't spend more time on this right now. I will try to log an issue with a reproduction in the future.

chadharrington16:06:38

Static session mapping would be great. Simpler is better, right?

dpsutton16:06:17

i think so. inf-clojure has this notion and it is quite nice. In some places it might be less convenient but having the ultimate predictability has its benefits

daemianmack19:07:04

FWIW i just found this thread looking for this same functionality -- two sibling CLJ REPLs, each "bound" to a different CLJ buffer, such that cider-switch-to-repl-buffer in CLJ buffer A moved cursor to REPL A, and in in buffer B moved cursor to REPL B. currently i find myself having to switch namespaces a lot more than i'd like.

zimablue06:07:14

I have this question for two nrepls connected to the same buffer but not in the cider part, don't understand the nrepl part => does nrepl "broadcast" by default if two people connect to the same socket?

vinurs07:06:38

i hava a java file HelloJava.java in src/java/main

package com.dieya.testjava;

public class HelloJava {

   public static String greetMe() {
      return "Hello, this is Java calling!";
   }

}
and set :java-source-paths ["src/java"] then in core.clj
(:import 
   (com.dieya.testjava HelloJava)
   )
but ,when i cider-jack-in-clj, it outputs
error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Exception in thread "main" Syntax error compiling at (app/core.clj:1:1).
	at clojure.lang.Compiler.load(Compiler.java:7652)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:372)
	at clojure.lang.RT.load(RT.java:459)
	at clojure.lang.RT.load(RT.java:424)
	at clojure.core$load$fn__6856.invoke(core.clj:6115)
	at clojure.core$load.invokeStatic(core.clj:6114)
	at clojure.core$load.doInvoke(core.clj:6098)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5897)
	at clojure.core$load_one.invoke(core.clj:5892)
	at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
	at clojure.core$load_lib.invokeStatic(core.clj:5936)
	at clojure.core$load_lib.doInvoke(core.clj:5917)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$load_libs.invokeStatic(core.clj:5974)
	at clojure.core$load_libs.doInvoke(core.clj:5958)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$require.invokeStatic(core.clj:5996)
	at clojure.core$require.doInvoke(core.clj:5996)
	at clojure.lang.RestFn.invoke(RestFn.java:703)
	at user$eval140$loading__6737__auto____141.invoke(user.clj:1)
	at user$eval140.invokeStatic(user.clj:1)
	at user$eval140.invoke(user.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7181)
	at clojure.lang.Compiler.eval(Compiler.java:7170)
	at clojure.lang.Compiler.load(Compiler.java:7640)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:368)
	at clojure.lang.RT.maybeLoadResourceScript(RT.java:364)
	at clojure.lang.RT.doInit(RT.java:486)
	at clojure.lang.RT.init(RT.java:467)
	at clojure.main.main(main.java:38)
Caused by: java.lang.ClassNotFoundException: com.dieya.testjava.HelloJava
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:433)
	at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:69)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:586)
	at clojure.lang.DynamicClassLoader.loadClass(DynamicClassLoader.java:77)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:466)
	at clojure.lang.RT.classForName(RT.java:2212)
	at clojure.lang.RT.classForNameNonLoading(RT.java:2225)
	at app.core$eval1595$loading__6737__auto____1596.invoke(core.clj:1)
	at app.core$eval1595.invokeStatic(core.clj:1)
	at app.core$eval1595.invoke(core.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7181)
	at clojure.lang.Compiler.eval(Compiler.java:7170)
	at clojure.lang.Compiler.load(Compiler.java:7640)
	... 34 more

jumar10:06:17

Do you have the class in the src/java/com/dieya/testjava directory?

vinurs16:06:53

no, in src/java/main, and file HelloJava.java

jumar16:06:17

So that's perhaps the problem? 😉

vinurs17:06:48

so ,the package name should be ?

vinurs17:06:57

package testjava;?

vinurs17:06:12

i put the file in src/java/main/com/dieya/testjava, named HelloJava.java, and in project.clj :java-source-paths ["src/java"]

vinurs17:06:27

oh, is that i should remove the main directory?

vinurs17:06:45

i put the file in src/java/com/dieya/testjava, and in HelloJava.java

package com.dieya.testjava;

vinurs17:06:49

but, the same error

jumar17:06:31

The thing is that the package name should follow the directory structure. That is if you have java sources in src/java/ your HelloJava class is in the package com.dieya.testjava then the file should be src/java/com/dieva/testjava/HelloJava.java There might be some other problem but this is the basic convention that's followed in Java projects.

vinurs17:06:43

strange, if i comment the

(:import (com.dieya.testjava HelloJava))
and cider-jack-in-clj, then uncomment the import code, it works

vinurs07:06:02

but in lein repl, it works ok

timvisher17:06:55

Is Cognitect actually not sponsoring CIDER or do I just not know how to list the sponsors properly? I'm asking because Calva lists Cognitect's sponsorship quite prominently on https://calva.io/ which makes it feel very official. :)

Alex Miller (Clojure team)18:06:19

Cognitect is sponsoring at least Bozhidar, maybe others doing stuff for CIDER, see https://github.com/orgs/cognitect/sponsoring

❤️ 2
Alex Miller (Clojure team)18:06:04

that's not a complete list, there are also a few under nubank org and on Patreon

Alex Miller (Clojure team)18:06:23

I'll feature CIDER in a future sponsorship spotlight on the Deref, feel free to tell me what the best list of people/projects is there

timvisher18:06:11

@alexmiller As always you're the best! :) I only noticed this because I jokingly posted in my shop whether anyone had considered moving away from Emacs now that Calva's out and VS Code is eating the world and someone immediately pointed out that Calva's sponsored by Cognitect as a serious plus and I went to go prove that CIDER was sponsored as well and came up empty. ¯\(ツ)

calva 4
Alex Miller (Clojure team)18:06:47

we also buy a lot of IntelliJ Cursive licenses :)

timvisher18:06:31

Makes sense but I wouldn't even jokingly imply that someone would consider moving from Emacs to IntelliJ… xD

dpsutton18:06:09

There’s a wealth of open source and proprietary clojure tooling. I am particularly happy when paid products can sustain people. Glad Colin has built such a great product

timvisher18:06:48

(If it's not clear I've got no beef with any set of tooling so long as it supports RDD. I'm being lighthearted here. :) )

Alex Miller (Clojure team)18:06:08

seriously though, I do a lot of Java interop and impl and IntelliJ is so good that it's worth it for that

☝️ 2
pez18:06:48

Calva is destilled CIDER. Just sayin' 😎

cider 5
calva 2
timvisher18:06:49

The first Clojure shop I ever worked had some decently serious Java components and we literally kept Eclipse around full time just for the job. I'm lucky (?) enough to write very little Java these days so on the very rare occasion that I jump into that space I still feel mostly happy from Emacs. I think if I did really serious work there I wouldn't have the option to stay away from an IDE. ¯\(ツ)

Alex Miller (Clojure team)18:06:30

many years ago, Cognitect funded Counterclockwise too :)

Alex Miller (Clojure team)18:06:11

personally, I enjoyed Clojure on Netbeans the most, don't even remember what that was called now

timvisher18:06:39

These are deep cuts, Alex. :)

dpsutton18:06:09

Emacs as a dev environment and a production ready lisp we’re what got me into clojure. Now I’m on the simplest inf-clojure setup. Just a few handy keybindings to call repl-provided tooling like doc and source

timvisher19:06:03

@dpsutton Did you ever give monroe a go?

dpsutton19:06:15

i have not. i'l look into it

dpsutton19:06:40

ah, it's nrepl. i'm staying away from nrepl this year. maybe i'll be back but digging it so far

timvisher19:06:54

I heard about years ago at this point from someone who said that CIDER had obfuscated one too many issues for them.

timvisher19:06:35

What repl are you running in the inferior buffer?

dpsutton19:06:59

socket repls err day. Absolutely lovely to connect locally to the repo or to a production jar and the tooling is identical

dpsutton19:06:31

download a released jar, check out the code from that commit, socket repl java -jar the.jar with a socket repl command line addition

timvisher19:06:08

:grinning_face_with_star_eyes: Dev teaching you skills that directly translate to prod :grinning_face_with_star_eyes:

dpsutton19:06:40

i think it is more built in tooling from Clojure is everywhere

dpsutton19:06:57

and using the rich tooling built into the language and not relying on more means a jar and a repo are effectively the same dev environment

dpsutton19:06:17

how amazingly awesome that a production jar is queryable

timvisher19:06:59

Stunningly amazing. :)