Clojurians Log v2

Hi, just for a fast update on what I'm doing: lots of things in Chlorine are becoming waaay too much "tangled" for me to like. There are lots of room for errors, like "am I evaluating this on the right REPL?" and such. So, I made a quick POC with Pathom to resolve everything that I need to run on commands. So, time for some good news: I'm going to start to refactor lots of Chlorine code in Pathom resolvers. This made the code simpler, more reliable, faster (one of the big problems I was having was calling things multiple times) and less prone to errors (now I just need to test the pathom's resolvers, and everything should work out-of-the-box).

@seancorfield how do you start your deps.edn project to communicate with "that" thing? 🙂

Nothing will change on Chlorine for now. The only difference is that on the config file we'll be able to query things with EQL, instead of different commands like editor/get-current-var for example. But it opens possibilities: for example, clj-kondo emits analysis data while it's linting files. These could be used for autocomplete, goto var definition, documentation for var, etc... without having to rewrite any of these commands to be kondo-aware

Obviously, these will be used if there's no REPL connected. When there's a connection, it'll use the dynamic analysis

@fabrao Which is "that" thing?

(sorry for the slow response -- I was in a meeting)

I start all my REPLs basically the same way: clj -M:test:socket:reveal -- some per-project variations but basically "add in test dependencies, start a Socket REPL server (on a known port), add Reveal and start its REPL".

My Chlorine setup will look for REBL and use it if available but will otherwise just tap> each value -- and Reveal automatically displays those.

@fabrao does that answer your question, or were you asking something else?

thats I want, I can use with clj -A:dev:reveal , I included the reveal line from your deps.edn. Thank you

-M:dev:reveal if you're using Clojure CLI 1.10.1.697 or later (I recommend upgrading if you're on an earlier version!)

Man, too many things to read all the changes that happens in all clojure enviroment

It does take work to stay on top of it all, I agree.

I don't think that Clojure changes that much. Well, it's becoming more and more popular, so more exciting tools are indeed being developed, but I remember when I worked with Ruby, at least once per "Rails version" you had to change lots of things, change lots of APIs, and that was indeed a pain - you had to learn like 3 different dialects of "Ruby-ish code and Rails-ish code" just to work on a single company :face_with_rolling_eyes:

Maybe it's because there's no "single standard framework that 90% of the community uses" like Rails, Spring Boot, Phoenix or whatever that it gives this impression... but I'm glad that this is the case, honestly 😄

Yeah, I agree in general, but I think there are certain key areas where Clojure sees a lot of changes and "most" Clojure devs don't track them all that closely: the Clojure CLI, tools.deps.alpha, where Spec 2 is going... Most everything else in the Clojure world is very stable and evolves only very slowly. Even nREPL/CIDER has stopped breaking everyone's setup with every release these days 😆

If you're not actively trying out the prerelease and/or alpha versions of some of these things, you can get quite a surprise when you update to a "stable" version when it is announced.

Yes, maybe it's because I don't really use too much alpha/pre-release libraries and tools, so it makes sense I don't have this experience :)

Do you use the Clojure CLI @mauricio.szabo?

Only occasionally. In my work I use lein, and for most other things I'm on ClojureScript with shadow-cljs