Have a look how Portal uses bb tasks in GitHub actions — I got some inspiration from that! https://github.com/djblue/portal I like that everything is bundled in BB tasks, and the Github workflow runs those.

I would say, let's stay on the stable and let early adopters experiment with the jdk19-loom branch

I guess also: preview features are "subject to change"

yeah

I’m for defaulting to loom. How would this console bug affect me?

The console bug would affect you with tools that e.g. look if you are connected to a console and then print colorized output instead of raw output

when was the last time anybody ran bb on a terminal that doesn’t support colorized output?

@U5H74UNSF This affects you when you're piping output to another tool, which is quite common

I have yet to test this with the new 22.3.0, but code like this won't work reliable: https://github.com/AvisoNovate/pretty/blob/716bf0647ab92e5bfce629f4919289e2790c2704/src/io/aviso/ansi.clj#L36

The difference:

$ bb -e '(binding [*out* *err*] (prn (if (System/console) :console :pipe)))' > /tmp/foo.clj
:pipe

$ bb -e '(binding [*out* *err*] (prn (if (System/console) :console :pipe)))'
:console

could it be patched default to color? If you can still turn it off via an ENV that seems fine?

holding back loom for compatibility with PDB-11s seems silly to me 😛 unless there’s an aspect that matters today that I’m missing

and the custom build option isn’t with the effort imo

doubt we’d see any usage based on that

lastly subject to change in the JDK has about the same meaning as alpha in clojure: none

not all code has the option to disable color output with an env var. bb takes 1.5 minutes to build on an arm mac. if people desperately want to try the virtual threads with bb now they can do it

sure, the same can be said of uncolorized output however

the issue with colorized output is that you will get mangled output in a piped to file which can cause bugs

could bb include a flag to filter ansi escape sequences?

@U5H74UNSF Not sure if it can reliably do that, also a performance concern, and I'd rather not add any flags that should be removed afterwards. What would be your main use case for bb + jdk19 virtual threads and have you tried the previous binaries I linked last time?

I'd still be very wary of adopting jdk preview features in bb. But... for the color thing, https://no-color.org/?

That env var should be supported by libraries, not a platform. Bb itself doesn't output any ansi codes anywhere

jet does do this and it uses a more sophisticated way of checking terminal connected-ness, since Console returns null both when you pipe input and output, but only the output matters

22.3.0 indeed seems to manifest this bug with jdk19:

$ bb -e '(binding [*out* *err*] (prn (if (System/console) :console :pipe)))'
:console

$ bb -e '(binding [*out* *err*] (prn (if (System/console) :console :pipe)))' > /tmp/foo.clj
:console

@U04V15CAJ im eager to move away from core.async (which is hard to reason about and ruins stack traces). This isn’t exclusive to bb of course but knowing the code is compatible here is a plus as we’re now targeting bb for our more shortlived http deployments.

I still miss the reliability of the erlang VM after switching to clojure so I’m very excited about loom

I suppose bb could have an --enable-preview like the Java folks have?

You can't really switch the JVM's version with which bb is built with a command line flag though?

No, but I suppose you could throw if someone used a JDK19 feature/class. Could be too much of a pita to manage?

curl -sLO 
tar xzvf babashka-1.0.165-SNAPSHOT-macos-aarch64.tar.gz
./bb

The flag is not worth the hassle. I'm not concerned about people using classes that will change, I think early adopters of virtual threads will be aware or at least they should

It's the System/console edge case that bugs me. It seems that the one built on cirrus always returns nil:

$ ./bb -e '(prn (System/console))'
nil

I'll ask in the Graal slack if there is a plan to release a follow up update

https://graalvm.slack.com/archives/CN9KSFB40/p1666722100651669

This is a program that should work with the above binary:

(import '[java.util.concurrent Executors Future])

(defn loads-of-tasks
  [concurrency]
  (let [executor   (Executors/newVirtualThreadPerTaskExecutor)
        ;; executor   (Executors/newFixedThreadPool concurrency)
        tasks      (mapv #(fn []
                            (Thread/sleep 1000)
                            %)
                         (range concurrency))
        start-time (System/currentTimeMillis)
        sum        (->> (.invokeAll executor tasks)
                        (map #(.get ^Future %))
                        (reduce +))
        end-time   (System/currentTimeMillis)]
    (println "Blazingly Fast!")
    {:sum     sum
     :time-ms (- end-time start-time)}))

(loads-of-tasks 100000)

> A fix for this is already on master and ships with dev builds

so soon we can have our virtual threads on consoles?

not sure when they will release another one

perhaps I can depend on a dev build - but it's not clear to me how "dev" those are

I’m personally fine with waiting on the next graal release, more so than waiting on the JDK to declare the feature stable in JDK 25+

ok

at least there is a branch that I can update regularly for people who want to try it out right now and also pre-built binaries I can provide

I also noticed one failing build on Windows with JDK 19

something with hmac256

I think I have a fix for that, probably an encoding issue on Windows in my test

I vote to wait for LTS before adopting. Having a jdk19 bb build available for the frontier explorers enables them to discover things that may be an issue before we affect everyday users.

The console bug seems to be solved in 22.3.1:

$ ./bb -e '(prn (System/console))'
#object[java.io.Console 0x42e8df80 "java.io.Console@42e8df80"]

I’d like to re-use the parse fn with different specs. can this be done somehow? maybe a higher order fn flavour? this seems to be specific to the way the exec fn calls the parse fn so it’s not obvious to me

btw I’m writing blog post and making video today. pitching bb to a whole new audience. hopefully it’ll get you a few new sponsors

Maybe this is useful? https://blog.michielborkent.nl/babashka-tasks-meets-babashka-cli.html

yes it does. and yes, it was a lazy question. now that I checked the CLI source I can see the parse-opts and parse-args fns that will do this for me

looking forward to your blog :) and thanks for those sponsor links

@U04V15CAJ blog post is up https://www.nextdoc.io/blog/automating-salesforce-dx-using-babashka.html

let me know if you get any sponsors from this community

cool! I notice a minor typo: Bashashka

nice work! will you share this to #C8NUSGWG6, reddit etc? :)

thanks. typo fixed

I’ll share to articles now…

Thanks!