Fork me on GitHub
#babashka
<
2023-03-09
>
renewdoit05:03:49

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

lispyclouds06:03:12

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

lispyclouds06:03:37

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.

renewdoit11:03:22

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

imre10:03:26

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

borkdude10:03:08

I don't know exactly how getops works, but this is the recommended approach: https://github.com/babashka/cli

borkdude10:03:24

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

borkdude10:03:35

It also supports subcommands

borkdude10:03:58

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

imre10:03:42

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

lispyclouds10:03:33

https://github.com/l3nz/cli-matic is another option working with bb as well

imre10:03:00

thanks 🙂

borkdude15:03:23

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 clojure.stream organization. https://clojure.stream/workshops/babashka

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

borkdude15:03:32

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.

pesterhazy18:03:40

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

pesterhazy18:03:04

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

borkdude18:03:09

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

borkdude18:03:20

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

Jakub Šťastný18:03:52

It's a lovely feature.

pesterhazy19:03:34

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

pesterhazy19:03:49

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

skylize22:03:50

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.

borkdude22:03:53

This works for JVM clojure, but not bb

skylize22:03:04

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

skylize22:03:47

> 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.

borkdude22:03:27

yes. just throwing an exception would already have that effect

borkdude22:03:05

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

skylize22:03:26

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?

borkdude22:03:11

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

skylize22:03:43

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

skylize22:03:13

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.

borkdude22:03:18

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

borkdude22:03:34

except maybe shutdown-agents

borkdude22:03:20

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

borkdude22:03:47

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

👍 2
skylize22:03:55

> 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)))

borkdude23:03:02

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

pesterhazy18:03:40

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

lread18:03:23

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 🧵

lread18:03:55

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

user=> (format "%x" (bit-and 16rFFFFFFFF -1073741502))
"c0000142"
And then we look https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55, 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.

borkdude18:03:27

Never seen it

lread18:03:54

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.

borkdude18:03:01

I use appveyor mostly, but also sometimes github actions

lread19:03:45

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

borkdude19:03:06

I'm also dealing with a Windows issue right now

lread19:03:59

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

borkdude20:03:07

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

borkdude21:03:25

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

borkdude21:03:34

maybe it's the windows version...?

borkdude21:03:46

This might be a Windows 2017 vs 2019 problem

lread21:03:07

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

borkdude21:03:08

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

lread21:03:23

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 https://bugs.openjdk.org/browse/JDK-8238588.

borkdude21:03:33

Ah:

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.

borkdude21:03:39

This sounds re-assuring

lread21:03:25

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

borkdude21:03:56

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.

lread21:03:28

Ah! Right, ok.

lread21:03:56

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

borkdude22:03:34

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

borkdude22:03:57

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

Max19:03:45

Has anything changed wrt next.jdbc support since https://github.com/babashka/babashka/releases/tag/v0.0.89? 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?

Max19:03:06

I’ll take a look, thanks!

borkdude19:03:28

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

Max19:03:46

That was my plan, yes

borkdude19:03:15

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

borkdude19:03:32

There are some other options here for other databases: https://github.com/babashka/babashka-sql-pods

Max19:03:52

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

borkdude19:03:15

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

borkdude19:03:28

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

Max19:03:32

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

👍 2
borkdude19:03:08

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

borkdude19:03:15

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

borkdude19:03:23

it supports all Node.js libs

Max19:03:40

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

borkdude19:03:03

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

👍 2
skylize23:03:41

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.

borkdude23:03:41

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