This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (3)
- # beginners (41)
- # boot (7)
- # cider (16)
- # cljs-dev (8)
- # cljsrn (2)
- # clojure (214)
- # clojure-austin (4)
- # clojure-russia (52)
- # clojure-spec (8)
- # clojure-taiwan (1)
- # clojure-uk (10)
- # clojurescript (87)
- # cursive (14)
- # datascript (34)
- # datomic (11)
- # dirac (55)
- # emacs (12)
- # hoplon (44)
- # luminus (6)
- # lumo (24)
- # off-topic (1)
- # om (8)
- # onyx (7)
- # overtone (2)
- # pedestal (1)
- # protorepl (4)
- # re-frame (7)
- # reagent (1)
- # ring (4)
- # rum (2)
- # slack-help (1)
- # spacemacs (2)
- # specter (32)
- # unrepl (131)
- # untangled (14)
- # yada (3)
@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.
Cool, I remember we spoke about that, but wasn’t sure to what extent that was already implemented.
@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’m going to have to write a PoC CLJS REPL ASAP to get my head around what’s actually required.
I have back-pedaled on the idea of standard commands a bit. A standard utils lib would be much more appropriate.
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 ...
sure it is nice to be able to do that, but as you said when in comes to CLJS you often have multiple processes
yeah as you said above: the CLJS tooling is a bit more complex as the REPL sometimes is just an afterthought
I'm more just wondering about backgrounding processes in general and the needs of different tools and users
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
Not really. Commands don't make in multiplexed. Most commands defined so far are related to the session (connection) they are not independent.
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.
This will likely lead to tool makers creating commands that launch and communicate with processes.
each tool is going to have a different philosophy about how to approach this problem
Not simpler. More familiar. And not easier if you need any kind of session management.
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.
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
If 1 HTTP connection = 1 session then it's not a session it's a stateless request response. However the discussion is drifting away.
yes, but that is what I was talking about. sometimes you just want to do one request and get one response.
I believe Rich made that point already: you can do request/response over a REPL, you can't do a REPL over request/response.
wrote something about that recently. we are using the REPL because we love it. but tools don't love it
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
user=> (apropos "assoc") (clojure.core/assoc clojure.core/assoc! clojure.core/assoc-in clojure.core/associative?)
I'm just saying that it may be helpful to think in terms of streams only first and see where that leads
what I see as a problem with regards to CLJS is that
@U05224H0W Why? Unrepl doesn't rely on round tripping values. Just "single tripping" representations.
not sure I understand what you mean. I meant to say that for a CLJS REPL the
:eval result is always a string.
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
When you eval in CLJS, the result gets printed on the JS side. This print needs to be replaced.
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
I'm just coming to the conclusion that sometimes a REPL should just be a REPL aka. a stream of text
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).