[26196] in Perl-Users-Digest
Perl-Users Digest, Issue: 8385 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 2 18:05:58 2005
Date: Fri, 2 Sep 2005 15:05:05 -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 Fri, 2 Sep 2005 Volume: 10 Number: 8385
Today's topics:
Re: Can a Perl Programmer Pick up PHP quickly? axel@white-eagle.invalid.uk
Re: Can a Perl Programmer Pick up PHP quickly? <john@castleamber.com>
Re: Combining multiple hash references into one hash re <nomail@sorry.com>
Re: values of hash of hash <ngoc@yahoo.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 02 Sep 2005 18:27:05 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: Can a Perl Programmer Pick up PHP quickly?
Message-Id: <ZP0Se.742$ix3.534@fe1.news.blueyonder.co.uk>
Matija Papec <perl@my-header.org> wrote:
> X-Ftn-To: axel@white-eagle.invalid.uk
> axel@white-eagle.invalid.uk wrote:
>>> *sniggers* Only if you have little understanding of Perl and little
>>> understanding of PHP is required.
>>It really depends on what you want to do with it. If it just a
>>question of picking up some data from a database and displaying it
>>on a website, then it is very straight forward.
> It is, but you can soon find struggling with php if you want to do something
> more => http://tnx.nl/php
Thanks...an interesting webpage. I have no desire to do much
with PHP... I just have to sometimes, normally just connecting
with MySQL or Oracle... I need to pay my Amazon book bills :)
Axel
------------------------------
Date: 2 Sep 2005 20:58:01 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Can a Perl Programmer Pick up PHP quickly?
Message-Id: <Xns96C5A244D57ABcastleamber@130.133.1.4>
axel@white-eagle.invalid.uk wrote:
> John Bokma <john@castleamber.com> wrote:
>> Average_Joe <joe@pong.tunestar.net> wrote:
>
>>> You can probably pick up PHP just by sitting down with it for an
>>> evening.
>
>> *sniggers* Only if you have little understanding of Perl and little
>> understanding of PHP is required.
>
> It really depends on what you want to do with it. If it just a
> question of picking up some data from a database and displaying it
> on a website, then it is very straight forward.
Yup, little understanding of PHP. Although pěcking up some data leaves
enough room to create huge security issues.
--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
------------------------------
Date: Fri, 02 Sep 2005 12:18:10 -0700
From: Arvin Portlock <nomail@sorry.com>
Subject: Re: Combining multiple hash references into one hash reference
Message-Id: <dfa8ho$2nq9$1@agate.berkeley.edu>
xhoster@gmail.com wrote:
> >$hash1 and $hash2 do not go out of scope.
>
> Why not? As far as I can tell (and I admit to being a bit lost here, with
> all the non-trivial transtions from XML to hashes), once they are put into
> $newhash, they are no longer needed.
Let's see. On the face of it your are right. Once I've
collected my data I'll no longer refer directly to $hash1,
$hash2, etc. I want to keep it around merely to act as
the target of my references. The storehouse for my strings.
Sort of like:
$string = 'Long string I want to share throughout my program';
$stringref1 = \$string;
...
$stringref10000 = \$string;
I know even if $string goes out of scope the references
to it will remain, so I suppose it could go out of scope
at some point. I don't think it matters in the end, does
it? My whole point to this question is that I only want
one instance of this very long string with thousands of
references pointing to it. The problem is complicated be-
cause in fact it's not a single, simple string, but strings
packed into the values of a hash references. I only ever
want one instance of the actual values but with thousands
of references to them. PLUS I need to be able to access
them through their original hash keys.
> >BTW, the above was only an attempt to simplify the problem.
> >In reality of course I won't be naming my hashes %hash1,
> >%hash2, etc.
>
> I'm not sure that is the best choice for simplifying. $hash{1}{foo} and
> $hash{2}{foo} are not much more complicated than $hash1{foo} and
> $hash2{foo}, and they give valuable clues about the (simplified away)
> structure of the program.
The usual reason for using hashes over named variables. Don't
know how many there will be, etc. Could be only 5, could be 20.
> The key *is* what a hash element is referenced by, so the key of
> the element referenced by "id1" is "id1"!
Yes, that's exactly right. The key will always be that id value.
>foreach my $refelement (@bigarray) {
> print $refelement->{size}, "\n";
> print $refelement->{type}, "\n";
> }
>
> Where "size" and "type" are typical keys from
> among the original 20 or 30 elements (assuming
> <refelement ids="id1 id6 id21"/>, "size" may be
> a key from the element referenced by "id1",
> Do you mean that the literal
> string "size" might be the *value* of the element whose key is "id1"? Or
> do you mean that the size will be the value of the element referenced by
> the first component of the space-separated refelement? (which in this case
> happens to be id1, because id1 is the first component of "id1 id6 id21")
Heh, poor choice of example key names I guess. The elements
I am referencing are things like filenames, size of the file,
format of the file, the time it was created, the url where
it can be found... about 20 or 30 values in all. I'll rewrite
that example as:
foreach my $refelement (@bigarray) {
print $refelement->{key1}, "\n";
print $refelement->{key2}, "\n";
}
>
> >my $newhash = {};
> >foreach my $id (1, 6, 21) {
> > foreach my $key (keys %{$hashelements->{$id}}) {
> > $newhash->{$key} = \{$hashelements->{$id}->{$key}};
>
>
> You are creating an ref to an anonymous hash (by using curlies) then
> taking
> a reference to that (using backslash).
Yes, of course you are right. Thank you for pointing that out.
That didn't occur to me.
> So you get a reference to a scalar
> which holds a reference to a one-element hash. Try this:
>
> $newhash->{$key} = \($hashelements->{$id}->{$key});
>
> The parenthesis are not actually necessary, but in this case they make it
> easier to read correctly (at least for me).
With things like this I always get confused about when
parentheses are needed and when they are not. I think I'd
better retain the parentheses.
> >foreach my $key (keys %$newhash) {
> > print "$key: ", $newhash->{$key}, "\n";
>
> You need an extra dereference:
> print "$key: ", ${$newhash->{$key}}, "\n";
I was hoping for a simpler syntax and thought perhaps
there was some way to avoid the extra dollar dereferencer.
That may not be possible I suppose.
> You would be better
> off just copying it unless either a) You need a change made through
> $newhash to be reflected in the original structure, or b) the actual
> string
> is much much bigger than it's example of "Value 9" (which I suspose is not
> unlikely)
No, they'll never be changed. Yes, they're bigger than just
"Value 9". It won't take a huge amount of memory, I certainly
*could* get away with just making copies without a huge impact
on performance. Frankly, I just wanted to learn some new perl
tricks and hope to understand references better as a bonus.
Plus, coming from C++, all this deep copying seems distasteful
on general principle.
> But I still don't see why you want both $hashelements and $newhash to
> exist simultaneously. Unless you are doing something else with
> $hashelements which are you aren't showing us or telling us about
No nothing else. It could be $hashelements isn't necessary.
Just someplace to store the actual instances of the strings
which will be referenced elsewhere. But I'm open to all
suggestions.
> there is
> no need for it once $newhash is made. Which means you could dispense with
> $hashelements altogether, and change whatever is making $hashelements so
> that it just makes $newhash directly, instead.
But then each $newhash will have copies of the strings rather
than references.
You've been very helpful. Thanks for taking the time to
try and understand what I'm trying to do.
Arvin
>
>
>
>
>
> >Perhaps using "each" somehow is the answer. Can't quite get
> >that to work either though.
>
>
> Each doesn't address the root of what you are trying to do, but you could
> use it for a slight memory efficiency improvement. For example, replace
>
> foreach my $key (keys %$newhash) {
>
> with
>
> while (defined (my $key = each %$newhash)) {
>
> The first way makes a list which holds a copy of all the keys in
> %$newhash right up front. The second one copies the keys one at
> a time, as it goes through the hash, so that the memory for each
> key can be reused.
>
> Or you could use the list context "each". You have to change the print
> statement, too, so it isn't a drop-in replacement, but it does look better
> than what it replaces in this case:
>
> while (my ($key,$v) = each %$newhash) {
> print "$key: $$v\n";
> };
>
>
> Xho
>
------------------------------
Date: Fri, 02 Sep 2005 19:14:33 +0200
From: ngoc <ngoc@yahoo.com>
Subject: Re: values of hash of hash
Message-Id: <4318957e$1@news.broadpark.no>
Matija Papec wrote:
>
>>foreach (keys %unique_hash) {
>> foreach (keys %{$unique_hash{$_}}) {
>> foreach (keys %{$unique_hash{$_}{$_}}) {
>> $values = $unique_hash{$_}{$_}{$_};
>> }
>> }
>>}
>
>
> I guess this isn't your actual code as $_ can't be three different things at
> the time?
yes, I have changed a little bit. The original is "foreach my $proj_id
....." form.
and the name of 'unique_hash' is not used in my actual code. Because of
posting things in a forum reading by many people, I have to use easy
understanding words. And using publicly examples that are similar to my
actual problems.
> #...
>
> for my $k (keys %unique_hash) {
> my $values = $unique_hash{$k};
> }
>
> Suddenly, even five nested loops look better then this. :)
>
>
>>Looking back to my app. I use 3 for loop, in many places in my app. So I
>>have to change it, IF I WANT TO KEEP my job :-).
>
>
> Sounds like subroutine could replace your repeating code.
>
>
Thanks guys. I get much help from you, guys.
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 8385
***************************************
