This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-01
Channels
- # aws (1)
- # beginners (237)
- # boot (2)
- # calva (6)
- # cider (16)
- # clara (10)
- # clj-kondo (1)
- # cljs-dev (24)
- # clojure (29)
- # clojure-brasil (2)
- # clojure-dev (20)
- # clojure-europe (1)
- # clojure-italy (56)
- # clojure-japan (1)
- # clojure-nl (16)
- # clojure-spec (12)
- # clojure-uk (12)
- # clojurescript (24)
- # clojureverse-ops (3)
- # core-async (3)
- # cursive (21)
- # datascript (5)
- # datomic (82)
- # devops (5)
- # duct (14)
- # emacs (2)
- # fulcro (2)
- # jobs (6)
- # juxt (7)
- # kaocha (6)
- # leiningen (19)
- # luminus (3)
- # nrepl (51)
- # off-topic (208)
- # other-languages (1)
- # re-frame (8)
- # reagent (9)
- # remote-jobs (6)
- # shadow-cljs (37)
- # spacemacs (6)
- # testing (12)
- # tools-deps (25)
@bozhidar: Building nrepl from master I get a third behaviour from Calva. With my test script, using the same bencode and nrepl-client as Calva does, I get consistent behaviour across 0.5.3, 0.6.0, and 0.7.0-SNAPSHOT. But with Calva I get that behaviour only with 0.5.3. However, with 0.6.0 I get an ex
message, with a stacktrace pointing me at the same file as you are pointing me at. So I’ll try to see if the nrepl code can help me figure out what I am doing wrong in Calva.
I am not quite following the instructions at https://nrepl.org/nrepl/0.6.0/hacking_on_nrepl.html#_interactive_hacking
One example of “not following” is: “make some changes and test them by starting new nREPL instances from the REPL and connecting to them to see how they are having”.
The example code/session there works. And I do start a server there, is that was is meant in the piece I quoted?
As I am seeing the problems I have only in the CLJS REPL, I need some advice on how to do some interactive hacking towards that. I tried to promote/convert the repl by eval:ing (figwheel.main.api/cljs-repl :dev)
, which might or might not have worked, but don’t really have a clue how to go about it.
There’s a start-server
function in the nrepl.server
namespace. I guess we should make this clearer.
> Building nrepl from master I get a third behaviour from Calva. With my test script, using the same bencode and nrepl-client as Calva does, I get consistent behaviour across 0.5.3, 0.6.0, and 0.7.0-SNAPSHOT. But with Calva I get that behaviour only with 0.5.3. However, with 0.6.0 I get an ex
message, with a stacktrace pointing me at the same file as you are pointing me at. So I’ll try to see if the nrepl code can help me figure out what I am doing wrong in Calva.
I think it’d be easiest for you to just modify that particular function with some debug info and see what’s going on there. What’s the third behaviour you’re getting on master
?
> With my test script, using the same bencode and nrepl-client as Calva does, I get consistent behaviour across 0.5.3, 0.6.0, and 0.7.0-SNAPSHOT. But with Calva I get that behaviour only with 0.5.3.
Yeah, it is a total mystery for me still, despite having trying to figure it out for a while now. But in my test script I force the communication to be synchronous, so it might well be that what goes wrong in Calva is to due with asynchronisity.
With master
I get the value
and status
(`done`) responses, but no out
and no ex
. (I shouldn’t say I don’t get those, I think I do, but that I somehow mess things up so that they are not delivered to my nrepl client.)
I’m using the :master
profile and it sort of works. But it seems that being jacked in to the same server as I am developing causes it to start recursing, so maybe I should go about it some other way…
I’m simply using the dev profile and I’m connecting to the new servers I start afterwards.
Alternatively you can always make some changes, do lein install
and use force the use of that build in profiles.clj
.
Leiningen does not complain when I say I want to use profile dev
. And it seems to work. It also seems to me that I modify the server I am connected to when I evaluate forms in the source of that server. But what you are saying, @bozhidar, is that I should create a new server and connect to that one after modifying the source?
My mind is actually quite blown away by connecting to the server I am modifying. Starting to realize what happened to Cantor…
Yeah, you are in essence modifying the server you’re connected to, although certain things are set when the server starts and those can’t be modified on the fly. For those cases you need to start a new server from the updated code.
I know what you mean. This was super mind bending to me when I started working on CIDER back in the day.
There is a lot of stuff in the msg
map. Is there something in particular I should be looking for?
So, if I start the repl like so:
lein update-in :dependencies conj "[nrepl \"0.7.0-SNAPSHOT\"]" -- update-in :plugins conj "[cider/cider-nrepl \"0.21.1\"]" -- update-in "[:repl-options :nrepl-middleware]" conj "[\"cider.nrepl/cider-middleware\"]" -- repl 2> repl-errors.txt
It prints the following. (I do (printn (pr-str msg))
in that function).My terminal stars throwing away input when it grows to large so I catch stderr in a file. Where we find this error:
Hmm, a StackOverflow is usually in indication of some endless recursion. That’s weird.
Looking at the debug output it seems to be in order, but I assuming that’s from a Clojure session, right?
Yeah, I thought that was the Cantor thing first, but then I noticed that it happened before I connected anything. I’ve seen some other errors that indicate it is the pr-str
.
Also when removing piggieback and other dependencies things crash if I try to reference that mysterious dev
profile. So maybe that profile comes from some of those projects?
When I said dev profile I meant I was under the impression that’s what lein runs by default.
At least I can reproduce the problem using that nashorn cljs-repl and such. But if I try to peek at it, with that println, things blow up. Observation changes behaviour, or something.
Anyone else that can repro the stackoerflow crash? Just tuck that (println "printing-transport msg: " (pr-str msg))
in there and run:
lein update-in :dependencies conj "[nrepl \"0.7.0-SNAPSHOT\"]" -- update-in :dependencies conj "[cider/piggieback \"0.4.0\"]" -- update-in :dependencies conj "[figwheel-sidecar \"0.5.18\"]" -- update-in :plugins conj "[cider/cider-nrepl \"0.21.1\"]" -- update-in "[:repl-options :nrepl-middleware]" conj "[\"cider.nrepl/cider-middleware\"]" -- update-in "[:repl-options :nrepl-middleware]" conj "[\"cider.piggieback/wrap-cljs-repl\"]" -- repl
I'm thinking... Since my first impression was that things started to recurse. Maybe that is what is happening? When I collected the output in that log, it grew very fast. So, maybe the stuff I put in stdout here, gets fed back into the function somehow?
SO happens in 0.5.3 if I add a println
there too. I’m not knowledgeable enough to go figure about it. 😃 But I’m out of ideas on how to inspect the messaging… No.. maybe I can send it to a file…