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.

šŸ‘ 4
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. šŸ™‚