This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-21
Channels
- # announcements (14)
- # aws (8)
- # babashka (3)
- # babashka-sci-dev (41)
- # beginners (78)
- # calva (15)
- # cider (9)
- # clj-commons (10)
- # clj-kondo (5)
- # cljs-dev (8)
- # clojure (47)
- # clojure-bay-area (3)
- # clojure-europe (13)
- # clojure-nl (2)
- # clojure-norway (15)
- # clojure-uk (13)
- # clojured (2)
- # clojurescript (20)
- # conjure (29)
- # cursive (4)
- # emacs (19)
- # events (3)
- # funcool (13)
- # hyperfiddle (16)
- # jobs (2)
- # lsp (4)
- # malli (13)
- # meander (1)
- # missionary (2)
- # nrepl (7)
- # off-topic (68)
- # other-languages (82)
- # polylith (1)
- # reagent (28)
- # reitit (12)
- # releases (3)
- # remote-jobs (5)
- # ring (27)
- # sci (6)
- # shadow-cljs (9)
- # spacemacs (2)
- # sql (10)
- # tools-deps (10)
- # vim (10)
Hey is there any weirdness with trying to reference an interface with a period in it like Application.OnActivate
? For the life of me I can't figure out how to access https://javadoc.jitpack.io/com/github/bailuk/java-gtk/main-fb80fb6f1c-1/javadoc/ch/bailu/gtk/gio/Application.OnActivate.html interface from Clojure.
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
I found something interesting. Can someone explain this behaviour?
(= (clojure.instant/read-instant-timestamp "2021-02-01T00:00:00Z")
(clojure.instant/read-instant-timestamp "2021-02-01T00:00:00Z"))
; true
(= #inst "2021-02-01T00:00:00.000000000-00:00"
#inst "2021-02-01T00:00:00.000000000-00:00")
; true
(= (clojure.instant/read-instant-timestamp "2021-02-01T00:00:00Z")
#inst "2021-02-01T00:00:00.000000000-00:00")
; false
;; 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
(= (hash (inst/read-instant-timestamp "2021-02-01T00:00:00Z")) (hash #inst "2021-02-01T00:00:00.000000000-00:00"))
; true
and also
(.equals #inst "2021-02-01T00:00:00.000000000-00:00" (inst/read-instant-timestamp "2021-02-01T00:00:00Z"))
is trueThe 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
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.
What is the best way to check if a file is binary from the JVM?
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
hey all - we're doing some benchmarking on small pieces of code related to performance, which we have a lot of tools for, but a related area of concern is memory allocation and GC - are there any benchmark type tools out there that will run an expression over and over and then give a report on how much workload for GC it threw off? Ideally - how much memory allocated in how many objects, per invocation? something like that?
Maybe https://github.com/hugoduncan/criterium, because I see this code: https://github.com/hugoduncan/criterium/blob/cf1c70fa765dae2c05b7b33746b8775e6d15aa78/src/criterium/core.clj#L275-L285
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.
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
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
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.