Hi Mike, These changes are rare, really. Bruno made most of them recently and the core has been unchanged for quite some time now. The same goes for fastutil, koloboke and other libraries. I don't think it's a problem and I think it's more than fine to poach what's needed if it makes people's lives easier downstream. I'll try to do this today and provide a patch.
Dawid On Mon, May 27, 2024 at 1:53 AM Mike Drob <md...@mdrob.com> wrote: > What is the cost of maintaining the fork? I don’t feel it’s fair to you > Dawid, if we were to expect you to port over any changes made to hppc > upstream. > > Mike > > On Sun, May 26, 2024 at 3:59 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > >> If we increase the hppc fork to 23 classes and 14 test classes, then we >>> can remove the hppc dependency from all modules. >>> Do we agree that we should >>> - Increase the fork size >>> - Move it to oal.internal >>> - Remove the hppc dependency from everywhere >>> >> >> Yes, I think it's the safest way to go and it's also the cleanest - keeps >> the implementation details private and doesn't clash with anything out >> there. Dropping an existing dependency shouldn't be a problem, I think. >> >> >>> Dawid, for the size of hppc, I counted the number of files with >>> find . -type f | wc -l >>> in hppc/build/generated/main >>> >> >> Oh, ok. Many of these are a bit esoteric (even though we don't generate >> all combinations). Taking what's needed sounds reasonable to me - and it >> shouldn't be that much, really. >> >> D. >> >> >>> >>> Le dim. 26 mai 2024 à 21:52, Dawid Weiss <dawid.we...@gmail.com> a >>> écrit : >>> >>>> >>>> Hi Bruno, >>>> >>>> Currently the hppc fork in Lucene is composed of 15 classes and 8 test >>>>> classes. >>>>> Forking everything in hppc would mean 525 classes and 193 test >>>>> classes. I'm not sure we want to fork all hppc? >>>>> >>>> >>>> My superficial analysis hinted at far fewer classes but I'll take a >>>> look tomorrow, had a busy day today. >>>> >>>> >>>>> +1 to moving the hppc fork to oal.internal. >>>>> >>>> >>>> Yes, I think it's a good idea to move it and hide it, at least for the >>>> module system. >>>> >>>> D. >>>> >>>>
