@cpmcdaniel I published a version yesterday, probably fixes your issue π
Confirmed. Thanks for the fix.
FWIW, I was doing some stuff with Leiningen yesterday (ugh!) and Chlorine's new nREPL stuff connected to it just fine and worked very smoothly!
Great! Let me know if you find any issues, but I am glad that its working π
Running clojurescript β1.10.597β I cannot seem to connect to a clojurescript socket repl using the following command (the browser opens correctly, but Chlorine never triggers the blue βconnected to replβ notification)
clj -J-Dclojure.server.browser="{:port 4444 :accept cljs.server.browser/repl}" -- --main cljs.main --watch "src" --compile app
However, if I pull in the latest clojurescript repo, build it locally, making β1.10.663β available to me, and then run the above command I can successfully connect to the cljs socket repl through atom.
Is anyone able to connect to the REPL from the above command using version β1.10.597"? :thinking_face:I mean no offense by this line of questioning, but I am generally curious. Several years ago I found proto-repl and was excited about some of its visualizations (especially since it looks like Light Table had been abandoned by Chris Granger). However, for reasons I moved back to emacs and have just started using Atom again, only to discover that proto-repl was practically abandoned. I am wondering why Chlorine was started new instead of taking over proto-repl? Are there plans to implement some of the visualizations such as the call stack graph, charts, and the ability to extend with custom visualizations? @mauricio.szabo
I can't speak for Mauricio but I suspect part of it was wanting to have an Atom package written in ClojureScript rather than CoffeeScript. I did a bit of hacking on ProtoREPL back in the day when I was using it and I hated working in CoffeeScript π
I think there was also great value in providing a solution for a Socket REPL instead of nREPL. That was the main thing that drew me to Chlorine initially -- not needing any dependencies on the server-side, so I could have the exact same editor experience with a local JVM as with a remote JVM process.
FWIW @cpmcdaniel I was also a LightTable user (and I'd hacked on that source a bit while I was using it) and I was also pretty disappointed when Chris moved on. I was excited about ProtoREPL when that appeared and disappointed when it too was abandoned. Just glad to have a very active maintainer for Chlorine π
It's probably also worth noting that Chlorine is designed as a set of core, reusable tooling that could be used with multiple editors -- there's a VS Code version of Chlorine as well, built on the same core.
Hi, @cpmcdaniel, don't worry, no offense taken. The story goes wayy back, but it starts with me contributing to Proto-REPL π. I did lots of code on it to support multiple things that were missing on my workflow, adding callbacks, emitters, and so on.
Then, I created another package that would extend some functionalities from proto-REPL, called clojure-plus
. It solved some issues on asynchronous evaluations, refresh namespaces, and added support for ClojureScript to live side-by-side with Clojure.
But I found lots of limitations on this approach. For starters, the support for ClojureScript over nREPL was really bad - very slow (I'm talking about 5s to evaluate a simple (+ 1 2)
, for example), unreliable (lots of time it simply disconnected and I had to re-connect everything), and it sometimes would even confuse the compiler (at the time, figwheel was the best choice, figwheel-main didn't exist). I also wanted to add better support for inline results (for example, there were multiple results that just confused proto-repl because it was using some kind of interop between ClojureScript's EDN parser and CoffeeScript)
@mauricio.szabo That's fascinating history -- thank you! I have so little experience with ClojureScript that I was never exposed to those problems (but I still had an underlying dislike of nREPL π ).
Also, and this is completely unrelated to proto-repl, programming a package on Atom with JS or Coffee is less than ideal - you write some code, save, reload Atom, connect everything... I wanted a better way, so I started to research on how to work with ClojureScript. If you look at clojure-plus
, you'll see lots of CLJS code over there, but again, it was less than ideal π
@seancorfield I think I'll transform it into a post π.
Now, just to finish the reason for the new package, when I discovered shadow-cljs, things became way better - if you try to hack something into Chlorine today you'll see there's auto-reload inside Atom - no need to restart anything. So, I forked clojure-plus
, renamed it to Chlorine, and began to work on a package that would connect to Socket REPLs. Chlorine now supports nREPL too, but it is primary a Socket-REPL package, and also support nREPL - not the opposite. To be able to make proto-repl works like this would mean to rewrite lots of things, so it made sense to start from "almost scratch" π.
I have to say that my hacking on Chlorine with the live-reload was by far the most pleasant editor hacking I've done so far π
More so than emacs π?
My hacking on Emacs was never very pleasant, in the 20 or so years I used it on and off π
is parinfer the parens-wrangler of choice?
I have both Parinfer and lisp-paredit installed -- I prefer the former for general code input since it handles parens and indentation automatically, but the latter provides more advanced structural editing.
actually, it's the structural editing I was after.
please do - looking forward to it β€οΈ