Fork me on GitHub

Hi guys, what's the easiest way to use babashka + sqlite3 for Intel and M1 Mac? I tried out but bombs out with an M1 machine


@UR37CBF8D You could try running it under Rosetta and it should download the amd64 pod and work as expected. Meanwhile I can look into setting up the CI to produce arm64 mac Go binaries too.


Since @U04V15CAJ has an M1 machine now, maybe he could attach an arm64 binary to the release for now? 😄


Also how are you running babashka on M1? Is it a docker image or running under Rosetta already? We dont have M1 builds for bb yet, it shouldve downloaded the correct pod


ah or i guess if you're using docker then we would need a arm linux binary too.


Hey man, actually, I'm not the one running on M1 (an interviewer that I submitted a technical test to, is) For now, I've just migrated the code to regular Clojure (instead of running via babashka)


I'll test on my M1


macOS Monterey 12.3


Perhaps things improved with M1 compatibility in newer macOS versions. I also noticed this with clj-kondo.


Can you ask the interviewer/interviewee what version of macOS they are running?


Ah I see. Yep I'll ask


And could you also ask wether they were able to run babashka at all or if the problem was with the go-sqlite3 pod specifically?


Nice! I'll anyways take this opportunity to start producing arm Linux and mac binaries. Should be useful sooner or later.


@U04V15CAJ I think he was able to run bb, here's the trace:

----- Error --------------------------------------------------------------------
Type:     java.lang.IllegalArgumentException
Message:  No executable found for pod org.babashka/go-sqlite3 (0.1.0) and OS Linux/aarch64
Location: /api.clj:13:1

----- Context ------------------------------------------------------------------
10: ;; --- Load extra deps not supported by babashka out of the box
12: ;; See 
13: (pods/load-pod 'org.babashka/go-sqlite3 "0.1.0")
    ^--- No executable found for pod org.babashka/go-sqlite3 (0.1.0) and OS Linux/aarch64
14: (require '[pod.babashka.go-sqlite3 :as sqlite])
16: ;; See 
17: (deps/add-deps '{:deps {camel-snake-kebab/camel-snake-kebab {:mvn/version "0.4.2"}}})
18: (require '[camel-snake-kebab.core :as csk]

----- Stack trace --------------------------------------------------------------
babashka.pods.impl.resolver/match-artifacts - <built-in>
babashka.pods.impl.resolver/resolve         - <built-in>
babashka.pods.impl/load-pod                 - <built-in>
babashka.pods.sci/load-pod/fn--31543        - <built-in>
babashka.pods.sci/load-pod                  - <built-in>
clojure.core/apply                          - <built-in>
babashka.impl.pods/load-pod                 - <built-in>
api                                         - /api.clj:13:1


It looks like he ran this in linux, perhaps Docker, then


Ah wait, good point. I misread that arm64 🤯 yeah, I guess a docker container in a M1 mac


ok, then providing the arm64 for linux is the solution. @U7ERLH6JX


Yeah and can do the mac one when bb arm is there for mac too


@UR37CBF8D @U7ERLH6JX it should now work on aarch64 macos docker:

$ docker run --rm -it babashka/babashka
Babashka v0.7.8 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (System/getProperty "os.arch")
user=> (babashka.pods/load-pod 'org.babashka/go-sqlite3 "0.1.0")
Downloading pod org.babashka/go-sqlite3 (0.1.0)
Successfully installed pod org.babashka/go-sqlite3 (0.1.0)
#:pod{:id "pod.babashka.go-sqlite3"}
You will have to clear out ~/.babashka/pods/repository before trying again

🎉 1

oh damn, sweet, thanks guys

Jo Øivind Gjernes13:03:02

Is it possible to compile babashka for native/m1 now ?


@jodleif Not yet, but you can use it within docker on m1 as aarch64.

Jo Øivind Gjernes13:03:52

I was able to get graalvm up and running with native-image

Jo Øivind Gjernes13:03:57

(had to build it from source)

Jo Øivind Gjernes13:03:14

ok, got it working. Had to modify script/compile a tiny bit to make it compile


you have m1 compilation working?

Jo Øivind Gjernes13:03:30

Finished generating ‘bb’ in 1m 0s.

Jo Øivind Gjernes13:03:39

Yeah--- had to build graalvm manually


can you summarize what you did on the wiki maybe?

Jo Øivind Gjernes13:03:15

Create a new page?


Yeah, maybe a page about M1


I mean also how to compile graalvm for m1 yourself


haven't tried that myself yet

Jo Øivind Gjernes14:03:36

👍 It was very simple now that a recent JDK was posted on the graal/issue


I wonder how fast this example runs for you:

./bb -e "(time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))"

Jo Øivind Gjernes14:03:22

It’s a bit rough- but take a look ^


That's totally fine! I'll take it for a spin soon, thank you very much!


Instructions on how to compile #babashka for Apple M1 processors: Thank you @jodleif!

Jo Øivind Gjernes14:03:29

I tested with OpenJDK 17 from the graal m1 issue thread linked in the wiki


Ah, maybe add that to the wiki?

👍 1

How's the compilation time of bb itself? Which machine are you using?

Jo Øivind Gjernes14:03:54

I’m on a MBP/M1 MAX

Jo Øivind Gjernes14:03:55

finished generating 'bb' in 1m 11s.


On my m1 air compilation time is 1m23


I will soon merge this to master after some more testing


Perhaps an odd question. Is there a way to compile a babashka script into a native executable, thus eliminating the need to install babashka?


Since caxa is under nbb - does the resulting binary use node.js? Or does that work for any babashka script, independent of Node?


@teodorlu @hairfire Oh sorry, I meant to link to this one: caxa runs using Node.js, but that's just an implementation detail, the resulting binary does not need Node.js

👍 1
awesome 1

caxa could have been implemented using golang or Rust, but people do use it to bundle Node.js (and nbb) scripts as executables too. it creates self-extracting tar-balls, works even on Windows, provided you bundle the Windows binaries of course

👍 1