Fork me on GitHub

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


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


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


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


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


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


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


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


Only Chas knows when. 🙂 The fun begin afterwards.


I’m mostly curious about the fun 🙂


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 🙂


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?


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


@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


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


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


:thumbsup: thanks


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


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


Could you open an unrepl issue?


Of course 🙂 Just wanted to check it was unrepl


Makes sense.