Add Tuples test coverage

[pimfm]

Hi 👋

Thank you for providing this beginner friendly story (#2894). It was very helpful to get started with the first contribution.

I saw that Tuples 10-22 will be removed in Arrow2.0, I wasn't sure if you still wanted some test coverage for earlier versions. I have commited these tests in a seperate (atomic) commit so that it can be easily cherry-picked or removed. Let me know what you prefer and if it is of any value :)

[nomisRev]

Hey @vngrp!

Thank you for the contribution!! This is great 🙌 Also congrats on your first contribution ☺️

You're right, we decided to limit the maximum arity, I think it's perfect like this. We're planning to make the arrow-2 the main branch in the next couple weeks.

[nomisRev]

@vngrp I think we're running into a weird JS issue 😅 Test is failing with this:

Caused by AssertionFailedError: expected:

(0, , -1e+308, -7e+37, false, (1502718338, true), Z, 0, 9758211233277423)
but found:
(0, , -1e+308, -7e+37, false, (1502718338, true), Z, 0, 9758211233277424)

My guess would be it's the floating numbers, not sure if we should create a YouTrack Kotlin ticket for this or if this is expected behavior 🤔 cc\ @serras

[nomisRev]

Looks perfect to me! Thanks @vngrp Except for the strange error in shortToString.

[pimfm]

Good day @nomisRev and @serras,

Thank you for providing the actual JS error, the difference occured on the 8th position, which was of type Byte, I share your view that it could be some JS weirdness similar to floating points.

I've changed the type to uInt, which should make this build pass and make this PR good to go. I'll reproduce the Byte issue outside the PR and see if it's relevant for a YouTrack ticket. I did not yet manage to run all tests locally, I'll give that another shot next time.

Thanks, have a good day :)

[pimfm]

Apologies for all the build triggers, changed uInt and float to Int to remove inconsistencies as it is not testing the Tuple functionality, but the underlying language.

I'll be sure to check all tests locally next time :)

[nomisRev]

No worries @vngrp! All good ☺️

[nomisRev]

The same issue again on JS @vngrp 🤔

Caused by AssertionFailedError:
(0, , -1e+308, 0, true, (-1316168953, false), J, 0, 9243625104359195) // expected
(0, , -1e+308, 0, true, (-1316168953, false), J, 0, 9243625104359196) // actual

[pimfm]

The same issue again on JS @vngrp 🤔

Caused by AssertionFailedError:
(0, , -1e+308, 0, true, (-1316168953, false), J, 0, 9243625104359195) // expected
(0, , -1e+308, 0, true, (-1316168953, false), J, 0, 9243625104359196) // actual

Oh, that is very interesting.. Did not expect that. Thank you for sharing. I looked at the wrong position, the ninth was probably Long.MAX_VALUE and this does something strange.

For now every single one is an int, if I get everything build locally I'll see to change it back to different data types as it's kinda neat to have all these different types in a tupleN. And investigate why that Long behaves this way in KotlinJS.

Thanks for the assistance

[nomisRev]

@vngrp it's something with large numbers on JS 🤷 Same for Int.MAX_VALUE == Int.MAX_VALUE.

https://play.kotlinlang.org/#eyJ2ZXJzaW9uIjoiMS45LjEwIiwiY29kZSI6ImZ1biBtYWluKCkge1xuICByZXF1aXJlKExvbmcuTUlOX1ZBTFVFID09IExvbmcuTUFYX1ZBTFVFKSB7IFwiTG9uZy5NSU5fVkFMVUUgIT0gTG9uZy5NQVhfVkFMVUUgb24gSlNcIiB9XG59IiwicGxhdGZvcm0iOiJqcy1pciIsImFyZ3MiOiIifQ==

Thanks for the assistance

My pleasure Pim ☺️

[nomisRev]

I'm going to merge this already, since it's unrelated to the test but it's something on JS.

[pimfm]

Hey Simon! 😄

Wow, that play.kt link is useful, I didn't know you could also use JS IR directly.
The link you sent compared Long.MIN_VALUE to Long.MAX_VALUE which luckily doesn't equal :)

I've updated the snippet:
https://pl.kotl.in/4-6ROpLEi

There is indeed some strangeness to be found there. The last 3 digits are rounded, only on the toString variant. I'm gonna check if the Kotlin JS team has a YouTrack item for this and otherwise create one :)

[nomisRev]

The link you sent compared Long.MIN_VALUE to Long.MAX_VALUE which luckily doesn't equal :)

Oops, 🤦‍♂️

That is indeed curious. I think we should indeed report that to YouTrack. Nice reproducible btw!

[pimfm]

KT-62763