The dot is not in its name. The name of the interface is OnActivate, but the interface is defined within a class named Application. Try using $ instead of that particular ..

Omg thank you so much! Just had to (:import ch.bailu.gtk.gio.Application$OnActivate) and refer to it as Application$OnActivate

(= (hash (inst/read-instant-timestamp "2021-02-01T00:00:00Z")) (hash #inst "2021-02-01T00:00:00.000000000-00:00"))
; true 

(.equals #inst "2021-02-01T00:00:00.000000000-00:00" (inst/read-instant-timestamp "2021-02-01T00:00:00Z"))

The results of #inst ... and (clojure.instant/read-instant-typestamp ...) are objects of different classes.

why does switching the order work then? :thinking_face:

;; if I switch the order, it evaluates to true.
(= #inst "2021-02-01T00:00:00.000000000-00:00"
   (clojure.instant/read-instant-timestamp "2021-02-01T00:00:00Z"))
; true

Because the classes have different implementation of .equals.

Of course that how it is, but the question is whether that’s the desired solution. I feel this should be considered a bug, as it can throw some nasty surprises.

Not sure what you mean. A Timestamp is a Date but a Date is not a Timestamp. It's regular inheritance at play. And one has to use clojure.instant/read-instant-timestamp quite deliberately - that's not something you do by accident. And its docstring hints at the fact that by default #inst is not read as Timestamp. And that's also documented here: https://clojure.org/reference/reader#_built_in_tagged_literals

So a Date can be compared with a Timestamp, but not vice versa. You are right about the deliberate usage, the caller should know what they are getting into. Thanks.

Perhaps file -I -b and check that the result does not say .* charset=binary

First attempt:

(defn is-binary? [f]
  (let [stdout (:out (clojure.java.shell/sh "file" "-I" "-b" f))
        charset (second (re-find #"charset=(.*)" stdout))]
    (= "binary" charset)))

Yeah, that might be the easiest way. See also https://stackoverflow.com/questions/620993/determining-binary-text-file-type-in-java

When exactly is a file "binary"?

There are many ways to answer that question

One program's EBCDIC text file is another's binary file.

Maybe https://github.com/hugoduncan/criterium, because I see this code: https://github.com/hugoduncan/criterium/blob/cf1c70fa765dae2c05b7b33746b8775e6d15aa78/src/criterium/core.clj#L275-L285

async-profiler

I second async profiler. There's also clj-memory-meter. Then allocation profiling in popular profilers like YourKit. And maybe enabling and analysing GC logs

familiar with several of these tools - but we're looking for a tool more specifically like quick-bench, which can be invoked in code and give a summary answer, as opposed to a profiler that is more of an analysis tool - i.e., comparison vs exploration. async profiler looks like a very interesting profiler tool, esp open source, but not quite in the exact use case I'm reaching for here.

The criterium approach looks too simplistic

What's wrong with async profiler? You can profile an expression and run it multiple times,getting a pretty accurate view of allocations

You can get the stats you want through jmh with the gc profiler. jmh-clojure provides a useful interface https://github.com/jgpc42/jmh-clojure

FYI: https://github.com/clojure-goes-fast/clj-async-profiler lets you use async-profiler at the REPL

And it lets you do allocation profiling

super neat, both jmh-clojure and clj-async-profiler look like very strong possibilities!

Just note that you will be profiling the whole jvm not necessarily only your expression- so make sure there's nothing else significant running in the same process

just now wanted to ask exactly this question Thanks Universe, and @U03A0EGF82E 🙂

With clj-async-profiler you can wrap whatever expression you're interested in with dotimes and let it spin, collecting plenty of samples. You can profile CPU or memory allocation. It's very informative

Sure, but you are still profiling the whole jvm - there's no special magic. Still, You will likely get good results if you have an isolated environment

True, although it's better to profile an entire application to get a realistic image

What do you mean by profiling the whole JVM? The resulting flame-graph is filtered down to only your enclosed call-stack scope, so you do get to see only the part you're concerned with.

He's right in that you're affected by the whole JVM even if you're only running the sampling process for the duration of your run.

I'm not sure what that means? Like, you could argue I'm also profiling my whole computer, if I've got some protein folding going on in the background, and a big file copy, than my timings will be affected, but I'm still getting the profile of my function as it is running on my computer

You can of course see what your function did but you will also see other threads (cpu) or allocations completely unrelated to your function.

our axe was more about repeatability and repl/ease of use, so we're not super worried about the rest of the JVM in our use case - no other work going on really

Yeah, as I said, it's most likely gonna be fine 🙂.

Hum... are you sure? I haven't done an allocation profile in a while, but when I do a CPU one, it only shows me things that spawned from the function

It seems to all be filtered on the stack of the function. So it doesn't show anything unrelated.

Like isn't that the whole point of the flame graph? You can see within a function what is taking time.

No, it doesn't work that way. Async Profiler typically profiles the whole process. Although you can filter specific methods, etc. - but that's not what clj-async-profiler is doing When you look at the code, you can see it simply calls start and stop - no magic filtering is happening: https://github.com/clojure-goes-fast/clj-async-profiler/blob/master/src/clj_async_profiler/core.clj#L362-L365

The filtering is on the render, the flame graph is displayed and shows you each functions and their stack.

Maybe we're talking past each other. My point is that you get to see exactly how much time the function took, and of that time how much time the functions inside it took, etc. So you can see clearly the time/allocations related to your function and yours only.

Are you saying that's not the case? That the time you see your function took in the resulting flame graph actually includes compute time from other unrelated things?