[pacman-dev] [PATCH 2/3] pacsearch with repo-agnostic coloring

Jason St. John jstjohn at purdue.edu
Fri Jan 17 19:39:11 EST 2014


On Fri, Jan 17, 2014 at 5:44 AM, Pierre Neidhardt <ambrevar at gmail.com> wrote:
> On 14-01-17 20:29:36, Allan McRae wrote:
>> On 17/01/14 14:07, Andrew Gregory wrote:
>> > On 01/16/14 at 11:48am, Pierre Neidhardt wrote:
>> >> Ooopsy! Looks like I forgot to sum the result! Actually I didn't notice the flaw
>> >> since it still works. The reason is that the resulting numbers are so big they
>> >> are casted and rounded to float or sth equivalent. This is _terrible_ code
>> >> indeed!
>> >>
>> >> In the first place this was an attempt to use Perl features for a quick,
>> >> one-line hash of strings, but since I'm not a Perl guru this may be doomed to
>> >> fail. Any better suggestion from a Perl champion?
>> >>
>> >> A more traditional way to do it:
>> >>
>> >>    sub hash_string {
>> >>            my $sum = 0;
>> >>            foreach my $l (split //, $_[0]) {
>> >>                    $sum = $sum + 31*ord($l) + 5;
>> >>            }
>> >>            return $sum;
>> >>    }
>> >>
>> >>     [...]
>> >>    my $repo_hash = hash_string($v[0]);
>> >>
>> >> This is not a very good hash since a permutation will yield the same
>> >> result. The following is much better
>> >>
>> >>    $sum = $sum + 31*ord($l)^$pos + 7;
>> >>
>> >> but do we really need this? This is just for repo names after all, the extra
>> >> exponentiation is superfluous in my opinion.
>> >>
>> >> The offset (e.g. '+5') can be patched by other distributions make sure their
>> >> repo have different colors.
>> >
>> > Two suggestions:
>> >
>> > 1. Use Term::ANSIColor instead of raw ANSI color codes.  This will
>> >    make the code more readable and make life easier for distro's that
>> >    need to patch in their own repo colors.
>> >
>> > 2. Provide a hash variable for hard-coding repo colors.  It can be
>> >    empty by default, making it very easy for distro's to patch in
>> >    their official repos if the default gives poor results.
>> >
>> > Something like:
>> >
>> >   use Term::ANSIColor;
>> >
>> >   my %repo_colors;
>> >
>> >   my @colors = (
>> >    color('blue'),
>> >    color('red'),
>> >    ...
>> >   );
>> >   ...
>> >   my $repo_name = ...;
>> >   my $color = ( $repo_colors{$repo_name} || $colors[ hash($repo_name) ] );
>> >
>>
>>
>> Just throwing this out there...  How important is it to have the repos
>> different colours?  Dan?
>>
>> Allan
>
> I agree, all this is sounding rather futile... This is causing debatable design
> issues, which are certainly worthless. But this is also one of the only 2
> pacsearch features: per-repo colouring and local+sync searching.
>
> --
> Pierre Neidhardt
>

If the goal is to make pacsearch's output match that of 'pacman
-{S,Q}s', then this per-repo coloring should be scrapped completely
because those pacman commands use only one color for every repo.

However, because the remaining benefit of pacsearch is a combined
'pacman -{S,Q}s' search, it would be useful to have one color for
local packages and a different color for packages in the sync repos.

Jason


More information about the pacman-dev mailing list