Fork me on GitHub

I will migrate my CI on local Gitlab from to bb tasks. One problem is finding a clojure docker image with babashka installed.


Are you looking for an image with both clojure/JVM and babashka installed?


if yes, one of the recommended ways is to create one yourself from a clojure docker image and having a:

RUN curl -sLO  && bash install
or use the clojure image and install bb using the same command and then call your build commands.


Thanks! It looks like it is the only way to make one.


What's the best option these days for getopts-like cli arg parsing in babashka scripts?


I don't know exactly how getops works, but this is the recommended approach:


Using that will also make your functions work well with bb -x


It also supports subcommands


There is a nubank library available that supports getops-like stuff and works with bb


Cheers Michiel, bb/cli was the one I recall I had seen earlier!

lispyclouds10:03:33 is another option working with bb as well


thanks 🙂


Next week Friday @rahul080327 will be giving a babashka workshop. There's still a few places left. I'll also be there in the last hour to close with some Q&A. All under the loving care of @jacek.schae's organization.

Jakub Šťastný15:03:13

Hey guys. What's the Clojure alternative to :babashka/exit 1? I have (throw (ex-info message {:babashka/exit 1})) that Michiel advised me to use so that my NREPL wouldn't quit like it would if I do System/exit. How do I do the same for Clojure itself? So that process exits with a given status code but it doesn't quit NREPL if I call it.

Jakub Šťastný15:03:48

Fair enough. Thanks for letting me know @alexmiller


Just throwing the same exception should also work for Clojure though. In babashka :babashka/exit will affect the exit code and won't print a "pretty" error report. So it's compatible with clojure, as long as you don't care about the exact exit code cc @alexmiller

👍 2
Alex Miller (Clojure team)15:03:50

in general, the Clojure CLI will return exit code 1 if it gets an uncaught exception and 0 otherwise

Jakub Šťastný15:03:15

Yeah I think that'll do just fine.


Speaking of which, is there a pretty error printer for babashka? So you can throw an ex-info with a message, and the program prints the message for human consumption without a stacktrace? I'm rolling my own but perhaps this could be a useful addition to babashka


People get freaked out when they see a stacktrace for non-exceptional circumstances


@U06F82LES This is already what :babashka/exit 1 is for


it's an intentional exiting of babashka, rather than an unexpected error

Jakub Šťastný18:03:52

It's a lovely feature.


Whoa I didn't realize that it worked like that already, super cool


