I didn’t use this tool but you should be able to make a filter for logging framework of java.util.logging if you use native logging and filter there by thread name.

So it may still be interesting to learn about getting triggers to work, but the use-case I had (setting the updated_at column in the database), is actually covered by generated columns: http://www.h2database.com/html/features.html#generated_columns

What exactly do you want to do in that second #(...)? In plain English terms.

I want to unwrap the futures, which to my understanding is what .get does

But that's what you're doing in #(.get %). What are you trying to achieve in #(comp ...)? comp is a higher-order function that composes other functions. You don't pass regular data in there.

Right, I could be using this .getEntity method wrong as I have never used the Apache client before today. But the method does exist on BasicHttpResponse: https://www.javadoc.io/doc/org.apache.httpcomponents/httpcore/4.4.5/org/apache/http/message/BasicHttpResponse.html#getEntity()

I am under the (maybe erroneous) impression that I can compose these two methods and get the underlying data.

Maybe you want (map (comp #(.getEntity %) #(.get %)) (api-call)) ?

Huh, right you are @U051G1K7Y!

That would work. But I'd just do (map #(.. % get getEntity) (api-call)). Or, if you're not a fan of .., then (map #(-> % .get .getEntity) (api-call)).

Both of those look better, imo. Thanks @U2FRKM4TW @U051G1K7Y!

comp is great though, you just have to remember that it’s a function that takes functions and returns a function 😅 Lots of HOF going on there! juxt is also nice.

If you don't care about loading times, you should be able to create an uberjar without actually compiling anything - in other words, without calling (compile).

And when you call (compile) again, it should only recompile the changed files. So maybe when making an uberjar, you're also cleaning the already existing .class files?

do you have a company-required file scanner that runs on your machine? i’ve seen small uberjars take ~4m to build with scanners on and <20s with the scanner disabled

I’ve tried removing the clean step, but that didn’t help.

I don’t think I have a scanner running, but let me double check on that.

agree that 10+ minutes sounds very high and that this is usually file scanner issues

what is # of files being compiled?

Could potentially be some blocking code at the top-level of some ns - after all, a namespace is evaluated when it's compiled, right?

our dependencies are huge. Let me get a count of *.class files in the target folder

around +50k *.class files are getting ubered

but how many are being compiled?

how can I determine that?

find target/classes "*.class" | wc -l 

assuming you're compiling into target/classes

there are 4828 class files just related to us

the clojure CLI uberjar build compiles about 3500 classes in ~13 s on my machine

hmmm I can only imagine its all the dependencies that its pulling in.

is the slow part the compile or the uber jar? you can wrap time calls around those steps in your build if you're not sure

The compile took about 2 minutes, the uber took the rest

so uber took 8 minutes?

That’s right

let me try uber without the compile in the picture

the clojure CLI uberjar has about 75 libs and final jar has about 15k files size 20MB, takes about 31 sec, just as a comparison point

certainly uber'ing directly into a jar would be faster and we may end up moving to that (there are complexities with managing conflicting files across jars), but usually when people have had these issues, they had something external with their filesystem or virus scanners affecting things

Ok, cool, let me take a look there. We have an EC2 instance where I can try the uber jar as well. That would tell us if its a scanner

That was it. I turned off the company Virus scanner, and brought it down to 3 minutes without cleaning. Cleaning adds another minute. Still now as fast as your stuff, but it is about 5 times bigger. So maybe that explains the rest.

Hey @U064X3EF3 thanks for your help. I’ve got one simple question I hope. In the examples of an Uber build, why do we have the lines below:

(b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})

I assumed that the :path in deps.edn would be enough

this copies the Clojure source into the target where it can be jar'ed. if you don't need/want that, you can take it out!

you do probably want the resources to end up in the jar though, so maybe just remove "src" there

Thank you! Gotcha. I’m still relatively new to clojure, would there be some runtime need for the src ?

it depends, but probably not

if compiled classes exist, then they are preferred

thanks