This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (6)
- # beginners (61)
- # boot (1)
- # chestnut (1)
- # cider (18)
- # cljs-dev (1)
- # cljsrn (3)
- # clojure (176)
- # clojure-android (8)
- # clojure-germany (12)
- # clojure-russia (4)
- # clojure-spec (7)
- # clojure-uk (5)
- # clojurescript (28)
- # css (10)
- # cursive (36)
- # datomic (7)
- # devcards (1)
- # docs (8)
- # emacs (17)
- # fulcro (29)
- # hoplon (28)
- # lein-figwheel (3)
- # leiningen (37)
- # lumo (1)
- # off-topic (54)
- # om (6)
- # re-frame (2)
- # reitit (7)
- # ring-swagger (23)
- # shadow-cljs (115)
- # sql (10)
- # uncomplicate (1)
- # unrepl (24)
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 https://github.com/cemerick/nREPL/issues/1
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?
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
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
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:
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?
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