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

Allan McRae allan at archlinux.org
Fri Jan 17 05:29:36 EST 2014


On 17/01/14 14:07, Andrew Gregory wrote:
> On 01/16/14 at 11:48am, Pierre Neidhardt wrote:
>> On 14-01-16 10:13:18, Allan McRae wrote:
>>> On 16/01/14 02:03, Martti Kühne wrote:
>>>> On Wed, Jan 15, 2014 at 9:50 AM, Allan McRae <allan at archlinux.org> wrote:
>>>> [...]
>>>>>
>>>>>> +     # hash function (x*2+1) is completely arbitrary.
>>>>>> +     my $repohash = $v[0];
>>>>>> +     $repohash =~ s/(.)/ord($1)*2+1/ge;
>>>>>
>>>>> I have very little perl knowledge, so I have no idea what that hash is
>>>>> doing.  Can someone explain to me so I can see if that "hash" is reasonable.
>>>>>
>>>>
>>>> Replace each character with its [0] ascii index times two plus one?
>>>> 'g' is group regexes, 'e' is eval expressions [1], as to utilize the
>>>> result of the calculation.
>>>>
>>>> cheers!
>>>> mar77i
>>>>
>>>> [0] http://perldoc.perl.org/functions/ord.html
>>>> [1] http://stackoverflow.com/questions/6082219/perl-regex-e-eval-modifier-with-s
>>>>
>>>
>>> Does that mean the answer can only be odd?
>>
>> 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


More information about the pacman-dev mailing list