If I create a file at src/main/clojure/aaa/bbb.clj, (ns aaa.bbb) will be auto inserted, and this is correct. but if I create src/main/cljs/aaa/bbb.cljs, ns will be (ns main.cljs.aaa.bbb). Is this configurable?

@doglooksgood how is your source paths configured? I think the namespace is correct.

actually I create the file before change the deps.edn. I wonder if it will read the aliases extra-paths config?

@dominicm Btw, I did some massive restructuring of the info middleware - https://github.com/clojure-emacs/cider-nrepl/commit/531d980b524baed792b4ebb5fdfef3fe72b787c8 Extracting things to orchard really puts into perspective some bad API decisions. 😄

> I might see about setting cider-default-cljs-repl for edge in dir-locals.el then.

Yeah, that’s how I envision people would normally use this.

> It’s interesting to watch my emacs colleagues use things, and be surprised when they don’t work 😛

Guess they didn’t read the manual. 😉

@doglooksgood I think this is something in clj-refactor. @benedek probably knows.

Hi 👋 Is CIDER integrated with these functions (or similar ones)? https://github.com/stuartsierra/reloaded/blob/master/src/leiningen/new/reloaded/templates/user.clj Or should I be responsible for having these functions invoked?

@vemv I use something similar to this: https://github.com/stuartsierra/dotfiles/blob/d0d1c46ccc4fdd8d2add363615e625cc29d035b0/.emacs#L307-L312

(some tweaking necessary, and then bind to some keyboard shortcut)

@andnils gotchu! yeah, have used similar stuff in the past. But I was wondering if there's a more robust way. Classloading can be funny

You can set a pair of variables to be called before and after cider-refresh

Should I use cider-refresh if using component/tools.namespace etc?

I do.

Yeah, that’s the general idea.

nREPL 0.3.1 is out - I had done a moronic mistake and compiled the Java sources with a Java 10 target. 😄

Dumb nREPL PR - updating the BEncode spec URL as it has changed https://github.com/nrepl/nREPL/pull/27

@bozhidar fyi registering http://nrepl.org just so /someone/ has it

@arrdem That’s awesome! Thanks!

$12 lol thanks Grimoire patrons you fund all kinds of random stuff

I wonder what else is available like that...

😄

we really need to get a better holding entity off the ground

see other conversations

@arrdem I think I already invited you to the org - you can configure some simple GH page (e.g. using the README) under http://nrepl.org.

@bozhidar I don't think I'm an nREPL member but I'll check.

I was certainly inviting people when I created it and I remember you and @dominicm were on the list.

Oh, I need to accept

Not seeing an invite on GH but checking my inbox. I may have missed the invite.

@arrdem navigating to http://github.com/nrepl brought it up

I think only repo invites cause a gh notification (based on this one event)

I'm in!

inbox[infinity--]

Great!

You’ve got all the power. Use it wisely and commit lots of improvements! 😉

I actually don't have much familiarity with the desired improvements to nrepl itself. I should look 🙂

Some are already listed and I have to create a bunch of extra issues.

Generally there’s also a lot of work to be done with respect to updating the code, as it currently targets Clojure 1.2 and Java 5. 😄

I'm going through the list now. What are you thinking WRT Clojure version compatibility?

For all that my aesthetic screams to clean the code up /because/ there's nothing really wrong with it ATM, and I'd like to have a plan for how nREPL's version will state Clojure version compatibility before we go drop 1.2 etc.

I’ve put Clojure 1.8+ and Java 8+ on travis based on the Clojure survey (<5% of people on Clojure 1.7, <1% on Java 7)

Frankly, I don’t think anyone will notice the updates, and some of them would be meaningful e.g.

If the only improvement is to drop support for older versions of things, then that's really not an improvement? 😛

Oh for sure nobody'll notice, I just want to have a plan for more than releasing an 4.0 which just drops older versions.

Eg, we will be on 4.X until we drop support for Clojure 1.8 or something.

Or we'll always do a major version bump when dropping support for a Clojure/JVM version

https://github.com/nrepl/nREPL/blob/master/src/java/clojure/tools/nrepl/Connection.java#L100

https://github.com/nrepl/nREPL/blob/master/src/clojure/clojure/tools/nrepl/ack.clj#L30

I'm probably being daft again, but I don't see what we would gain in exchange for switching to a delay there?

https://github.com/nrepl/nREPL/blob/master/src/clojure/clojure/tools/nrepl/server.clj#L113

Frankly, I’m not sure either - I just saw comments like these here and there.

One thought I had - if we're gonna adopt a "standard" port, we really need different standard ports for "bare" socket nREPL vs BEncode nREPL which is what everyone actually uses.

Since there's now the bare socket repl in Clojure, do we even want to keep the bare repl?

bare socket nrepl? that's a thing?

According to the readme 😉

The code is also full of todos to analyse like this one…

https://github.com/nrepl/nREPL/blob/master/src/clojure/clojure/tools/nrepl/server.clj#L91

https://github.com/nrepl/nREPL/blob/master/src/clojure/clojure/tools/nrepl/server.clj#L102

I’m pretty familiar with using nREPL as an API, but not super familiar with the internal, unless it was something frustrating to me as an end user.

