Clojurians Log v2
clojure-dev
@seancorfield clojure now works again on the latest release of OpenJ9 (0.26.0)
2đź’Ż
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 <http://clojure.org|clojure.org> 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.
Not blaming anyone. Just typing when I should have gone to bed.
Another case one could argue is a bug vs. GIGO performance optimization in a hot code path:
user=> (nth [:a :b :c] 1.5)
:bMakes sens though, 1.5 is in the middle of 3, right?
Well, 2.5 also returns :c
and -0.1 returns :a
at least it’s rounding and not flooring.
-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.
Not that it would have helped me, but it could help others.
Might be a JIRA for that, but if not, <http://ask.clojure.org|ask.clojure.org> is ready for your suggestion.
asked 🙂
of transients you need some kind linear dataflow analysis
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.
well it is what rust's borrow checker does, and what haskell's new linear types do
but yeah, something like any use of assoc! (or other transient write operation) where the result ends up in what the compiler calls a statement context would catch most of it