This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-23
Channels
- # announcements (5)
- # aws (4)
- # babashka (141)
- # beginners (139)
- # calva (35)
- # cider (5)
- # clj-kondo (27)
- # cljsrn (20)
- # clojure (37)
- # clojure-czech (5)
- # clojure-dev (26)
- # clojure-europe (11)
- # clojure-germany (1)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-spec (17)
- # clojure-uk (16)
- # clojurescript (2)
- # conjure (1)
- # cursive (6)
- # datomic (20)
- # defnpodcast (1)
- # emacs (15)
- # fulcro (26)
- # honeysql (2)
- # instaparse (3)
- # jackdaw (4)
- # jobs (2)
- # lsp (70)
- # luminus (2)
- # meander (16)
- # missionary (2)
- # other-languages (151)
- # pathom (6)
- # portkey (13)
- # re-frame (13)
- # reagent (2)
- # reitit (43)
- # releases (1)
- # remote-jobs (1)
- # reveal (5)
- # rum (2)
- # sci (15)
- # shadow-cljs (37)
- # spacemacs (4)
- # tools-deps (8)
- # vim (20)
JIT bugs! Scary!
It's not the first time that I see this bug
(find [:a :b] 8589934592) => [8589934592 :a]
There is a jira for it?
The issue is at PersistentVector#valAt
public Object valAt(Object key, Object notFound){
ensureEditable();
if(Util.isInteger(key))
{
int i = ((Number) key).intValue();
// here key = 8589934592 generates i = 0
if(i >= 0 && i < cnt)
return nth(i);
}
return notFound;
}
This might be a case of one man's bug is another man's performance optimization with a touch of GIGO. That isn't my call to make, though.
It reminds me of (sort-by - xs)
which “works” until we have numbers that are greater than ints can be.
One could argue that it’s surprising that math operations in Clojure are designed to not overflow, and then other places, stuff overflows silently producing wrong results.
Well, for that example, there is documentation on
that warns about that and recommends against it: https://clojure.org/guides/comparators. (beware using subtraction section)
Ah, but that’s because you wrote that after I highlighted it. At least that’s my recollection of the events 🙂
Clojure on JVM cannot change the compareTo
Java interface, while using that interface, and it returns a 32-bit int
I don't know the time ordering of events there. I collected a lot of corner cases there from wherever I could find them.
Another case one could argue is a bug vs. GIGO performance optimization in a hot code path:
user=> (nth [:a :b :c] 1.5)
:b
Well, 2.5
also returns :c
and -0.1
returns :a
-0.99
returns :a
, too. I don't know what exactly it is doing, but I'd recommend not calling it with floating point values, for sure.
On a personal note, I think it would be nice with an addendum to the docstring for assoc!
to never ever use it without using the return value.
Might be a JIRA for that, but if not,
is ready for your suggestion.
In general it is probably undecidable, but a linter check that tells you when you are obviously and locally discarding the return value catches a lot of cases. Eastwood has it, and there is a clj-kondo issue for it, too, apparently.