@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.

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

you can do this right now

it is missing a basic api command

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

the files=changed command

files-changed

so that you don't need to start a watcher

you can turn auto loading on an off

from the rrepl

@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.

I think he meant that for client behavior

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

you mean remote cljs repl?

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

maybe start with the quick start and do a nashorn repl

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

then maybe use a figwheel/repl-env

then try nREPL piggieback

that should give you the lay of the land

Will do

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

But one thing that keeps coming to mind is this

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

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

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

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

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

not even a different port

just a new connection

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

connecting to a CLJ port and then upgrading it

oh yes for cetain

doesn't seem all that useful

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

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

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

and hot-reloading is desired more for example

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

a new repl process for everything may be the answer

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

I mean you use the REPL to use the API

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

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

and trying to reconcile all that over one *out*

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

but it is also being multiplexed anyway with commands

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

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.

but if we are starting to mulitplex input

to handle interrupt and commands

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

as this is a real need

I'm not too sure about that

it's debatable

so for instance

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

For an example apropos in CLJS

you would need two cljs repls for that

no you don't

to do it in parallel you would

you don't need a REPL at all for that

you need a compiler-env

that is populated with the files you are interested in

let's not focus on the specifics

of the particular example

there are many macros in the cljs that are intended

to provide tooling support

that need to be compiled and interpreted by the compiler

testing macros for instance

you can hobble together a way around them

or you can just use the repl

and get cross host support

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

say if that information was exposed via HTTP

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

yes anything is possible

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

that's what it's for

its a standard interface to tooling

no it is not

we just made it that

https://groups.google.com/d/msg/clojure-dev/goNt-dPLrHs/kFBCk63wDgAJ

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

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

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

and because of the real difference in the many clj hosts

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

this is far and away from my initial suggestion

the best way is not what I'm talking about

there ways to do this can be enumerated to the stars

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

but lets get back to the topic: the actual REPL

not the tooling concerns of apropos et al.

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

this is fine when the user types it

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

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

lets not mix these concerns

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

and create new sessions/processes with connections

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

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

assumes that the result can be serialized back and forth

which just doesn't work some of the time

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

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

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

or we have to make pr-str work better

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

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

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

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).

Inputs multiplexing must happen below unrepl.