This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (3)
- # announcements (29)
- # babashka (99)
- # beginners (30)
- # calva (46)
- # cider (9)
- # clara (1)
- # cljsrn (4)
- # clojars (10)
- # clojure (41)
- # clojure-dev (4)
- # clojure-europe (45)
- # clojure-nl (3)
- # clojure-norway (13)
- # clojure-uk (5)
- # clojurescript (61)
- # community-development (11)
- # cursive (10)
- # data-science (1)
- # events (1)
- # fulcro (17)
- # graphql (1)
- # gratitude (1)
- # holy-lambda (1)
- # jobs (4)
- # jobs-discuss (5)
- # meander (22)
- # off-topic (50)
- # pedestal (3)
- # re-frame (3)
- # reagent (3)
- # reitit (82)
- # releases (2)
- # rewrite-clj (14)
- # shadow-cljs (3)
- # spacemacs (14)
- # tools-deps (7)
- # xtdb (33)
babashka v0.6.4 - a fast starting Clojure scripting environment https://github.com/babashka/babashka/blob/master/CHANGELOG.md#063 • Add `java.security.Provider` and `java.security.Security`. This adds compatibility with https://github.com/clj-commons/digest. • Fix mapping for `babashka.fs/unzip` https://github.com/babashka/babashka/issues/1030 • Pods: support metadata in pod vars, like docstrings (https://github.com/quoll) • babashka.curl: support `:follow-redirects false` (https://github.com/sudorock) • Add support for `--init` as a file to be loaded before evaluation actions https://github.com/babashka/babashka/issues/1033 (https://github.com/bobisageek) • Bump rewrite-clj to v1.0.699-alpha (https://github.com/yannvanhalewyn) • Fix `BABASHKA_FEATURE_POSTGRESQL` feature flag, initialize `java.sql.SQLException` build time https://github.com/babashka/babashka/issues/1040 • Deps.clj: upgrade to tools version `188.8.131.528` and include new `DEPS_CLJ_TOOLS_VERSION` environment variable to use older or newer tools jar.
A weird (but cool) announcement: lilactown/autonormal has been renamed to town.lilac/pyramid. • Why the rename? I didn't like the old one. • What does the new name mean? I just like it. I probably won't do this again, it was a bit of a hassle. pyramid is a Clojure(Script) library for doing cool things with graphs made of Clojure data. It provides the same capabilities as autonormal before: • Normalize your data for you, allowing datascript-like accretion of facts about entities over time with just a simple Clojure map! • Use https://edn-query-language.org/eql/1.0.0/what-is-eql.html to pull information out of deeply nested maps with blazing speed! You might be asking, "What do I get by using this new name, anyway?" Glad you asked. The latest version of pyramid includes a brand new capability: an experimental engine for querying your pyramid db (a map in normal form) using datascript-like "datalog" queries. Perfect for exploring a db from a REPL. Get the latest here: https://github.com/lilactown/pyramid Questions, comments, suggestions can be made in #pyramid. Bug reports go in github.
it is funny that many people at the same time come across similar problems and find identical solutions
a lot of people are disappointed with the way datascript works on the frontend and it is very good that things are emerging to replace it
also watching doxa 🙂 was an inspiration to provide basic datalog-ish query support for pyramid
also huge shout out to @U051N6TTC who helped me get over some big hurdles early on in understanding how a query engine like this even should work 😄
I imagine, given my current approach to parsing and resolving queries, that any speed improvements
pyramid.query has over datascript will go away as I add more features. Only time will tell, though.
Like I said in the announcement, I found the datalog-ish queries immensely helpful when debugging and exploring a large db
q performance is not bad for the first version, looks like it will be great library
exciting times, seems like we need something like https://clojurelog.github.io/ for local normalized database maps 😛
@U0BBFDED7 "it is funny that many people at the same time come across similar problems and find identical solutions"
Like you made a
=>> six months before I did with
injest/=>>, and it does a very similar thing. Had no idea 😆
Well, I think yours has more optimizations which are interesting... Slightly different use-case I think. I plan to mention your lib in the reference section, seeing how similar in spirit it is.
danzig I simply assume that we have a collection of maps, so I use native methods to deal with them and avoid reflection
> I thought scheme was renamed to racket? @U7RJTCH6J How am I just now realizing the pun here!? 🤯
A new release of holy-lambda v0.6.0: https://github.com/FieryCod/holy-lambda
Holy Lambda is a library + set of utils that provide an extremely fast AWS Lambda runtime for Clojure.
The release introduces new features and improvements to existing ones; fixes some long-standing bugs, and improves the dev experience.
Few important changes:
• support arm64 architecture for Native/Clojure backend, which means you can now develop lambdas on M1 🙂
• dependencies for Clojure & Native backend are not longer downloaded to local
• compilation to
.jar is now handled via
:compile-cmd key and happens locally. No more adding local libraries via docker volumes. Also one may use arbitrary
uberjaring tool now,
• HL now distributes docker images with GraalVM + native-image included (See https://github.com/FieryCod/holy-lambda/pkgs/container/holy-lambda-builder/versions),
• new arm64 runtime for babashka has been introduced, which means even lower cold starts!
If you're already on holy-lambda v0.5.0 check a https://fierycod.github.io/holy-lambda/#/migration-guide.
See the full changelog https://github.com/FieryCod/holy-lambda/releases/tag/0.6.0.
For more information/questions visit #holy-lambda channel.