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?
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
With two REPLs of the same type, the most recently used will be preferred.
(or at least it should be)
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).
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).
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.
Static session mapping would be great. Simpler is better, right?
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
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.
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?
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
but in lein repl, it works ok
Do you have the class in the src/java/com/dieya/testjava
directory?
no, in src/java/main, and file HelloJava.java
So that's perhaps the problem? š
so ,the package name should be ?
package testjava;?
i put the file in src/java/main/com/dieya/testjava, named HelloJava.java, and in project.clj :java-source-paths ["src/java"]
oh, is that i should remove the main directory?
i put the file in src/java/com/dieya/testjavaļ¼ and in HelloJava.java
package com.dieya.testjava;
but, the same error
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.
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. :)
strange, if i comment the
(:import (com.dieya.testjava HelloJava))
and cider-jack-in-clj, then uncomment the import code, it worksCognitect is sponsoring at least Bozhidar, maybe others doing stuff for CIDER, see https://github.com/orgs/cognitect/sponsoring
that's not a complete list, there are also a few under nubank org and on Patreon
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
@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. ĀÆ\(ć)/ĀÆ
we also buy a lot of IntelliJ Cursive licenses :)
Makes sense but I wouldn't even jokingly imply that someone would consider moving from Emacs to IntelliJā¦ xD
I did :)
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
(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. :) )
seriously though, I do a lot of Java interop and impl and IntelliJ is so good that it's worth it for that
Calva is destilled CIDER. Just sayin' š
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. ĀÆ\(ć)/ĀÆ
many years ago, Cognitect funded Counterclockwise too :)
personally, I enjoyed Clojure on Netbeans the most, don't even remember what that was called now
These are deep cuts, Alex. :)
Enclojure!
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
@dpsutton Did you ever give monroe a go?
i have not. i'l look into it
ah, it's nrepl. i'm staying away from nrepl this year. maybe i'll be back but digging it so far
I heard about years ago at this point from someone who said that CIDER had obfuscated one too many issues for them.
Nice.
What repl are you running in the inferior buffer?
socket repls err day. Absolutely lovely to connect locally to the repo or to a production jar and the tooling is identical
download a released jar, check out the code from that commit, socket repl java -jar the.jar
with a socket repl command line addition
:grinning_face_with_star_eyes: Dev teaching you skills that directly translate to prod :grinning_face_with_star_eyes:
i think it is more built in tooling from Clojure is everywhere
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
how amazingly awesome that a production jar is queryable
Stunningly amazing. :)