Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2018-03-07

Channels

#unrepl
<
2018-03-07
>
kotarak11:03:13

Should :set-source (optionally?) include the namespace?

cgrand12:03:18

should it evolve in something more general (eg set-env)

kotarak12:03:43

I need now five calls for eval. Set nspace. Set source. Eval. Revert nspace. Revert source.

kotarak12:03:20

That feels clunky.

cgrand12:03:15

and are youd doing the eval on the user connection?

kotarak11:03:03

Eval is now an operator compatible with vim-sexp.

dominicm11:03:47

Woohoo 🙂

kotarak11:03:13

The other flavours will go away.

cgrand12:03:18

should it evolve in something more general (eg set-env)

cgrand12:03:16

@kotarak says >>> I need now five calls for eval. Set nspace. Set source. Eval. Revert nspace. Revert source.

cgrand12:03:19

all of that to evaluate a selection in a buffer

cgrand12:03:47

Evaluating from a buffer is different from the typical repl interaction because: 1/ it’s framed (I usually expect evaluation to fail if selection is malformed) 2/ it overrides most of the repl context

kotarak12:03:49

You got actually another point! Syntax check! So it would be actually six evals.

cgrand12:03:32

syntax check? Isn’t this what I mean in 1/?

kotarak12:03:29

Yes. I don't do it, yet. 😝

cgrand12:03:28

Should this happen on the user connection? why? why not?

kotarak12:03:15

For me it happens at the tooling connection. The user connection is never touched. Maybe the revert could be saved...

cgrand12:03:29

From a UX point of view, is it integrated with the repl buffer/transcript?

cgrand12:03:16

Just to be clear: these questions are meant for all of us, not Meikel alone

kotarak12:03:22

Side-band transmission. Only user interaction is repl buffer relevant.

kotarak13:03:25

That's what I do and will do. It was not that it necessarily has to be that way. (Just to be clear. )

cgrand14:03:48

Now you get :read events for everything that is consumed

cgrand14:03:15

whitespace ✅ malformed code ✅

kotarak15:03:09

Malformed code? How can I resume? Eg. when a trailing paren is missing? I don't know in which state things are when the tooling repl evals some code (eg. a defn) on the users behalf. So I can't resume. The connection has to be reestablished.

kotarak15:03:09

For me the tooling connection is the master where everything is auxed from. So this would be rather annoying.

cgrand15:03:03

Trailing missing paren is not malformed it’s just waiting to be closed. (In a steaming context)

cgrand14:03:59

:read events should cover the entire input

cgrand14:03:29

also there’s a new :file key in the :read payload

cgrand15:03:03

Trailing missing paren is not malformed it’s just waiting to be closed. (In a steaming context)

kotarak15:03:19

Yes. So I still have to check the readability of the snippet.

kotarak16:03:56

Goto considered harmful. ;-)

kotarak16:03:43

Read from string also has the problem of missing source info.

kotarak16:03:29

For now I do syntax check ( and report problems). Problem remaining is that only the last result is reported for several forms in one request. Similar for problems. So this is not really framing.

kotarak16:03:31

Urk. Not even the last, but only the first. :face_palm: I have to implement read tracking. I will see how vim and :offset agree.

cgrand17:03:29

@kotarak all my commits since yesterday are baby steps towards an hopefully better solution.

kotarak17:03:56

I was syncing on prompt. But there might be newlines.....

kotarak23:03:21

How about allowing to set the id part of the responses? That way the clients could identify their frames without changing anything on stream input. Similar to set-source. So far the provided id is of no use to me... (unrepl/do (start-frame)) (form1)(form2) ... (formN) (unrepl/do (end-frame)) ... start-frame returns an id, which is used in the forms' responses. end-frame acts as an await to identify when all forms are done evaling.