-
-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose a cljs prepl via socket #508
Comments
prepl suffers from the same problems that nrepl has. Implementing this I feel like I repeat all the nREPL problems (nREPL, not shadow-cljs) all over again. nREPL and pREPL are built for Clojure and not ClojureScript. Sure, we can make it look like Clojure but then we are omitting certain important aspects of CLJS all over again. Can anyone point me to an implementation of a CLIENT that actually uses prepl? I will probably write a more detailed post about this at some point to explain my frustrations with all of this in more detail. Sorry pREPL support is delayed by this. |
https://github.com/Olical/conjure Conjure is a plugin for Neovim that provides prepl tooling. You configure it declaratively by describing a number of prepl servers, and Neovim connects to them and lets you evaluate code over the relevant connection. Return values of various types (ret, out, err, tap, etc.) are collected in a log buffer. |
You configure it via {:source-paths [...]
:dependencies [...]
:prepl {:app 12345}
:builds {...}}
Some open questions about the operation of the prepl servers.
Currently they are started with the
As I tried outlining here there are scenarios (common, not unlikely) where there is either no connected JS runtime at all or many at once. So it might be a browser build where the user hasn't loaded the page, or the page could be open in multiple browsers (eg, chrome + firefox). Currently if there is no runtime connected at all a new prepl connection is immediately terminated after sending one I don't know what to do about multiple runtimes. There should be some way to "select" a given runtime but given prepls design that isn't easy.
When a prepl connection is made one runtime is selected. That runtime may disappear and re-appear or not (eg. browser reload). Currently I decided to disconnect the prepl connection when the runtime disappears (after sending an |
This is fantastic news! I know it'll be a key use case for Conjure, having more and more easy was to hook a tool up to an environment via a prepl will help get newer users up and running really quickly. I'm not sure if it helps, but my approach with prepls has been to have one per environment, so if I was starting multiple ClojureScript environments I'd start a prepl on a port for each one, that may not be possible with your constraints but I thought I'd mention it. I'll try it out with Conjure soon 😄 thank you so much for this! |
@Olical that is already supported. You can run one prepl per build each on its own port. That however does not address the "runtime" issue I described. Pretty sure the other CLJS REPLs don't address that problem at all and just pretend it doesn't exist. Figwheel has some support but I'm not sure how it works with prepl. One simple example: Using The problem isn't isolated to the Browser. Same can happen for
I have an internal REPL protocol that I'll might expose publicly and document a bit which addresses all these issues and is currently in use by the UI. I tried making a quick video showing how the UI currently displays the runtime information and how you can pick one particular runtime directly from the UI. Runtimes are added the moment they connect and removed if they are closed. The UI isn't quite finished and I don't actually want to run a REPL in the UI itself. Just using it as a testbed for how I'd like things to work. The problem is that currently no editor even attempts to show this information, probably because that information isn't available from any other REPL impl. |
Ah I understand what you mean now, thanks for the explanation! I would argue you go for the first environment and maybe disconnect the prepl if there's nothing there, that way the client will know it's reconnecting to a new environment. Conjure, for example, requires and injects things it needs on connection. If the env is replaced but Conjure doesn't know it might die when you try to execute certain things, which isn't the end of the world. If it gets kicked off the prepl though that'll help a lot. |
@thheller Nice explanation. I think this is the sort of content which would be great in a FAQ section of the documentation. (or a link to this issue to draw attention to the content). It is one reason I really like shadow-cljs - you put in the time to discuss and explain, which is very appreciated. |
Noting here for future reference, here's my guide to prepls for tool authors: https://oli.me.uk/clojure-prepl-for-tool-authors/ There's still a few things in the shadow prepl that aren't quite right but I hope I (or anyone else!) can help Thomas get them inline soon. There's so many people coming to Conjure because they want to use it with shadow. They'll all be happy to jump on it as soon as it's working 🎉 |
I'm currently trying to improve my understanding of Shadow's prepl support and was trying to get a prepl running for a 1. Enable prepl for the
|
@martinklepsch the
Suggestions on how to make it clearer would be very very very welcome. I keep having to explain this and I don't understand why its so confusing for others. In short if you don't run The dummy builds like The other prepl issues are already listed here: #610 |
Thanks and sorry for asking a question that I seemingly could have answered myself. One suggestion I may have is to add links to the docs to the error messages. At least that way people are more pushed to read those properly first. I guess I didn't consider that I have to run the node script myself because:
Is there a way to start the bare bones I've also tried to run |
This is an aside to the current conversation, but I've started working on a tool to check compliance https://github.com/Olical/prepl-compliance-test Contributions of tests will be much appreciated! I've documented it a little, hopefully it's easy enough to get started and running. I only had an hour over lunch while eating a sandwich 😬 |
@martinklepsch you can get a prepl for node-prepl by setting |
prepl sort of works but I'm not really interested in maintaining it any further. I'll document shadow.remote a bit more soon so anyone that wants to write a less capable prepl layer can do so as a separate lib. I will likely remove remove all prepl related bits from shadow-cljs completely and maybe provide the current code as an example impl. |
Totally understandable! I think any capturing of the work you put in will
be valuable for others in the future
…On Thu, 4 Jun 2020, 22:31 Thomas Heller, ***@***.***> wrote:
prepl sort of works but I'm not really interested in maintaining it any
further.
I'll document shadow.remote a bit more soon so anyone that wants to write
a less capable prepl layer can do so as a separate lib. I will likely
remove remove all prepl related bits from shadow-cljs completely and maybe
provide the current code as an example impl.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#508 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACM6XMYAMANNQYRYYOUWK3RVAHCXANCNFSM4HWUUIFA>
.
|
Currently shadow exposes a socket repl but some tooling require a socket prepl to work. The most useful one for shadow would be a cljs prepl so that it could share the shadow-cljs context. There is a description of how it works with figwheel on https://oli.me.uk/2019-03-22-clojure-socket-prepl-cookbook/
The text was updated successfully, but these errors were encountered: