Clojurians Log v2

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

looks good to me

kind of like a connection factory

why is it called state-machine though?

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

so I first introduced socket-connector

which is the factory stuff to create pairs

oops

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

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

cool

so the latest commit is the state machine

Basically I introduce a state machine to remove the nested handlers

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

there’s a case that should be merged with process

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

@pesterhazy here you go

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

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

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

https://github.com/Unrepl/unravel/blob/7da6d34c29fde7cb31c4a77b580a121b6bd2215c/src/unravel/loop.cljs#L281-L288

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

looks good

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

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

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

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

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

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

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

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

elisp server you mean?

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

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

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

@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

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

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

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

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

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.

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

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

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)

vimscript one is more important :troll:

edn-as-usual would be whatever makes sense

substitution and serialization strategies being dependent on the template type

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

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

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

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

fair enough 🙂

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

yeah good point, didn't think of that