This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-19
Channels
- # announcements (52)
- # asami (83)
- # atom-editor (1)
- # babashka (143)
- # beginners (123)
- # calva (18)
- # chlorine-clover (21)
- # cider (7)
- # clj-kondo (57)
- # cljs-dev (4)
- # clojure (209)
- # clojure-boston (1)
- # clojure-europe (27)
- # clojure-germany (12)
- # clojure-italy (17)
- # clojure-nl (3)
- # clojure-serbia (6)
- # clojure-spec (1)
- # clojure-uk (59)
- # clojurescript (82)
- # conjure (9)
- # core-async (6)
- # cursive (20)
- # data-science (1)
- # datahike (1)
- # datascript (1)
- # datomic (86)
- # duct (5)
- # emacs (6)
- # events (6)
- # figwheel-main (4)
- # fulcro (27)
- # graalvm (19)
- # leiningen (14)
- # lsp (30)
- # malli (48)
- # meander (3)
- # off-topic (6)
- # pedestal (2)
- # practicalli (1)
- # rewrite-clj (21)
- # shadow-cljs (18)
- # sql (15)
- # tools-deps (9)
- # vim (3)
- # wasm (3)
- # xtdb (18)
Any plans to add generators to spartan spec? I see there is already clojure.test.generators in bb.... ?
@holyjak There is also a library called https://github.com/green-coder/minimallist which should support generators, should also work with bb
Hi Gentlepeople, my name is Dominik Mohilo and I am editor for the GERMAN Java Magazine 🙂 I am looking for someone (apart from Mr. borkdude 😉 ) that would like to write an article (deadline. 16th of April) about Babashka for our German audience. Obviously it would be preferred when the article would be written in German, but this is not a must 🙂 Please write me a direct message or an email via <mailto:[email protected]|[email protected]> if you would be able to keep the deadline and are interested in writing 🙂 Hit me also up, if you'd be interested to write about Clojure in the future or about another topic 🙂 Cheers,
We will definitely publish the English version, too 😉
Just not in printed form, unfortunately, but the most likely place for it would be http://jaxenter.com 🙂
Idea for bb.edn: https://github.com/babashka/babashka/discussions/757#discussioncomment-502805 Feel free to comment.
Hola! I’ve got a cljc file that has babashka sections and jvm-clojure forms, and clj-bb-common forms that include symbols like *err*
and pmap
that aren’t available in cljs, so clj-kondo (and by extension clojure-lsp) complain about unresolved symbols. I’m not interested in using this namespace from cljs as all. What’s the common way of making the linter happy in these cases?
@grzm Good question. Can you try :cljc {:features [:clj]}
in your config? I am experimenting with this, it's still undocumented and might change.
Looks like it clears it up the emacs/clojure-lsp, too. So clojure-lsp is .clj-kondo/config.edn
aware?
Are there known issues using babaska pods on NixOS? I’m able to use pods on macOS but not NixOS. I can investigate further, but I wanted to know if this is a known issue before diving in.
On macOS:
bb
Babashka v0.2.8 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.
user=> (require '[babashka.pods :as pods])
nil
user=> (pods/load-pod 'org.babashka/aws "0.0.5")
#:pod{:id "pod.babashka.aws.credentials"}
user=>
On NixOS:
λ bb
Babashka v0.2.8 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.
user=> (require '[babashka.pods :as pods])
nil
user=> (pods/load-pod 'org.babashka/aws "0.0.5")
java.io.IOException: Cannot run program "/home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws": error=2, No such file or directory [at <repl>:2:1]
user=>
λ ls -la /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
-rwxr--r-- 1 mglaesemann cloud_users 99238904 Mar 2 00:19 /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
what happens if you run /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws directly?
Well, isn’t this interesting:
λ ls -la /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
-rwxr--r-- 1 mglaesemann cloud_users 99238904 Mar 2 00:19 /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
17:05 mglaesemann@pair: ~
λ /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
-bash: /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws: No such file or directory
17:05 mglaesemann@pair: ~[127]
This is a message you get when the dynamically linked library cannot be found I think
$ ldd $(which bb)
linux-vdso.so.1 (0x00007ffebb7c3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4177d5f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4177bdc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4177bbb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4177bb6000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4177998000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f417798e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f41777cb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f417cd23000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f41777b1000)
λ ldd /home/mglaesemann/.babashka/pods/repository/org.babashka/aws/0.0.5/pod-babashka-aws
linux-vdso.so.1 (0x00007ffffed1c000)
libstdc++.so.6 => not found
libpthread.so.0 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libpthread.so.0 (0x00007f094aea4000)
libdl.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libdl.so.2 (0x00007f094ae9f000)
libz.so.1 => not found
librt.so.1 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/librt.so.1 (0x00007f094ae95000)
libc.so.6 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libc.so.6 (0x00007f094acd6000)
/lib64/ld-linux-x86-64.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib64/ld-linux-x86-64.so.2 (0x00007f0950d4c000)
17:08 mglaesemann@pair: ~
λ ldd $(which bb)
linux-vdso.so.1 (0x00007fff895ad000)
libstdc++.so.6 => /nix/store/hxs99j1kx878pxxw5lbdarml69r5f1qb-gcc-9.3.0-lib/lib/libstdc++.so.6 (0x00007fcee1fd8000)
libpthread.so.0 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libpthread.so.0 (0x00007fcee1fb7000)
libdl.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libdl.so.2 (0x00007fcee1fb2000)
libz.so.1 => /nix/store/z39zr65hrbimzh40mxmdbpz64ma4b5vy-zlib-1.2.11/lib/libz.so.1 (0x00007fcee1f95000)
librt.so.1 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/librt.so.1 (0x00007fcee1f8b000)
libc.so.6 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libc.so.6 (0x00007fcee1dca000)
libm.so.6 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/libm.so.6 (0x00007fcee1c89000)
/nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/ld-linux-x86-64.so.2 => /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib64/ld-linux-x86-64.so.2 (0x00007fcee6c7c000)
libgcc_s.so.1 => /nix/store/hxs99j1kx878pxxw5lbdarml69r5f1qb-gcc-9.3.0-lib/lib/libgcc_s.so.1 (0x00007fcee1c6f000)
17:09 mglaesemann@pair: ~
Yeah, but there’s the whole Nix layering stuff going on, too. I’ll ask some of our nix gurus.
this downloading of binaries is against the spirit of nix. maybe you should also build the pods using nix recipes. good luck ;)
Indeed 🙂 One more thing to ask the nix gurus about :rolling_on_the_floor_laughing: Or, of course, it could be a learning opportunity
I'm trying to make a small http-server using http-kit and babashka, but the process is quitting, how do I keep babashka alive?
Hi! Can I distinguish whether a bb script is run from the command line (`bb -f`) or inside repl? Python has a nice trick for that and I believed bb as well but cannot find it now... 🙏
thanks a ot!
How do I tell emacs that my file that starts with a shebang (for bb) is a clojure file>
@grazfather https://gist.github.com/borkdude/2b963db1582654ec28bfd40b4dc35748#file-api_diff-clj-L2
because I want it on my PATH 🙂
less typing
hl
is a lot shorter than hl.clj
but the -*-
thing works 🙂
I knew that was a thing, I’ve seen it a ton but I didn’t know its syntax nor its name to google
yeah, makes sense. I've been thinking about a task runner for bb projects. like:
bb hl
and then define in bb.edn
:
{:tasks {hl {:task/type :babashka :args ["-f" "script/hl.clj"]}}}
but because I want to avoid conflicts with existing files, I am considering using keywords for task names:
bb :hl
Would that be too ugly or awkward, or ok?yep, I was just thinking of writing my own. I like the ‘subcommand’ style of clis
bb :hl
would be cool
bb :hl -p "foo.bar"
I thought it would maybe be awkward since keywords are often expected to be used in k/v pairsit is strange when edn-style keywords make it to the shell
but i think it’s used in lein cli sometimes without a corresponding value?
I think it would be kind of distinguishing to use keywords for this, since it's clear you are invoking a task
And I would then promote all of the other things to tasks as well:
bb :uberjar -m foo.bar
I am no UI expert but I prefer that
go run
go build
go env
etc
I am indifferent to whether :
is in there
but if it’s a ‘task’ and you can’t run more than one than I think it’s better without --
there will also be a :do
task which allows you to combine tasks, but the syntax for this is currently controversial:
bb :do :task1 arg1 arg2 :__ :task2 arg1 arg2
why :__
as the delimiter?
I am not sure
--
often separates arg opts from opts to the script
i thought you were alluding to that
lein uses:
lein do task1 arg1 arg2, task2 arg1 arg2
yes, I am alluding to that. but --
might already be used by tasks?as in task1 could also be using --
for its own parsing and then it would never see the remaining args?
this is what I was hinting at
this is what I was hinting at
You definitely are in a weird spot: You’re nesting tasks that can have their own arg parsing delimiters
so pretend I write my own docker exec
in bb
You split the args from the container and the args to the exec
docker exec -it --rm ubuntu -- bash -c "/bin/sh"
(don’t ask why i’d run that)
bb :do :exec -it --rm ubuntu -- bash -c "/bin/sh" :-- ...
--
as task delimiter wouldn’t work there
right {:docker {:task/type :shell :args ["docker exec"]}}
bb :do :docker -it --rm --ubuntu -- bash -c :-- :yolo
:--
seems reasonable. Have you ever seen it used in other clj/lisp cli contexts?
I think that basically you want something unique, obvious, and easy to type
but I would ask people who aren’t me ’cause I am new to clj/lisps
someone also suggested: :--/ok
and :--/continue
to indicate continue even when the previous task failed
or sacrifice that granularity (per task) and instead allow :cont
as an arg taht must be before :do
and apply it to each task
or something make
-like: if the :task
is actually :-task
or similar it means allow errors
[graziano@gm-mbp:~/code/dotfiles/bin]$ make t
false
make: *** [t] Error 1
[graziano@gm-mbp:~/code/dotfiles/bin]$ make t2
false
make: [t2] Error 1 (ignored)
echo ok
ok
[graziano@gm-mbp:~/code/dotfiles/bin]$ \cat Makefile
t:
false
echo ok
t2:
-false
echo ok
Yeah. I just don’t like ‘smuggling’ out bb task context args in the middle of task args
idk if that’s the best word
if you think of like lexical contexts I guess :--/continue leaks out of the task context
bb :do :task1 :t1a1 :-- :task2 :t2a1 :--/continue :-- :task3 :t2a1
between :task2
and :--
in my mind everything should apply to task2
ahh, I guess that is obvious, I misunderstood 🙂
yeah, that seems a lot more reasonable
I don’t imagine it would be used a ton
getting into the weeds, why /
to delimit :--
from the ‘opt’?
we might be bike shedding
you’re pre-1.0 for a reason
if you choose one and people don’t like it, user your god given right to break backwards compatibility
yeah but I am shielded from that 😄
yeah true
YAGNI is a good principle