Fork me on GitHub
#babashka
<
2023-03-23
>
benfleis15:03:33

I’m quite ign’ant on my new-ish ARM mac, but naively using the fswatcher pod fails on my ARM mac:

λ › bb -h
Exception in thread "main" java.io.IOException: Cannot run program "/Users/ben/.local/share/.babashka/pods/repository/org.babashka/fswatcher/0.0.4/mac_os_x/aarch64/pod-babashka-fswatcher": error=86, Bad CPU type in executable
 ...
λ › file /Users/ben/.local/share/.babashka/pods/repository/org.babashka/fswatcher/0.0.4/mac_os_x/aarch64/pod-babashka-fswatcher
/Users/ben/.local/share/.babashka/pods/repository/org.babashka/fswatcher/0.0.4/mac_os_x/aarch64/pod-babashka-fswatcher: Mach-O 64-bit executable x86_64
...
I see that there are no aarch64 binaries here: https://github.com/babashka/pod-babashka-fswatcher/releases/tag/v0.0.4 Manually building it works as expected, but it’s unclear to me whether the auto-translation magic should just be happening underneath, or that I should be asking about adding an aarch64 release for mac os. (I assume the former, since I can’t be the first to come across this?)

borkdude15:03:16

and asking for an aarch64 mac release is ok too

borkdude15:03:45

but rosetta2 would solve it for now

benfleis15:03:27

gotcha, thanks! (I’ll add a small issue in the repo too)

camdez18:03:16

Hi all. Having a bit of trouble reading a file relative to my bb.edn file when running Babashka from a different directory. Files are like this:

bb.edn
bb/tasks/mytask.clj
foo/resource.json    ; what I want to read
bar/                 ; working directory
Everything works fine if I run bb mytask from the root directory. When running from bar/ (via bb --config ../bb.edn mytask), I need some notion of where bb.edn is, or where mytask.clj is so I can find my way to resource.json. Within mytask.clj, (System/getProperty "babashka.file") returns nil, and *file* returns "<expr>", presumably owing to the fact that it’s running via exec. No sweat, I thought, I’ll just pass in the directory via :exec-args. But what the task receives is the unevaluated form (e.g. *file*), not the file path. Any suggestions?

borkdude18:03:49

@U0CV48L87 You can add the resources.json to the classpath and then use (io/resource "resource.json") . Just put that file in $project/resources and add :paths ["resources"] to your bb.edn

camdez18:03:21

Hmmm, that is a fair point. It’s an optional configuration file, not committed (contains secrets, etc.), so I don’t really think of it as a project resource conceptually, but it’s probably a fine solution.

camdez18:03:32

Thank you for the suggestion!

borkdude18:03:41

There is also a system property: babashka.config which contains the (absolute) link to the config file

borkdude18:03:38

You can also put (def current-file **file*)* in mytask.clj which has the absolute path to the file.

borkdude18:03:08

Just don't use *file* in a function at runtime, this value is only bound to the file it's evaluated in during analysis.

borkdude18:03:55

So not like this:

(defn foo []
  *file*)

borkdude18:03:02

but like this:

(def foo *file*)

camdez18:03:23

Ahhh, that’s how it’s implemented. Awesome! Thank you.

borkdude18:03:33

Same as Clojure JVM

borkdude18:03:21

This will also work btw:

(some-> (resolve 'mytask/function) meta :file) 

👍 2
Max19:03:46

What’s the most straightforward way to correctly parse possibly-url-encoded query strings? I’m hesitant to pull in ring’s codecs library for just the parser

borkdude19:03:08

user=> (java.net.URLDecoder/decode "foo%20bar")
"foo bar"

Max19:03:24

and just pull apart the key=val part with a regex or something?

borkdude19:03:06

that is query param parsing, not url decoding 😅

Max19:03:39

aren’t querystrings url-encoded by the browser by default?

Max19:03:44

or did I mix up my encodings

borkdude19:03:50

but yea, it should not be that difficult (he said optimistically)

😅 2
borkdude19:03:15

yes, you're right