Clojurians Log v2
babashka
Extended poll about including clojure.spec in babashka here: https://twitter.com/borkdude/status/1300428421252747266
And the issue: https://github.com/borkdude/babashka/issues/558
> I think it would be good to try it again, since there were several improvements concerning performance @borkdude The script is broken it seems (not sure if was working before). I’ve updated it so that the command generation will work. The spartan.spec version still adds quite some overhead 130ms vs 100ms.
time bb -f tasks.cljc
No task found for ''
Existing tasks
* options : Demonstrate the task options DSL.
bb -f tasks.cljc 0.09s user 0.04s system 89% cpu 0.140 totaltime QUICK=1 bb -f tasks.cljc
No task found for ''
Existing tasks
* options : Demonstrate the task options DSL.
QUICK=1 bb -f tasks.cljc 0.06s user 0.03s system 92% cpu 0.093 total
What is driving the inclusion of spec in either version?
Excellent question. Some people like to validate their command line args with spec: https://github.com/l3nz/cli-matic/issues/113 Some people like to generate data from specs. Instrumenting functions during script development (may be far fetched). There's probably more command line applicability to spec, but maybe it's not really an urgent thing to have. @jeroenvandijk also had a need for it. Earlier requests resulted in a library which can be interpreted and is not built-in: https://github.com/borkdude/spartan.spec
If you have any thoughts on this, I'd like to hear them. Btw, the version with the uberscript fixes was released (0.2.0).
Thanks for the release
I wonder how Clojure will incorporate spec alpha2. I suppose it could just include both versions so it doesn’t make a breaking change.
Good question. I'll ask in #clojure-spec
Regarding my use case, I was working on a cli tool for launching cloudformation stacks. I wanted to validate these templates with Spec (and expound). At the time it was unclear (to me) how Spec could work with Graalvm. Now there are more examples of this option, but being able to use spec for things like this, without needing to set up a graalvm project makes things easier and cheaper
Can spec not be used with bb by adding it to the class path?
Right now it can't. That's why I have created spartan.spec
At least at the time there were several limitations. And having spec built-in will make it run lots faster
Malli might also be interesting to look at, since it's more data driven
Mali does indeed look very interesting
Ah yeah regarding speed, I had a cli parser with spartan.spec and it was indeed to slow https://gist.github.com/jeroenvandijk/c6cb6cdecfd5aa8e990c3765f3411c0f
I think it would be good to try it again, since there were several improvements concerning performance
True, I’ll do that tomorrow probably
$ time bb tasks.cljc options -a :foo
::foo
bb tasks.cljc options -a :foo 0.10s user 0.03s system 93% cpu 0.135 totalWould making it easier to build graalvm native images reduce the pressure to include more things in bb?
There's one project that allows you to convert a babashka script into a Graal binary: https://github.com/MnRA/nativity
I think having a compilation step in between is always going to be a barrier, no matter how "easy", it will still take time and memory
There is also distribution. Is Brew a sufficient distribution mechanism for Linux and windows?
For things that are not used by everyone there is https://github.com/babashka/babashka.pods. It lends itself well for libraries that receive data and return data. Spec is probably not so suited for that architecture.
Brew doesn't work on Windows, but Windows has scoop, which is similar
Babashka pods do have the same distribution problems as other graal binaries
I think brew and scoop are nice solutions for distributing binaries
I'd like to get an idea on core.async usage in babashka. If you are using it, please leave a note here: https://github.com/borkdude/babashka/issues/559