Fork me on GitHub
Karol Wójcik08:04:18

Proudly annoucing new version (0.1.18) of [holy-lambda]( a simple micro framework which turns your code into AWS Lambda functions for both JVM and native runtime. Notable changes: - Interceptors support - Fixes for a project template. You can now generate a project with lein new holy-lambda <name-of-the-project> - Basic support for GraalVM EE (PGO optimizations in-process) - Easier way of generating native configurations via (agent/in-context). Docs about native-configurations (in-progress) - Unify responses. Response can be either null (for event ack) or a map of [:body, :isBase64Encoded :headers :multiValueHeaders] (breaking change) - Rename gen-main to entrypoint. Move to fierycod.holy-lambda.native-runtime (breaking change) - Use new group name for all artifacts (old one could not be verified :() io.github.FieryCod/holy-lambda - Add some docs EDIT: You can now also join a slack channel #holy-lambda 🙂

👏 24
❤️ 9
Tomas Brejla08:04:50

Since you added GraalVM EEsupport.. Are there any noticable differences between CE and EE-compiled versions? Different performance characteristics, utilization of resources,..?

Karol Wójcik09:04:39

I don't know yet. This or next month I will make some benchmarks for: • holy-lambda-ce • holy-lambda-ee • holy-lambda-ee-with-pgo-optimizations , compare them with other runtimes and write a summary in doc/ 🙂 My bet is that there will be some real differences for complex applications, but you have to wait a little bit for a proof 🙂

👍 11
👏 4

Please don’t use 2.2.0 there is a serious data-loss bug in it. The offending commit has been reverted, but I’m waiting for a new release. I’m terribly sorry for this. Thanks to @thheller for reporting the bug.

👍 32
❤️ 27

Introducing Eximia, the state of the art Clojure XML processor 😉 Roughly 4x faster than the usual options. Small codebase. With XML namespace support and secure defaults.

👍 46
❤️ 3

@U4MB6UKDL Looks cool. In the README you refer to clojure.xml (Clojure 1.10.3), what is this?


Is that the built-in namespace? That's pretty much deprecated in favor of data.xml I think


But I doubt that that is common knowledge


I think not mentioning clojure.xml contributes to the process of deprecation. Many people probably don't know it even exists ;)


Any chance those speed-ups can end up in proper? @U04V5VAUN has been doing some nice work on Perhaps @U064X3EF3 is open to have someone contribute to in a similar fashion?

borkdude11:04:42 hasn't really seen a lot of work on it for a while, it would be nice to get someone who knows this stuff on it maybe


I thought maybe they would at least get a stable release out if I do this


The laziness in data.xml does have substantial performance and complexity costs but I think there is some low-hanging fruit there nevertheless


Sure, happy to look at stuff like I've been doing with Erik in data.json. The important thing is to break it into manageable (smaller better) chunks, defined well with tickets, and build patches for each. I can then evaluate those on a regular basis (often on Fridays I have a little more time for things like this). I would want to communicate with Herwig on that stuff but I have not a lot of luck getting in touch with him recently.


One specific thing I noticed is reusing XMLInput/OutputFactories. It's probably the reason Eximia is 15x faster than data.json on tiny inputs


Oops. s/json/xml/

🙂 3

Great work 👏 Probably it would be a good idea to have some sort of roundtrip/equivalence test against


Perhaps. Although with namespaced XML they aren't going to be equivalent anyway.

👍 4

org.clojure/data.json 2.2.1 is now available - addresses a serious bug in 2.2.0 (rolls back the change)

👍 27

PGMig 0.7.0 is out. Check it out if you use .cljmigrations using SCI. The native image compiled binary should be now on par with uberjar but still much faster.

postgresql 12
sci 19

Hi everyone. I’ve written a to try to make websockets easy to use from Clojure without bringing in lots of dependencies. Intro post on

nice 67