Clojurians Log v2

@shen I’ve added some basic docs about the new transport here (https://nrepl.org/nrepl/design/transports.html#_edn_transport). I guess we should extend this with some of the things we’ve discussed yesterday about the differences in the request format.

Definitely. I'm keen to do some consolidation-ish work, including documentation

those flaky tests are really annoying too 😕

something different: I was thinking about what's the potential role of clojure spec in all of this, if any

especially given it won't be available in all the clojure versions we support

It could work well as a validation middleware

I think we can run the specs only on the version that we support. That shouldn’t be a big deal.

> those flaky tests are really annoying too 😕

@cichli told me he was pretty busy lately, but he hoped he’d have some time for OSS this week. Fingers crossed.

> Definitely. I’m keen to do some consolidation-ish work, including documentation

Fantastic!

I spoke with the author of Calva and he said he’ll play with the new transport when he gets the chance.

I'm not sure when last did someone check fastlane. It's definitely broken against master

I think I tried it against 0.6.0, and that didn't work either

Really? It certainly worked in 0.5. Guess we messed something up. Would you please file a ticket with fastlane, so we won’t forget about fixing this?

Will do.

do you consider fastlane to be part of nrepl?

(i.e. should nrepl always be tested against fastlane?)

I know it's not part of the artifact because of transit related reasons

Yeah, I do. All projects in the nREPL org are considered official and should always work.

Piggieback is the most important one, and drawbridge also has quite a few users. fastlane is rather new, and doesn’t have much (any?) usage yet, but I hope this will change.

I meant is there some expectation that nrepl master always works against a set of fastlane versions?

there's no matrix to speak of right now

There’s the expectation that it should work with the latest released version, and ideally with the master as well, but that’s not a hard requirement.

Ok.

how can i start testing the new edn transport at work? any easy way to set an option in CIDER or something?

Same question for all the first party transports I guess (drawbridge + ??)

and do changes in nrepl require a new lein based on that version?

depends on what you want to do/test

if you just want to have it up and running, grab nrepl master and follow this https://nrepl.org/nrepl/0.6.0/hacking_on_nrepl.html

there's no clients (other than the one in nrepl) to test with. cider.el probably won't switch to EDN as bencode is easier

i thought i saw that nrepl is now 0.7-snapshot. lein requires 0.6 i thought

so first native client is probably going to be some cljs/js one

ah-ha, I see: https://clojars.org/nrepl/versions/0.7.0-SNAPSHOT

I haven't tried it. I'd guess to get a server running with lein, it's a matter of requiring 0.7.0-SNAPSHOT as a dependency, and specifying the transport in :repl-options

Yep. Or nrepl.edn, as lein respects it.

We’ll bump the lein dep once we release 0.7 final.

👍

> there’s no clients (other than the one in nrepl) to test with. cider.el probably won’t switch to EDN as bencode is easier

Yeah, CIDER will likely never switch to an EDN transport.

That mostly depends on the maturity of the Elisp EDN parser, though.

I just realized that we’ll have to support the EDN transport for things like rich printing in the REPL.

I just tried nprel.edn

but that seems to still start the bencode transport?

Are you sure?

it is :transport and not :transport-fn, right?

(server/start-server
                      :transport-fn transport-fn
                      :handler (ack/handle-ack (server/default-handler)))

https://github.com/nrepl/nrepl/blob/master/src/clojure/nrepl/cmdline.clj#L331

i got my form from nrepl.cmdline-test

Yeah, the server key is transport-fn, but I think it’s transport in the config.

ah apologies

(fwiw, I'm trying to run it from lein repl, but with the 0.7.0-SNAPSHOT dependency. shouldn't that work?)

https://nrepl.org/nrepl/0.6.0/usage/server.html#_server_options

Try it with clj first, I might have made some silly mistake in lein, although I’m pretty sure I tested it with other transports.

(almost) works as expected if I run with clj

spotted a bug...

but it only affected command line info output

this is one of the WIP PRs?

Missed an entry here: https://github.com/nrepl/nrepl/blob/aeb7fa8db04491301cd63019ffc31af64066108c/src/clojure/nrepl/transport.clj#L226

but this is not the issue with lein

I think in Lein we use the same function, right?

In the latest Cursive, I’ve upgraded the nREPL used internally to nrepl:nrepl:0.6.0.

I have a user with a CLJS project using Leiningen who’s reporting that under this version his app breaks at startup, with an error like this:

Exception in thread "main" java.lang.RuntimeException: No such var: nrepl.transport/uri-scheme, compiling:(/private/var/folders/fw/gd1yg_sd5sx_dvqv5pnk6f3m0000gn/T/form-init4758704793550975827.clj:1:3327)
    at clojure.lang.Compiler.analyze(Compiler.java:6792)
    at clojure.lang.Compiler.analyze(Compiler.java:6729)

Cursive doesn’t use that var at all, and I’m awaiting details on what his stack looks like. But does that look familiar to anyone?

I assume it’s a conflict between the new nREPL and piggieback or something similar.

The var that’s required but missing is in the new nREPL namespace though, strangely.

Actually, I suspect that this might be a lein version incompatibility, and the nREPL upgrade is a red herring. I’m waiting for feedback to confirm that.