<Solved>

Could you report this on https://ask.clojure.org ?

At a glance it's not clear to me how anything added in 1.11 could affect this (just a couple functions that wrap Java uuid methods) but happy to take more than a glance later

Thanks @U064X3EF3 > Could you report this on https://ask.clojure.org ? yup sure thing: https://ask.clojure.org/index.php/11658/clj-uuid-v5-uuids-inconsistent-after-clojure-1-11-0 It looked to me that it may be here where it calls writeObject https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid.clj#L565 , and as the signature of clojure.lang.Keyword has changed with https://github.com/clojure/clojure/commit/bd4c42dc7946cb015b8d0699596662aa68bcdc89, then the ByteArray used to construct the final UUID has changed(?)

That seems like a promising line of thinking. If that's the case then maybe the implementation of as-byte-array for Objects relies too much on implementation details?

Yes indeed. We probably should have used plain string in the first place 😉 But as it stands, I can’t see how we will be able to generate the exact same byte-array/the same uuids as before.

Yeah this one is a very sticky problem. 😞

so the problem is that the serialized byte array has changed for keywords?

if so, then setting the serialversionuid on Keyword would be a fix for that (would need testing), but really I would not say we guarantee anything about the serialized form of clojure objects

it might be useful to file this as an issue on clj-uuid as well as this inherently unreliability might be better doc'ed (and knowing Dan, I'm sure he would be happy to help with this)

@U0HJAJ64E what is the downstream system doing with these UUIDs, out of curiosity?

Thanks @U064X3EF3 good idea, ill raise an issue on clj-uuid. @U01R1SXCAUX after searching our internal GitHub i’ve found a few different examples where this will cause a problem; one being where the v5 uuid is generated and then used as the key when publishing to a Kafka topic. Having new/different keys on these topics could result in the records sent to different partitions, which could effect ordering guarantees, and potentially joining behaviour

Not sure if there is a better way, but you can use let:

(let [^Session session nil]
  (MimeMessage. session))

lemme try

seems working, thanks!

Use the 2 arity version of this: https://clojuredocs.org/clojure.core/into-array

sharp, thanks!

A bug in the graphql-query library.

At least, that's where I'd start researching it.

haha

Function is here: https://github.com/district0x/graphql-query/blob/master/src/graphql_query/core.cljc#L223

Thing is I see nothing strange, maybe the dynamics

That the dynamic definition does something different depending on the type

there is a protocol extended to IndexedSeq, but not ChunkedSeq

(def ^:dynamic *kw->gql-name* name)

You’re right

extending to concretes is a smell, you're gonna miss some

Thanks!

thanks a lot it was nagging me why things were going wrong and did not really know where to look, but now it’s clear as day (bit strange I overlooked that protocol in the middle of the page)

And I agree that it’s a code smell, better to find some abstractions that cover all . The library creator did do so in the Clojure version, but that maybe did not work in the ClojureScript one

user=> (instance? clojure.lang.IObj {1 2})
true
user=> (instance? clojure.lang.IObj [])
true
user=> (instance? clojure.lang.IObj nil)
false

you could check if argument is an instance of IObj #(instance? clojure.lang.IObj %)

interesting. (source meta) checks for clojure.lang.IMeta and not IObj

ah.

public interface IObj extends IMeta {

    public IObj withMeta(IPersistentMap meta);

}

i wonder what things implement IMeta without IObj

there are several things like that

IMeta is "metadata read", IObj is "metadata modify"

so checking whether something "accepts metadata" sounds like the latter to me, going back to the original question

thank you all, I solved the problem that prompted this question checking if the value is an instance of IObj 😍

What you write is already possible, no?

Oh is it? Hah I'm on my phone so can't test that in a repl at the moment

Except that 1.11 would be a proper map with the version.

And I would put the if inside the def of course.

You can do it using a macro in which you check the Clojure version, it's a little cleaner than eval

[x y] - this is the source of nth.

=> (destructure '[[x y] data])
[vec__147 data x (clojure.core/nth vec__147 0 nil) y (clojure.core/nth vec__147 1 nil)]

Ohh .... Thank you @U2FRKM4TW. I can't believe how much time it's taking to pull that apart! I'll try passing x and y as regular arguments.

Are you passing a vector as the last argument or something else? It should be rather fast for a vector.

It is a vector. It's newly constructed by the function that calls perc-foodspots-exactly. (I wouldn't think this would matter, but fwiw, the actual function to which the vector pair is passed is (partial perc-foodspots-exactly env perc-radius). That's what sees [x y].) Let's see what happens when I have a chance to run clj-async-profiler with the changed code.

In case anyone is interested, passing x and y as [x y] was indeed the cause of the call to nth, and getting rid of that made a significant difference. That's an important lesson. Thanks @U2FRKM4TW! (Also grateful to Alexander Yakushev for clj-async-profiler, which I just started using.) (The time used up by nth was not as much as I thought, btw. I think I might not have been running a sufficient number of iterations to get an accurate result from async-profiler.)