Clojurians Log v2

cheers for the tip!

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 ?

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

Alternatively you can use a hard coded path in load pod

And download the pod yourself in Dockerfile

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

@marco.pasopas https://book.babashka.org/#_running_tests

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

Fighting name-spaces and folders 🙂

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.

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

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

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

.
├── run-test.sh
└── test
    └── util_test.clj

# util_test.clj
(ns util-test)

(deftest testme
  (is (= true)))

(deftest testme2
  (is (= 8 (+ 1 2))))

# run-test.sh
#!/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)))

@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

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

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

Hello! I have read https://github.com/babashka/pods but did not find an explanation of how bb finds the pod. Does it use https://github.com/babashka/pod-registry 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

But it still works

Thanks a lot!

@borkdude I guess it would be nice to update the "About" of https://github.com/babashka/babashka to point to https://book.babashka.org/ 🙏

done

We will perhaps have a nice landing page on http://babashka.org sometime soon.

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

nice!

@borkdude I have just noticed https://github.com/babashka/babashka/pull/642 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

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

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

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

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

ok!

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

good plan!

@borkdude here is my first attempt https://github.com/babashka/babashka-sql-pods/pull/15 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 > com.oracle.svm.core.util.UserError$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

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)

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

ah, this one

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

yes

and compile.bat

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

yes

and appveyor.yaml

🙏

you can do it as a separate PR

I don't see this file

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

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

Welcome @tgg

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: https://github.com/seancorfield/next-jdbc/issues/156

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

Thanks!

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