This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (24)
- # asami (25)
- # babashka (17)
- # beginners (99)
- # bitcoin (1)
- # calva (2)
- # cider (6)
- # cljs-dev (4)
- # clojure (88)
- # clojure-australia (3)
- # clojure-europe (23)
- # clojure-france (6)
- # clojure-nl (5)
- # clojure-uk (31)
- # clojured (1)
- # clojurescript (6)
- # clojureverse-ops (1)
- # datomic (28)
- # depstar (18)
- # emacs (11)
- # events (1)
- # fulcro (21)
- # graalvm (4)
- # graphql (7)
- # heroku (1)
- # jackdaw (18)
- # joker (3)
- # kaocha (1)
- # lsp (1)
- # malli (13)
- # meander (4)
- # off-topic (12)
- # pathom (14)
- # pedestal (2)
- # podcasts (1)
- # re-frame (37)
- # reagent (17)
- # reitit (9)
- # shadow-cljs (44)
- # xtdb (17)
joker v0.17.0 is released: https://github.com/candid82/joker/releases/tag/v0.17.0
Proudly annoucing new version (0.1.18) of [holy-lambda](https://github.com/FieryCod/holy-lambda) a simple micro framework which turns your code into AWS Lambda functions for both JVM and native runtime.
- Interceptors support https://github.com/FieryCod/holy-lambda/blob/master/examples/hello-lambda/src/hello_lambda/core.clj
- 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 🙂
Since you added
GraalVM EEsupport.. Are there any noticable differences between CE and EE-compiled versions? Different performance characteristics, utilization of resources,..?
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 🙂
Please don’t use clojure.data.json 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.
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. https://github.com/nilern/Eximia
@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
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 clojure.data.xml proper? @U04V5VAUN has been doing some nice work on clojure.data.json. Perhaps @U064X3EF3 is open to have someone contribute to clojure.data.xml in a similar fashion?
clojure.data.xml 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
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
Great work 👏 Probably it would be a good idea to have some sort of roundtrip/equivalence test against clojure.data.xml
org.clojure/data.json 2.2.1 is now available - addresses a serious bug in 2.2.0 (rolls back the change)
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.
Hi everyone. I’ve written a https://github.com/jdf-id-au/talkfor https://netty.io/ to try to make websockets easy to use from Clojure without bringing in lots of dependencies. Intro post on https://clojureverse.org/t/netty-http-websockets-wrapped-in-core-async-jdf-talk/7535.