chlorine-clover

About Chlorine for Atom and Clover for VS Code: https://atom.io/packages/chlorine and https://marketplace.visualstudio.com/items?itemName=mauricioszabo.clover
mauricio.szabo 2020-04-05T00:56:28.045400Z

@cpmcdaniel I published a version yesterday, probably fixes your issue πŸ™‚

cpmcdaniel 2020-04-05T20:05:57.050800Z

Confirmed. Thanks for the fix.

seancorfield 2020-04-05T01:45:18.046200Z

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!

πŸ’― 1
πŸŽ‰ 1
mauricio.szabo 2020-04-05T01:46:59.046900Z

Great! Let me know if you find any issues, but I am glad that its working πŸ™‚

athomasoriginal 2020-04-05T16:12:15.050Z

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:

cpmcdaniel 2020-04-05T21:08:02.054800Z

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

seancorfield 2020-04-05T21:17:30.056200Z

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 😞

seancorfield 2020-04-05T21:19:37.057900Z

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.

seancorfield 2020-04-05T21:23:37.059800Z

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 πŸ™‚

seancorfield 2020-04-05T21:24:31.060900Z

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.

mauricio.szabo 2020-04-05T21:45:33.064200Z

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.

mauricio.szabo 2020-04-05T21:48:14.067200Z

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)

seancorfield 2020-04-05T21:50:21.070400Z

@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 πŸ™‚ ).

mauricio.szabo 2020-04-05T21:50:41.070700Z

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 πŸ˜„

mauricio.szabo 2020-04-05T21:50:58.071100Z

@seancorfield I think I'll transform it into a post πŸ˜„.

mauricio.szabo 2020-04-05T21:54:24.075Z

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" πŸ™‚.

seancorfield 2020-04-05T21:55:43.075700Z

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 πŸ™‚

1
jaihindhreddy 2020-04-07T08:53:24.080700Z

More so than emacs πŸ˜‰?

seancorfield 2020-04-07T15:59:25.081800Z

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

πŸ‘ 1
cpmcdaniel 2020-04-05T22:03:48.076100Z

is parinfer the parens-wrangler of choice?

seancorfield 2020-04-05T22:23:05.077400Z

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.

cpmcdaniel 2020-04-05T22:23:39.077900Z

actually, it's the structural editing I was after.

2020-04-05T22:24:14.078Z

please do - looking forward to it ❀️

βž• 2