This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (40)
- # babashka (41)
- # beginners (32)
- # calva (15)
- # clara (8)
- # clj-kondo (14)
- # cljs-dev (30)
- # clojure (37)
- # clojure-dev (8)
- # clojure-europe (21)
- # clojure-norway (21)
- # clojure-uk (4)
- # clojured (3)
- # clojurescript (4)
- # community-development (10)
- # core-async (13)
- # cursive (23)
- # datomic (15)
- # emacs (9)
- # fulcro (3)
- # google-cloud (4)
- # graphql (24)
- # gratitude (2)
- # holy-lambda (4)
- # honeysql (5)
- # hyperfiddle (9)
- # keechma (1)
- # klipse (5)
- # lsp (23)
- # malli (4)
- # missionary (32)
- # pathom (28)
- # re-frame (2)
- # reagent (40)
- # reitit (17)
- # releases (2)
- # remote-jobs (1)
- # shadow-cljs (25)
- # specter (3)
- # vim (19)
- # xtdb (41)
https://github.com/ivarref/yoltq, an opinionated Datomic queue for building (more) reliable systems, is out with new features:
• Added support for https://github.com/ivarref/yoltq#2022-06-22-v0256-diff. This requires that the function metadata contains the queue name. This makes it easier to jump directly from the producer to the consumer code.
• Added support for https://github.com/ivarref/yoltq#retrying-jobs-in-the-repl.
unhealthy? function that returns
true if there are queues in error. For the first 10 minutes it will return
false so that if you include this in your application's health check, you can push new code and not have old failures stop your deploy. Yes, I was hit by this. ¯\(ツ)/¯
• Safer EDN reading and writing.
Limitations and alternatives have also been documented.
Yoltq supports retries, backoff, ordering and more. On-prem only. https://github.com/ivarref/yoltq#change-log.
https://github.com/athos/trenchman 0.4.0 is out! Trenchman is a standalone nREPL/prepl client written in Go and heavily inspired by Grenchman.
• Added support for the
nrepl+unix scheme to allow connections via UNIX domain sockets (which is a new feature that nREPL 0.9 introduced)
• Added a new option
--debug to print messages sent between the client and server
Clojure 1.12.0-alpha1 is now available https://clojure.org/news/2022/06/30/clojure1-12-alpha1
This release includes some changes to var interning as per the post. While we have thought of and tried many scenarios, it is hard to tell if we found them all. We really would appreciate you giving this a try early while you're developing and reloading etc to see if you encounter anything unexpected and drop us a question at https://ask.clojure.org if so.
Alex, would you say that this reflects a desire from the core team to shift toward smaller and more frequent new versions, or is that just how it happened to turn out this time?
We always desire smaller and more frequent versions, we’re just sometimes better at succeeding :)
Does CLJ-1872 mean (seq coll) is not going to be an idiom for (not (empty? coll)) going forward?
empty? docstring has been updated: "To check the emptiness of a seq, please use the idiom (seq x) rather than (not (empty? x))"
Does this mean that clj-kondo should not warn on
(not (empty? ...)) anymore unless it knows 100% sure the argument is a seq already?
It does sound like to me that going forward,
(not (empty? coll)) should generally be preferred in cases where you don’t want to make any assumptions wrt what
Do note that I’m not on the core team (yet 😄) so I’m by no means a good source of information, I’m just speculating
Well this is an alpha1, so I wouldn't go run around changing anything yet
I think I'd flip that advice around and say that when you DO know you have something counted like a persistent coll, it is better to build a conditional on empty? than seq (esp if you are not doing anything else with seqs). If you are in a seq context, then keep using seq.
Generally I arrange the branches of the condition to not use not in either case if possible
So do I. I just find that there is a bit of an imbalance introduced here, with idiomatic
(empty? x) being extended onto non-seq xes, but the so-far-idiomatic nonempty? check
(seq x) isn’t.
empty? is now generic across seqs and counteds but there isn’t a similarly generic counterpart I feel.
Maybe Clojure can have a
(not-empty? ...) predicate which does the right thing for the right type.
Backwards-compatibility isn’t affected as far as I can tell, but it might be surprising in new code that relies on
empty? supporting counted colls that aren’t seqable
I think the difference is seqs have nil punning, other colls don't
I think basing
empty? is a step in the right way. Note that it would still result in double negations in the seqable branch. Implementing a
not-empty? similarly to the new implementation of
empty? could save that.
Really what I’m looking for is the ‘one idiomatic way’ of checking both. Pre-1.12 that would be
empty?/`seq`, from 1.12 it could be
empty?/`x` where x is one specific function/macro and not a conditional expression.
(defn populated? [coll] (boolean (not-empty coll)))
not-emptyworks as intended, you could just coerce it to a boolean, right?
I tried hard to come up with a word that didn't include
not in the name. The internet suggests
I'm disappointed in the English language here. We have "nothing", "something", and "everything", mapping to "empty", <go fish>, and "full".