Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Problem with hash and regexp

Reply
Thread Tools

Problem with hash and regexp

 
 
Francisco
Guest
Posts: n/a
 
      03-21-2005
Can someone please explain me what's wrong here? (coments in the code).
Thank you.

#!/usr/bin/perl -w
use strict;
use diagnostics;

my %severity = (
000 => 'emerg',
001 => 'alert',
010 => 'crit',
011 => 'err',
100 => 'warn',
101 => 'notice',
110 => 'info',
111 => 'debug'
);

my $numsev = 123;
my $binsev = dec2bin($numsev);
#it's clear after some experiments that the problem comes from this
conversion
print "binsev: $binsev\n";
#the binary number was converted OK
$binsev =~ /(\d{3})$/;
print "binsev3: $1\n";
#it appears that I get the 3 LSB of the binary number as I wanted
print "sev: $severity{$binsev3}\n";
#but here the hash lookup fails and I can't understand the reason, maybe
something at the end of the string that is wrong?

sub dec2bin { return sprintf "%b", shift }

Perl output:
binsev: 1111011
binsev3: 011
Use of uninitialized value in concatenation (.) or string at ./bla.pl line
24 (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.

To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes
your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, "that $foo" is
usually optimized into "that " . $foo, and the warning will refer to
the concatenation (.) operator, even though there is no . in your
program.

sev:

 
Reply With Quote
 
 
 
 
Brian McCauley
Guest
Posts: n/a
 
      03-21-2005
Francisco wrote:

> Subject: Problem with hash and regexp


Your problem has nothing to do with hashes or regexes.

> my %severity = (
> 000 => 'emerg',
> 001 => 'alert',
> 010 => 'crit',
> 011 => 'err',
> 100 => 'warn',
> 101 => 'notice',
> 110 => 'info',
> 111 => 'debug'
> );


The auto quoting effect of => does not apply to numbers. 000 is just 0.
001 is just 1. 010 is just 8.

 
Reply With Quote
 
 
 
 
Fabian Pilkowski
Guest
Posts: n/a
 
      03-21-2005
* Francisco schrieb:

> Can someone please explain me what's wrong here? (coments in the code).
> Thank you.
>
> #!/usr/bin/perl -w
> use strict;
> use diagnostics;
>
> my %severity = (
> 000 => 'emerg',
> 001 => 'alert',
> 010 => 'crit',
> 011 => 'err',
> 100 => 'warn',
> 101 => 'notice',
> 110 => 'info',
> 111 => 'debug'
> );


Here I would add the following two lines

use Data:umper;
print Dumper \%severity;

to see how %severity is initialized now. Remember: numbers beginning
with zero are interpreted as octal ones. Try to use more quotes.

regards,
fabian
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      03-21-2005
Francisco <(E-Mail Removed)> wrote:

> print "binsev3: $1\n";
> #it appears that I get the 3 LSB of the binary number as I wanted
> print "sev: $severity{$binsev3}\n";

# ^^^^^^^^ Where did this come from?

Aside from the fact that you haven't made sure the contents of your
hash are what you think they are, as others have pointed out, you also
apparently aren't using strict.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
Francisco
Guest
Posts: n/a
 
      03-21-2005
Brian McCauley wrote:

> The auto quoting effect of => does not apply to numbers. 000 is just 0.
> 001 is just 1. 010 is just 8.


I can't believe it!!, thank you very much. I've made tests before asking for
the values directlly, but I was using the value "101" of the hash that
wasn't changed, so I though the hash wasn't the problem.
 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      03-21-2005
Fabian Pilkowski <(E-Mail Removed)-marburg.de> wrote:
> * Francisco schrieb:


>> my %severity = (
>> 000 => 'emerg',
>> 001 => 'alert',
>> 010 => 'crit',
>> 011 => 'err',
>> 100 => 'warn',
>> 101 => 'notice',
>> 110 => 'info',
>> 111 => 'debug'
>> );



> Try to use more quotes.



Or, try to use *less* quotes:

my %severity = qw(
000 emerg
001 alert
010 crit
011 err
100 warn
101 notice
110 info
111 debug
);




--
Tad McClellan SGML consulting
http://www.velocityreviews.com/forums/(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Paul Lalli
Guest
Posts: n/a
 
      03-21-2005
"Francisco" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Can someone please explain me what's wrong here? (coments in the

code).
> Thank you.
>
> #!/usr/bin/perl -w
> use strict;
> use diagnostics;
>
> my %severity = (
> 000 => 'emerg',
> 001 => 'alert',
> 010 => 'crit',
> 011 => 'err',
> 100 => 'warn',
> 101 => 'notice',
> 110 => 'info',
> 111 => 'debug'
> );
>
> my $numsev = 123;
> my $binsev = dec2bin($numsev);
> #it's clear after some experiments that the problem comes from this
> conversion
> print "binsev: $binsev\n";
> #the binary number was converted OK
> $binsev =~ /(\d{3})$/;
> print "binsev3: $1\n";
> #it appears that I get the 3 LSB of the binary number as I wanted
> print "sev: $severity{$binsev3}\n";
> #but here the hash lookup fails and I can't understand the reason,

