Fork me on GitHub
#unrepl
<
2017-11-10
>
cgrand10:11:28

@pesterhazy please have a look at this WIP and tell me your opinion

pesterhazy10:11:19

looks good to me

pesterhazy10:11:37

kind of like a connection factory

pesterhazy10:11:02

why is it called state-machine though?

cgrand10:11:02

I should have split the refactoring in two, got carried away

cgrand10:11:31

so I first introduced socket-connector

cgrand10:11:52

which is the factory stuff to create pairs

cgrand10:11:28

I did split the refactoring in two but forgot the second part...

pesterhazy10:11:48

btw there's a simple "smoke test" in scripts/tests (you need to start scripts/server in another tab)

cgrand10:11:47

so the latest commit is the state machine

cgrand10:11:34

Basically I introduce a state machine to remove the nested handlers

cgrand10:11:52

(side effect: “started” event is not used anymore)

cgrand10:11:15

there’s a case that should be merged with process

pesterhazy11:11:28

could you create a WIP PR? It's easier to comment that way

cgrand14:11:30

The last one is interesting because it sets the print limit for strings on the aux connection to 2^32-1.

cgrand14:11:05

and doing so it’s possible to use completion and doc anew

cgrand14:11:08

moreover it’s the first use of a parametrized message template

cgrand14:11:04

@volrath and @pesterhazy so no need to piece together elided strings anymore

volrath14:11:03

looks good

volrath14:11:49

although I kept thinking on the tag readers for a bit after one of the questions in the talk. Someone asked if unrepl, as a protocol, could be used to work with any other language other than clj. So the answer is that basically the thing that would have to change would be these action templates, that should accomodate to the particular target language. In that case, transforming those templates to strings instead of code would make sense. For the case of edn readers it's the same: right now a reader would consume the whole message and transform it into a data structure, including the templates. If templates were to be strings, they could be then read again with the proper tag reader substitutions. This would make clients easier to implement, in the sense that they would have to rely only on edn readers instead of implementing tree traversal operations

cgrand14:11:34

You are presuming that the edn reader would work like Clojure one and allow to specify a map of readers for read-time resolution.

volrath14:11:15

Yes, I'm assuming edn readers should implement that feature, as being part of the specification

volrath14:11:40

"It is envisioned that a reader implementation will allow clients to register handlers for specific tags." https://github.com/edn-format/edn#tagged-elements

cgrand14:11:59

A reader that would resolve no tag but preserve them all is also a possibility (see last paragraph)

volrath15:11:51

yes. imo, that would be the second best option, to have an edn reader that won't report errors on unhandled tags and then the client's author would have to walk and replace

cgrand15:11:39

in loanguages with an impoverished data model it could even be the best option

volrath14:11:05

which, again, i don't think is super bad, but just a thought...

volrath14:11:55

for clj/cljs, there's already core.walk and core.zip, but for other languages, the client author might have to figure out how to traverse

volrath14:11:29

(luckily I already made a library to traverse tree like data structures in elisp 😉 https://github.com/volrath/treepy.el)

dominicm14:11:30

nrepl was intended as cross-platform too. It didn't really happen though.

cgrand14:11:05

I tried to not close doors for xplatform but it’s not a priority, we’ll sort out details with it when/if it happens

dominicm14:11:46

It's probably not horrible to have x-platform use edn.

volrath14:11:10

as long as we take elisp into account, I'm good 🙂

dominicm14:11:13

elisp server you mean?

cgrand14:11:45

@dominicm if x-platform emits EDN then it can’t do that on the main connection (as it’s not EDN or Clojure) but only on tooling connections, and it requires to have a edn reader on the server

volrath15:11:53

@dominicm I mean in general, as a client implementation written in elisp is of great importance for the project

cgrand15:11:06

so my current idea would be to tag templates (no tag = EDN), eg #unrepl.template/brainfuck edn-as-usual and then specify how to serialize the instanciated msg to brainfuck.

volrath15:11:54

in this case, where you put edn-as-usual, would that be a string?

volrath15:11:12

I mean, kind of like this: [:eval {... :actions {:interrupt #unrepl.template/brainfuck "some brainfuck code"} ...}] ?

cgrand15:11:24

if you work at the string level you need to know how to 1/ find parameters (with an escape sequence specific to each lang), 2/ escape values (and that may depend on context)

dominicm15:11:32

vimscript one is more important troll

cgrand15:11:18

edn-as-usual would be whatever makes sense

cgrand15:11:40

substitution and serialization strategies being dependent on the template type

cgrand15:11:44

if string interpolation (beware of accidental injection) works for your lang, go

volrath15:11:51

Hmm what I was thinking was more of the form of: [:eval {... :actions {:interrupt "(some-more-edn #unrepl/param etc)"} ...}], so when I client edn-reads a message, the actions are still not entirely transformed to data structure, the client would have to edn-read them again with the correct tag readers (the one that would do the actual parametrization) and they would be ready to use. In case of using a reader that won't accept tag readers, client would have to traverse the action data structure and replace params

volrath15:11:00

now if some one would want to transform an action from edn to, let's say brainfuck, I say they just edn-read the action with the correct tag readers, get their data structure, and then transform from that data structure to brainfuck

cgrand15:11:33

I find this approach hacky and won’t change the default for it.

volrath15:11:01

fair enough 🙂

cgrand15:11:56

actions may be called multiple times (eg autocomplete), so parsing once, finding paths to params and then using the paths (rather walking each time) is a possibility too. Parsing and reparsing to get the benefit of a free walk is a bit wasteful imo

volrath15:11:22

yeah good point, didn't think of that