Clojurians Log v2

Any plans to add generators to spartan spec? I see there is already clojure.test.generators in bb.... ?

@holyjak Feel free to try to add them.

@holyjak There is also a library called https://github.com/green-coder/minimallist which should support generators, should also work with bb

I didn't test it though

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:dmohilo@sandsmedia.com|dmohilo@sandsmedia.com> 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,

Hopefully it will be written in English and published somewhere in that shape. 😃

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?

oh my goodness, I've been meaning to write this exact same thing in babashka at some point: https://stevelosh.com/blog/2021/03/small-common-lisp-cli-programs/#s8-case-study-a-batch-coloring-utility

Unfortunately, if I can get the SBCL version working, it may take all the wind out of my sails...

hah, running the build-binary script results in an error and I get dropped to an SBCL prompt

and it turns out that SBCL is harder to exit than vim...

@grzm Good question. Can you try :cljc {:features [:clj]} in your config? I am experimenting with this, it's still undocumented and might change.

I am using it in babashka/fs myself

oh cool, I had to install quicklisp: https://lisp-lang.org/learn/getting-started/

To confirm, in the clj-kondo config?

yes

This will cause the linter to ignore :cljs branches

oh, nice.

I got it to work, this is amazing

Yup, that works!

Cheers!

Looks like it clears it up the emacs/clojure-lsp, too. So clojure-lsp is .clj-kondo/config.edn aware?

yes, it uses clj-kondo for its analysis

Nice to confirm that the local config gets picked up, too. Thanks!

I was actuallly going to port this to babashka as well

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

these pods are dynamically linked. Maybe you are missing libc++?

That could be. I’ll track that down.

Cheers!

on the other hand, if bb itself runs, then the pod should also run I think

unless bb was built statically

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?

@wilkerlucio @(promise) is what I usually do

Looks like we’re using the dynamic release.

babashka-0.2.8-linux-amd64.zip

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]

Someone’s lying to me.

Something else for me to track down.

This is a message you get when the dynamically linked library cannot be found I think

I think you can see the list of required libs with ldd

$ 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: ~

yeah, so it's libstdc++

λ 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: ~

but this is weird, since bb already uses that too

maybe this is because you are using nix

it has different dirs for every lib

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

very cool!

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... 🙏

@holyjak https://book.babashka.org/#main_file

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

I don't know the solution in general though. why not just name it .clj?

Or .bb and then configure clojure-mode to be activated on that extension as well

because I want it on my PATH 🙂

so? I have lots of .clj files 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

{:tasks {hl {:task/type :babashka :args ["-f" "script/hl.clj"]}}}

bb :hl 

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"

it 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?

true, also (require [foobar] :reload) is without 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

instead of:

bb --uberjar -m foo.bar

I am no UI expert but I prefer that

maybe there can also be a built-in bb :test like lein test

prefer that = which one?

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?

because I could not find another one, which one should I use?

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

as in task1 could also be using -- for its own parsing and then it would never see the remaining args?

or isn't this a problem...?

maybe it isn't

bb :do :task1 foo bar -- :task2 baz quuz ?

could also use :--

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)

so

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

no, maybe in prismatic schema, but there it is :-

cool

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

hm

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

that will make parsing more awkward, I prefer something more explicit

:-- I like

and works for most cases

and you can always use :--/continue if necessary

(or some better name)

Yeah. I just don’t like ‘smuggling’ out bb task context args in the middle of task args

smuggling?

idk if that’s the best word

I just don't understand what you didn't like. Be explicit please ;)

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

how so?

between :task2 and :-- in my mind everything should apply to task2

no, this would be:

bb :do :task1 :t1a1 :-- :task2 :t2a1 :--/continue :task3 :t2a1

:--/continue is just a more special version of :--

ahh, I guess that is obvious, I misunderstood 🙂

yeah, that seems a lot more reasonable

from a distance, I'm not sure if this is too ugly though

I don’t imagine it would be used a ton

getting into the weeds, why / to delimit :-- from the ‘opt’?

dunno :)

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

sure, but this is never a popular thing to do ;)

yeah but I am shielded from that 😄

maybe I'll just keep this tasks idea very very basic

and then let it grow organically based on feedback

but bb :task kind of felt good to me

yeah true

YAGNI is a good principle

maybe there will be somebody who reads all of the tasks from bb.edn and generates bash stubs for those in a bin folder ;P

so you can do $ task :P

💥