> My suggestion is maybe releasing this static version with musl separated from the other static binary, at least until we can figure out why this tests are flakly. Actually, after more testing maybe it is fine. It is just some libs that fail sometimes (but when it works all tests pass), and this musl based binary should work in any Linux system, so this is still a win in my book. The current static binary based on glibc seems more useless in comparison. When it fails it fails hard, and most of the time people are better using the non static version anyway. I also don't think the static glibc version works in Alpine anyway since Alpine is a musl based system (I may be wrong here). My opinion is to release it as is, just leaving somewhere in the release notes that this release is more unstable than the non-static build so the non-static build is still preferred. My 2c.
(And we keep track of new GraalVM releases, I think it is a bug there that will eventually be fixed. It does seem that with GraalVM 21.1 this bug is more difficult to trigger, but this is completely a non-scientific observation.)
Thanks. Yes, *~
is all files ending in tilde.
This might be tangential, but hereβs a better way to solve the emacs ~ files
issue:
Tell emacs to create them in a dedicated directory (in this example ~/.emacs/savefile/
):
(defconst savefile-dir (expand-file-name "savefile" user-emacs-directory))
;; create the savefile dir if it doesn't exist
(unless (file-exists-p savefile-dir)
(make-directory savefile-dir))
Hello π congrats on 0.4.0! It is a big release. I wonder with the addition to Selmer, if we could also consider adding this library from Yogthos for templating with hiccup? https://github.com/yogthos/hiccup-template
@neo2551 I think you could also just run that lib from source? It doesn't seem like a popular, widely used library yet, so including it seems pre-mature
Make sense :), but yes you could use from source indeed. I just find it more natural as a Clojure dev.
We already have hiccup included. This library seems to re-implement hiccup. Why do you need this lib?
Because for now, we generate hiccup through function calls as in (defn f [x] [:div x])
whereas with template, you can define a plain data structure [:div :data/x]
and then replace :data/x
with the hiccup-template/hiccup
function.
This allows you to serialize the template
so you could have your template in plain .edn file
when your logic is mostly replacing the fields with data.
does it make sense?
I would say we dissociate the act of writing the template and the function call?
yeah, I think the library is basic enough to be run from source right now.
thanks for your hinsight π
hindsight π
New static linux binary for testing: https://18553-201467090-gh.circle-artifacts.com/0/release/babashka-0.4.1-SNAPSHOT-linux-amd64-static.tar.gz
@borkdude Static binary is basically an executable with musl built in?
yes
a static binary would be great
well, ^ there is one, try it out? :)
π thatβs the plan
We're releasing an MIT-licensed project using babashka to to configure WordPress servers on EC2. The MySQL code is more robust than the examples (it can handle tabs), although not suitable for untrusted/arbitary input. Code's at https://github.com/staticweb-io/staticweb-open-wp/tree/master/static-wp-daemon/src/io/staticweb/static_wp_daemon
@borkdude Do you still want a MySQL/MariaDB example app? I just saw https://github.com/babashka/babashka/issues/387
@jshaffer2112 That was more about adding feature flags to babashka to support the mysql driver than about shelling out to the mysql binary.
I know
I'd much rather use JDBC than deal with the hellscape of mysql escaping
I'd be happy to write an app up if it would help
@jshaffer2112 I think honeysql (v2) can be of service here
it's compatible with bb afaik
if you want to shell out to mysql
ah yeah, it would be nice to have a reference example of how to do graalvm native with mysql
Then we can add support to https://github.com/babashka/babashka-sql-pods
A direct PR to that project would work too
The project is looking exciting btw!