[32054] in Perl-Users-Digest
Perl-Users Digest, Issue: 3318 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 14 06:09:21 2011
Date: Mon, 14 Mar 2011 03:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 14 Mar 2011 Volume: 11 Number: 3318
Today's topics:
Re: Autovivification <hjp-usenet2@hjp.at>
convenient module to take statistics for hashed structu <ela@yantai.org>
Re: convenient module to take statistics for hashed str <smallpond@juno.com>
Re: convenient module to take statistics for hashed str <nospam.gravitalsun@hotmail.com.nospam>
DBD::mysql used to take octets into the utf8 texts but <peter@vereshagin.org>
Re: DBD::mysql used to take octets into the utf8 texts <rvtol+usenet@xs4all.nl>
Re: going from CPAN to RPM <m@rtij.nl.invlalid>
Re: Ok, simpler..... (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 13 Mar 2011 13:21:38 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Autovivification
Message-Id: <slrninpdmi.eva.hjp-usenet2@hrunkner.hjp.at>
On 2011-03-10 09:28, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
> PJH> I see I was a bit short on context.
>
> PJH> The situation with @{} was something like this:
>
> PJH> #!/usr/bin/perl
> PJH> use warnings;
> PJH> use strict;
>
> PJH> my $x = [];
>
> PJH> if (@{ $x->[0] }) {
> PJH> print "do something\n";
> PJH> } else {
> PJH> print "do something else\n";
> PJH> }
> PJH> __END__
> PJH> Can't use an undefined value as an ARRAY reference at ./ref1 line 7.
>
> PJH> So $x->[0] does not exist but should clearly be an arrayref. The
> PJH> program dies with an exception, the element is not autovivified.
>
> PJH> Compare this with:
>
> PJH> #!/usr/bin/perl
> PJH> use warnings;
> PJH> use strict;
> PJH> use Data::Dumper;
>
> PJH> my $x = [];
>
> PJH> if ($x->[0][0]) {
> PJH> print "do something\n";
> PJH> } else {
> PJH> print "do something else\n";
> PJH> print Dumper $x;
> PJH> }
> PJH> __END__
> PJH> do something else
> PJH> $VAR1 = [
> PJH> []
> PJH> ];
>
> PJH> Again, $x->[0] does not exist but should clearly be an arrayref.
> PJH> In this case, however, the element is autovivified and the program does
> PJH> not die.
>
>
> PJH> Why? I don't see the difference. In both cases the element doesn't exist
> PJH> but the type is clear (so it would be possible to autovivify it). In
> PJH> both cases there is no explicit assignment, only a read access (so it is
> PJH> debatable whether the element should be autovivified at all - it isn't
> PJH> necessary to determine the value of the expression and it is unintuitive
> PJH> that a read access modifies a value). The main difference is that
> PJH> @{ $x->[0] } queries a property of the anonyous array itself, and
> PJH> $x->[0][0]queries a property of one of its elements. But I don't think
> PJH> this should influence the behaviour.
>
> i said this in another post. something needs to be assigned. or rather
> an lvalue context is needed.
This is a circular argument. The only reason why something needs to be
assigned is because of autovivication. So you are saying that
autovivication needs to happen because of autovivication.
Otherwise there is no lvalue context in
if ($x->[0][0]) { ... }
> this is from perlref:
>
> This is one of the cases we mentioned earlier in which
> references could spring into existence when in an lvalue
> context.
Note that "This" refers to:
$array[$x]->{"foo"}->[0] = "January";
which is an lvalue context (it is on the *l*eft side of an assignment).
> your first case is read only. the second one makes the top level array
> an lvalue since it needs an array ref in there to lookup the element in
> the next level.
The same is true for the the first one. It needs an array ref to
evaluate the number of array elements. If one works, the other should,
too. If one doesn't work, I see no reason why the other should.
> autivivification happens when you must have a ref or the
> whole expression dies.
Well, that's just the case for the first example. I don't have a ref and
the whole expression dies. So you say that autovivification should
happen in this case.
(OTOH, there is no reason why $x->[0][0] (or @{ $x->[0] }) has to die:
It could just return undef, just like an access to a non-existent array
element returns undef)
> just reading a top level ref or deref like print
> @{$ref->[0]} isn't enough. pushing to that expression is enough as the
> missing array ref is now being used to store data so it is an lvalue.
push naturally creates an lvalue context. $x->[0][0] doesn't.
> it does make sense when you think about it in an lvalue context.
No, that makes even less sense, because there is no intrinsic lvalue
context. It probably does make sense if you look at it from a
implementation POV ("it was simpler that way") or a historic POV
(compatibility with pre-strict behaviour).
hp
------------------------------
Date: Sun, 13 Mar 2011 08:32:12 -0700
From: "ela" <ela@yantai.org>
Subject: convenient module to take statistics for hashed structures?
Message-Id: <ilgvng$7ec$1@ijustice.itsc.cuhk.edu.hk>
__DATA__
ID B C D E F G H
1 3 7 9 3 4 2 3
1 3 7 9 3 4 2 2
1 3 7 9 5 8 6 6
1 3 7 9 3 4 2 3
2 4 7 9 3 4 2 1
2 4 7 9 3 4 2 2
2 4 7 9 3 4 2 3
2 4 7 9 3 4 2 3
For each ID (the above example has two (1 and 2)), I want to identify the
"last common
ancestor: LCA, H being higher preference than B " based on some defined
threshold. If the threshold is set to 100%, then the LCA of ID 1 is D=9; if
set it to 75%, then it is F=2. For ID 2 (100%, G=2; 75%, G=2; 50% H=3)
While hash is good at allocating different instance easily, I don't know
whether perl supports simple architecture to get the max/min. For the
following code,
@array
For each row
for ($i=0; $i<$numcol; $i++)
$array[$i]{$key}++;
if just for B, I know the following should be written in this way:
foreach $key (keys %B) { $Bpertpot{$key} = $B{$key}/$total; }
for ($i=0; $i<$numcol; $i++) {
$maxcol[$i] = 0;
foreach $key (keys %Bpertpot) { if ($Bpertpot{$key}> $maxcol[$i]) {
$maxcol[$i] = $Bpertpot{$key}; }
}
but then I don't know how to do that for array of hash to traverse... i.e.
replace the %B and %Bpertpot to something that is compatible with the array
structure... In fact, I wonder if there is already well-established modules
that may have handled this kind of max-min statistics problems that seem to
encounter frequently in the business sector...
------------------------------
Date: Sun, 13 Mar 2011 17:40:56 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: convenient module to take statistics for hashed structures?
Message-Id: <1ccc6500-01a0-48f6-9b0f-510d486731cb@y14g2000vbb.googlegroups.com>
On Mar 13, 11:32=A0am, "ela" <e...@yantai.org> wrote:
> __DATA__
> ID =A0 =A0B =A0 =A0C =A0 =A0D =A0 =A0E =A0 =A0F =A0 =A0G =A0 =A0H
> 1 =A0 =A03 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A03
> 1 =A0 =A03 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A02
> 1 =A0 =A03 =A0 =A07 =A0 =A09 =A0 =A05 =A0 =A08 =A0 =A06 =A0 =A06
> 1 =A0 =A03 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A03
> 2 =A0 =A04 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A01
> 2 =A0 =A04 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A02
> 2 =A0 =A04 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A03
> 2 =A0 =A04 =A0 =A07 =A0 =A09 =A0 =A03 =A0 =A04 =A0 =A02 =A0 =A03
>
> For each ID (the above example has two (1 and 2)), I want to identify the
> "last common
> ancestor: LCA, H being higher preference than B " based on some defined
> threshold. If the threshold is set to 100%, then the LCA of ID 1 is D=3D9=
; if
> set it to 75%, then it is F=3D2. For ID 2 (100%, G=3D2; 75%, G=3D2; 50% H=
=3D3)
>
> While hash is good at allocating different instance easily, I don't know
> whether perl supports simple architecture to get the max/min. For the
> following code,
>
> @array
>
> For each row
> =A0 =A0 for ($i=3D0; $i<$numcol; $i++)
> =A0 =A0 =A0 =A0 $array[$i]{$key}++;
>
> if just for B, I know the following should be written in this way:
>
> foreach $key (keys %B) { =A0 =A0 $Bpertpot{$key} =3D $B{$key}/$total; =A0=
=A0}
>
> for ($i=3D0; $i<$numcol; $i++) {
> $maxcol[$i] =3D 0;
> foreach $key (keys %Bpertpot) { if ($Bpertpot{$key}> $maxcol[$i]) {
> $maxcol[$i] =3D $Bpertpot{$key}; =A0 =A0}
>
> }
>
> but then I don't know how to do that for array of hash to traverse... =A0=
i.e.
> replace the %B and %Bpertpot to something that is compatible with the arr=
ay
> structure... In fact, I wonder if there is already well-established modul=
es
> that may have handled this kind of max-min statistics problems that seem =
to
> encounter frequently in the business sector...
Have a look at List::Util which is a core module - it has max and
first
functions that you will find useful.
Any book on Perl will explain how to create and use a hash of arrays
or an
array of arrays.
------------------------------
Date: Mon, 14 Mar 2011 10:58:47 +0200
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: convenient module to take statistics for hashed structures?
Message-Id: <ilklas$qos$1@news.ntua.gr>
"ela" <ela@yantai.org> wrote in message
news:ilgvng$7ec$1@ijustice.itsc.cuhk.edu.hk...
> __DATA__
> ID B C D E F G H
> 1 3 7 9 3 4 2 3
> 1 3 7 9 3 4 2 2
> 1 3 7 9 5 8 6 6
> 1 3 7 9 3 4 2 3
> 2 4 7 9 3 4 2 1
> 2 4 7 9 3 4 2 2
> 2 4 7 9 3 4 2 3
> 2 4 7 9 3 4 2 3
>
> For each ID (the above example has two (1 and 2)), I want to identify the
> "last common
> ancestor: LCA, H being higher preference than B " based on some defined
> threshold. If the threshold is set to 100%, then the LCA of ID 1 is D=9;
> if set it to 75%, then it is F=2. For ID 2 (100%, G=2; 75%, G=2; 50% H=3)
>
> While hash is good at allocating different instance easily, I don't know
> whether perl supports simple architecture to get the max/min. For the
> following code,
>
> @array
>
> For each row
> for ($i=0; $i<$numcol; $i++)
> $array[$i]{$key}++;
>
>
> if just for B, I know the following should be written in this way:
>
> foreach $key (keys %B) { $Bpertpot{$key} = $B{$key}/$total; }
>
> for ($i=0; $i<$numcol; $i++) {
> $maxcol[$i] = 0;
> foreach $key (keys %Bpertpot) { if ($Bpertpot{$key}> $maxcol[$i]) {
> $maxcol[$i] = $Bpertpot{$key}; }
> }
>
> but then I don't know how to do that for array of hash to traverse...
> i.e.
> replace the %B and %Bpertpot to something that is compatible with the
> array
> structure... In fact, I wonder if there is already well-established
> modules
> that may have handled this kind of max-min statistics problems that seem
> to
> encounter frequently in the business sector...
>
>
>
set it to 75%, then it is F=2
I do not see any 2 at F column. I have problem to undestand what you
mean/what you want.
------------------------------
Date: Sun, 13 Mar 2011 12:59:15 +0300
From: Peter Vereshagin <peter@vereshagin.org>
Subject: DBD::mysql used to take octets into the utf8 texts but no more in mariadb
Message-Id: <20110313095914.GA14332@external.screwed.box>
Hello,
I had used DBD::mysql for ages with utf8 in mysql 4.1-5.1.
Now I go by with mariadb-5.2.
I notice the strange disappearing of the feature I implicitly used for years, and authors of very well established applications, e. g., bugzilla.org, webgui.org, etc. did, too.
In the past, the text columns ( including char columns ) allowed to insert the data from octet scalars, those without utf8 flag set.
Now it must be a blob column. Or, the variable should be utf8::decode'd, perhaps additionally checked before if it is utf8::valid.
Or any national character will be the question marks instead stored in a database.
There is a test, 55-utf8.t in a DBD::mysql distribution, that inserts and selects back, seperately the octet scalar in blob field, and utf8 scalar in text and varchar field.
This is why the lack of the feature is not noticed on make test.
But the applications I mentioned afore certainly use it. They insert octet perl variables into text and char type fields careless about utf8 flag should be set.
There are three kind authorities that have influence on this: DBD::mysql, mariadb, and authors of those applications.
Question is: whom I shall ask for a response for this?
- mariadb revealed this bug, but it may be not of their's in the C API. It can be because of DBD::mysql's XS.
- DBD::mysql was hiding this bug, but they stated clear in their test that octets should use blob-fields only. Despite I remember the times when mysql did no difference between text and blob fields.
- applications writers may need to rewrite their code taking care on utf8 flag before their scalar to fit the DBI placeholders. But it just may not sound real as there is too much of their too long spaghetti code.
As a workaround, I use the mysql_enable_utf8 attribute included into the dsn whet connect but authors of those apps don't do that in their code supposing that setting this as a dbh property later by the code runs is enough. But it doesn't dwim.
Thank you for any ideas about whom shall I ask about this.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
------------------------------
Date: Sun, 13 Mar 2011 17:51:56 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: DBD::mysql used to take octets into the utf8 texts but no more in mariadb
Message-Id: <4d7cf62c$0$41103$e4fe514c@news.xs4all.nl>
On 2011-03-13 10:59, Peter Vereshagin wrote:
> I had used DBD::mysql for ages with utf8 in mysql 4.1-5.1.
> Now I go by with mariadb-5.2.
> I notice the strange disappearing of the feature I implicitly used for years, and authors of very well established applications, e. g., bugzilla.org, webgui.org, etc. did, too.
> In the past, the text columns ( including char columns ) allowed to insert the data from octet scalars, those without utf8 flag set.
> Now it must be a blob column. Or, the variable should be utf8::decode'd, perhaps additionally checked before if it is utf8::valid.
> Or any national character will be the question marks instead stored in a database.
> There is a test, 55-utf8.t in a DBD::mysql distribution, that inserts and selects back, seperately the octet scalar in blob field, and utf8 scalar in text and varchar field.
> This is why the lack of the feature is not noticed on make test.
> But the applications I mentioned afore certainly use it. They insert octet perl variables into text and char type fields careless about utf8 flag should be set.
>
> There are three kind authorities that have influence on this: DBD::mysql, mariadb, and authors of those applications.
> Question is: whom I shall ask for a response for this?
> - mariadb revealed this bug, but it may be not of their's in the C API. It can be because of DBD::mysql's XS.
> - DBD::mysql was hiding this bug, but they stated clear in their test that octets should use blob-fields only. Despite I remember the times when mysql did no difference between text and blob fields.
> - applications writers may need to rewrite their code taking care on utf8 flag before their scalar to fit the DBI placeholders. But it just may not sound real as there is too much of their too long spaghetti code.
>
> As a workaround, I use the mysql_enable_utf8 attribute included into the dsn whet connect but authors of those apps don't do that in their code supposing that setting this as a dbh property later by the code runs is enough. But it doesn't dwim.
It could also just be that you had a C<SET NAME 'utf8'> done initially
for every session.
This is configurable on the host.
--
Ruud
------------------------------
Date: Mon, 14 Mar 2011 07:45:35 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: going from CPAN to RPM
Message-Id: <f5q058-63b.ln1@news.rtij.nl>
On Sun, 06 Mar 2011 21:28:20 -0500, Art Werschulz wrote:
> Hi.
>
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>
>> On Sun, 06 Mar 2011 11:01:54 -0500, Art Werschulz wrote:
>>
>>> Hi.
>>>
>>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>
>>>> On Redhat, packages installed via RPM generally reside in
>>>> vendor_perl, while packages installed via CPAN reside in site_perl.
>>>
>>> I'm not finding a vendor_perl subdirectory in /usr/lib/perl5.
>>
>> I do, both on CentOS (RHEL) and Fedora. Are you sure you're on (a)
>> RedHat (derivative)?
>
> I'm using Fedora 14.
> When I print the contents of @INC, I get
> /usr/local/lib/perl5
> /usr/local/share/perl5
> /usr/lib/perl5
> /usr/share/perl5
> /usr/lib/perl5
> /usr/share/perl5
> /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi
> /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi
> /usr/local/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl
> /usr/lib/perl5/site_perl
> But:
> $ ls /usr/lib/perl5/vendor_perl
> ls: cannot access /usr/lib/perl5/vendor_perl: No such file or
> directory
Funny,
When I do a "rpm -ql $(rpm -qa perl-*) | grep /usr/lib/perl5 | less" I
see the modules about 50/50 using /usr/lib/perl/5.10.0/ and /usr/lib/
perl5/vendor_perl/5.10.0/. So that is not reliable.
M4
------------------------------
Date: Sun, 13 Mar 2011 06:47:02 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Ok, simpler.....
Message-Id: <86tyf7b0a1.fsf@red.stonehenge.com>
>>>>> "ccc31807" == ccc31807 <cartercc@gmail.com> writes:
ccc31807> I say, "Build a man a fire and you warm him for an hour. Set him on
ccc31807> fire and you warm him for a lifetime."
That's not quite as funny unless you get the proper wording:
"Give a man a fire, and he's warm for an hour.
Set a man on fire, and he's warm for the rest of his life!"
Please leave the comedy to the professional next time... :)
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3318
***************************************
