This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-08
Channels
- # aws (3)
- # beginners (126)
- # boot (19)
- # cider (31)
- # cljs-dev (324)
- # clojure (96)
- # clojure-boston (2)
- # clojure-denver (9)
- # clojure-dusseldorf (2)
- # clojure-greece (4)
- # clojure-italy (5)
- # clojure-losangeles (1)
- # clojure-spec (18)
- # clojure-uk (59)
- # clojurebridge (1)
- # clojurescript (184)
- # community-development (29)
- # cursive (2)
- # datascript (2)
- # datomic (5)
- # emacs (1)
- # figwheel (6)
- # fulcro (270)
- # hoplon (2)
- # jobs (1)
- # jobs-discuss (1)
- # keyboards (2)
- # leiningen (2)
- # london-clojurians (2)
- # luminus (10)
- # mount (1)
- # off-topic (26)
- # onyx (8)
- # other-languages (1)
- # parinfer (1)
- # protorepl (6)
- # re-frame (23)
- # reagent (61)
- # reitit (5)
- # shadow-cljs (100)
- # spacemacs (3)
- # sql (19)
- # unrepl (90)
- # vim (25)
It’s a bit more efficient to do it as mentioned there, but it’s confusing for many people reading the code afterwards. The reason for the recommendation is that everything’s implemented in terms of macros and inline functions that are expanded during the compilation phase, so in the end you don’t really end up including any new definitions from there.
when M-x cider-grimoire getting "Bad url: /" ... help
can't seem to resolve the issue.
in a clojure file, while pointer is in, say, the word conj, invoking cider-grimoire via M-x cider-grimoire, which causes "Grimoire doc for (default conj):" to appear in the minibuffer... accepting the default by hitting enter produces in the minibuffer "Bad url: /" .
I didn't find this error mentioned much while searching online, so not sure what's up.
if I supply a different string for it to search grimoire for at the prompt, I get the same result.
I'm on 24.5.1
grimoire did work once, if I recall right
in this version, I mean.
well, an obscure one relating to some strange state in my system, no doubt.
and no really critical, as I can just look it up in a browser.
but thought I'd bounce it off #cider to see if anything sprang to mind here.
I don’t know - seems to me something like this should work just fine on 24.5 as well.
Here’s an interesting 🐛: https://github.com/clojure-emacs/cider/issues/2233 We may even kill 2 🐦s w/ 1 🥌 if this is the cause of #1936 as well: https://github.com/clojure-emacs/cider/issues/1936
@U051BLM8F @gonewest818 If you could reproduce and confirm, that’d be great. Want to make sure I’m not 🔩s
confirmed. I can reproduce that too. I’m using Emacs 25.3 and cider 0.17.0-snapshot.
I'm interested in trying to use custom/multiple REPLs to interact with processes, after a Stuart Halloway talk last year. It appears that's not possible in my current dev environment due to https://github.com/clojure-emacs/cider/issues/2017
is there anything I can do to help with this bug? or, should I be looking into changing up my environment, like using inf-clojure or something?
Inf-clojure might be a better tool for that because it does not assume anything I guess, have you tried with that?
@richiardiandrea Not yet. Since my spacemacs/CIDER set-up "Just Works" for most stuff I've been trying to avoid getting into devtooling
Ah! Especially with Emacs 😺
I can’t quite tell if this accomplishes what you need, but you can start a tools.nrepl server on a different port and get a second repl connection using M-x cider-connect
.
user> (require 'clojure.tools.nrepl.server)
nil
user> (clojure.tools.nrepl.server/start-server :bind "localhost" :port 9999)
#clojure.tools.nrepl.server.Server{:server-socket #object[java.net.ServerSocket
"0x6200214e"
"ServerSocket[addr=localhost/127.0.0.1,localport=9999]"],
:port 9999,
:open-transports #object[clojure.lang.Atom
"0x3af6099b"
{:status :ready,
:val #{}}],
:transport #object[clojure.tools.nrepl.transport$bencode
"0xf75b0f8"
"clojure.tools.nrepl.transport$bencode@f75b0f8"],
:greeting nil,
:handler #object[clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__5306
"0x69ee663f"
"clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__5306@69ee663f"],
:ss #object[java.net.ServerSocket
"0x6200214e"
at this point you can M-x cider-connect
to port 9999 and have two separate repls into your server process. In practice you need to keep the object returned from start-server
(I let it print to the repl so you could see), because that’s the object you pass to stop-server
when done.@gonewest818 Cool thanks! I will at the very least file it with my notes on the topic, as I haven't exactly decided what I'm going to do with sub-repls, just that they seem like an interesting way to attack a class of problems