This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-22
Channels
- # announcements (28)
- # babashka (77)
- # beginners (122)
- # calva (40)
- # circleci (3)
- # clj-kondo (47)
- # cljs-dev (9)
- # clojure (119)
- # clojure-australia (1)
- # clojure-europe (88)
- # clojure-nl (3)
- # clojure-uk (33)
- # code-reviews (64)
- # core-logic (37)
- # cursive (10)
- # datomic (13)
- # emacs (1)
- # fulcro (4)
- # graalvm (1)
- # graphql (5)
- # helix (4)
- # integrant (25)
- # jobs (1)
- # jobs-rus (1)
- # off-topic (3)
- # pathom (12)
- # random (1)
- # re-frame (48)
- # reagent (1)
- # remote-jobs (1)
- # reveal (1)
- # rewrite-clj (4)
- # ring (6)
- # ring-swagger (1)
- # shadow-cljs (21)
- # sql (8)
- # tools-deps (25)
- # vim (15)
- # xtdb (12)
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 đ
@marco.pasopas go to the book and Ctrl-f on clojure.test. It is in there somewhere
@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?
@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)))
Still it shows up with running 0 tests running@marco.pasopas '[util]
should be 'util-test
that invocation should throw with "Could not find namespace util" or something similar
I mean, in util
you need to require clojure.test
as well and :refer [deftest]
if you want to use it unqualified
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
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/ đ
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
@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
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
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
Some things trigger excessive growth (usually runtime resolve
or require
), so taking it one var and test at a time is probably the best
@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? đ
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
ah, this one
--initialize-at-run-time=java.lang.Math\$RandomNumberGeneratorHolder \
in compile
?I don't see this file
I guess I should also update generate_circleci.clj
to use 20.3.0?
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
@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!
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
...