Clojurians Log v2

@cgrand uploaded a file: https://clojurians.slack.com/files/U3E46Q1DG/F8JFYKUUF/pasted_image_at_2017_12_20_04_05_pm.png

there are issues around prompt (which is appears spuriously when suspended) and bindings (one socket repl out appearing in another)

https://github.com/anmonteiro/lumo/compare/master...cgrand:suspension

^^diff

cljsSender is a nasty global when dealing with multiple sessions

(x-post with #unrepl) Brave souls can try to build lumo from https://github.com/cgrand/lumo/tree/suspension on this branch the stock repl (both term & socket) is upgradable Example:

(lumo.repl/suspension-request
  (fn [r resume]
    (let [print-fn *print-fn*]
      (lumo.repl/read-chars r
        (fn loop [s]
          (if (re-find #"bye" s)
            (resume {:value :ok})
            (binding [*print-fn* print-fn]
              (println "you said: " s)
              (lumo.repl/read-chars r loop))))))))

the equivalent clojure code is:

(loop []
  (let [s (.readLine *in*)]
    (if (re-find #“bye” s)
      :ok
      (do
        (println “you said: ” s)
        (recur)))))

@anmonteiro I’d like your opinion on this

@cgrand very nice 🙂 works! Just the damn prompt jumps sometimes into the text field. Easy bug to fix I guess.

I was in the term not socket. I can see this being implemented into inf-clojure right away. Or I may check the status of Daniel's new unrepl clojure mode and try that.

@hlolli unrepl still have to be ported 🙂

yes.. but how I want to use this is basucally something like (socket-send lumo-udp-info-blabla "$c red") -> the suspension receives it and relizes that this is actually a code sent by editor asking for a completion of symbols starting with red. Saveing the "read" part and go straight to eval (or callback).

dollar sign maybe not a good protocol. But this was not toroughly thought idea anyway

with two different connections or only one?

another good point, two connections would be best, but that exceeds my thinking of how to implement one. You've been working with two or more connecions on a single repl?

unrepl.el and unravel use at least 3 connections to the repl

and I have tested lumo with multiple connections, each differently upgraded

Wow 🙂

it’s a bit like tea spoons, you need one or two for the pot 😉

1 for the user, 1 (or more) for tooling, 1 for the classloader

soooo

about inf-clojure, I guess plain repl does not have yet all the fancy features right?

ok that is not possible at all in inf-clojure at the moment. It would be cool to have though...if things go right probably in unrepl.el I guess?

@richiardiandrea I guess I will be quick to stop using inf-clojure. The problem with it, is just that it mixes up the return values too frequently, causes my emacs to freeze and prints code intended for eldoc into the repl window. This is especially annoying when I'm performing music with inf-clojure, that has happened, in Belin night club, that the music haults for a second because inf-clojure didn't know what to do with a list of completions 🙂 not good 🙂

@hlolli yeah well, that is a know problem of emacs being single threaded...however anything can be improved, for instance emacs understands json and the completion logic can be greatly simplified. I spent innumerable hours trying to detect edge cases with regexes on strings...that is why we need a protocol

So to make emacs experience better, then it's either to make lumo respond much faster (the idea of different protocol for inf-clojure->lumo interaction) or cgrand's idea of multiple socket instances, then there's no doubt what emacs should be doing with data coming from x and y udp responses.

well, that won't make lumo faster tough, I think best to mix the both, just call a compiled function for frequent communication of metadata/completions and the different udp instances. At least to minimize reading of clojure s-expressions, determine namespaces, resolve macros, determine if nil should be printed, this chain of reading takes sub-second but longer than millisecond....

@hlolli yes not faster lumo but better tooling can be built around it because now the protocol is solid (no more string parsing), kind of like the idea of using the Server Language Protocol.

if somebody would implement that, emacs + all the other editors (Atom...) would work out of the box

That protocol can be different, maybe in the future this may become a standard. But Atom can if this gets merged, say to lumo "this is how I'm going to communicate with you and this is how I want you to respond with me". Bit slower startup time, but potentially way faster interaction, each time s-expression parsing is avoided.

But Server Language Protocol is what I'm essentially talking about I think.

maybe there can be a unrepl -> SLP at some point

@richiardiandrea what is not possible at all exactly?

To have multiple connections

But I think I can peek at @volrath code for that

What do you mean by plain repl?

I mistakenly thought that the above was doing something more...it's not even the plain repl..sorry!