Fork me on GitHub
Marco Pas07:01:53

I am a bit lost on how one should write and execute unit tests for bb scripts. Checked the bb book but could not find any pointers on how to start doing this. Quick remark that this question is coming from a clojure newbie 🙂 Is there something like $ bb run-tests ?

Marco Pas07:01:04

Would be more then happy to write some howto that maybe can be added to the book if this is usefull by the way 🙂


@marco.pasopas go to the book and Ctrl-f on clojure.test. It is in there somewhere

Marco Pas08:01:55

Found the recipe indeed trying to understand what it is doing 🙂

Marco Pas08:01:00

Fighting name-spaces and folders 🙂

Marco Pas08:01:03

But i will get there 🙂


@marco.pasopas I now updated that part of the book, hopefully it's clearer


pod-babashka-aws 0.0.5 released: fixes an issue with nil in the aws-api response which prevented using it with the lambda API. Now it works.

Adrian Smith10:01:38

Will espresso for Graalvm allow Babashka to run more Clojure programs?


Maybe, possibly, I don't know yet :)

👍 3
Marco Pas12:01:37

@borkdude Thanks this surely helps.. But i am not there yet 🙂 Fighting the concepts of namespaces and filename is guess.. Having the following simple test project..

└── test
    └── util_test.clj
# util_test.clj
(ns util-test)

(deftest testme
  (is (= true)))

(deftest testme2
  (is (= 8 (+ 1 2))))
