Clojurians Log v2

@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”.

How do I start new instances from the REPL?

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.

> How do I start new instances from the REPL?

There’s a start-server function in the nrepl.server namespace. I guess we should make this clearer.

> How do I start new instances from the REPL?

You also have to eval a bit of piggieback code for this to work.

https://github.com/nrepl/piggieback#usage

That’s how I typically test cljs interactions.

> 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.

How come you’re getting different behaviour if you’re using the same client? 🙂

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.)

Is there any particular profile I should start when jacking in to the nrepl project?

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.

There is no dev profile as far as I can see.

oh sorry. nrepl 🙂

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?

When I add some printlns to the function I get StackOverflow when it runs…

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

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.

Looks like so. Including some traces of what else I have tried to do. 😃

The session is before I do anything else. So, probably from starting the repl?

It lasts a bit longer if I add :headless.

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.

You can just select Clojure 1.10 or whatever for that matter.

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

Actually it doesn’t matter what I print. (println "foo") results in the same SO.

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?

I don’t see how this can happen. It should act only on middleware responses.

But the SO is certainly indicative of some recursion. Go figure…

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…

Yeah, spitting it out worked. Now dinner, will examine the output later. 😃

is it possible the middleware is set up to handle println and you are println-ing from the middleware giving you the SO?

Sounds very possible to me.