@ewen I following the example project, It works. thanks!

What's the road map for replique?

Wow replique is fast! I just tried to (println (range 10000)): in Cider it takes 10 seconds and the repl stalls updating only a couple of times, inf-clojure doesn’t choke but takes almost 15 seconds, finally replique completes in about 4 seconds with a dozen repl updates

@jfntn that's probably because nrepl encodes everything in bencode

the difference between inf-clojure and and replique is probably because the raw cljs repl tries to reorder messages sent by the browser

@doglooksgood I would like to add less, sass and stylus support

@doglooksgood cljs autocompletion for js interop things

if I find a way to do it right

@jfntn oh, you mean at the clojure REPL? then I don't know where the difference between inf-cojure and replique comes from

@ewen as far as inf-clojure is concerned it’s definitely the comint filter

@ewen curious to hear 1) why you started replique rather than build upon cider or one of the existing projects? and 2) what are your thoughts in terms of roadmap and things you want to add?

I think there's a feature should be added, whenever I save the file, it reload the relative namespaces. so that the browser can reload.

And I wonder if it is possible to have es5 syntax for output js file. maybe some additional shim for react native. currently react native did not have a perfect solution.

@jfntn 1) because I did not want to use nrepl and because adding replique style clojurescript support to cider would be a lot of change to cider, so 1) it would be harder to implement than starting from scratch, 2) it would probably not have been accepted into cider anyway

2) there is a lot of things I want to add to replique, css preprocessors support, spec based completion and documentation, classpath reloading

but i may change my mind of course

@doglooksgood if you mean reloading a file on file save, that's not something i am going to add, I want to keep control when files are reloaded, although you can easily hook into emacs buffer saving to implement something like that

@ewen totally agree on 1), I think it’s time to move away from nrepl but unfortunately cider is so dependent on it that it seems to make more sense for them to try and retrofit socket repl into nrepl rather than build on the native stuff directly

@doglooksgood if you mean automatically reloading dependent namespaces, I think it could be useful but I'm not going to add it because 1) that's hard to implement, it requires some amount of global static analysis and because 2) I don't think that's needed in a repl driven workflow where files are often reloaded right after beeing edited

@doglooksgood the es5 output configuration would definitively be useful

@doglooksgood concerning react native, I have no idea what's needed to support react native, but i'm definitively interested in adding that

@ewen are there any large chucks of cider functionality you’d like to implement/port? I can see myself missing the stacktrace popup/navigation and most definitely the debugger

@jfntn you can't retrofit a stream oriented REPL into nrepl. a stream oriented REPL (or socket REPL) is more fundamental than a message oriented REPL. you can build a message oriented REPL on top of a stream oriented REPL but the opposite is not true

actually replique have both, the REPL is stream oriented, and the tooling stuff uses a message oriented REPL

Hmm couldn’t you have an adapter that wraps the socket and parses the stream into messages to restore compatibility? Not saying I’d wanna do that, just doesn’t seem impossible...

yes you can parse stream into message but not the opposite

Don’t wanna bikeshed here since we’re both not interested in a socket-based nrepl, but I don’t understand why you couldn’t do it 2way. Have a proxy take messages in nrepl format and write them to the socket…? Not familiar with nrepl internals at all, so disregard if I’m totally wrong!

you mean by using 2 sockets ?

you can do that but the second socket is still message oriented then, ie the reader still has to parse messages

Yeah I see your point

there is a good discussion about that on the mailing list https://groups.google.com/forum/#!topic/clojure-dev/Dl3Stw5iRVA

@ewen What are your thoughts on emacs/clojure interop? I’ve seen mostly the clj code as strings sent over the wire, as well as the nrepl request payloads with lists of strings. Both of which seem like a maintenance nightmare esp on the client side

Thanks will take a look

It seems like the clojure code should have a clear api for exposing methods to the client, and possibly use macros/templating/code-generation to spit a emacs-lisp library that clients can use?

well the emacs client of replique prints EDN data and reads elisp data, the server read EDN and prints elisp. Implementing a printer is much easier than implementing a reader. On the server side, tooling message handling is done by a multimethod so adding a new tooling message means adding a new method

At first I implemented an EDN reader on emacs side. That worked but was MUCH slower that reading elisp

(and it was much more code too :p)

the only downside I can see is that elisp cannot be extended like edn

If I ever need it to be extensible, I would probably have to implement something like transit

Like an elisp transit codec?

more like a transit-elisp spec

rather than transit-js

but i don't think that will ever be needed

interesting thought though 😉

Do you have any thoughts on debuggers? I’ve been wondering how feasible it’d be to write one as a library to work with socket repl.

The one in Cider is pretty decent, but still pales in comparison to what people use in CL or even scheme and at a glance it seems like this could be a symptom of the implementation being too much of a emacs hack as opposed to a clojure-first effort with an emacs ui on top

cljc support certainly seems like it’d make it tricky...

i have never use a debugger in cl or scheme so i can't tell

but the cursive debugger looks very good, i think that's just a matter of spending a lot of time to make it good

Certainly not a CL or scheme expert but what they have is basically a debugging mode right in the repl. When an error occurs, the repl switches to the debugger right at that frame, and you have a bunch of commands to inspect the environment, step through the code etc

like the emacs one

The emacs tools like slime that build upon that makes for a really great experience

building upon a separate platform (the jvm) definitively makes a good integration harder, although not impossible

Well slime has the same problem really

+ the jvm debugger has good support for multithreading debugging, I'm not sure that's the same story in CL or scheme

There’s probably a lot to be learned from it, though the codebase is huge at this point

a downside of the jvm debugger is that it only keeps track of line numbers, which is not sufficient for lisp languages

Actually this is a lot better in CL because of the restart system that’s more powerful than exceptions. Any error in any thread will yield a debugger prompt, you can inspect and redefine the code while execution is paused, and once it looks like the bug is fixed you exit the debugger and execution resumes from the last restart point (think the last try block) as if the bug never happened. Really cool

Was referring to multi-threaded support, interesting point about line numbers, wasn’t aware of that, not sure how this’d work...

that's the last time i looked though, maybe it improved since

quick google search hints at method entry breakpoints on the jvm

yes but you need the associated line number and column number in the source file

@ewen do you have any interest in supporting boot-clj as well?

@jfntn yes if it does not affect the REPL startup process too much

I'd like to follow along with this clojure setup tutorial (http://www.braveclojure.com/basic-emacs/) but I have an existing Spacemacs config I'd like to keep. What's the preferred way to manage multiple configurations?