#!/usr/bin/env bash
bb -cp "src:test:resources" \§
   -e "(require '[clojure.test :as t] '[util])
       (let [{:keys [:fail :error]} (t/run-tests 'util)]
         (System/exit (+ fail error)))
Still it shows up with running 0 tests running


@marco.pasopas '[util] should be 'util-test


also in run-tests


that invocation should throw with "Could not find namespace util" or something similar


The name of your namespace is not util, it is util-test

👍 3
Marco Pas12:01:05

Guess i need to include something more..


:refer [deftest]


The example has (t/deftest ...)


I mean, in util you need to require clojure.test as well and :refer [deftest] if you want to use it unqualified

👍 3

(ns util (:require [clojure.test :as t :refer [deftest is]]))

Marco Pas06:01:14

@borkdude You are really helping me out in understanding BB and also Clojure txs!!

Jakub Holý (HolyJak)13:01:55

Hello! I have read but did not find an explanation of how bb finds the pod. Does it use to find the source gh repo and then downloads whatever is needed? And what if I want to package the pod with my app (aws lambda, actually)? Thanks!


@holyjak You can load pods using a qualified symbol, like org.babashka/aws and a version "0.0.5". In that case it will download it from the pod-registry by looking up a manifest. When calling load-pod with a string or vector of strings, the pod is looked up on the local file system (either using the PATH, or using an absolute path)


If you want to take pods along into a docker image, probably the best is to download them manually inside the docker image and use an absolute or relative path


But you can also just copy the ~/.babashka directory where the downloaded pods are living, that should also work


@holyjak I noticed you were using clj-http-lite from source, this isn't necessary anymore, now that there is babashka.curl and org.httpkit as built-in clients

👍 3

But it still works

Jakub Holý (HolyJak)14:01:15

@borkdude I guess it would be nice to update the "About" of to point to 🙏



❤️ 3

We will perhaps have a nice landing page on sometime soon.

Jakub Holý (HolyJak)15:01:17

FYI I will be looking into adding Oracle support to the sql pod

Jakub Holý (HolyJak)15:01:18

@borkdude I have just noticed is still open. What would you like me to do with it?


Up to you, you can close it or finish it. Beware of Oracle Licensing when distributing pods

Jakub Holý (HolyJak)15:01:03

What is missing for it to be finished? I believe the licensing is nowadays ok, i.e. you can re-distribute, but I will check it again and link to some official docs.


I would prefer to add these vars to the pod first, so we can write real tests to verify if they work correctly and to see what impact they have on the size. See other message in channel

👍 3

If they are verified to work in the pod, they can be added to the feature flag as well

Jakub Holý (HolyJak)15:01:21

I will first work on adding oracle to the pod then come back to extend the next-jdbc support


@holyjak When adding stuff, I would recommend to take very small steps, so we can monitor the growth of the binary

👍 3

Some things trigger excessive growth (usually runtime resolve or require), so taking it one var and test at a time is probably the best

Jakub Holý (HolyJak)16:01:04

@borkdude here is my first attempt However it fails to compile, with > Error: Incompatible change of initialization policy for java.lang.Math$RandomNumberGeneratorHolder: trying to change RUN_TIME from the command line to RERUN for random number generator >$UserException: Incompatible change of initialization policy for java.lang.Math$RandomNumberGeneratorHolder: trying to change RUN_TIME from the command line to RERUN for random number generator Any tips how to trouubleshoot & fix that? 🙏


@holyjak Yes, with GraalVM 20.3.0 this line should be removed


Feel free to also update GraalVM in circleci / appveyor to 20.3.0

Jakub Holý (HolyJak)16:01:04

I have 20.3:

🐟  $GRAALVM_HOME/bin/native-image --version
GraalVM Version 20.3.0 (Java Version 11.0.9+10-jvmci-20.3-b06)
yet I still am getting this error 😭


> Yes, with GraalVM 20.3.0 this line should be removed I mean, you should actually delete that line

Jakub Holý (HolyJak)16:01:50

ah, this one

--initialize-at-run-time=java.lang.Math\$RandomNumberGeneratorHolder \
in compile ?


and compile.bat

Jakub Holý (HolyJak)16:01:11

I don't see this file


oh sorry, this is not part of this repo. there is no Windows version yet, ok

Jakub Holý (HolyJak)16:01:43

I guess I should also update generate_circleci.clj to use 20.3.0?


and appveyor.yaml


you can do it as a separate PR

👍 3

@holyjak let's take this to the dev channel, I just invited you there

👍 3

Welcome @tgg

😄 3
👋 3

Does babashka work with next.jdbc? I thought it did but I just got an issue opened that next.jdbc doesn't compile with GraalVM:


@seancorfield We have a feature flag for next.jdbc and also some sql "pods" which are optional binaries which bb can download to get more features. These are all compiled with GraalVM native-image, but probably not with the most recent versions of next.jdbc.


@seancorfield The issue isn't very descriptive of what goes wrong, but we can update our next.jdbc to see if it still works, in the sql pods


we were using "1.1.610", now trying upgrade to 613


@seancorfield Just upgraded to 613 and everything works correctly:


I really appreciate you providing all that information in the GH issue!

Jakub Holý (HolyJak)12:01:06

Also notice that the sql pod exposes only a subset of next-jdbc. My experience was that when I tried to add the .prepare ns, the compile time and CPU use exploded until my PC could not take it anymore. So it is possible that not all parts of next-jdbc can work in GraalVM (yet)


I'm happy to review PRs that folks send in about GraalVM compatibility but it's very low priority for me since I have zero interest in native-compiled Clojure right now.


@seancorfield The most important thing for GraalVM users is avoiding reflection warnings, so as long as you have (set! *warn-on-reflection* true) everywhere, and you can avoid using require, resolve and eval (or variations) during runtime (top-level is ok), this will cover 99% of the problems


I think I have (set! *warn-on-reflection* true) everywhere... Ah, I don't have it in next.jdbc.default-options or next.jdbc.plan. Will add it there (and fix any reflection warnings).


Added. No reflection warnings. A couple of places have requiring-resolve (for whether camel-snake-kebab is on the classpath or not). There's one place in next.jdbc.prepare that refers to a symbol from next.jdbc.result-set (which already requires next.jdbc.prepare) so that's probably what @holyjak ran into...


The CSK stuff is all handled in macros so if you do not have CSK on your classpath, there's no dynamic require in the runtime (but it does mean you can't create a GraalVM native image if you try to use CSK).


That prepare one is nasty since it's trying to avoid a circular dependency. I'll open an issue for that.


Ah that makes a lot of sense, yes, these things can make native-images 30-50 mb larger and also analysis takes a lot longer. I sometimes work around circular dependencies by creating a volatile in another namespace and vreset-ing the defined function to that volatile, so I can use it from other places. A bit hacky, but it works


Interesting workaround. In my case, prepare/execute-batch! is really in the wrong place. It should have been in result-set instead. But I could use your volatile approach to fix it -- although there might still be paths through people's code to next.jdbc.prepare that don't go through next.jdbc or next.jdbc.result-set which would be the two obvious candidates to include that vreset...