Clojurians Log v2
babashka
A part of me thought that "relativizing against empty" should make no changes, therefore (fs/relativize "" "/assets/script.js") returns "/assets/script.js" unchanged. Currently, it throws on empty string argument and on nil. I'm not completely sold on this, though, maybe explicit throwing is less likely to cause bugs.
Edit: After consideration, I like the current, explicit behavior better. I retract my idea, have a nice Sunday!
Current behavior:
(fs/relativize "" "/assets/script.js")
;; => Execution error (IllegalArgumentException) at sun.nio.fs.UnixPath/relativize (UnixPath.java:485).
;; 'other' is different type of Path
(fs/relativize nil "/assets/script.js")
;; => Execution error (NullPointerException) at babashka.fs/as-path (fs.cljc:40).
;; Cannot invoke "java.io.File.toPath()" because the return value of "clojure.lang.IFn.invoke(Object)" is nullBah, I retract my suggestion. Cute idea, I like explicit better. Nothing to see here!
OMG, somebody on the internet that doesn't hold strong opinions forever and is open about changing their mind! 😉👍
we may all try to carry the "care about problems, not solutions!" torch Rich gave us!
I'm not sure if you know this (https://github.com/babashka/fs/issues/152!), but the underlying JDK APIs typically treat "" as the current working directory.
So "" is typically treated as ".".
(fs/same-file? "." "")
;; => true
(fs/same-file? "./" "")
;; => true(fs/relativize "." "/assets/script.js")
;; => Execution error (IllegalArgumentException) at sun.nio.fs.UnixPath/relativize (UnixPath.java:485).
;; 'other' is different type of PathAh! Today I learned, thank you. In that case it makes absolute sense that we should leave the current API absolutely unchanged (relative to my point of view).
> relative to my point of view Absolutely! 🥁
Hello! Using babashka with clojure.tools.logging and timbre leads to pretty long startup time. I assumed it would be fast given both of them are baked in. A simple POC follows:
#!/usr/bin/env bb
(ns script
(:require
[clojure.tools.logging :as log]
[taoensso.timbre :as timbre]))
(defn -main [& args]
(log/info "Hello there"))
(when (= *file* (System/getProperty "babashka.file"))
(apply -main *command-line-args*))
; vim: set ft=clojure:
I don't see anything abnormal
$ time bb /tmp/foo.clj
2026-01-04T12:46:41.523Z MBP25-2.local INFO [script] - Hello there
bb /tmp/foo.clj 0,01s user 0,01s system 73% cpu 0,029 totalI beg to differ 🙂 :
> time bb foo.clj
2026-01-04T12:48:59.964Z UnknownHost INFO [script] - Hello there
bb foo.clj 0.00s user 0.01s system 0% cpu 5.018 totalalso for context:
> bb --version
babashka v1.12.213$ /opt/homebrew/bin/bb /tmp/foo.clj
2026-01-04T12:49:57.094Z MBP25-2.local INFO [script] - Hello there
$ /opt/homebrew/bin/bb --version /tmp/foo.clj
babashka v1.12.213It probably has to do with you not having set the host name
timbre does an API call to get the host name and this times out after 5s or so
it came up before in this channel
I do have the hostname set. I reproduced this in two different linux distros / machines too, both Arch and Bazzite
"UnknownHost"
read here for a previous conversation on this: https://clojurians.slack.com/archives/CLX41ASCS/p1700744390336579?thread_ts=1700659069.699279&cid=CLX41ASCS
> summary: my hostname in /etc/hostname was blackdog, but this was not entered into /etc/hosts
well, adding my hostname to /etc/hosts solved the issue thanks 🙂
kinda weird that logging relies to dns lookups
We should add a FAQ on this in the babashka book I guess
PR welcome :)
Given that there isn't a FAQ section, is a logging recipe with the above hint good enough?
We should probably add a Troubleshooting section
just making an issue for it is also fine
@brandon268 have you left this feedback for timbre itself too? @ptaoussanis #timbre
I remember it was reported as a github issue. I'm not finding it at the moment, though
Oh, I see. It was specifically in slf4j-timbre: https://github.com/fzakaria/slf4j-timbre/issues/40
@brandon268 Yes, please note that this doesn’t seem to have been an issue with Timbre, but with a 3rd-party library (slf4j-timbre). Timbre v6.6+ includes an official SLF4Jv2 backend provider that should offer significantly better performance. @borkdude Thanks for looping me in on this 👍 > timbre does an API call to get the host name and this times out after 5s or so Just confirming that this is correct, and would explain the slow startup. https://github.com/taoensso/telemere provides an https://github.com/taoensso/telemere/issues/68 to disable hostname info but this might not be relevant since I believe Telemere doesn’t currently support Babashka.
Huh, wow. Fun fact, one point a few years ago we adopted timbre for logging, and it ended up causing a catastrophic perf degradation - some code deep in timbre was constructing exceptions constantly in order to get stack traces and evaluate whether a particular logger was enabled or not (it was, in fact, disabled, and not logging anything). That was a fun one to track down...
I just tried brew update && brew upgrade and got failures for both Babashka and clj-kondo -- any ideas/suggestion? This is on Ubuntu 20.04. Deets in 🧵
✘ Formula babashka (1.12.213)
Error: Failed to download resource "babashka (1.12.213)"
Download failed:
✘ Formula clj-kondo (2025.12.23)
Error: Failed to download resource "clj-kondo (2025.12.23)"
Download failed:
==> Upgrading borkdude/brew/babashka
1.12.212 -> 1.12.213
==> Downloading
-=O=- # # ##-=O=- # ###-=O=- ####curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number ##
Error: An exception occurred within a child process:
DownloadError: Failed to download resource "babashka (1.12.213)"
Download failed: Hmm, the root cause seems related to the old Ubuntu 20.04 version I'm using, and the old curl. But after trying everything that Copilot recommended, and ensuring I have an updated curl and that brew is using it, it still bails with the same ssl3_get_record error 😞
The download URL redirects to location: https://release-assets.githubusercontent.com/github-production-release-asset/... and that is the URL that brew fails to negotiate TLS with.
I seem to remember that Ubuntu has a CA certs package that you can update
ca-certificates
Yeah, tried that too. Copilot/OpenAI eventually guided me to a solution...
✅ Solution: it seems my ISP is hijacking DNS lookups. I installed the cloudflared DNS proxy and configured WSL2 to use that, to force DNS-over-HTTPS in a way that Armstrong (ISP) cannot hijack.
This seems to have speeded up a lot of my network requests on WSL2 as well 🙂
Weirdly, it only seems to happen on my Windows Laptop 3, not my Dell Inspiron 7700 desktop -- on the same WiFi network, even tho' they are configured identically as far as I can tell. I hate network sh*t 😞