Fork me on GitHub
#babashka
<
2023-03-11
>
borkdude11:03:18

Recommended listen if you want to know more about @rahul080327, the "behind the scenes" of babashka's development and the contents of the coming workshop at https://clojure.stream!

👀 2
2
Mario Giampietri11:03:13

Late to the party - well done @rahul080327 👏 Question: I was caught off on the point of (more or less) additional checks/verifications per platform needed because after code is interpreted, is on another platform, we don't have the JVM comfort zone as we do in Clojure JVM which highlighted my lack of understanding on how things are on Clojure JVM vs Babashka. I was assuming that things were more or less write once run everywhere also for GraalVM. I guess this is an issue "only" for a maintainer (Babashka maintainers in this case), so that final users/devs can actually write once run everywhere. Is this correct? I was searching actual examples in this area. Could you confirm that the changesets below are good examples of this problem, or if not, can you provide another example? Thanks. Changeset 1: https://github.com/babashka/babashka/commit/34136173d52cc837561455be82ed90e619e4fc1f Changeset 2: https://github.com/babashka/babashka/commit/b5dea3563d777684d9e4a2c8318fd5d3befab8bf

lispyclouds17:03:16

Yes so that concerns mostly with building babashka itself not the code that it runs. The part of graalvm that we use is called the Native image to build bb and as the name suggests it compiles code to native assembly much like C or Go or Rust compilers would do. This makes it platform dependent like those languages unlike Java or usual clojure which compiles to portable bytecode.

👌 2
lispyclouds17:03:44

The examples you looked at is us making decisions based on which platform you want to target. It’s the same as building the JVM itself for instance. All the byte codes are write once run anywhere but not the JVM itself. That’s platform dependent.

Peter Tonner19:03:55

is there are way to play nicely with command line tools that modify the shell with source ? Unless I'm totally missing something, this doesn't seem to work for me. My specific use case is SDKMAN, which requires a source "$HOME/.sdkman/bin/sdkman-init.sh" in your shell config to work. This, among many things, defines an sdk shell function for use on the command line. But when I try say bb -e "(require '[babashka.process :refer [shell]]) (shell \"sdk help\")" I get an error saying "Cannot run program 'sdk'". This is despite the fact that I can run sdk help directly in the same shell no problem. I also am not able to do bb -e "(require '[babashka.process :refer [shell]]) (shell \"source /path/to/.sdkman/src/sdkman-main.sh\")", instead receving an error "Cannot run program 'source'"

borkdude19:03:52

source is a built-in shell command, so you should do something like:

(shell (System/getenv "SHELL") "-c" "source" ...)

Peter Tonner19:03:15

got, I'll try that!

borkdude19:03:19

If sdk is function you should do the same

borkdude19:03:34

shell only runs binaries on your system, it actually doesn't use a shell ;)

borkdude19:03:50

it's only called like that because of the term "shelling out"

Peter Tonner19:03:11

oh okay, that makes sense - will definitely add that shell-calling pattern to my codebase somewhere I think I'll need it a lot. and calling sdk works now, thanks!

👍 2
pesterhazy21:03:28

Development question: How do I try out bb code from lein repl? Is this the recommended way?

(babashka.main/main "-e" "(prn :foo)")

borkdude21:03:14

or from the command line:

clj -M:babashka/dev -e '(prn :foo)' 

👍 2
borkdude21:03:31

where babashka/dev is a local/root dependency with :main-opts ["-m" "babashka.main"]

borkdude21:03:48

I usually use clj for local development