Le mer. 23 sept. 2026 à 19:20, Kamila Szewczyk
<[email protected]> a écrit :
>
> Laurent,
>
> I thought of that already, but the LS_COLORS environmental variable
> needs to be supported anyway (iuic). There could be a gperf fallback,
> though.
>
> --
> With Valediction,
> Kamila Szewczyk (https://iczelia.net)
>
> On 9/23/26 7:19 PM, Laurent Lyaudet wrote:
> > Le mer. 23 sept. 2026 à 18:24, Pádraig Brady <[email protected]> a écrit :
> >>
> >> On 23/09/2026 16:54, Collin Funk wrote:
> >>> Pádraig Brady <[email protected]> writes:
> >>>
> >>>> On 23/09/2026 08:34, Kamila Szewczyk wrote:
> >>>>> Pádraig,
> >>>>> > It wouldn't be fair to impose implementing that on you.
> >>>>> No, please. I would be more than happy to. It just depends on
> >>>>> whether
> >>>>> you would accept the patch, of course.
> >>>>
> >>>> For the moment I've applied your original patch,
> >>>> after removing support for these obsolete formats:
> >>>> .ace, .alz, .apk, .arc, .arj, .bz, .zoo
> >>>
> >>> Is .apk really obsolete? I think Alpine packages and side loaded Android
> >>> applications use that extension. It seems your patch didn't remove it
> >>> anyways [1].
> >>>
> >>> Collin
> >>>
> >>> [1]
> >>> https://github.com/coreutils/coreutils/commit/965657d686f7f7b182181f2fdd7478630385d0a3
> >>
> >> Oops good spot.
> >>
> >> That was actually a copy/paste issue.
> >> Right I didn't actually remove apk.
> >> Others being removed happened to be around that,
> >> and I forgot to remove it when copy/pasting the list.
> >>
> >> sorry,
> >> Padraig
> >>
> >
> > Hello,
> >
> > Slightly surprising and somewhat funny discussion
> > that with hardware of 2026 we're afraid of listing more archive formats
> > whilst optimized code could handle a list of ten thousands of archive
> > formats without any problem.
> > May I recall that GNU has a software called gperf for perfect hashing?
> > https://www.gnu.org/software/gperf/manual/gperf.html
> >
> > Have a nice day, best regards,
> > Laurent
>
Hello Kamila,
Can you say hello, instead of just Laurent like if I was a kid that
says unimportant things or can be sent back to its child place?
> I thought of that already, but the LS_COLORS environmental variable
> needs to be supported anyway (iuic). There could be a gperf fallback,
> though.
Correct me if I'm wrong:
- perfect hashing is about hash key not about values associated,
- O(1) + O(1) = O(1)
- So the perfect hash table (gperf) should not be used as a
fallback... but in first intent.
gperf should be used during development to obtain a perfect hash
function for the keys that are in the file dircolors.hin.
And all these keys should be preset in the corresponding hash table to
a default "NON-NULL" witness value.
Then when you parse LS_COLORS if the key exists with a default
"NON-NULL" witness value in PHT (Perfect Hash Table),
you set the value in PHT to what you read in LS_COLORS.
Other keys in custom LS_COLORS are to be put with their value in
either another hash table,
with a hash function that is not perfect since we cannot guarantee
anything on these keys,
or keep the current linked list to store these uncommon values.
Then whenever a search for a key is done in this data-structure made
of a front PHT and a fallback (either HT or LL),
if the result is from the PHT with the witness value, ignore it,
otherwise use it.
PHT for common keys, something else otherwise.
I don't see the reason for your "but the LS_COLORS...".
That's simple, not over-engineered common optimizations
done for the usual 90 % of use cases in 10 % of the features.
Have a nice evening, best regards,
Laurent
