Fork me on GitHub
#clojure-dev
<
2021-04-23
>
ghadi19:04:55

@seancorfield clojure now works again on the latest release of OpenJ9 (0.26.0)

💯 2
andy.fingerhut20:04:47

JIT bugs! Scary!

souenzzo20:04:01

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;
	}

andy.fingerhut21:04:19

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.

slipset21:04:29

It reminds me of (sort-by - xs) which “works” until we have numbers that are greater than ints can be.

slipset21:04:28

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.

andy.fingerhut21:04:35

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)

slipset21:04:14

Ah, but that’s because you wrote that after I highlighted it. At least that’s my recollection of the events 🙂

andy.fingerhut21:04:21

Clojure on JVM cannot change the compareTo Java interface, while using that interface, and it returns a 32-bit int

andy.fingerhut21:04:57

I don't know the time ordering of events there. I collected a lot of corner cases there from wherever I could find them.

slipset21:04:20

Not blaming anyone. Just typing when I should have gone to bed.

andy.fingerhut21:04:49

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

slipset21:04:48

Makes sens though, 1.5 is in the middle of 3, right?

andy.fingerhut21:04:16

Well, 2.5 also returns :c

andy.fingerhut21:04:43

and -0.1 returns :a

slipset21:04:51

at least it’s rounding and not flooring.

andy.fingerhut21:04:32

-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.

slipset21:04:51

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.

slipset21:04:20

Not that it would have helped me, but it could help others.

andy.fingerhut21:04:00

Might be a JIRA for that, but if not, is ready for your suggestion.

slipset21:04:16

asked 🙂

hiredman21:04:04

of transients you need some kind linear dataflow analysis

andy.fingerhut21:04:40

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.

hiredman22:04:39

well it is what rust's borrow checker does, and what haskell's new linear types do

hiredman22:04:04

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