Fork me on GitHub
#babashka
<
2021-11-02
>
borkdude08:11:33

TIL: reader conditionals may be nested:

(prn #?(:clj [1 2 #?(:bb 3 :clj 4)]))

bb: [1 2 3]
clj: [1 2 4]

lread12:11:16

Huh! I had assumed that only one platform would be active. But I guess here bb is considered a sub-variant of clj? Whereas cljs is not a sub-variant of clj. But... can bb be a subvariant of cljs when using sci?

borkdude12:11:22

It's up to the dialect of clojure which reader features to support. bb supports both :clj and :bb and prioritizes :bb, order matters.

lread13:11:21

Interesting

schmee16:11:21

is there a way to preserve the coloring when doing (-> (sh "git" "diff") :out println)?

borkdude16:11:42

@schmee if you don't care about the string and just wait to see the output, use babashka.process or babashka.tasks/shell

schmee16:11:01

I’ll give them a shot, thanks!

borkdude16:11:35

@(babashka.process/process ["git" "diff"] {:inherit true})

borkdude16:11:51

or:

(babashka.tasks/shell "git diff")

schmee16:11:11

@(babashka.process/process ["git" "--no-pager" "diff"] {:inherit true}) gives me the result I want, thanks! 🙏

jkrasnay20:11:14

I’m trying to use :deps in my bb.edn but it’s failing when Babashka tries to download the clojure tools JAR. The reason is that our SSL connections are terminated by an internal proxy server and the cert they use to spoof SSL certs is not available. I’ve tried providing a keystore with the proper certs like this, but it doesn’t seem to be working: bb -.ssl.trustStore=path/to/cacerts tasks

jkrasnay20:11:23

Does anyone have an idea how to fix this?

borkdude20:11:52

@jkrasnay babashka (or rather deps.clj) emits information about where it tries to download the tools jar, so when it fails you can do it manually

jkrasnay21:11:13

Yeah, I think that might be the only way. According to this, the keystore is embedded into the binary at runtime: https://github.com/quarkusio/quarkus/issues/9713#issuecomment-641914502

borkdude21:11:55

This might have changed in GraalVM 21.3, I think I read something, let me look

borkdude21:11:46

> Root certificates can now be configured at image run time. Previously, the root certificates present at image build time were the only root certificates available at run time. See the https://www.graalvm.org/reference-manual/native-image/CertificateManagement/#runtime-options for details, and to find a list of system properties that are now read at run time to configure the root certificates

borkdude21:11:24

.ssl.trustStore

borkdude21:11:40

So this should work after an upgrade to 21.3.0

borkdude21:11:01

If you can make an issue about this, I'll do it on the next release

borkdude21:11:20

Btw, if you already have the Clojure CLI installed you can also set DEPS_CLJ_TOOLS_DIR and DEPS_CLJ_TOOLS_VERSION to piggy-back on that installation directory

jkrasnay21:11:43

OK, will do. Should the issue just be “upgrade to GraalVM 21.3.0” or should I reference that the trust store setting isn’t working?

borkdude21:11:23

Adding that detail would be nice, then we have a good reason to upgrade

jkrasnay21:11:15

Thanks for the quick response!

borkdude21:11:58

I wonder if babashka should upgrade to 21.3.0 JDK 11 or JDK 17. Is there anything in JDK 17 worth having right now? Upgrading to JDK 11 gives us: 10 mb binary reduction. JDK 17 gives us: the same binary size + ?? features?

kokada02:11:48

Unless JDK 17 has some really interesting new features (that as far I understand we need to manually export manually, otherwise bb wouldn't have access at runtime) or better performance, I would prefer to keep it at JDK 11 and get the binary size reductions

kokada02:11:49

At least for now, 21.3.0 is the first GraalVM release with JDK 17, and while I don't expect it to be unstable I think JDK 11 is more battle tested

kokada02:11:14

But I am fine either way. I already packaged GraalVM with JDK 17 on nixpkgs, so the change should be pretty easy

Karol Wójcik05:11:12

I want 10mb binary reduction :D

borkdude07:11:01

This benefit will only be temporary until we upgrade to 17 again (e.g. for unix domain socket support, or macOS aarch64 support)

Karol Wójcik07:11:39

You mean <unix://var/xx> support? I thought it's supported in native-image already?

kokada00:11:43

Is aarch64 on macOS something that going to be exclusive for JDK 17 :thinking_face: ? Not that it seems to be available on this release.

kokada00:11:36

Well, I am fine either way. I just don't think upgrading it right now brings any benefits. If it was me I would expect one more GraalVM release to avoid possible issues with a JDK 17 that is still relatively new (and on GraalVM side it is completely new)

Karol Wójcik06:11:57

@UFDRD93RR It brings. Lower cold starts on AWS Lambda. Java 11 is stable worth upgrading.

borkdude10:11:10

@UFDRD93RR I "fixed" the setup-musl script for 21.3.0 simply by adding ln -s /usr/bin/musl-gcc /usr/bin/x86_64-linux-musl-gcc

kokada12:11:51

> @UFDRD93RR It brings. Lower cold starts on AWS Lambda. Java 11 is stable worth upgrading. "Upgrading" I mean JDK 17, sorry if this wasn't clear It is clear that we should upgrade to GraalVM 21.3.0, the question is if we should use JDK 11 or 17. I am actually arguing that we keep JDK 11, but as I said, I don't have strong feelings either way. It is just that I think JDK 17 is still too new.

kokada12:11:43

> @UFDRD93RR I "fixed" the setup-musl script for 21.3.0 simply by adding ln -s /usr/bin/musl-gcc /usr/bin/x86_64-linux-musl-gcc Yeah, this looks fine too me

borkdude21:11:01

It might be better to bite the JDK 17 bullet now

😅 2
👍 3
Imdad Ahmed23:11:35

I think the default should be upgrading unless there is a good reason not to.