This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-21
Channels
- # announcements (1)
- # aws-lambda (62)
- # babashka (116)
- # beginners (67)
- # chlorine-clover (39)
- # cider (10)
- # cljs-dev (5)
- # clojure (30)
- # clojure-austin (2)
- # clojure-europe (2)
- # clojure-italy (6)
- # clojure-nl (24)
- # clojure-uk (28)
- # clojurescript (33)
- # data-science (6)
- # datascript (10)
- # datomic (5)
- # duct (39)
- # emacs (1)
- # events (8)
- # fulcro (9)
- # graalvm (29)
- # hoplon (7)
- # juxt (10)
- # malli (4)
- # off-topic (6)
- # pathom (10)
- # perun (1)
- # reagent (45)
- # shadow-cljs (5)
- # sql (14)
- # tools-deps (10)
- # xtdb (9)
anyone had luck getting http://java.io.File's deleteOnExit to work in babashka?
regarding sha1-ing of strings, here's something that i've tested on linux and windows: https://gist.github.com/sogaiu/fa930abb815daade41dd24e0c76f4d86
(def hashed (.digest (.getInstance java.security.MessageDigest "SHA-1")
(.getBytes "babashka")))
(doseq [b hashed]
(print (format "%02X" b)))
prints:
0AB318BE3A646EEB1E592781CBFE4AE59701EDDF
@borkdude ah thanks -- that works on linux. i don't see why it shouldn't on windows. will check.
here's a defn version:
(defn sha1
[a-string]
(let [hashed (.digest (.getInstance java.security.MessageDigest "SHA-1")
(.getBytes a-string))]
(apply str (map #(format "%02X" %) hashed))))
added it to the docs: https://github.com/borkdude/babashka/#sha-hash-string-and-print-in-hex
Babashka on AWS Lambda: https://github.com/dainiusjocas/babashka-lambda
@hobosarefriends The above example is interesting, maybe also inspiring for your problem to package up a bb script as a standalone thing. Maybe packaging it as a Docker image could work. 🙂
Just push it to docker hub mno/thing and then let the consumer run it as docker run --rm mno/thing
I mean, you can make a Dockerfile:
FROM borkdude/babashka
COPY yourscript
ENTRYPOINT bb yourscript
and then push it to dockerhub.making a tiny bash script that downloads bb on their system and then runs your script also could work 😉
I wonder what the startup time on linux is for docker. On macOS it's not too great, like 400ms 😉
Though that's probably a fixed cost, and half a second isn't too much unless you're running it a bunch
Filed https://github.com/borkdude/babashka/issues/303 and submitted https://github.com/borkdude/babashka/pull/304 to make it a built-in alias.
@renewdoit responded in the issue
@renewdoit to recap: the library comb can be interpreted with babashka, but cannot be compiled with graalvm native, because graalvm native cannot handle clojure.core/eval.
therefore it cannot be included, that's the technical argument. the other argument is that we should consider carefully all alternatives before including something in bb, because once it's in, it's likely that we'll have to maintain it forever
But it's nice that you pointed at this lib, because now we can list it with the compatible libraries: https://github.com/borkdude/babashka/#comb
running into a bit of an inconsistency and wondering if it's a bug in my code or something in babashka (story in thread)
mostly a proof of concept, but I'm working on a bb script that uses comb to template edn data
if I run my code with deps.clj:
$ cat data/names.edn | bb -I --stream -cp $(deps.clj -Spath) "(ns user (:require [comb])) (apply comb/-main *command-line-args*)" -t "<%= name %>"
data: {:name "Bob"}
Bob
data: {:name "Bob"}
Bob
but if I uberscript it and run it:
$ cat data/names.edn | bb -I --stream -f uberscripts/comb.clj -t "<%= name %>"
data: {:name "Bob"}
Bob
data: {:name "Marcia"}
Marcia
I can't figure out why the classpath version doesn't properly re-bind user/*input*
to each input map
I don't really mind to terribly much as I'm planning on using the uberscript versions after development
@borkdude Here's a repo with minimal code for reproduction. I also put the commands in the readme. https://github.com/justone/bb-input-repro
Thanks, that's a big compliment. I found something:
"stream?" true
dude
read from in {:name Bob}
args nil
input {:name Bob}
dude
read from in {:name Marcia}
args nil
input {:name Bob}
yeah, so $ cat names.edn | clj -A:bb-local -I --stream '*input*'
works as expected... hmm
this also works as expected:
$ cat names.edn | clj -A:bb-local -I --stream -cp src "(ns user (:require [testinput])) (prn \"X\" user/*input*) "
When I first ran the one that prints two Bobs, I figured it was something with my code. And then I tried the uberscript version and was surprised that worked.
Note that:
$ cat names.edn | bb -I --stream -cp src "(ns user2 (:require [testinput] :reload)) (apply testinput/-main *command-line-args*)"
Bob
Marcia
does work 😉re-using the existing var did the trick. the code that re-inserted a new item into the state every iteration was still from the time that we didn't have vars.
First, thank you so much for babashka, @borkdude! It scratches an itch that I'd only just begun to realize I had. 😄
I'm running into an issue where clojure's reader function fails to read files off linux's /proc
fs, apparently due to the way procfs reports virtual file metadata.
user=> (-> "/proc/loadavg" io/reader line-seq)
Execution error (IOException) at .FileInputStream/available0 (FileInputStream.java:-2).
Invalid argument
Apparently there's a workaround using java's FileReader
instead of the BufferedReader
that Clojure's reader
uses, but I'm unable to import it under babashka:
user=> (import .FileReader)
Unable to resolve classname: .FileReader [at line 1, column 1]
If not, (shell/sh "cat" "/proc/loadavg")
is always an option, but hoping there's a way that doesn't require a new process.
creating a new process with babashka isn't too bad though, it's what you would have done in a bash script as well
I'm not sure in what other cases FileReader would be useful. Note that it will add size to the binary if we include it, so if the use case is fairly niche, shelling out might be preferable
In bash I would have done something like: cut -d' ' -f1,2,3 < /proc/loadavg
, which afaict would have been one external process cut
with /proc/loadavg
redirected as its stdin. In babashka I can (and do) just use str/split
and keep-indexed
for this, so it can be all in process.
I kind of feel like my case is niche and easily worked around using cat
, but since procfs misreports inode data for all its virtual file entries, which are numerous. io/reader
and slurp
would be equally unusable for them as well. But it would be just as easily worked around using cat
.
As a result of procfs being my primary driver, the test would be OS-specific.
The size with filereader is 42025276. Without filereader it's 42008876. That's 16kb, almost nothing if you ask me, so I'm ok with adding it.
My native-image install seems to be broken, but the jar seems to work just fine:
[git:master] kanin:…/code/github/babashka>% rlwrap java -jar target/babashka-0.0.79-SNAPSHOT-standalone.jar
Babashka v0.0.79-SNAPSHOT REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.
user=> (import '.FileReader)
user=> (require '[ :as io])
user=> (-> "/proc/loadavg" FileReader. io/reader slurp)
"0.57 0.28 0.11 3/239 2989\n"