Fork me on GitHub
#babashka
<
2020-06-12
>
jeroenvandijk06:06:21

Doing some performance tests for issue https://github.com/borkdude/sci/issues/348 I got the feeling some tooling is missing to do these tests properly. I think I miss a criterium for command line utils. Ideally you would want to compare two binaries under the same circumstances. I think this requires shuffling of tests cases, setting thresholds and some other tricks. We could write this in Babashka itself. What do you think?

borkdude10:06:14

idea: a .babashka directory with a config.edn with e.g. a :classpath-cmd that tells babashka how it should get a classpath for the current directory (project) using some other tool, most often clojure -Spath haven't really thought this through, or simply a :classpath entry that can be "." or "src:test" or :paths` rather, with just ["src", "test"]

borkdude10:06:03

classpath-cmd could also just be git clone + printing a string of the cloned dir for projects that don't have transitive deps

dominicm11:06:31

bb-deps.edn

jeroenvandijk12:06:36

@borkdude sounds handy! Is your main intention to support libraries like deps.edn or do you have other use cases in mind?

borkdude12:06:34

the question which sparked this was @bozhidar asking if babashka has some kind of notion of a "project" and if so, how CIDER can know about it

jeroenvandijk12:06:07

Makes sense. I can also imagine that it would be useful to know how to retrieve a pod and what version. Slightly different problem I guess

dominicm13:06:05

I suspect there's an important question about what users expect. Cider could perhaps use the deps.edn?

borkdude13:06:01

right now people should just start their --nrepl-server manually and connect from CIDER with cider-connect - which is fine

borkdude14:06:19

Latest commits on master add compatibility with clojure.data.generators 🙂 - thanks @jeroenvandijk

$ export BABASHKA_CLASSPATH=$(clojure -Sdeps '{:deps {org.clojure/data.generators {:mvn/version "1.0.0"}}}' -Spath)
$ bb -e "(require '[clojure.data.generators :as gen]) (binding [gen/*rnd* (java.util.Random.)] (gen/anything))"
5997391543372303418/406970517245213237
$ bb -e "(require '[clojure.data.generators :as gen]) (binding [gen/*rnd* (java.util.Random.)] (gen/anything))"
#uuid "5d31aa8f-6d13-a110-f924-a1c55a325ab3"

jeroenvandijk14:06:45

Awesome! @borkdude thank you 🙂

jeroenvandijk15:06:00

I would like to expand on this idea to make performance tests more reliable https://gist.github.com/jeroenvandijk/dcfebddd7ba9bda1ae298b29ee2f8998

borkdude15:06:51

that's a very nice idea

jeroenvandijk15:06:41

for next week 🙂

plins16:06:57

Im trying to use the new csk included lib without success

bb                                                                           ✔  13:36:51 
Babashka v0.1.1 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (require '[camel-snake-kebab.core :as csk])
java.lang.Exception: Could not require camel-snake-kebab.core. [at line 1, column 1]

plins16:06:09

am I missing something?

borkdude16:06:25

probably the classpath?

plins16:06:02

so its not included with babashka but now its being supported because of partial protocol support?

plins16:06:59

I mean, I can require chesire without setting any classpath right?

borkdude17:06:57

Got an experimental branch with taoensso/nippy in it:

$ ./bb "(require '[taoensso.nippy :as n]) (n/thaw (n/freeze [1 2 3]))"
[1 2 3]
Not sure how useful that would be. I haven't used this myself a lot. Would also consider to make a pod for it first, but at least it's GraalVM compatible.

nate18:06:37

oh awesome!

nate18:06:39

I have quite a bit of nippy'd data, and having this in bb would be incredibly useful

borkdude18:06:31

I also tried to make it work as running from source as a lib, but I'd have to put a lot of stuff in the reflection config. it is doable though

nate18:06:15

looking at the diff, it looks like I was heading in the right direction

nate18:06:35

when the lib was trying to use java.lang.reflect.Method, I got scared

borkdude18:06:07

exactly. then it'd needed to use reflection to invoke java.lang.reflect.Method... hmm

borkdude18:06:21

I'm a bit unsure about including it in bb right now, given nobody has requested it before but you, but doing it as a pod is a no-risk thing. I'm wondering what's the kind of data you freeze and thaw, pure EDN or also records, etc?

borkdude18:06:11

and what's your main use case for using this over EDN, JSON or Transit?

nate18:06:43

we use nippy primarily for storage and transfer of large data sets, because it's so compact and it retains types

borkdude18:06:55

what kind of types

borkdude18:06:06

(hence my pure EDN question)

nate18:06:11

usually just keywords, sets

borkdude18:06:24

but transit also does that?

nate18:06:24

we used to use edn for these, but the data is big enough that it's really slow

nate18:06:41

transit isn't as compact as nippy

borkdude18:06:54

does nippy also use gzip, or what makes it compact?

nate18:06:19

I'm not sure if it gzips, but it's usually about the same level of compactness that gzip gets

borkdude18:06:25

there is usually a trade-off between speed and size

nate18:06:51

nippy is amazingly fast and the serialized format is very compact

nate18:06:30

we use it sometimes for when we have a dataset in memory and want to save it out for ease of reloading, we'll just nippy it out to a file

borkdude18:06:31

@nate here are some binaries with nippy in it: https://clojurians.slack.com/archives/CSDUA8S6B/p1591979798021900 you could try and see if it works as expected and report some problems in that issue if there are any

nate18:06:52

I have a pretty big data set right now, trying different options to have a comparison