Fork me on GitHub

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

🎉 4
💯 4

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


please do - looking forward to it ❤️


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 🙂

thanks3 4

More so than emacs 😉?


My hacking on Emacs was never very pleasant, in the 20 or so years I used it on and off 🙂

👍 4

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.