hello all, sorry my dumb question but is possible to start more than one repl session?
with Chlorine?
or connect to other repl session if already connected?
You can only be connected to one REPL at a time but it is easy enough to switch between REPLs. I do that all the time.
you disconnect and connect to the other?
Yes. The REPL state remains the same so it's easy to just jump between REPLs as you need.
I often switch between a locally started REPL, a live app running locally, and a live app running on another server.
Just upgraded to 0.7.0 and started rewriting my init.coffee
file in Clojure using the new extension facility -- very nice!
Although I don't think editor/get-selection
works? I've tried a couple of functions based on it and when I execute them, nothing happens at all (well, Atom crashed one time).
Looks like get-selection
is returning {:text nil :range nil}
regardless of whether I have text selected or not.
I have all of my init.coffee
file converted over to chlorine-config.cljs
and everything works, modulo get-selection
not working.
https://github.com/seancorfield/atom-chlorine-setup/blob/master/chlorine-config.cljs
Oh, I'll look at get-selection. Let me see if there's anything I missed
Oh.... get-selection is using a completely wrong destructuring... will fix it.
@seancorfield fixed on 0.7.1 ๐
Hello all, I have a similar question to fabrao above - when working on a fullstack app there will be at least 2 repls I'll want open at the same time - clj and cljs, and often more - another cljs for a node.js server for example. Is there a recommended approach to a setup like this with chlorine?
@mauricio.szabo That works perfectly now! Thank you!
(go click my Chlorine config link again to see the updated version)
I've removed all the init.coffee
code now and I'm doing all of it via cljs -- is there a way to show Atom info/error messages? I switched those to plain println
calls for now.
@danvingo when I have to work with Clojure and ClojureScript, I use shadow-cljs together with lein
or cli
, and start the compilation process on the Clojure REPL
That way, I can migrate between Clojure and ClojureScript with ease
But... two different Clojure REPLs the thing starts to become complicated. I never had to use something like this, but I'm open to suggestions on how to implement it
(or, to be more specific, how to present it - like, how do you select which files are evaluated by which REPL, which REPL is the "active" one, and so on... things are quite complicated today on how things are implemented, specially when you consider the semantics of ClojureScript REPLs)
the obvious UX idea that comes to mind is having UI tabs for each repl, the active tab is the active repl - the nice to have is a keyboard shortcut to switch between them.
(i'm just throwing out ideas, I have no idea how complicated, or not, this would be to implement ๐ )
Yeah. That's why I'm happy to explicitly switch between REPLS as needed. Especially since I'm switching between live processes.
Well, you can have a situation when there's no REPL tab active at all ๐
maybe i just need some pointers on how to switch between repls
And I have my REPL tab mostly minimized
Having Chlorine remember recent REPLs and offer a drop down to switch would be less work than disconnecting and then connecting each time (and having to enter the port each time -- since all of my REPLs are over ssh tunnels or else local on different ports)
For me switching is ctrl-; e ctrl-; y (then type the port and press return)
Yes, this approach can work fine - probably it'll be what I end up doing. Maybe add as a second command, so you don't accidentally disconnect your REPL ๐
yea the drop down of recent connections would work for me too
@mauricio.szabo Not sure if you noticed my additional question among all of that: with the new cljs extension stuff, is there a way to do Atom info/error popups?
Oh, no, I didn't. Yes, there's a way, it's not yet documented, so let me see if I can reproduce here...
Yes, @seancorfield, it's not yet documented (some APIs can change on the future) but there's already a way to call any callbacks that Chlorine registers when it connects to a REPL. For example, the code below will notify on Atom the current selected var:
(defn info []
(let [{:keys [text]} (editor/get-var)]
(editor/run-callback :notify {:type :info :title text})))
Oh nice!
The current list of supported callbacks, and their schemas, are here: https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/editor_integration/schemas.cljs#L70-L90
Oh this is so much nicer than writing CoffeeScript or JS to extend the editor! Thank you @mauricio.szabo -- this is truly awesome work!
Glad that you like it ๐. I'm also using it on some experiments, and as soon as I remove those strange internal state like Browsable
and friends, I believe it'll be easier to hack more complex things!
Hello all, when Iยดm in deps.edn
and I save the file, in Chlorine console shows
java.lang.IllegalArgumentException: "No value supplied for key: true"
in clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
in clojure.core/hash-map (core.clj:387)
in clojure.core/hash-map (core.clj:379)
in clojure.lang.RestFn.applyTo (RestFn.java:137)
in clojure.core/apply (core.clj:665)
in clojure.core/load-lib (core.clj:5934)
in clojure.core/load-lib (core.clj:5928)
in clojure.lang.RestFn.applyTo (RestFn.java:142)
in clojure.core/apply (core.clj:667)
in clojure.core/load-libs (core.clj:5985)
why? The "Should we refresh namespaces when save a file (Clojure Only)?" is onis Chlorine trying to evaluate deps.edn
file?
With simple
refresh, and evaluate on save, probably... I don't remember making a code to disable it for .edn
files, will open an issue ๐
Seriously, just turn refresh off and get used to a tighter REPL-driven workflow instead. Auto-reload/-refresh is a can of worms.
I've been a fan of the reloaded workflow ever since Stuart Sierra's talk, but have increasingly been simplifying the tools I use, as per advice from you and Stuart Halloway. Badly written component impls may create dangling resources on reload, and reloads might get slow in large enough systems. I'm sure there are many more worms from that can. Can you please point out a couple more?
The main thing I've seen is refresh-based workflows which sometimes seem unable to load code after removing definitions that it depends on. When beginners report these problems, it's almost impossible to tell what they've done "wrong" and a restart of their REPL nearly always fixes it.
When I have tried various reload/refresh workflows in the past, they nearly always break in hard-to-debug ways -- and tooling should make life easier not create additional problems.
Since I've moved to a simpler REPL workflow, where I control all of the evaluation/removal/etc, I hardly ever get into a bad state even with a REPL running for weeks at a time.
Although funnily enough I did break my REPL state last week -- for the first time in many months. I think I got sloppy about eval'ing changes and then I removed a namespace to force some global state there to be recreated (`defonce`, protocol, record, something like that), and then a (require ... :reload-all)
broke and it was just easier to restart the REPL than spend time figuring out the incantation needed to get things back to a sane state...
...if it happens again any time soon, I'll probably spend a bit more time figuring out a simple automation for the solution ๐