I’m also a bit puzzled about why the Connection class in implemented in pure Java, maybe it was simpler at the time.

May also make embedding an nREPL endpoint in a Java app easier from an FFI perspective.

No need to muck about with Clojure AOT.

I don't see any major features that warrant spending time pulling out support for old versions.

It'd be kinda nice to drop some of the old #^{} notation and some stuff, but yeah I agree it's kinda an aesthetic only upgrade AFAIK.

Well, that’s certainly not a big deal, but then again - I don’t want to spend time ensuring compatibility with something no one uses.

I'd support adding a cider/version_check pseudo-ns of some sort that everything requires / forces so that we have some way to check Clojure and Java's version and tell users about (in)compatability.

And I’ve got this dream of nREPL that could be started with a self-hosted cljs, which certainly would require “a few” changes, but that’s not high up the todo list.

What's this incompatibility you speak of? Growth!

>.>

well in order to get an IANA port assignment we need protocol-level versioning support which may or may not be a breaking change.

also probably means we need different port assignments for a "bare" socket REPL vs a BEncode repl because they aren't really wire-compatable or negotiable - they're different formats.

fun

re-namespacing things if we do that is gonna be another breaking change

dropping support for ancient clojure / java versions would be a breaking change if we decided to do it

and philosophically I don't support burdening yourself with indefinite backwards compatibility as a design goal, especially when we're as ah lightly resourced as we are

Plan for change /management/ because you will want change 😉

Well, it’s done to some extend as I already deleted some compatibility code for Java 5, but I doubt someone is going to notice it. 😄 We’ve also restyled all the ns-es to Clojure 5 syntax or something like this (I don’t quite remember when ns got its current syntax).

> re-namespacing things if we do that is gonna be another breaking change

Probably the only meaningful change of the two.

the existing non-nREPL nREPL clients all seem like abandonware? can't really tell.

I wonder when exactly to do it, as this will require a ton of PRs to other projects.

The only client that matters as Java code is reply, everything else is dead.

I'm an owner on Chas' python-nrepl client which is incomplete anyway

can probably get full ownership of that codebase and move it to the nrepl org if I want it.

Clients that don’t use the API directly won’t notice the change.

Maybe we should move it to the new org at least for historical reasons.

yeah but if/when we do a protocol version handshake something

which is probably the only thing I care to work on besides supporting better custom result handlers

so many yaks so little time

Yeah, that’d be great to have, but we’ll have to have a fallback for current clients - e.g. whatever the “version” was before we introduced this.

You don’t say…

heh

@arrdem https://github.com/clojure-vim/nrepl-python-client/ would prefer we use my tree of nrepl-python-client, it supports crazy things like negative numbers.

and empty lists

@dominicm yeah I definitely want to get them merged / have only one

we should also update the deployed copy on PyPi

I'd suggest that I get Chas' (which shows up on google) moved into the nREPL org, merge your code as a big-bang PR and go from there.

sgtm.

I think I broke the api at some point by switching to binary sockets, but I'm not entirely certain. It works.

🤷 I think you're the primary user anyway and there was never a good documented API so shouldn't be a problem.

'cause Grenchman has its own entire nREPL+BEncode client

^ I realise it might be a Pedestal-specific question, but also stdout handling may be a faq

should all new changes happen on a 4.x release and then once its stabilized go to a 5.x?

@vemv There’s a setting about this in CIDER - cider-redirect-server-output-to-repl.

Btw, that’s one of the biggest improvements on my personal list for nREPL - the situation with output that ends up in the server’s output instead of the clients is quite annoying. We should certainly fix this, so such workarounds are not needed.

There are also some cases when clients receive out messages without a request id attached to them and that breaks stuff.

@dpsutton I’ll likely change the namespace in the next release and mark this as nREPL 1.0 (or 0.4) - I still wonder about this. nREPL has been around for a very long time, so I guess it’s time to release 1.0.

I was just thinking prevent any clients from using the new code unless the opt into it by specifying the new major version

And need to keep @cfleming in the loop for any changes. Can't risk interrupting his product with changes to nrepl

@dpsutton I really doubt most clients would be impacted by the internal changes at all - there will be 0 backward incompatible changes to the protocol for now, you’ll only notice the changes if you’re doing something with the nREPL API (and the changes are one change - the new namespace).

👍

But yeah - if Colin is using the Clojure API of nREPL he’ll have to update a bit of code on Cursive, that’s true.

For me the most painful part is getting this upstream in reply, boot and lein. Everything else should be relatively easy. Luckily it’s a one time deal and we’ll never have to make changes like this again.

There was also just a little hiccup when switching namespaces previously so just want him to be aware and test with us

With piggieback

And, of course, someone will actually have to update their deps to notice something - nREPL is now essentially a different project than the contrib one, there can’t be accidental updates.

Ah yeah good point

Yeah, the middleware breakages are mostly unavoidable, but I’m not that worried about them controlling directly almost all the nREPL middleware in existence. 🙂

If it gets problematic to push for changes upstream I’ll just start booting cider with custom tasks using the new nREPL and update all of my middleware projects to rely on it. Whoever wants to stick to clojure.tools/nrepl can do so, but they won’t have much middleware they’d be able to use with it. 🙂