Clojurians Log v2

Hey thanks a lot for offering a hand, much appreciated! yes, i could use some help, specially in the following areas: • the https://github.com/babashka/pod-babashka-go-duckdb/blob/main/test/script.clj are quite generic, lifted from sqlite. since youre probably more experienced with duckdb would be great if you could add in some more duck relevant tests? things like excel files etc? • testing on minimal linux environments, currently we dont want to do a fully static musl build due to https://duckdb.org/docs/stable/guides/performance/environment.html#glibc-vs-musl-libc and build complexities. is there any issues in that? can we test it? • since youre a gopher as well, have a look at the source and if there is a way to stress test this for perf, specially how the pod protocol stuff behaves, would be really helpful! of course, any other general ideas welcome! thanks again!

Starting off with tests makes a ton of sense. Is there a preferred docker image that you like to use for minimal linux? http://gcr.io/distroless/static-debian12 is one of the more minimal that I know. I would lean towards alpine.

Maybe we can start just getting some dockerized test target set up? So you can run on local and also some minimal linux?

This moves into things that I'm moderately competent with

The alpine one would present us with the glibc problem, see the second point. It’s detrimental to performance. But we could try alpine with gcompat package. But this is go, should compile and run in most places, why container tests?

If I'm testing glibc vs. musl on my mac, my default is to reach for docker

I could use a VM though

Right, that should be okay, but the way we have it in the CI is to run directly and test the native app

But don't you also test locally?

Not on alpine, we test on macs and Linuxes that we have. But yes just for local, worth having a container. But as of now we don’t plan to build a musl binary due to the 5x perf impacts.

We could just test if the glibc binary works on alpine with gcompat

I think I misunderstood - I thought you wanted to test musl vs glibc to get a sense of the performance hit. But the goal would just be to get some glibc build that works fine on something like alpine?

Yeah they duckdb devs are quite sure of the performance hit so not much use in testing I guess. What would be nice to test is if we can run the glibc binary on alpine via https://pkgs.alpinelinux.org/package/edge/main/armhf/gcompat

If you want to go that route, I'm still curious to compare that to alpine-pkg-glibc (which I think is full glibc). But I'm happy to start with gcompat

Don’t think I have a preference, whichever works and hopefully without perf hits

Let’s go with the one you’re used to

Last question before I try mucking about. Currently there is no obvious build task runner. Does it make sense to include a bb.edn or do you prefer to just keep things simple in the pod?

An absolute nice thing to have