Fork me on GitHub
#announcements
<
2021-05-05
>
bozhidar13:05:39

clojure-mode 5.13 is out! The release features a few small improvements https://github.com/clojure-emacs/clojure-mode/releases/tag/5.13.0

🎉 26
🚀 23
clojure-spin 18
emacs 12
👏 12
pez15:05:14

toggle-ignore, hmm… Someone asked for a command helping with ignores quickly in Calva, but we agreed that typing alt+left, #_ was quick enough (the first keypress there moves the cursor to the start of the form). But now, looking at the changelog for this update… I see a toggle-ignore-surrounding-form and it starts to make more sense.

Karol Wójcik14:05:06

Announcing clojure-graalvm-agent-helper to ease native configuration generation for native-image tool. https://github.com/FieryCod/clojure-graalvm-agent-helper

🎉 25
seancorfield20:05:29

com.github.seancorfield/next.jdbc {:mvn/version "1.2.659"} — The next generation of clojure.java.jdbc: a new low-level Clojure wrapper for JDBC-based access to databases. — The main difference from 1.1.646 (and the reason for 1.2.x) is that clj-commons/camel-snake-kebab is now an unconditional dependency, rather than a conditional one, which improves GraalVM-native compatibility and removes some potential edge cases when trying to use the library in certain multi-artifact projects. https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.2.659/doc/getting-started Follow up in #sql Thanks to @snorremd for additional PostgreSQL-related docs and @delaguardo for help getting GraalVM testing up and running!

👍 45
2
🎉 8
2
borkdude22:05:31

It is possible to make dependencies conditional and make them compatible with GraalVM native-image. I would say this could even improve native-image compatibility by leaving out deps that don't play well with it (and reduce binary size) but do it the right way: only resolve at compile time (top level) and not at runtime (function body). https://github.com/yogthos/Selmer/blob/master/src/selmer/tags.clj#L392-L403

borkdude22:05:00

But it seems you were already doing this correctly, so I don't understand why this change makes it better for GraalVM. Anyway, it's great that you are considering support for it :thumbsup:

seancorfield00:05:39

I was running into problems with it in our multi-artifact monorepo at times and I just sort of got tired of working around it. I also wasn’t 100% sure I was doing it correctly, conditionally, for use with GraalVM-native so I figured I should just remove the “at times”/uncertainty and be done with it. Lots of next.jdbc users seem to want the snake/kebab conversions anyway (and it’s not like next.jdbc doesn’t already depend on other libs — I’m a bit surprised the java.data dependency/code doesn’t cause GraalVM-native issues…?).