Fork me on GitHub
#announcements
<
2022-06-30
>
Ivar Refsdal08:06:42

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. • Added 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.

clojure-spin 4
🎉 4
👍 1
athos14:06:45

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

🎉 8
littleli07:07:44

Can I add it to scoop? #scoop

Alex Miller (Clojure team)21:06:22

Clojure 1.12.0-alpha1 is now available https://clojure.org/news/2022/06/30/clojure1-12-alpha1

🎉 33
😮 11
🔥 7
sheepy 2
clojure 10
clojure-spin 8
Alex Miller (Clojure team)21:06:14

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.

seancorfield22:06:38

Updating deps.edn at work to test it... 🙂

eggsyntax22:06:32

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?

Alex Miller (Clojure team)22:06:07

We always desire smaller and more frequent versions, we’re just sometimes better at succeeding :)

😆 10
imre22:06:09

Does CLJ-1872 mean (seq coll) is not going to be an idiom for (not (empty? coll)) going forward?

seancorfield22:06:09

@U08BJGV6E The empty? docstring has been updated: "To check the emptiness of a seq, please use the idiom (seq x) rather than (not (empty? x))"

1
borkdude07:07:13

Does this mean that clj-kondo should not warn on (not (empty? ...)) anymore unless it knows 100% sure the argument is a seq already?

imre08:07:41

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 coll is

borkdude08:07:48

Maybe I'll just remove the linter then or disable it by default.

imre08:07:02

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

Eugen08:07:59

feels like Christmas in July 🙂

Alex Miller (Clojure team)11:07:37

Well this is an alpha1, so I wouldn't go run around changing anything yet

Alex Miller (Clojure team)12:07:49

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.

Alex Miller (Clojure team)12:07:54

Generally I arrange the branches of the condition to not use not in either case if possible

imre12:07:09

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.

borkdude12:07:07

Maybe Clojure can have a (not-empty? ...) predicate which does the right thing for the right type.

👍 5
1
imre12:07:09

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

Alex Miller (Clojure team)12:07:11

Well there’s not-empty

borkdude12:07:12

And then this debate can be over :)

Alex Miller (Clojure team)12:07:48

Maybe not-empty should be based on empty?

1
👍 4
Alex Miller (Clojure team)12:07:38

I think the difference is seqs have nil punning, other colls don't

imre12:07:37

My vote would be on maintaining symmetry

Alex Miller (Clojure team)12:07:22

not sure what you're even advocating

imre12:07:45

Apologies Alex, I misread your reply. Allow me to clarify

imre13:07:04

I think basing non-empty on empty? is a step in the right way. Note that it would still result in double negations in the seqable branch. Implementing a notempty? or 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.

henrik09:07:02

(defn populated?
  [coll]
  (boolean (not-empty coll)))
If not-empty works as intended, you could just coerce it to a boolean, right?

henrik09:07:41

I tried hard to come up with a word that didn't include not in the name. The internet suggests populated, occupied, and cherished 🙂

borkdude09:07:49

I think I prefer not-empty? ;)

henrik09:07:30

Come on, what's wrong with cherished?

henrik10:07:16

I'm disappointed in the English language here. We have "nothing", "something", and "everything", mapping to "empty", <go fish>, and "full".

borkdude10:07:41

Well, we have *, ? and + in regexes to denote 0 or more, 0 or 1 or 1 or more. So why not use: (+? coll) , that seems like an excellent choice to me... 😁