This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-05
Channels
- # announcements (1)
- # asami (21)
- # aws (19)
- # babashka (37)
- # beginners (38)
- # clj-kondo (7)
- # clj-otel (8)
- # clojure (29)
- # clojure-europe (54)
- # clojure-nl (3)
- # clojure-spec (2)
- # clojure-uk (2)
- # clojurescript (15)
- # conjure (1)
- # data-science (1)
- # datomic (21)
- # emacs (6)
- # events (3)
- # figwheel-main (1)
- # gratitude (13)
- # holy-lambda (11)
- # joyride (6)
- # klipse (3)
- # malli (14)
- # missionary (26)
- # nbb (31)
- # omni-trace (2)
- # pathom (3)
- # reagent (1)
- # reitit (1)
- # releases (1)
- # shadow-cljs (24)
- # sql (27)
- # tools-deps (4)
- # vim (21)
I'm writing a simple async rest client, and there is an auth session token that should be shared, updated between all requests. I came up with a lock based solution, is there better options to do so? <https://gist.github.com/nxtk/b1936633ccb5b456e51198d2f958fc56>
I usually have a core.async go block that runs a loop keeping credentials fresh and handing credentials to anyone that needs them. I don't think keeping state for a rest client in a global singleton (a def) is a good idea.
Not of mine, no. https://github.com/cognitect-labs/aws-api/blob/master/src/cognitect/aws/credentials.clj is vaguely similar, but much more complex, largely due to different potential ways to get away credentials. I've mostly used the core.async loop think for exchanging credentials for a bearer token and keeping that token up to date.
aws-api creates a single scheduled executor for doing refreshes, but the credential state itself is in passed around atoms (not singletons)
If it truly is a kind of stateful session token, forcing serial interaction, I would be tempted to use a threadpool of size 1 to enforce that instead of a lock, basically instead of blocking on a lock, when you need to access the serial resource you throw a thunk on the threadpool for that resource. But that may be more complex, just the idea that serial usage can be well represented by the execution of a single thread, instead serializing multiple threads via a lock
When calling core.async
's thread
function, will that use the thread pool? Or is it equivalent to spawning a new Java thread?
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L473
This took me by surprise:
(sorted-map "hello" "world") ;; => {"hello" "world"}
(sorted-map :hello :world) ;; => {:hello :world}
(sorted-map "hello" "world" :hello :world) ;; => Execution error: class java.lang.String cannot be cast to class clojure.lang.Keyword
Is this expected?Sorted map needs comparable keys. This makes it unsafe for checking if a key is there or not, unless you provide a comparator that can sort any key
hi please help how i can do arity overload in defprotocol?
(defprotocol Logger
(error
([_ params])
([_ ex params]))
)
(defprotocol Logger
(error [_ params])
(error [_ ex params])))
are not working
---
UPD: found
(defprotocol Logger
(error
[_ params]
[_ ex params]))
The empty?
docstring famously recommends using seq
instead of (not (empty?
.
However doesn't that create transient garbage? Which might happen in a tight loop, you never know
Maybe I can use not-empty
(or just (not (empty?
)? What is being traded off other than concision?
Clojure 1.11.1
user=> (source not-empty)
(defn not-empty
"If coll is empty, returns nil, else coll"
{:added "1.0"
:static true}
[coll] (when (seq coll) coll))
nil
It sounds a bit off that for any emptiness check you have to coerce to seq first. I would wager that any given coll just knows whether it's empty - it could be a fast boolean check?
> any given coll just knows whether it's empty Lazy seqs don't know that though. And constructing ephemeral classes that will be thrown away almost immediately should be a cheap op at the end of the day, at least as far as I'm aware, given all the optimizations JVM is doing. Of course, probably not as cheap as a check of a field or whatever, but still much cheaper than one might guess.