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:
BigIntinto an abstract class and a
BigIntegerBigIntimplementation class. Verify that binary compatibility is preserved, and that tests pass.
LongBigIntimplementation class; still perform the computations using
BigInteger, but allocate the result as a
LongBigIntif 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?