Fork me on GitHub
#cider
<
2018-05-19
>
tianshu07:05:02

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?

dominicm07:05:33

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

tianshu07:05:38

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

bozhidar07:05:16

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

bozhidar07:05:34

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

bozhidar07:05:44

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

bozhidar07:05:55

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

bozhidar07:05:01

Guess they didn’t read the manual. 😉

dominicm08:05:56

We didn't find the variables to override for this in the manual! There's only advice for boot and lein.

bozhidar13:05:12

(it’s in the very first section)

dominicm13:05:41

Unless I'm being daft, I can't see anything there that would have worked for edge.

bozhidar14:05:35

Ah, I now get what you mean. I first thought you were talking about the variable I mentioned.

bozhidar14:05:15

Yeah, there are no instructions about the clojure cli in the manual.

bozhidar07:05:53

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

vemv08:05:51

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?

andnils08:05:50

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

vemv08:05:50

@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

dominicm08:05:54

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

vemv08:05:26

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

bozhidar13:05:06

Yeah, that’s the general idea.

bozhidar14:05:05

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

arrdem17:05:25

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

arrdem17:05:49

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

dotemacs07:05:07

Nice. I saw that it was available but figured that it’s not important to register it … cool that you have it now

bozhidar17:05:16

@arrdem That’s awesome! Thanks!

arrdem17:05:49

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

dominicm17:05:05

I wonder what else is available like that...

arrdem17:05:30

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

arrdem17:05:58

see other conversations

bozhidar17:05:01

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

arrdem17:05:17

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

bozhidar17:05:55

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

dominicm17:05:14

Oh, I need to accept

arrdem17:05:20

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

dominicm17:05:55

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

arrdem17:05:18

inbox[infinity--]

bozhidar17:05:49

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

dominicm17:05:09

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

bozhidar17:05:41

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

bozhidar17:05:16

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

arrdem17:05:27

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

arrdem17:05:12

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.

👍 1
bozhidar17:05:14

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)

bozhidar17:05:15

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

dominicm17:05:35

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

arrdem17:05:50

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.

arrdem17:05:06

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

arrdem17:05:31

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

dominicm18:05:05

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

bozhidar18:05:34

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

arrdem18:05:41

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.

arrdem18:05:52

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

dominicm18:05:00

bare socket nrepl? that's a thing?

arrdem18:05:19

According to the readme 😉

bozhidar18:05:57

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

bozhidar18:05:04

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.

bozhidar18:05:52

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

arrdem18:05:32

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

arrdem18:05:57

No need to muck about with Clojure AOT.

dominicm18:05:23

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

arrdem18:05:21

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.

bozhidar18:05:39

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.

arrdem18:05:35

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.

bozhidar18:05:39

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.

dominicm18:05:12

What's this incompatibility you speak of? Growth!

arrdem18:05:11

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

arrdem18:05:47

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.

arrdem18:05:13

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

arrdem18:05:27

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

arrdem18:05:25

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

arrdem18:05:06

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

bozhidar18:05:54

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

bozhidar18:05:02

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

bozhidar18:05:13

Probably the only meaningful change of the two.

arrdem18:05:44

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

bozhidar18:05:02

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

bozhidar18:05:21

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

arrdem18:05:47

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

arrdem18:05:56

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

bozhidar18:05:04

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

bozhidar18:05:17

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

arrdem18:05:18

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

arrdem18:05:34

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

arrdem18:05:21

so many yaks so little time

bozhidar18:05:24

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.

bozhidar18:05:11

You don’t say…

dominicm18:05:48

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

dominicm18:05:55

and empty lists

arrdem18:05:20

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

arrdem18:05:33

we should also update the deployed copy on PyPi

arrdem18:05:32

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.

dominicm18:05:50

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

arrdem18:05:54

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

arrdem18:05:18

'cause Grenchman has its own entire nREPL+BEncode client

vemv18:05:17

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

vemv18:05:03

As a quick bandaid I just removed <appender-ref ref="STDOUT" /> from logback.xml. Although it'd be nice to print logger stdout at lein repl, while not doing so at the CIDER repl

dpsutton18:05:44

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

bozhidar19:05:55

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

vemv19:05:12

Cool! Will be playing with it

bozhidar19:05:08

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.

bozhidar19:05:39

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

bozhidar19:05:10

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

dpsutton19:05:50

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

dpsutton19:05:55

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

bozhidar19:05:08

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

bozhidar19:05:34

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.

bozhidar19:05:48

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.

dpsutton19:05:11

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

dpsutton19:05:31

With piggieback

bozhidar19:05:58

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.

dpsutton19:05:23

Ah yeah good point

bozhidar19:05:06

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

bozhidar20:05:52

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