Fork me on GitHub
#unrepl
<
2017-03-11
>
cfleming01:03:08

@bhauman I would love that, if Figwheel were more isolated from nREPL. I’d like to be able to essentially use it as a lib independent of the REPL tech.

cfleming01:03:34

I know it’s somewhat like that already, but haven’t been down in the weeds enough to know how much.

bhauman01:03:41

you can do this right now

bhauman01:03:02

it is missing a basic api command

cfleming01:03:22

Cool, I remember we spoke about that, but wasn’t sure to what extent that was already implemented.

bhauman01:03:24

the files=changed command

bhauman01:03:32

files-changed

bhauman01:03:48

so that you don't need to start a watcher

bhauman01:03:12

you can turn auto loading on an off

bhauman01:03:20

from the rrepl

cfleming01:03:58

@cgrand Re: the untangle thing, isn’t that handled by having CLJ and CLJS on separate connections? I was expecting to have one for CLJ, one for CLJS and then the client would send to one, the other, or both. So the responses come back on separate channels anyway.

bhauman01:03:27

I think he meant that for client behavior

cgrand07:03:04

I meant both. If the client behavior makes sense.

cfleming01:03:12

I’m going to have to write a PoC CLJS REPL ASAP to get my head around what’s actually required.

bhauman01:03:18

you mean remote cljs repl?

cfleming01:03:17

No, just any CLJS REPL and try to integrate it properly into Cursive.

bhauman01:03:43

maybe start with the quick start and do a nashorn repl

bhauman01:03:35

then graduate to a browser or node repl repl which are remote envs

bhauman01:03:50

then maybe use a figwheel/repl-env

bhauman01:03:09

then try nREPL piggieback

bhauman01:03:40

that should give you the lay of the land

bhauman14:03:34

I have back-pedaled on the idea of standard commands a bit. A standard utils lib would be much more appropriate.

bhauman14:03:51

But one thing that keeps coming to mind is this

bhauman14:03:47

Does this build on a more general implicit pattern of launching processes and managing/multiplexing their various in and out streams?

bhauman14:03:09

And is part of that the ability to background and foreground these processes by redirecting stdin to them?

bhauman14:03:47

And always being able to direct input to the various processes via a "commands" like tag?

bhauman14:03:01

and yes connecting and launching a separate process is trivial and perhaps the best approach to this, but ...

thheller14:03:46

@bhauman doesn't have to be a separate process, could just be a different port.

bhauman14:03:06

not even a different port

bhauman14:03:13

just a new connection

thheller14:03:19

yeah that would work, just meant different port as-in: this is where CLJS lives

thheller14:03:28

connecting to a CLJ port and then upgrading it

bhauman14:03:48

oh yes for cetain

thheller14:03:49

doesn't seem all that useful

thheller14:03:35

sure it is nice to be able to do that, but as you said when in comes to CLJS you often have multiple processes

bhauman14:03:45

well we do have it and you can do it with this model

thheller14:03:59

yeah as you said above: the CLJS tooling is a bit more complex as the REPL sometimes is just an afterthought

thheller14:03:16

and hot-reloading is desired more for example

bhauman14:03:27

I'm more just wondering about backgrounding processes in general and the needs of different tools and users

bhauman14:03:06

a new repl process for everything may be the answer

thheller14:03:24

no, but I don't think this is a REPL issue either

thheller15:03:04

I mean you use the REPL to use the API

thheller15:03:21

but you could be using that API via normal clojure code as well

thheller15:03:04

the issue really is how to deal with all the eventual output you are going to get

thheller15:03:22

and trying to reconcile all that over one *out*

thheller15:03:05

ie. if you have multiple builds running concurrently. or you are connected to a REPL that prints a lot because it is connected to a browser the user is clicking around in

bhauman15:03:16

but it is also being multiplexed anyway with commands

cgrand23:03:58

Not really. Commands don't make in multiplexed. Most commands defined so far are related to the session (connection) they are not independent.

bhauman15:03:06

I'm just wondering if a more general pattern may make the implementation and conception of this trivial.

bhauman15:03:32

And at the same time offer perhaps a better solution for backgrounding and tooling than fire up another connection. But I agree that multiplexing the output is most important.

bhauman15:03:14

but if we are starting to mulitplex input

bhauman15:03:31

to handle interrupt and commands

bhauman15:03:16

This will likely lead to tool makers creating commands that launch and communicate with processes.

bhauman15:03:30

as this is a real need

thheller15:03:48

I'm not too sure about that

bhauman15:03:19

it's debatable

bhauman15:03:36

so for instance

thheller15:03:39

each tool is going to have a different philosophy about how to approach this problem

bhauman15:03:58

For an example apropos in CLJS

bhauman15:03:15

you would need two cljs repls for that

thheller15:03:23

no you don't

bhauman15:03:32

to do it in parallel you would

thheller15:03:48

you don't need a REPL at all for that

thheller15:03:05

you need a compiler-env

thheller15:03:19

