This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-21
Channels
- # announcements (13)
- # babashka (63)
- # babashka-sci-dev (64)
- # beginners (37)
- # biff (1)
- # calva (10)
- # cider (7)
- # clj-kondo (15)
- # cljsrn (6)
- # clojure (26)
- # clojure-dev (10)
- # clojure-europe (34)
- # clojure-france (9)
- # clojure-nl (2)
- # clojure-norway (36)
- # clojure-uk (5)
- # clojurescript (142)
- # community-development (1)
- # conjure (3)
- # datalevin (5)
- # datalog (2)
- # datomic (5)
- # events (11)
- # fulcro (40)
- # gratitude (9)
- # guix (32)
- # honeysql (10)
- # jobs (2)
- # lsp (32)
- # malli (15)
- # meander (5)
- # membrane (43)
- # missionary (3)
- # nextjournal (9)
- # off-topic (38)
- # pathom (3)
- # polylith (30)
- # portal (78)
- # programming-beginners (4)
- # quil (6)
- # re-frame (20)
- # reagent (21)
- # remote-jobs (2)
- # shadow-cljs (7)
- # tools-deps (6)
- # xtdb (23)
Hi guys, what's the easiest way to use babashka + sqlite3 for Intel and M1 Mac? I tried out https://github.com/babashka/pod-babashka-go-sqlite3 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)
This example ran fine on my M1: https://github.com/babashka/pod-registry/blob/master/examples/go_sqlite3.clj
Perhaps things improved with M1 compatibility in newer macOS versions. I also noticed this with clj-kondo.
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?
Also ask them to try the same exact example here: https://github.com/babashka/pod-registry/blob/master/examples/go_sqlite3.clj
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 ------------------------------------------------------------------
9:
10: ;; --- Load extra deps not supported by babashka out of the box
11:
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])
15:
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
Ah wait, good point. I misread that arm64 🤯 yeah, I guess a docker container in a M1 mac
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")
"aarch64"
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 againoh damn, sweet, thanks guys
Is it possible to compile babashka for native/m1 now ?
I was able to get graalvm up and running with native-image
(had to build it from source)
ok, got it working. Had to modify script/compile a tiny bit to make it compile
Finished generating ‘bb’ in 1m 0s.
Yeah--- had to build graalvm manually
Create a new page?
👍 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)))"
It’s a bit rough- but take a look ^
Instructions on how to compile #babashka for Apple M1 processors: https://github.com/babashka/babashka/wiki/Compiling-for-M1 Thank you @jodleif!
I tested with OpenJDK 17 from the graal m1 issue thread linked in the wiki
I’m on a MBP/M1 MAX
finished generating 'bb' in 1m 11s.
@jodleif Adapted the wiki, it already became a lot easier: https://github.com/babashka/babashka/wiki/Compiling-for-M1
Perhaps an odd question. Is there a way to compile a babashka script into a native executable, thus eliminating the need to install babashka?
@hairfire yes, there is using caxa: https://github.com/babashka/nbb/tree/main/doc/caxa
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: https://github.com/babashka/babashka/wiki/Self-contained-executable caxa runs using Node.js, but that's just an implementation detail, the resulting binary does not need Node.js
