thanks for your message! I haven’t hacked the stdlib before (apart maybe from bug reports and documentation), so I welcome help in setting up a good process.
First and foremost, we can’t introduce bugs during the change. The Long/BigInteger split will introduce additional logic, and the interesting cases are when the numbers are just at the boundary.
I think the change should be introduced in a few steps:
BigInt into an abstract class and a
BigIntegerBigInt implementation class. Verify that binary compatibility is preserved, and that tests pass.
LongBigInt implementation class; still perform the computations using
BigInteger, but allocate the result as a
LongBigInt if it fits in a
Long. Be sure that existing tests cater for the boundary cases.
Migrate piece by piece the logic from Spire to avoid the detour through
I’m currently working with Ubuntu and Scala on the JVM. I need help setting up a minimal process that verifies that binary compatibility is preserved, and tests pass. The testing process should include parts of the community build as well after each step above, before we merge the PR in the stdlib.
In particular, I’ve never run any tests on my own computer; I’m familiar with testing with the JVM, but with Scala JS or Scala native. I may want to use test procedures with different levels of exhaustiveness to get feedback in a shorter amount of time (hacking Scala is sadly not my day-to-day job).
BTW, I’m sure of the positive performance impact this would have. Is there a standard framework to benchmark improvements in the stdlib, and where is it documented?