Fork me on GitHub
#off-topic
<
2021-12-13
>
hiredman00:12:52

A dep that includes log4j in its jar

noisesmith00:12:54

many libs misbehave by bundling deps

noisesmith00:12:14

(usually this only gets noticed when you realize you are using the wrong version of some lib...)

hiredman00:12:18

A nightmare in this scenario

noisesmith00:12:53

also log4j is a likely candidate for that kind of bundling, because the lib authors want to bake in logging features...

hiredman00:12:12

Hard to get rid of with out getting rid of the dep, annoying to track down which dep is behaving badly

hiredman00:12:10

Basically you have to look at all the jars of your deps and see if they contain log4j classes

noisesmith00:12:28

this does seem like something a plugin could do, logging out class files in deps / searching for classes matching some pattern and reporting their provenance

hiredman00:12:45

Some way to bind class file name prefixes to maven coords

Alex Miller (Clojure team)00:12:49

There are some that do this, although I don't recall the names

Alex Miller (Clojure team)00:12:32

Probably findable here via search, they've been discussed

Adam Kalisz01:12:58

tools.logging is a dependency of e.g. Aleph or https://github.com/yogthos/config it seems.

Alex Miller (Clojure team)01:12:00

tools.logging does not depend on log4j

Alex Miller (Clojure team)01:12:01

tools.logging can use log4j as an underlying framework, if you also provide log4j as a dependency and its either explicitly configured or automatically found via the load order at https://github.com/clojure/tools.logging/#configuration

👍 2
Ben Sless06:12:04

Anyone here ever played with ferns and frons? http://webyrd.net/frons/frons.pdf

🌿 1
respatialized15:12:15

https://github.com/conal/talk-2021-can-tensor-programming-be-liberated I watched this talk not too long ago and it seems like there may be some overlap (the static/dynamic gap notwithstanding) between these ideas - namely, that of decoupling sequential processing from the "array" representation: > The main message of this talk is that "array algorithms" are often not naturally array algorithms at all, but rather an error-prone, composition-resistant enmeshing of a safe, simple, and illuminating algorithm on a natural (non-array) data type, together with details of decoding from and encoding to arrays.

👀 1
respatialized15:12:35

Conal Elliot uses the ideas in that talk to make the Fast Fourier Transform "portable" across different data structures in a provably correct way, comparing its performance on a tree to its performance on a https://www.google.com/books/edition/Algorithms_for_Functional_Programming/kjR1DwAAQBAJ?hl=en&amp;gbpv=1&amp;dq=bush+data+structure&amp;pg=PA158&amp;printsec=frontcover.