Fork me on GitHub
#babashka
<
2019-12-24
>
sogaiu01:12:03

fwiw, there is some precedent for .bb already

sogaiu01:12:14

i'm not particularly attached though

sogaiu01:12:10

(i think it will be at least some hours before we hear from borkdude about things 🙂 )

sogaiu01:12:13

i think it would be nice to have an extension specific to babashka for tooling support. however, there is also the idea of somehow being able to interchangeably use clojure files in some cases. haven't quite figured out whether one or the other is preferable overall or whether it's good to use one in some cases and the other in other.

sogaiu01:12:27

may be there is no issue at all 🙂

sogaiu01:12:01

to give some background, some tooling (e.g. chlorine for atom) was using the extension to determine what functionality to execute. this turns out to be at least a bit problematic for clojure clr files because they, like jvm clojure, also use .clj. i guess that got decided before reader conditionals where one expresses the use of clojure clr using :cljr...

borkdude08:12:32

@deleted-user why is .bb not great, can you explain?

borkdude08:12:19

FWIW I’ve been using .clj for scripts that are portable so people without a bb installation can also run them

borkdude08:12:37

On the classpath .bb files have priority over .clj and .cljc. In reader conditionals :bb has priority.

solf08:12:25

I don't know what he had in mind. The only reason I can find it's that you might want to use a regex .cl+ to match clojure-something files

solf08:12:27

Maybe .cl+ extensions are better left to "full" platform implementations

borkdude08:12:54

yeah, I don't think we're going to do .cljb or something. it's kind of an unwritten rule to not name your tools after clojure, I think the same might apply to file extensions

borkdude08:12:43

I'd say just use .clj or .cljc (reader conditionals) unless there's a reason not to.

borkdude08:12:15

I use .bb in the test directory so leiningen won't execute those files

jeroenvandijk09:12:14

I've been using .bb for files that apply to babashka only and .cljc for common code (like in the clj/cljs situation)

borkdude09:12:30

I have a bump-version script here which can be ran with babashka and clojure, so that's why I called it .clj: https://github.com/borkdude/babashka/blob/master/script/bump_version.clj

jeroenvandijk11:12:52

What I like about .cljc is that it also indicates that it can be used by multiple platforms. To me .clj only promises to run in Clojure. It could be misleading for cljs readers maybe though

borkdude10:12:56

Added a section on known babashka libraries: https://github.com/borkdude/babashka#libraries If you have published any useful ones, feel free to add

jeroenvandijk11:12:11

Just playing around now. Does this mean loading the http library takes around 50 ms?

➜  ~ time bb -e "(prn 1)"
1
bb -e "(prn 1)"  0.01s user 0.01s system 80% cpu 0.019 total
➜  ~ time bb -e "(require '[clj-http.lite.client :as client]) (prn 1)"
1
bb -e "(require '[clj-http.lite.client :as client]) (prn 1)"  0.04s user 0.02s system 91% cpu 0.066 total
➜  ~

borkdude11:12:14

think so yes

borkdude11:12:46

you can maybe speed it up by removing clojure and some spec stuff from the classpath

borkdude11:12:09

as clojure puts it on the classpath by default, but that is not needed for bb

borkdude11:12:48

but maybe 50ms isn't too bad

borkdude11:12:11

btw, you can still shell out to curl as well, so this is an experimental phase where it's not yet clear what should go into babashka and what shouldn't. so for now it's a library

👍 4
borkdude12:12:34

$ echo "$(clojure -Sdeps '{:deps {limit-break {:git/url "" :sha "f44ebe45446f0f44f2b73761d102af3da6d0a13e"}}}' -Spath)" | bb -i \
"(->> (str/split (first *input*) (re-pattern (System/getProperty \"path.separator\"))) (remove #(re-find #\"clojure\" %)) (str/join (System/getProperty \"path.separator\")))"
"src:/Users/borkdude/.gitlibs/libs/limit-break/limit-break/f44ebe45446f0f44f2b73761d102af3da6d0a13e/src"

jeroenvandijk12:12:08

> but maybe 50ms isn't too bad Yes I agree. I can imagine it will grow with bigger libraries, but something to figure out. The GraalVM approach could potentially solve that I guess

borkdude13:12:25

if startup time becomes a problem as a result of loading libraries you might as well turn to the JVM instead at that point and pay the 1.5 second startup penalty

borkdude13:12:58

or indeed, roll your own binary

borkdude13:12:28

The new logo just arrived in time for Christmas! https://github.com/borkdude/babashka

👍 8
steveb8n01:12:14

Brilliant. BTW in my use case, I don’t convert back to a string as I’m decoding base64 pdf files. works great too!