Clojurians Log v2

We're talking with @viesti about holy-lambda support for babashka runtime. I would love to provide the same interface for babashka as I do for both Java and native runtime. My questions are: 1. Is it possible to pack some macros in babashka pod? If it's possible then on weekend I would release holy-lambda with babashka support 😄 2. Can babashka artifacts be packed in zip?

@karol.wojcik Yes, it is possible to define macros in pods. This is done using :code which defines "client side" code.

> Can babashka artifacts be packed in zip? Not sure what you're asking here. I will go for a run but will be back later.

@karol.wojcik https://github.com/babashka/pods#client-side-code

I want to provide holy-lambda.pod which exposes all the functions and macros to babashka. As I understand it babashka might be packed in the zip, but may I pack the dependencies in zip as well? If yes then in what format should I keep those dependencies?

@karol.wojcik Let's back up a bit. What does unholy lambda do that it needs to be a pod instead of, let's say, a script?

might be that @karol.wojcik realised that on #holy-lambda lambda, but I'll let him explain (explaining out leaves mental tracks :))

I don't know much about babashka. I've used very basic functionality of it to speedup docker builds in my company. @viesti said that babashka can read namespaces from .jar file as well, so maybe it would work that way. Still though don't know how to provide .jar dependencies to babashka.

@karol.wojcik It depends what kinds of dependencies. Not all Clojure dependencies are compatible with bb. So that's why I asked the above question.

You can run jar files with bb -cp foo.jar -m foo for example

Thanks. I can see that clojure.lang.RT is not supported.

That is correct, RT is an implementation detail of Clojure. https://ask.clojure.org/index.php/10303/interop-clojure-pattern-clojure-consider-adding-iter-clojure?show=10305#a10305

I will create a following patch:

#?(:bb
   (defn- process-interceptors
     [mixin payload type]
     (if-let [interceptors (seq (:interceptors mixin))]
       (loop [interceptors interceptors
              result payload]
         (if-not (seq interceptors)
           result
           (recur (rest interceptors) (if-let [interceptor (type (first interceptors))] (interceptor result) result))))
       payload))
   :clj
   (defn- process-interceptors
     [?mixin ?payload ?type]
     (if-let [it (some-> ?mixin :interceptors clojure.lang.RT/iter)]
       (loop [result ?payload]
         (if (.hasNext it)
           (recur
            (if-let [interceptor (some-> (.next it) ?type)]
              (interceptor result)
              result))
           result))
       ?payload)))

yeah that makes sense

You can suggest that you need RT for this iter method in that issue, it's pretty much the nr 1 reason why people depend on RT...

Ok. Babasha fails on including jsonista 😞

----- Error --------------------------------------------------------------------
Type:     java.lang.Exception
Message:  Unable to resolve classname: jsonista.jackson.DateSerializer
Location: jsonista/core.clj:50:3

