Clojurians Log v2

can you post a bug repro? perhaps this should be fixed even more upstream? not sure :)

That's a good point, sorry for not including a way to reproduce. Here is what causes the issue for me on babashka v1.12.196:

(require '[clojure.edn :as edn])
(let [out (promise)]
  (Thread/startVirtualThread
   #(deliver
     out
     (try
       (edn/read-string
        (pr-str (java.util.Date.)))
       (catch Exception e e))))
  @out)

is this specific to bb or specific to virtual threads or both?

when I paste it in a bb repl, I get this:

$ bb
Babashka v1.12.218-SNAPSHOT
Type :repl/help for help
user=> (require '[clojure.edn :as edn])
  #_=> (let [out (promise)]
  #_=>   (Thread/startVirtualThread
  #_=>    #(deliver
  #_=>      out
  #_=>      (try
  #_=>        (edn/read-string
  #_=>         (pr-str (java.util.Date.)))
  #_=>        (catch Exception e e))))
  #_=>   @out)
nil
#inst "2026-04-18T10:34:23.284-00:00"
user=> (require '[clojure.edn :as edn])
  #_=> (let [out (promise)]
  #_=>   (Thread/startVirtualThread
  #_=>    #(deliver
  #_=>      out
  #_=>      (try
  #_=>        (edn/read-string
  #_=>         (pr-str (java.util.Date.)))
  #_=>        (catch Exception e e))))
  #_=>   @out)
nil
#inst "2026-04-18T10:34:25.157-00:00"

I think it may be bb specific since the error is from GraalVM

what version of bb are you using

Ohh, maybe it is fixed upstream then 👍 v1.12.196

Dang, that is kinda of an old version at this point 😂

Ok, I'm on the latest version and I see it also works. Should have checked latest 🤦

no problem, good reason to upgrade :) maybe you can build portal TUI now that jline is included in the latest ;)

Is there something that has a react/hiccup API for TUI? I got server side rendering working for the Portal UI recently, so that may be an avenue to get the UI ported to a terminal 😂

don't know actually... one lib that builds on the new TUI stuff is https://github.com/TimoKramer/charm.clj. but it doesn't seem to have a hiccup-ish interface

jline itself already has a good "virtual diffing" thing called Display

so if you use Display, you can just re-render what you want and it'll do the performant thing

CircleCI also supports dynamic generation of CI config on startup. In bb’s repo we use this to generate the config from a bb script such that we don't need to write any YAML

One of the worst offence with GH is the total disregard for a local development. In a corporate environment like ours getting ready to deploy to dev is a mammoth task(feels certainly like it) Even if CIS delay is accepted, the effort to hop from system to system each with their own integrations and APIs and credentials and in some cases having to tunnel data through layers is back breaking and very hard to reason about. For example the region specific environment variable needed for my app has to be declared in helm, the chart built and uploaded to repository, then pulled into CD pipeline and the region specific value is translated/injected and the kubernetes deployment executed and finally the app has config values in the environment. So many places for slip-ups and confusing string escaping rules. I certainly won't be able to convince corporate, but maybe our team can use the bits of autonomy afforded to us and make our lives a little better with something else. Could that be bb:thinking_face: BTW it irks me to ends that the GH approach for sharing large data between jobs is to upload to data store in one and download from it for the other.

Not completely, but maybe substantially, depending on context. Assuming the aim is to use bb on GHA, then there's still the general 'integration contract' (secrets from environment variables, yaml to establish enough context to make bb available, etc), but if the actual content of the workflow is achievable in bb, I don't know what'd stop it. In a very similar way to how one could write a shell script and then run bash xyz.sh from a workflow step, one could make a bb script and run bb xyz.clj.