mmm, I had forgotten about this https://grep.app/search?q=fallback%20to%20using%20the%20latest%20cache%20if%20no%20exact%20match%20is%20found that's the answer. I think I had worked for a while on projects not featuring that snippet

With a high churn in dependencies the cache will be indefinitely growing though. I encountered problems with this in a js project a while back. Restoring the cache took more time than downloading the dependencies at some point. The workaround was including a timestamp in the cache-key.

(clojure.edn/read ( <org.httpkit.BytesInputStream>))

try this

no doesn't work

class java.io.BufferedReader cannot be cast to class java.io.PushbackReader (java.io.BufferedReader and java.io.PushbackReader are in module java.base of loader 'bootstrap')

One more level of wrapping might help. PushbackReader constructor instantiates from a Reader - a quick scan of the class shows.

While this works - do you need the inner-most PushbackInputStream? I think the reader can take the httpkit object - which I believe extends InputStream

correct

At this point, it seems like making a post on https://ask.clojure.org/ would be worth it.

voila: https://ask.clojure.org/index.php/10856/bug-format-that-does-not-pretty-print-corresponding-argument

TIL about the lib :) last commit isn't too distant so I think the right thing in this case is opening an issue with a repro

I ended up fixing the namespace, updating the dependencies, and opening a pull request 🙂

kudos 🚀

oddly:

(identical? (:on yy) (:on protocols/ApiAuth))
=> true
(identical? yy protocols/ApiAuth)
=> false

well, it was just a guess. you can use clojure.data/diff to narrow it down

I mean, the protocol gets updated as it gets extended, so you might be seeing an older version vs a newer version with different extensions

ah… maybe that’s the problem with my code

(s/def ::auth-token (partial satisfies? protocols/ApiAuth))

when you def yy, you're just getting a point in time, not tracking updates

that spec fails for objects it shouldn’t fail for

I am guess it closes over a version of protocol without the necessary implementations in the map

maybe? you might be better with using an anonymous function there instead so you're not evaluating early

#(satisfies? protocols/ApiAuth %)

worth a try

yeah that works as expected

Yeah, I recently encountered the same thing, using an anonymous function fixed it

well this is definitely a gotcha for most people

if you want to request a FAQ for it, please do... https://github.com/clojure/clojure-site/issues

I think https://clojure.atlassian.net/browse/CLJ-2094 describes the same scenario, would you agree @U66G3SGP5?

(https://clojure.atlassian.net/browse/CLJ-1814 also relates, but from a performance point of view I guess)

yes

it’s not a problem that it works that way, but it’s definitely unexpected by most

https://github.com/clojure/clojure-site/issues/545

I think partial behaviour is not poorly described. What is surprising is that extending a protocol produces a new value…. in most languages type identifiers are immutable singletons and as most people grok protocols as some sort of type/interface abstraction, they get blindsided by this “type” identifier changing as new implementations are defined.

I think that's a good insight. There are two "stateful" runtime constructs in Clojure - protocols and multimethods. As Clojurists we should not be surprised that state creates problems (like temporal coupling)

but you can't have open dispatch systems without managing state over time to allow for late behavior extension

I do think it is not immediately obvious what the tradeoff is in partial vs anon fn wrt evaluation and closures and that probably warrants a faq entry

yeah, I guess there are two different things here (which may or may not be obvious depending on your level of expertise): a) why (partial foo bar) isn't the same as a similar anonymous function (I'd guess this also applies to other HoF's too, like comp) and b) the value of a protocol may change when it's extended

I remember encountering the a) issue when adding instrumentation to a function foo, but had already defined some helpers with partial e.g. (def helper (partial foo 1)) -> calling helper with some incorrect args wouldn't trigger an instrumentation failure

build=> (require '[clojure.data.json :as json])
nil
build=> (json/read-str "[{\"topic\":\"xyz\", \"key\":\"abc\", \"message\": \"pqr\"}]")
[{"topic" "xyz", "key" "abc", "message" "pqr"}]

Not as json string. but the parameters

(defn myFunc
      [{:keys [params]}]
              (let [
                    topic (:topic params)
                    key (:key params)
                    message (:message params)
                    ])
)

params usually isn't a vector like you posted above

but you could try [{{:strs [topic key message]} :params]

(defn foo [{{:strs [topic key message]} :params}]
  [topic key message])

(foo {:params {"topic" "t" "key" "k" "message" "msg"}})
#_-> ["t" "k" "msg"]

[ {"topic":"xyz", "key":"abc", "message": "pqr"}, {"topic":"xyz1", "key":"abc1", "message": "pqr1"}, {"topic":"xyz2", "key":"abc2", "message": "pqr2"}] ] Would it run for this one?

nope

that's a different shape. what do you want your function to do?

generally, figure out how to make a function that takes one map with topic, key, and message, and then figure out how to do it multiple times

This is the json body in my api request. Need to parse this data one at a time

ok. i'm not aware of any json libraries that will parse one entry at a time

but i suspect you mean you need to act one one "record" at a time, not parse one at a time