(Also I could've checked before asking I now realize)


I have some code for that in a current project. Took a hack from StackOverflow for checking whether if I'm running things from the repl. Then wrapped up System/exit with that to keep it from exiting. Seems to be working as expected so far. Other code either calls shutdown to exit 0 or die to exit 1. Both defer to exit , which decides whether to actually exit or to abort and just print a message to the repl.


This works for JVM clojure, but not bb


The question was how specifically to do it in Clojure, right?


> How do I do the same for Clojure itself? So that process exits with a given status code but it doesn't quit NREPL if I call it.


yes. just throwing an exception would already have that effect


but you don't have much control over what gets printed etc which you do have in your version. there's also ways to make your version bb compatible


The project I have it in is currently sidelined, and I wasn't using bb yet when I wrote that, so that's why I haven't fixed compatibility. How could you exit with a 0 code by throwing an exception?


you don't use exceptions but just let the program flow end normally


That's the point. If the program flow ends normally, then so does the repl session.


The idea is to be able to let your program go through the motions of ending normally, but then not actually quit, so the repl session doesn't die.


when your program ends normally, it shouldn't have to do anything special


except maybe shutdown-agents


anyway my bb compatiblity remark was about the original question being about both clojure and bb. didn't mean to criticize your solution


just so it's clear that people won't think that they can grab that code as a solution that works everywhere

👍 2

> when your program ends normally, it shouldn't have to do anything special The case of the program ending normally is not why there is special stuff. An interface is inserted between the app and System/exit for the sake of the case where you want to keep your repl session alive. The program is not allowed to call System/exit directly so you have an opportunity to prevent normal shutdown. But the interface still provides a way for the app to declare the intent to shut down, even if it might not happen.

(defn exit [exit-code]
  (if (in-repl?)
    (println "-Aborting exit ... ")
    (System/exit exit-code)))


yeah. makes sense. I wish clojure (or the JVM) had a function that sets the exit code in case the jvm would shut down, rather than shutting it down yourself. node has that too


Speaking of which, is there a pretty error printer for babashka? So you can throw an ex-info with a message, and the program prints the message for human consumption without a stacktrace? I'm rolling my own but perhaps this could be a useful addition to babashka


Does anybody else ever occasionally get a Process completed with exit code -1073741502. when launching bb on GitHub Actions on Windows? I get it very sporadically. More deets in 🧵


I think -1073741502 is probably a 32-bit NTSTATUS value. Soo... if we convert it to hex:

user=> (format "%x" (bit-and 16rFFFFFFFF -1073741502))
And then we look, we see the following info: > 0xC0000142 > STATUS_DLL_INIT_FAILED > {DLL Initialization Failed} Initialization of the dynamic link library %hs failed. The process is terminating abnormally. Which is kinda vague, ya? Don't know if this is a GitHub Actions thing, Windows thing, GraalVM thing or bb thing. Was curious if others ever hit this too when using bb on Windows.


Never seen it


If anybody had, I would have expected it to be you! You use appveyor for Windows CI, ya? Maybe it is something in GitHub Actions Windows or the GitHub Actions Windows env/version.


I use appveyor mostly, but also sometimes github actions


Thanks, I guess this will probably be yet another unsolved Windows mystery for me


I'm also dealing with a Windows issue right now


Sorry to hear that, do we need to form a support group?


my day is going like: sure let's add a few classes to bb, into a deep rabbit hole


and I can't repro this on my local Windows machine


maybe it's the windows version...?


This might be a Windows 2017 vs 2019 problem


hmm.... that seems kinda annoying...


I wonder if building on Windows 2019 will still enable running on Windows 2017


Yah maybe not a thing in win 2017... (??) > Unix-domain sockets have long been a feature of most Unix platforms, and are now supported in Windows 10 and Windows Server 2019. From



We've kept the Microsoft Visual C++ Redistributable major version number the same for Visual Studio 2015, 2017, 2019, and 2022. That means only one instance of the Redistributable can be installed at a time. A newer version overwrites any older version that's already installed. For example, one app may install the Redistributable from Visual Studio 2015. Then, another app installs the Redistributable from Visual Studio 2022. The 2022 version overwrites the older version, but because they're binary-compatible, the earlier app still works fine. We make sure the latest version of the Redistributable has all the newest features, security updates, and bug fixes. That's why we always recommend you upgrade to the latest available version.


This sounds re-assuring


So support you are looking for is provided by the redistributable? Or the OS?


I want to know if I upgrade to Windows 2019 on appveyor, if my binary can still run on older windows computer. I think so if they install the newer redistributable.


Ah! Right, ok.


I've used up all my nerd energy on Windows today, gonna go play a video game now.


Oh fun, now my upgraded windows build is failing with:

Message:  curl: option --compressed: the installed libcurl version doesn't support this
curl: try 'curl --help' for more information
Wtf, this used to work in the 2017 image! facepalm


I guess it's a good time to upgrade to babashka.http-client


Has anything changed wrt next.jdbc support since When I try to require next.jdbc I get this error:

clojure.lang.ExceptionInfo: Could not resolve symbol: java.beans.Introspector/getBeanInfo rda_visualizer.core clojure/java/data.clj:77:28
Separately, has there been any movement on getting sqlite support?


I’ll take a look, thanks!


Is the database you're targeting sqlite via next/jdbc as well?


That was my plan, yes


ok, I think in that case go_sqlite pod is the best replacement


There are some other options here for other databases:


I’m concerned I’ll run into serialization as a performance bottleneck, but I’ll report back if that’s the case.


yes, that could be a bottleneck. if so you could also compile babashka with next/jdbc on board, but this is more work for you


but first I'd say try out the pod and see


In that case, I’ll probably revert to java clojure

👍 2

Another option is #C029PTWD3HR if you are not scared of Node.js


it's babashka-like scripting but on Node.js


it supports all Node.js libs


Not a bad idea, though I’d prefer to avoid the nodejs package ecosystem if I can avoid it


ok, so in summary: the go_sqlite pod (first link) or JVM

👍 2

Seemingly conflicting statements in readme for babashka/http-client. Does the "NOTE" indicate that breaking changes are no longer expected? > This library is in flux. Feedback is welcome. It can be used in production, but expect breaking changes. When this library is considered stable (API-wise) it will be built into babashka. > NOTE: The babashka.http-client library is built-in as of babashka version 1.1.171.


I don't expect any breaking changes in the http-client namespace, but there might be some changes coming in how error handling in interceptors works. This isn't built in yet. But this isn't something that you need to be bothered with normally

👌 2