15:19 <nakilon> hiding the BDIGIT from public api and using rb_integer_pack instead is 3-5 times slower

15:52 <nakilon> this monstruosity https://github.com/ruby/ruby/blob/3628e9e30d3809da67eb38b9d19fa99f8a999eaa/bignum.c#L3588

15:54 <nakilon> made for compatibility? I've no idea, I just need to read those bits; with no access to "BDIGITS" macro my gem isn't the faster anymore

17:27 <nakilon> looks like https://cache.ruby-lang.org/pub/ruby/\$RUBY_MAJOR/ruby-\$RUBY_VERSION.tar.gz isn't available anymore

20:14 <havenwood> nakilon: Curious if an AVX2-optimized version of bary_pack for 64-bit integers with no nails would help.

20:15 <havenwood> A bunch of parallel xors might matter.

20:16 <havenwood> I'm afraid 32-bit would require a separate implementation and it feels like diminishing returns to continue to care.

22:52 <sphex> so... #to_enum does not have the same ability to "capture" refinements as Symbol#to_proc does? am I getting this right?

23:18 <havenwood> sphex: "Capture refinement" isn't the right terminology since "refinements" are a thing. They're like lexically scoped monkey patches.

23:19 <havenwood> sphex: A proc encloses its binding.

23:22 <havenwood> sphex: An Object#to_enum creates an Enumerator rather than a Proc. They similarly enclose state but Enumerators are for internal and external iteration, so it's pretty specific.

23:22 <havenwood> They're similar in that they're both a shorthand for creating, one a Proc the other an Enumerator.

23:24 <havenwood> sphex: You're likely to call #to_enum on a collection or something that can produce one. A #to_proc is usually used implicitly, where you do `&:a_symbol` to pass a Symbol as a block.

23:24 <havenwood> The `&` calls #to_proc on `a_symbol` and also passes it as a block rather than a regular argument.

23:24 <sphex> havenwood: ok yeah, I was wrong. I thought to_proc could remember the refinements that were in scope at the time it was called but no, it doesn't do that. and to it's no different from to_enum...

23:27 <sphex> well, that makes it harder to make enumeration-style methods in refinements. methods that return an enumerator for themselves when called without a block I mean. the to_enum enumerator can't see the refined methods... you can work around it by creating an Enumerator manually, but kind of annoying, and probably slower...

23:44 <sphex> huh interesting... seems like it's possible to "capture" refinements with the "&" operator. "&:abc" isn't quite the same as "&:abc.to_proc". the implicit "to_proc" is magic.