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 live
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 wrote:
> If we increase the hppc fork to 23 classes and 14 test classes, then we
>> can remove
>
> 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
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
I can send a PR for this soon.
Dawid, for the size of
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
Hi David,
> On 25 May 2024, at 21:08, Dawid Weiss wrote:
>
> ...
>
> I understand it's a pain if the order changes from run to run but I don't see
> a way this can be avoided ([1] is the issue you mentioned on gh). Tests (and
> code) shouldn't rely on map/set ordering, although I realize it m
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?
+1 to moving the hppc fork to oal.internal.
Le dim. 26 mai 2024 à 12:22, Uwe Schindler a écrit :
> Hi,
>
Hi,
I was also wondering why parts of hppc were forked/copied to Lucene
Core, others not. IMHO it should be consistent.
I alaos agree that we should remove the classes completely from the util
package (public part of API) and move them to the non-exported packages
unter oal.internal. Of cour
I didn't copy all hppc, the Lucene hppc fork is limited.
I know there are some hppc classes used and not in the fork in the facet
module, which had the hppc jar dependency since a while ago. So maybe we
can keep this dependency?
For the new dependencies that I added to the join and spatial modules,
I will not have the time for this today but took a quick look and I think
these external dependencies on hppc can be removed after the work Bruno has
done to port some of these utility classes to the core. I'd also move the
entire Lucene hppc fork under internal and only expose it to other Lucene
m
10 matches
Mail list logo
