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:
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@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
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 We are all dying -- and we're gonna be dead for a long time.