----- Context ------------------------------------------------------------------
46:   jsonista uses Jackson Databind while Cheshire uses Jackson Core. In our
47:   benchmarks, jsonista performs better than Cheshire (take look at
48:   json_perf_test.clj). On the other hand, Cheshire has a wider set of features
49:   and has been used in production much more."
50:   (:import
      ^--- Unable to resolve classname: jsonista.jackson.DateSerializer
51:     (jsonista.jackson
52:       DateSerializer
53:       FunctionalKeyDeserializer
54:       FunctionalSerializer
55:       KeywordSerializer

babashka has cheshire.core, not jsonista

currently

Will it change in future?

Ok I will just use reader conditionals to use cheshire instead

🙂

Well, I probably won't remove it since that will be breaking, but perhaps add more options later, not sure.

To save you some time, what other deps are you using?

Then I can tell you if that will work or not

It's all I'm using.

Probably in 30 minutes I will have babashka example working.

nice!

@borkdude May i ship babashka with holy-lambda?

Sure

Got it working

@borkdude What is some babashka internal thing that I can prove it's running on babashka?

Ok will use babashka.main.version 😄

Huh. babashka.main is not available in scripts? 😮

You can do (System/getProperty babashka.version) (sorry typing on phone)

Not officially announcing yet, but holy-lambda with some minor tweaks can run on either java, native or babashka 🙂 Thanks @borkdude @viesti

(ns babashka-example.core
  (:gen-class)
  (:require
   [fierycod.holy-lambda.retriever :as r]
   [fierycod.holy-lambda.interceptor :as i]
   [fierycod.holy-lambda.agent :as agent]
   [fierycod.holy-lambda.native-runtime :as native]
   [fierycod.holy-lambda.response :as hr]
   [fierycod.holy-lambda.core :as h]))

(i/definterceptor LogIncommingRequest
  {:enter (fn [request]
            (println "Log incomming request:" request)
            request)})

(h/deflambda HelloBabashka <
  {:interceptors [LogIncommingRequest]}
  [{:keys [ctx]}]
  #?(:bb
     (hr/text (str "Babashka is sweet friend of mine! Babashka version: " (System/getProperty "babashka.version")))
     :clj (hr/text "Why you didn't use babashka? ;/")))


(native/entrypoint [#'HelloBabashka])

(agent/in-context
 (println "In agent context"))

Thank you! Got this working 🙂 https://bdsa1uru44.execute-api.eu-central-1.amazonaws.com/Prod/

Nice!!! @karol.wojcik

Babashka is well implemented I must say. It was just easy to provide such runtime. You're doing great work @borkdude

https://github.com/FieryCod/holy-lambda/blob/master/Makefile another candidate for new tasks 🙂

It's not so big 😄 But this is great candidate: https://github.com/FieryCod/holy-lambda/blob/master/modules/holy-lambda-template/resources/leiningen/new/holy_lambda/Makefile

Ah yes that is the one I was thinking about, reading tutorial.

There is not much yet in tutorial. Would love to work on it more, but my time is very limited 😞

May I please announce the new version here as well @borkdude? Just once to let people know about babashka runtime :)

Of course!

Thank you so much 🙂

As per @borkdude permission, I'm cross-posting this announcement here as well. If you interested in babashka layer then please put :babashka: in official announcement. Hope that #holy-lambda will make some new friends in #babashka community 🙂

Just checked babashka tasks. @borkdude I would love to have them in the project. Is it possibile to provide tasks in jar then somehow automatically merge user and jar tasks?

Right now bb tasks is only supports in bb.edn

Did some more automation, this time around the clj-kondo LSP server: https://github.com/clj-kondo/clj-kondo.lsp/blob/master/bb.edn I can't believe I did many of these steps manually, it's all very tedious. And almost every step depends on a previous step so a perfect fit for tasks. Also used fs/modified-since again to not rebuild the jar if nothing changed.

Ok got it. Will manualy copy bb.edn from one repository to another.

There's a babashka asdf plugin, but the 0.3.* releases don't work. Is this something that should be fixed in the asdf plugin? The code is here: https://github.com/fredZen/asdf-babashka/blob/master/lib/utils.bash#L34

$ asdf install babashka latest
* Downloading babashka release 0.3.5...
curl: (22) The requested URL returned error: 404
asdf-babashka: Could not download <https://github.com/borkdude/babashka/releases/download/v0.3.5/babashka-0.3.5-linux-amd64.zip>
asdf-babashka: An error ocurred while installing babashka 0.3.5.

$ asdf install babashka 0.2.1
* Downloading babashka release 0.2.1...
Archive:  /home/aleks/.asdf/installs/babashka/0.2.1/babashka-0.2.1.zip
  inflating: /home/aleks/.asdf/installs/babashka/0.2.1/bin/bb  
babashka 0.2.1 installation was successful!

@madstap Might be related to a migration from .zip to .tar.gz

False alarm, someone fixed it (just an hour ago)

Nice co-incidence

Might be worth mentioning asdf in the install section of the readme?

Feel free to PR anything that's worth mentioning there

Is it possible to exclude files from being included in a jar via the bb uberjar command?

I'm moving from an uberscript to an uberjar to make use of pods in a bb-based tool. Building with:

bb uberjar clawe.jar -cp $(clojure -A:remove-clojure -Spath) -m clawe.core

I can take a shot at a reproduction or a PR if it's helpful - not sure what the expected behavior is

@russell.matney you should set the classpath before the uberjar command probably

bb -cp $(clojure -A:remove-clojure -Spath) uberjar clawe.jar  -m clawe.core

----- Error --------------------------------------------------------------------
Type:     java.lang.Exception
Message:  File does not exist: uberjar

I tried that first to match the docs, but i get this error

ok, try this:

bb --classpath server/src --uberjar foo.jar

this is the old style

clearly something is wrong, please add to the issue

and PR is welcome to fix it

that seems to build properly, and more reasonably sized - i'm seeing a number of warnings for clashing jar items, which is interesting

{:warning "clashing jar item", :path ".cpcache/1246900521.cp", :strategy :noop}
{:warning "clashing jar item", :path ".cpcache/0DF01609C7D30D4D8B3579B5256F3E83.libs", :strategy :noop}
{:warning "clashing jar item", :path ".cpcache/1246900521.basis", :strategy :noop}
...

try removing the jar file before uberjaring again

It could also be a strange path being built on my part - when i run

bb -cp src/clawe --uberjar clawe.jar -m clawe.core

this is great - the uberjar is at least as fast as the uberscript

bb clawe.jar hello  0.11s user 0.03s system 102% cpu 0.139 total
vs
bb clawe-script.clj hello  0.12s user 0.05s system 103% cpu 0.160 total

thanks for the debugging help @borkdude!

ok. I see the command line parsing in the tests is different from the help

I figured out why it was adding everything - my clojure -Spath had a few empty entries in it :: (`src::/home/russ/russmatney/ralphie/src:/etc` ), which seemed to add the entire current directory

in the tests it accepts --classpath as an argument to the uberjar task

oh that's another bug then probably

please comment all your problems to the issue

will do!

Issue updated - the new info is that it looks like the 'blanks' in the classpath are coming from the classpath-overrides

{:aliases
 {:remove-clojure
  {:classpath-overrides
   {org.clojure/clojure          nil
    org.clojure/spec.alpha       nil
    org.clojure/core.specs.alpha nil}}}
==> resulting path:
src::/home/russ/russmatney/ralphie/src:::/home/russ/.m2/repository/cheshire/cheshire/5.10.0/cheshire-5.10.0.jar:/home/russ/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.10.2/jackson-core-2.10.2.jar:/home/russ/.m2/repository/com/fasterxml/jackson/dataformat/jackson-dataformat-cbor/2.10.2/jackson-dataformat-cbor-2.10.2.jar:/home/russ/.m2/repository/com/fasterxml/jackson/dataformat/jackson-dataformat-smile/2.10.2/jackson-dataformat-smile-2.10.2.jar:/home/russ/.m2/repository/tigris/tigris/0.1.2/tigris-0.1.2.jar

@russell.matney Note that you can now also set the classpath in bb.edn under :paths

but we should still fix this regardless

gotcha - i'll move over to use that