that is populated with the files you are interested in

bhauman15:03:47

let's not focus on the specifics

bhauman15:03:53

of the particular example

bhauman15:03:13

there are many macros in the cljs that are intended

bhauman15:03:20

to provide tooling support

bhauman15:03:31

that need to be compiled and interpreted by the compiler

bhauman15:03:46

testing macros for instance

bhauman15:03:14

you can hobble together a way around them

bhauman15:03:24

or you can just use the repl

bhauman15:03:34

and get cross host support

thheller15:03:33

yes .. but .. you just use the REPL to get the information you want

thheller15:03:47

say if that information was exposed via HTTP

thheller15:03:10

you could use that as well and it would probably be a lot simpler

cgrand17:03:43

Not simpler. More familiar. And not easier if you need any kind of session management.

thheller18:03:43

I can't think of a single scenario that would require a session.

thheller18:03:50

none of these do

thheller19:03:51

but FWIW I started implementing a language server for clojure yesterday. the JSON-RPC protocol they use has pretty much the same semantics as nREPL.

thheller19:03:57

as for sessions though: every connection is its own session. I can't think of a scenario where that isn't simpler than trying to multiplex 2+ sessions over one connection

cgrand19:03:30

If 1 HTTP connection = 1 session then it's not a session it's a stateless request response. However the discussion is drifting away.

thheller20:03:20

yes, but that is what I was talking about. sometimes you just want to do one request and get one response.

thheller20:03:29

agreed though that this isn't about a REPL at that point

cgrand20:03:09

I believe Rich made that point already: you can do request/response over a REPL, you can't do a REPL over request/response.

bhauman15:03:19

yes anything is possible

thheller15:03:39

I just mean that we are trying to force so many things over the REPL

bhauman15:03:52

that's what it's for

bhauman15:03:01

its a standard interface to tooling

thheller15:03:05

no it is not

thheller15:03:08

we just made it that

bhauman15:03:04

I said it is a standard interface to tooling not the standard interface to tooling

thheller15:03:05

wrote something about that recently. we are using the REPL because we love it. but tools don't love it

bhauman15:03:05

and as we are focusing on the benefits of using streams directly here

bhauman15:03:59

and because of the real difference in the many clj hosts

bhauman15:03:36

it doesn't seem unreasonable given the history of success that lisp has had using these streams that this is a decent solution for base level tooling that the platform can provide

bhauman15:03:03

this is far and away from my initial suggestion

bhauman15:03:20

the best way is not what I'm talking about

bhauman15:03:38

there ways to do this can be enumerated to the stars

bhauman15:03:52

I've been doing it my own way with figwheel (communication, rpc)

thheller15:03:23

but lets get back to the topic: the actual REPL

thheller15:03:41

not the tooling concerns of apropos et al.

thheller15:03:41

user=> (apropos "assoc")
(clojure.core/assoc clojure.core/assoc! clojure.core/assoc-in clojure.core/associative?)

thheller15:03:50

this is fine when the user types it

bhauman15:03:52

I'm just saying that it may be helpful to think in terms of streams only first and see where that leads

thheller15:03:07

if the tool types it you may want a more structured presentation

thheller15:03:22

lets not mix these concerns

bhauman15:03:28

and yes a valid conclusion is hey let's simply multiplex out

bhauman15:03:45

and create new sessions/processes with connections

thheller15:03:57

what I see as a problem with regards to CLJS is that eval and print happen in the JS runtime

thheller15:03:28

so anything fancy unrepl tries to do with "pretty" :eval results

thheller15:03:41

assumes that the result can be serialized back and forth

cgrand17:03:53

@U05224H0W Why? Unrepl doesn't rely on round tripping values. Just "single tripping" representations.

thheller18:03:23

not sure I understand what you mean. I meant to say that for a CLJS REPL the :eval result is always a string.

thheller18:03:56

in CLJ you can hold on to the actual value, which you could do in CLJS as well but that needs to happen on the CLJS side then

thheller18:03:08

making the REPL implementation a lot more complex

cgrand19:03:00

When you eval in CLJS, the result gets printed on the JS side. This print needs to be replaced.

thheller15:03:49

which just doesn't work some of the time

thheller15:03:55

ie. if your function returned a core.async channel or a promise or just a function

bhauman15:03:35

this isn't what I was talking about ...

bhauman15:03:59

but if you have a better solution to pr-str to serialize the results before sending them back over http to the server you can write a new wrap-fn and implement it

bhauman15:03:41

or we have to make pr-str work better

thheller15:03:01

I don't know .. my ideas are way to fuzzy at the moment.

thheller15:03:50

I'm just coming to the conclusion that sometimes a REPL should just be a REPL aka. a stream of text

thheller15:03:12

If you want more you might not actually want a REPL in the first place

cgrand21:03:27

On inputs multiplexing: the more I think about that the more I realize that making it part of unrepl would make it complex (around the :bye message).

cgrand21:03:52

Inputs multiplexing must happen below unrepl.