This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-30
Channels
- # announcements (1)
- # babashka (28)
- # beginners (68)
- # cider (12)
- # clj-kondo (5)
- # clojure (37)
- # clojure-spec (4)
- # core-async (5)
- # cursive (3)
- # data-science (1)
- # datomic (70)
- # fulcro (18)
- # graalvm (1)
- # joker (1)
- # luminus (2)
- # malli (11)
- # off-topic (21)
- # shadow-cljs (3)
- # spacemacs (11)
- # test-check (3)
- # vrac (8)
Extended poll about including clojure.spec in babashka here: https://twitter.com/borkdude/status/1300428421252747266
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. @U0FT7SRLP 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).
I wonder how Clojure will incorporate spec alpha2. I suppose it could just include both versions so it doesn’t make a breaking change.
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
At least at the time there were several limitations. And having spec built-in will make it run lots faster
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 total
Not sure how I should invoke the scriptWould 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.
> I think it would be good to try it again, since there were several improvements concerning performance @U04V15CAJ 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 total
vs
time 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
code is here https://gist.github.com/jeroenvandijk/c6cb6cdecfd5aa8e990c3765f3411c0fI'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