Clojurians Log v2

@pez Right now this can’t be done, but we’ve discussed it at some point with @shen. As this would result in changing more than the data encoding we’ve decided to first just return exactly the same data and consider a “richer” format down the road.

How do you plan to handle raw EDN on the client, btw? You might end up having to deal with unknown data readers (for instance)?

This is the rich printing functionality from unrepl?

> How do you plan to handle raw EDN on the client, btw? You might end up having to deal with unknown data readers (for instance)? To avoid burning up my computer just because I have pprint enabled when I evaluate a datomic transaction, I am moving the pprint stuff client side in Calva. I then have the problem that I need to parse the result and those datomic value-symbols do not parse. I solve it by just printing it w/o prettifying in the catch clause. But if I could get the result that I today get as EDN, then maybe I can get a prettifyer to work on it. I haven't tested that yet, because I don't know how to test it. So wanted to check if I could even dream about having EDN in, before I go about figuring out the next step.

Seems like you could write a new server-side pretty printer?

As for unkown data readers. We already have that situation with the non-pretty results, right? They come back as literals. Only if I let nrepl pretty-print it they get unpacked.

Yeah, I should test with providing a server side pretty printer too. I'll try to find the time.

I'm assuming it's the same effort, and it means I can use it too

Fwiw, we could also include default printers for annoying things in common libraries (eg datomic db)

That's a much easier solution really.

@dominicm I agree.

> This is the rich printing functionality from unrepl?

@shen Yeah. Although I think we had discussed this independently before as well.

righto.

guess this could also help if there were a server side printer? https://github.com/nrepl/nrepl/issues/93

I’m a channel zombie but... what’s the status/current thinking on printing? Last I was alive and taked with @bozhidar I think we discussed: 1/ unbundling printing in: * generic preemptible walking (can only done server-side) * layout (client or server) 2/ using unlikely char sequences (unicode provate or ANSI escape code) to intersperse “browsing affordances” in the middle of printed output (for quick regex-powered rendering)

Not sure there has been much more talk? think @bozhidar just talked to me about some of the ideas that's been floating around

Yeah, nothing much has happened. The convos we had with @cgrand in the printer PR are still as relevant as before and we still need to decide on the approach there.

> I’m assuming it’s the same effort, and it means I can use it too Fair enough. Before I go about changing Calva to use EDN Transport and try solve it that way, I’ll look at doing it server side, where we already have EDN (I assume).

In the server, you have values, classes, objects, etc

It's way easier, because you have richer data.

Though it is the data richness that is my current problem. 😃

From https://docs.cider.mx/cider-nrepl/hacking.html > If you’re already using a client that depends on cider-nrepl (e.g. CIDER) making changes to the cider-nrepl code will normally result in those changes becoming immediately available to your client. How do I set things up to reach this nirvana?

I just start lein repl in the source folder of cider-nrepl and connect to it. Pretty simple.

That sound pretty simple, yes.

Wow. that just worked.

Is there a way I can get the same magic with my test project? I mean, I have a test project with which I’d like to use my custom cider-nrepl.

Hi, I use Spacemacs/Cider for my Clojure development. Earlier today, cider results stopped pretty printing for me.

If I eval the following in Spacemacs, it starts working again.

(set! nrepl.middleware.print/*print-fn* clojure.pprint/pprint)

But, I have to this every time a new nrepl session is initiated.

Any ideas why this happened, and worst-case, is there a way to set the expression above in a global config to get back to the desired behavior?

Which version of cider-nrepl is being used?

I'm not sure. It's using whatever Spacemacs installed. Is there a way to get the version?

it'll be in the messages buffer when you start a session. also, can you check m-x cider-version?

CIDER 0.22.0snapshot (package: 20190623.1003)

0.22.0-beta4 <- cider-nrepl version

well nothing in your setup related to CIDER changed today i don't think. is this a new/different project? maybe there are some dir-locals in the other one if so?

Yeah, it's super weird. Spacemacs crashed (loading a very large JSON payload from an API), and then after that, it's been refusing to pretty-print. I spun up a new project with lein to see if it was specific to my existing project, and the same issue persists.

you can m-x toggle-message-logging and watch for the values going over. (i think they are config that are sent over at startup)

haven't dug into the pprinting stuff too much

but i've never regretted watching the nrepl traffic

It’s a pretty ancient CIDER though. Maybe take the opportunity to upgrade it?

I’m pulling my hair trying to test my custom cider-nrepl in another project. make install should do it, right? Except, it doesn’t.

Gonna give that a try.

what lein are you on @pez. some older leins had trouble with that

Now it's working.

2.9.1

Thank you.

@pez in the makefile there's some file that's created to indicate the inlining had been done. try deleting that and lein clean and then make install again

also, make sure that the version you are installing is the version you are using in your projects. if it installs 24-snapshot and the others are using 23 or something you'll not see it

Yeah. I’ve tried bumping it to 27 and such just to force it to use my install. Will try the cleaning now.

touch .inline-deps that one

So I deleted the file .inline-deps, then lein clean and then make install. The inlining happened again. But my version is still not used. So strange…

I start the repl like so:

lein update-in :dependencies conj '[nrepl"0.6.0"]' -- update-in :plugins conj '[cider/cider-nrepl"0.27.0-SNAPSHOT"]' -- update-in '[:repl-options :nrepl-middleware]' conj '["cider.nrepl/cider-middleware"]' -- repl :headless

/usr/local/bin/lein update-in :dependencies conj \[nrepl\ \"0.6.0\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.22.4-SNAPSHOT\"\] -- repl :headless :host localhost is what CIDER cranks up

I’ll try with removing :repl-options and see if that is what causes the strangeness.

not sure if the different style of quoting matters ¯\(ツ)/¯

That would make it not work at all, rather. Not just pull in some wahetevr cider-nrepl. Well, that’s what I think. Right now I am ready to believe anything. 😃