unrepl 2017-12-28 | Slack Archive

@rickmoynihan most (if not all) features could be backported to nrepl.

But that doesn’t mean that existing clients would work with “nreplU”.

Some differences: input is not framed, print is split in two: machine printing (server side) and actual rendering (usually client side), hypermedia (elisions)

volrath13:12:29

sounds good, I've been postponing it cause I'm not entirely sure how to do it, but yes, let's discuss it soon 🙂

volrath13:12:23

it is the one thing preventing me to work on unrepl using spiral, which would be cool

bozhidar17:12:05

I think the biggest practical difference is that for almost 3-4 years very little new has happened in nREPL. I’m really hopeful that the pending nREPL reboot will change this https://github.com/cemerick/nREPL/issues/1

bozhidar17:12:23

After 0.3 is out I certainly plan to work on a few improvements there myself.

bozhidar17:12:05

I really hate dealing with clojure-contrib and this made it pretty painful for me to contribute much in the past.

rickmoynihan18:12:10

@bozhidar: when do you think 0.3 will happen? And what changes would you like to see happen?

rickmoynihan18:12:48

ahhh I see you’ve asked the same question on that ticket…

bozhidar18:12:16

Only Chas knows when. 🙂 The fun begin afterwards.

rickmoynihan18:12:00

I’m mostly curious about the fun 🙂

bozhidar21:12:04

Aren’t we all. 😉 Things that are important for me are: * targeting Clojure 1.7 by default and adding native support for ClojureScript * making it easier to defer middleware loading until first usage * making it possible to dynamically load/unload middleware * better handing of huge evaluation results * fixing the open bugs 🙂

rickmoynihan23:12:59

Ouch clojure 1.2.0 by default, I remember you mentioned this at clojureX but hadn’t realised it supported such an old release… Why not shoot for 1.8.0 though? nREPL boot strapping from a socket-repl would be pretty sweet would it not?

rickmoynihan23:12:53

How would you handle huge evaluation results differently? Like unrepl with elisions?

volrath22:12:00

@rickmoynihan ^ there's a fix for what we were talking about last night. two things: it will warn you/ask you for confirmation when you want to kill the REPL buffer, and if you do kill the buffer, it will disconnect every other buffer from that connection automatically

rickmoynihan23:12:26

great! Can I get this from melpa yet or do I need to use git?

volrath23:12:52

run M-x package-refresh-contents and M-x package-list-packages, then search for the updated spiral version and install it, package.el will handle the rest

rickmoynihan23:12:24

:thumbsup: thanks

volrath00:12:58

turns out MELPA has not updated spiral since its release. I've never quite understood what's MELPA's criteria to do so... I bumped to a -snapshot version to see if that fixes it...

rickmoynihan23:12:08

@cgrand: FYI whilst playing with spiral and unrepl I noticed this problem on java 9:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by unrepl.replG__152$classloader to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of unrepl.replG__152$classloader
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Looks like it’s a problem with the module system in java 9; but don’t really know much about that. Could well be a clojure issue, or perhaps the fancy classloading/sideloading stuff you’ve been adding?

cgrand00:12:19

Could you open an unrepl issue?

rickmoynihan00:12:17

Of course 🙂 Just wanted to check it was unrepl

dominicm23:12:52

Makes sense.

2017-12-28

Channels