clojure-dev

slipset 2023-02-03T09:02:26.838309Z

Just stumbled upon https://ask.clojure.org/index.php/9010/distinct-should-support-sets. Basically I have a fn that takes a coll and I wanted to be sure it was distinct regardless of type. I see this question has no Jira ticket on it. Any chance of that happening?

slipset 2023-02-03T09:21:24.790359Z

Sort of related, but why isnโ€™t distinct implemented as (seq (set coll)) ?

favila 2023-02-03T11:44:56.930629Z

Distinct is lazy and preserves order. That does neither

โœ… 1
Alex Miller (Clojure team) 2023-02-03T14:49:08.214339Z

btw, the transducer version will work with sets

slipset 2023-02-03T14:50:07.997229Z

Does that make it worse or better?

slipset 2023-02-03T14:50:20.516389Z

(sorry late Friday here)

Alex Miller (Clojure team) 2023-02-03T14:50:21.392529Z

it provides a solution now in lieu of a change

Alex Miller (Clojure team) 2023-02-03T14:50:35.515849Z

but I will file a ticket for it

Alex Miller (Clojure team) 2023-02-03T14:59:30.664129Z

https://clojure.atlassian.net/browse/CLJ-2747

JoshLemer 2023-02-03T17:34:45.325599Z

I notice that there is opportunity to reduce a lot of allocations in int-maps during iteration, if we have Leaf nodes (https://github.com/clojure/data.int-map/blob/master/src/main/java/clojure/data/int_map/Nodes.java#L567) extend clojure.lang.MapEntry (since that is what they are basically anyways) Then its iterator can return this instead of new MapEntry(key, value) https://github.com/clojure/data.int-map/blob/master/src/main/java/clojure/data/int_map/Nodes.java#L596 and similarly its reduce method can invoke on this rather than new MapEntry(key, value) https://github.com/clojure/data.int-map/blob/master/src/main/java/clojure/data/int_map/Nodes.java#L614 On an int-map of 50k entries I observe about 40% speedup in reduce by doing that

JoshLemer 2023-02-03T17:36:26.965709Z

a complication is that int MapEntry.count() { return 2 } clashes in both meaning and signature with long INode.count() (which should return 1). So INode.count would need to be renamed to like nodeCount() or something.

dmiller 2023-02-03T22:25:51.896289Z

I don't have a way to check out against the latest build of Clojure(JVM), but I'm wondering about the effects of commit https://github.com/clojure/clojure/commit/b2366fa5c748f9d600879c3e0b549e631a5b386f on LongRange chunking. Prior to this commit LongRange had similar logic to what is still in Range for chunking, namely forceChunk would make sure that the LongChunk created had size no more than CHUNK_SIZE = 32 . in the new code, the LongChunk will have size equal to the size of the LongRange. I'm guessing this will be a surprise to anyone trying (take 1 (map f (range 1000000))) who likely will expect f to be called at most 32 times. (I'm basing this on comparing my current install of clj = 1.11.1 against the latest ClojureCLR which has this change. I used a side-effecting f . For clj f is called 32 times. for ClojureCLR, well, at least in only tested it against 100 and not 1,000,000. Tracing through my code vs current JVM code, I don't think the problem is just on my side.)

Alex Miller (Clojure team) 2023-02-03T22:32:50.016199Z

this is been changed back in master

Alex Miller (Clojure team) 2023-02-03T22:33:38.540349Z

or maybe it hasn't been ok'ed yet

dmiller 2023-02-03T22:35:33.400929Z

doesn't show in the repo yet. My usual assumption is that something is broken in my code. It took me a long time to think of checking the commit history on that file.

Alex Miller (Clojure team) 2023-02-03T22:35:42.122699Z

https://clojure.atlassian.net/browse/CLJ-2742

Alex Miller (Clojure team) 2023-02-03T22:35:46.327679Z

coming

Alex Miller (Clojure team) 2023-02-03T22:36:46.250409Z

actually had a missing field set so was not showing up in the right list, so thanks! ;)

dmiller 2023-02-03T22:37:30.230929Z

Also didn't think to check JIRA ๐Ÿ™‚ And all I was trying to do was come up with a final example for a blog post.