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

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

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

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!

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

thanks 🙂

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

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

Yeah I think that'll do just fine.

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

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

> 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

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"

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?

https://github.com/borkdude/graalvm-windows-unix-protocol-repro

more context: https://github.com/babashka/babashka/issues/1511#issuecomment-1462753799

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

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.

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.

yes, this works: https://ci.appveyor.com/project/borkdude/babashka/builds/46459736

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

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

For this we have pods. https://github.com/babashka/pod-registry/blob/master/examples/go_sqlite3.clj

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: https://github.com/babashka/babashka-sql-pods

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

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

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