Fork me on GitHub
#emacs
<
2016-12-03
>
tianshu04:12:24

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

tianshu04:12:01

What's the road map for replique?

jfntn06:12:03

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

ewen09:12:01

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

ewen09:12:34

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

ewen09:12:33

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

ewen09:12:16

@doglooksgood cljs autocompletion for js interop things

ewen09:12:34

if I find a way to do it right

ewen09:12:18

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

jfntn13:12:42

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

jfntn13:12:47

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

tianshu15:12:18

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.

tianshu15:12:58

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.

ewen16:12:58

@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

ewen16:12:40

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

ewen16:12:50

but i may change my mind of course

ewen16:12:11

@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

jfntn16:12:23

@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

ewen16:12:13

@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

ewen16:12:04

@doglooksgood the es5 output configuration would definitively be useful

ewen16:12:07

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

jfntn16:12:28

@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

ewen16:12:38

@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

ewen16:12:22

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

jfntn16:12:42

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

ewen16:12:27

yes you can parse stream into message but not the opposite

jfntn16:12:17

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!

ewen16:12:52

you mean by using 2 sockets ?

ewen16:12:48

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

jfntn16:12:04

Yeah I see your point

ewen16:12:06

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

jfntn16:12:41

@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

jfntn16:12:45

Thanks will take a look

jfntn16:12:37

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?

ewen16:12:16

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

ewen16:12:02

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

ewen16:12:18

(and it was much more code too :p)

ewen16:12:47

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

ewen16:12:20

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

jfntn16:12:44

Like an elisp transit codec?

ewen16:12:14

more like a transit-elisp spec

ewen16:12:22

rather than transit-js

ewen16:12:55

but i don't think that will ever be needed

jfntn16:12:16

interesting thought though 😉

jfntn16:12:27

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.

jfntn16:12:42

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

jfntn16:12:23

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

ewen16:12:49

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

ewen16:12:27

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

jfntn16:12:41

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

ewen16:12:57

like the emacs one

jfntn16:12:01

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

ewen16:12:31

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

jfntn16:12:52

Well slime has the same problem really

ewen16:12:20

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

jfntn16:12:21

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

ewen16:12:06

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

jfntn17:12:11

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

jfntn17:12:32

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

ewen17:12:44

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

jfntn17:12:03

quick google search hints at method entry breakpoints on the jvm

ewen17:12:33

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

jfntn20:12:57

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

ewen20:12:52

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

kzeidler23:12:24

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?