maybe
> something at the end of the string that is wrong?
>
> sub dec2bin { return sprintf "%b", shift }
>
> Perl output:
> binsev: 1111011
> binsev3: 011
> Use of uninitialized value in concatenation (.) or string at ./bla.pl

line
> 24 (#1)


That's a lie.

Here's the output I get from running your program:
Global symbol "$binsev3" requires explicit package name at clpm.pl line
25.
Execution of clpm.pl aborted due to compilation errors (#1)

Please post real code. Have you read the posting guidelines for this
group yet?

Paul Lalli

 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      03-21-2005
Jim Gibson <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>, Francisco <(E-Mail Removed)>
> wrote:


>> 010 => 'crit',


> 8: crit



> So '010' and '011' are being interpreted as octal numbers. This would
> seem to belie the Comma Operator documentation in perldoc perlop:
>
> "The "=>" operator is a synonym for the comma, but forces any word to
> its left to be interpreted as a string (as of 5.001). It is helpful in
> documenting the correspondence between keys and values in hashes, and
> other paired elements in lists."
>
> Why this is so and whether or not this is a bug in perl must be left to
> those more knowledgable about perl internals than I.



It may be a bug in the documentation, but I don't see how it
could be a bug in the internals.

"word" appears to mean "follows the same rules as user-defined
identifiers", that is: it is a word (and hence will be auto-quoted)
if it matches:

/^[a-zA-Z_]\w*$/


--
Tad McClellan SGML consulting
(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Chris Mattern
Guest
Posts: n/a
 
      03-21-2005
Tad McClellan wrote:

> Fabian Pilkowski <(E-Mail Removed)-marburg.de> wrote:
>> * Francisco schrieb:

>
>>> my %severity = (
>>> 000 => 'emerg',
>>> 001 => 'alert',
>>> 010 => 'crit',
>>> 011 => 'err',
>>> 100 => 'warn',
>>> 101 => 'notice',
>>> 110 => 'info',
>>> 111 => 'debug'
>>> );

>
>
>> Try to use more quotes.

>
>
> Or, try to use *less* quotes:
>
> my %severity = qw(
> 000 emerg
> 001 alert
> 010 crit
> 011 err
> 100 warn
> 101 notice
> 110 info
> 111 debug
> );
>
>
>
>

Arguably, that's still "using more quotes". You're just getting
Perl to put them in for you.

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"
 
Reply With Quote
 
Charles DeRykus
Guest
Posts: n/a
 
      03-21-2005
In article <(E-Mail Removed)>,
Tad McClellan <(E-Mail Removed)> wrote:
>Jim Gibson <(E-Mail Removed)> wrote:
>> In article <(E-Mail Removed)>, Francisco <(E-Mail Removed)>
>> wrote:

>
>>> 010 => 'crit',

>
>> 8: crit

>
>
>> So '010' and '011' are being interpreted as octal numbers. This would
>> seem to belie the Comma Operator documentation in perldoc perlop:
>>
>> "The "=>" operator is a synonym for the comma, but forces any word to
>> its left to be interpreted as a string (as of 5.001). It is helpful in
>> documenting the correspondence between keys and values in hashes, and
>> other paired elements in lists."
>>
>> Why this is so and whether or not this is a bug in perl must be left to
>> those more knowledgable about perl internals than I.

>
>
>It may be a bug in the documentation, but I don't see how it
>could be a bug in the internals.
>
>"word" appears to mean "follows the same rules as user-defined
>identifiers", that is: it is a word (and hence will be auto-quoted)
>if it matches:
>
> /^[a-zA-Z_]\w*$/
>


Ah, I've never noticed that subtlety.

Without clarifying what's meant by 'word', one might assume '=>'
acts like 'qw'. The docs IMO would be greatly improved by spelling
it out:

'...but forces any user-identifier (i.e.,/^[a-zA-Z]\w*$/)
to its left to be interpreted as a string...'

--
Charles DeRykus
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hash of hash of hash of hash in c++ rp C++ 1 11-10-2011 04:45 PM
[regexp] How to convert string "/regexp/i" to /regexp/i - ? Joao Silva Ruby 16 08-21-2009 05:52 PM
Hash#select returns an array but Hash#reject returns a hash... Srijayanth Sridhar Ruby 19 07-02-2008 12:49 PM
regexp+hash problem Le Lann Jean-Christophe Ruby 5 05-12-2008 08:38 PM
Programmatically turning a Regexp into an anchored Regexp Greg Hurrell Ruby 4 02-14-2007 06:56 PM



Advertisments