Clojurians Log v2

the reason that com.taensso.encore is partially included is that it is (unfortunately) used by taensso.timbre. I included just enough to make that work without adding more which adds to the binary and isn't generally useful for scripting. you can you try to load the namespace from source by using (require '[taoensso,encore] :reload)

I assume the , isn’t some fancy special incantation, and is instead a typo

typo

Yeah, given that the reader would elide it 😄

Tried it in my current sessions:

The :reload trick does successfully force bb to load from the source jar on the classpath (the encore jar is found and read), but it still fails — just
  for a different reason: bb's SCI runtime doesn't support java.util.function.UnaryOperator (a Java class that encore's full source imports). So the
  namespace can't be compiled under SCI regardless.

so that’s out 😄

yeah we can add that to bb I guess, java.util.function.UnaryOperator, if you're patient enough to go through these issues with me ;)

it really isn’t that important right now. THe number of functions I use is minimal…just inconvenient. I’m sure there are more pressing/important things

I see encore even includes custom Java files https://github.com/taoensso/encore/blob/master/src/java/com/taoensso/encore/Ids.java that's a no go for bb right now

I wish the author of timbre etc wouldn't include these sub-libaries, there's so much churn in those

I would agree. I’ve complained about that myself. Things disappear, move to other libs, etc. I am honestly glad for a reason to move away from using it, but I assumed since I was getting it as a transitive on timbre that I was stuck with it and might as well use it….now with bb’s problems I have a reason just to not.

We used Timbre for a while at work but switched off it because of the dependencies and the churn. We still use Nippy in one place, which still drags in Encore, which means you still get tools.reader and Truss. I wish there was a zero-dependency replacement for Nippy 😞

I think there is one lib who tries to be a better and faster nippy, but forgot the name

oh yes, this one: https://github.com/igrishaev/deed

haven't used it, so can't make any recommendations

The readme sounds promising. I'll create a Jira at work to investigate switching... I can't remember exactly how deeply we depend on Nippy's actual format... Thank you!

OMG! I just searched our codebase for nippy and taoensso -- no results -- so I searched our commit history and discovered that we got rid of Nippy back in 2019! 🙂 Still, good to know about Deed for the future.

lol :)

time flies

For the values we needed, EDN was a perfectly acceptable substitute with pr-str to "encode", and edn/read-string to decode, and it was all fast enough for what we needed.

I've personally never reached for nippy. I used transit in clj-kondo. I bet there's good uses cases for it. in clerk it is used to serialize state, I think because it needed to serialize more types that are normally available in EDN etc

Yeah, I think at some point in the past we were storing more complex data in Redis, which was why we went with Nippy, but over time we migrated to simpler types.

There’s always https://github.com/clojure/data.fressian

I started using Nippy when I ran into values I could encode into EDN that would not decode. It's been a while, so I can't recall the exact values that broke it. Maybe @nate remembers.

Deed looks really useful. Nice find!

I can't remember what those values were, but Nippy did the round tripping we need.