[29634] in Perl-Users-Digest
Perl-Users Digest, Issue: 878 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 23 16:09:38 2007
Date: Sun, 23 Sep 2007 13: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 Sun, 23 Sep 2007 Volume: 11 Number: 878
Today's topics:
Latest software downloads!!!!! freesoftwareweb@gmail.com
Re: Latest software downloads!!!!! <jwkizer@yahoo.com>
Re: List Variable becomes undefined inexplicably <nobull67@gmail.com>
Re: need help in solving error in perl <nobull67@gmail.com>
Re: perlipc bidirectional unix domain socket <nobull67@gmail.com>
Re: perlipc bidirectional unix domain socket <mjp-nntp@pilcrow.madison.wi.us>
Re: perlipc bidirectional unix domain socket <elvis-85363@notatla.org.uk>
Travel around the globe... travelingwebs1@gmail.com
Re: why do these snippets have different behavior? <nobull67@gmail.com>
Re: why do these snippets have different behavior? <please_no_more@spam.net>
Re: why do these snippets have different behavior? <bill@ts1000.us>
Re: why do these snippets have different behavior? <abigail@abigail.be>
Re: why do these snippets have different behavior? <abigail@abigail.be>
Re: why do these snippets have different behavior? <please_no_more@spam.net>
Re: why do these snippets have different behavior? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 23 Sep 2007 19:44:30 -0000
From: freesoftwareweb@gmail.com
Subject: Latest software downloads!!!!!
Message-Id: <1190576670.540724.150710@50g2000hsm.googlegroups.com>
http://freesoftwareupgrades.blogspot.com/
------------------------------
Date: Sun, 23 Sep 2007 15:50:03 -0400
From: "Killfile Victim #847238" <jwkizer@yahoo.com>
Subject: Re: Latest software downloads!!!!!
Message-Id: <ArzJi.241$ua4.43@newssvr22.news.prodigy.net>
I don't need your free software. I have my own personal Geek. TYVM.
--
Your winner... and NEW Wal*Mart Hot Dog Eating Champion
<freesoftwareweb@gmail.com> wrote in message
news:1190576670.540724.150710@50g2000hsm.googlegroups.com...
> http://freesoftwareupgrades.blogspot.com/
>
------------------------------
Date: Sun, 23 Sep 2007 03:59:31 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: List Variable becomes undefined inexplicably
Message-Id: <1190545171.813445.84500@d55g2000hsg.googlegroups.com>
On 20 Sep, 17:54, Brian McCauley <nobul...@gmail.com> wrote:
> Do not be temped to do local($_)
But, I should add, in 5.10 you can do my($_)
------------------------------
Date: Sun, 23 Sep 2007 04:10:43 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: need help in solving error in perl
Message-Id: <1190545843.044526.117630@w3g2000hsg.googlegroups.com>
On 23 Sep, 07:19, fenilkumar.golw...@wipro.com wrote:
> Subject: need help in solving error in perl
Please put the subject of your post in the Subject of your post.
If you are in doubt about that this means then please try this simple
test. Imagine you had done a search before you posted. Then imagine
that your subject line came up in the list of hits. Would you have
been able to guess with any degree of certainly that it was the same
question? If the answer is no then your subject line is not good
enough.
> I have written a perl script ,but while trying to run that i am
> facing the below error,please can someone help me with it.
>
> Error:-
>
> install_driver(Sybase) failed: Can't load '/sbcimp/run/pkgs/CORE/
> 12.6.0/links/cpan/lib/auto/DBD/Sybase/Sybase.so' for module
> DBD::Sybase: ld.so.1: aact_main_control.pl: fatal: relocation error:
> file /sbcimp/run/pkgs/CORE/12.6.0/links/cpan/lib/auto/DBD/Sybase/
> Sybase.so: symbol PL_memory_wrap: referenced symbol not found at /
> sbcimp/run/pd/perl/5.8.3/lib/DynaLoader.pm line 229, <PROFILE> line
> 21.
So a good subject line would have been "referenced symbol not found
loading DBD::Sybase".
This most likely means that DBD::Sybase was compiled against a
different build of Perl. Looking at the paths in your error I'm
guessing you downloaded binary packages of Perl and of DBD::Sybase
from different sources and they are not compatible.
If you don't want to download and build from sources you should speak
to the maintainer of the binary package library that you are using.
------------------------------
Date: Sun, 23 Sep 2007 04:31:28 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: perlipc bidirectional unix domain socket
Message-Id: <1190547088.951585.125460@n39g2000hsh.googlegroups.com>
On 22 Sep, 14:47, all mail refused <elvis-85...@notatla.org.uk> wrote:
> socket(SOCK, PF_UNIX, SOCK_STREAM, 0) or die();
> connect(SOCK, sockaddr_un($rendezvous)) or die();
> printf(SOCK "Request something\n");
> shutdown(SOCK,1); # finished writing
I may be off-base here but ISTR that (at least in some older versions
of Perl) you had to explicitly set SOCK to be autoflushed (or
explicitly flush the buffers) when using the low-level socket
operations rather than IO::Socket.
------------------------------
Date: Sun, 23 Sep 2007 14:25:49 GMT
From: Mike Pomraning <mjp-nntp@pilcrow.madison.wi.us>
Subject: Re: perlipc bidirectional unix domain socket
Message-Id: <NHuJi.38667$G23.34405@newsreading01.news.tds.net>
Brian McCauley wrote:
> On 22 Sep, 14:47, all mail refused <elvis-85...@notatla.org.uk> wrote:
>> socket(SOCK, PF_UNIX, SOCK_STREAM, 0) or die();
>> connect(SOCK, sockaddr_un($rendezvous)) or die();
>> printf(SOCK "Request something\n");
>> shutdown(SOCK,1); # finished writing
>
> I may be off-base here but ISTR that (at least in some older versions
> of Perl) you had to explicitly set SOCK to be autoflushed (or
> explicitly flush the buffers) when using the low-level socket
> operations rather than IO::Socket.
That's right. Given the OP's clarification of problem, autoflush is the
issue -- the client doesn't write until after it's read from the server,
and, indeed, the write fails anyway since shutdown has already been
called, leaving the server with EOF.
Something like this:
...
connect(SOCK, sockaddr_un($rendezvous)) or die();
$| = 1, select $_ for select SOCK;
printf(SOCK "Request something\n");
...
does the trick. ``perldoc -q flush'' has other $! idioms, and of course
IO::Socket objects offer ->autoflush().
-Mike
------------------------------
Date: 23 Sep 2007 15:11:38 GMT
From: all mail refused <elvis-85363@notatla.org.uk>
Subject: Re: perlipc bidirectional unix domain socket
Message-Id: <slrnffcvrr.lmk.elvis-85363@notatla.org.uk>
On 2007-09-23, Mike Pomraning <mjp-nntp@pilcrow.madison.wi.us> wrote:
>> I may be off-base here but ISTR that (at least in some older versions
>> of Perl) you had to explicitly set SOCK to be autoflushed (or
>
> That's right. Given the OP's clarification of problem, autoflush is the
> issue -- the client doesn't write until after it's read from the server,
> and, indeed, the write fails anyway since shutdown has already been
> called, leaving the server with EOF.
>
> Something like this:
> ...
> connect(SOCK, sockaddr_un($rendezvous)) or die();
> $| = 1, select $_ for select SOCK;
> printf(SOCK "Request something\n");
> ...
>
> does the trick. ``perldoc -q flush'' has other $! idioms, and of course
> IO::Socket objects offer ->autoflush().
Thanks a lot everybody. I'd imagined that shutdown() forced flushing of
the stream up to that point but obviously not.
--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
------------------------------
Date: Sun, 23 Sep 2007 12:35:34 -0700
From: travelingwebs1@gmail.com
Subject: Travel around the globe...
Message-Id: <1190576134.741786.259920@k79g2000hse.googlegroups.com>
http://world-traveling-destinations.blogspot.com/
------------------------------
Date: Sun, 23 Sep 2007 04:34:22 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: why do these snippets have different behavior?
Message-Id: <1190547262.116073.217240@w3g2000hsg.googlegroups.com>
On 23 Sep, 00:14, Ben Morrow <b...@morrow.me.uk> wrote:
> 5.10 will warn,
> Deprecated use of my() in false conditional
About $EXPLETIVE time!
------------------------------
Date: Sun, 23 Sep 2007 09:38:00 -0400
From: "Chris M." <please_no_more@spam.net>
Subject: Re: why do these snippets have different behavior?
Message-Id: <S8SdnR9MH5TT8WvbnZ2dnUVZ_ternZ2d@comcast.com>
"Bill H" <bill@ts1000.us> wrote in message
news:1190485710.111722.6330@y42g2000hsy.googlegroups.com...
> On Sep 22, 7:31 am, "Chris M." <please_no_m...@spam.net> wrote:
>> The following two versions don't have the same effect:
>>
>> # 2-LINE VERSION; this way works as expected
>> my $v;
>> $v = "hello" if 0;
>>
>> # 1-LINE VERSION; this way does not work as expected (imho)
>> my $v = "hello" if 0;
>>
>> Example Program:
>>
>> for my $i (1 .. 3) {
>> my $v = "hello" if 0;
>> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>> $v = "bye";
>>
>> }
>>
>> Sample Output:
>>
>> v somehow defined: 'bye', i = '2'
>> v somehow defined: 'bye', i = '3'
>>
>> When the 2-line snippet is used instead, the program produces no output,
>> as
>> I was expecting.
>>
>> It's as if not only the assignment (i.e. '= "hello"') part of the line is
>> subject to the conditional clause (false in this case), but also the
>> declaration (i.e. 'my') part of the line, too. Hence, the variable is
>> not
>> re-declared each iteration, but retains its previous value. But if that
>> were truly the case, then it seems to me Perl should complain when $v is
>> assigned to "bye" since the variable was never declared (I have both
>> 'strict' and 'warnings' on) which it doesn't. Although I suppose the
>> interpreter can't evaluate the conditional clause until runtime (even
>> though
>> in this case the condition is static); maybe that's why?
>>
>> Anyone else bothered by this behavior? This seems like a nasty feature.
>> Took me quite awhile before I realized some of my for-loop iterations
>> were
>> interfering with each other...
>>
>> Thanks,
>> Chris
>
> Curious - what is the benefit of putting the if at the end of the
> line?
>
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> versus
>
> if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> Bill H
I guess I would feel obligated to split the 'if' clause across 3 lines to
maintain coding style consistency,
which seems like a pain for such a small clause. :)
if (defined $v) {
print "v somehow defined: '$v', i = '$i'\n";
}
Whereas the end-of-line conditional check seems to lend itself nicely to a
1-line coding style.
And the off-chance that you do trip up one of your fellow programmers is
simply one more reason to use it... :)
Chris
------------------------------
Date: Sun, 23 Sep 2007 06:51:30 -0700
From: Bill H <bill@ts1000.us>
Subject: Re: why do these snippets have different behavior?
Message-Id: <1190555490.134584.76190@r29g2000hsg.googlegroups.com>
On Sep 22, 10:26 pm, "Petr Vileta" <sto...@practisoft.cz> wrote:
> Bill H wrote:
> > Curious - what is the benefit of putting the if at the end of the
> > line?
>
> > print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> > versus
>
> > if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> The benefit can be in better look only. I use both syntax, case to case
> basis. Please compare this:
>
> print "abc";
> print "def";
> print "HUH" unless defined $huh;
> print "ghi";
>
> print "abc";
> print "def";
> unless(defined $huh) {print "HUH";}
> print "ghi";
>
> In this case the primary job is to print something and only one case is
> conditional. And in first example I spared 3 characters compared to second
> example :-)
>
> --
>
> Petr Vileta, Czech republic
> (My server rejects all messages from Yahoo and Hotmail. Send me your mail
> from another non-spammer site please.)
It would seem if you start with the "if" it would parse faster than if
you end with it. Since, from what I read, perl compiles your code when
you run it, it would seem to be easier on the compiler to know ahead
of time that the following lines are conditional, instead of compiling
the line and then finding out it is conditional. For example:
if (2 == 3){print "Never print this line\n";}
would never get compiled (I would assume), but
print "Never print this line\n" if 2 == 3;
would get compiled and then thrown away when it reached the if
statement. I know this is non-sense code but it illustrates an extreme
example.
If I'm wrong, let me know.
Bill H
------------------------------
Date: 23 Sep 2007 13:51:56 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: why do these snippets have different behavior?
Message-Id: <slrnffcrq9.8no.abigail@alexandra.abigail.be>
_
Chris M. (please_no_more@spam.net) wrote on VCXXXV September MCMXCIII in
<URL:news:6vmdnUxFIKeEYGnbnZ2dnUVZ_v6rnZ2d@comcast.com>:
^^ The following two versions don't have the same effect:
^^
^^ # 2-LINE VERSION; this way works as expected
^^ my $v;
^^ $v = "hello" if 0;
^^
^^ # 1-LINE VERSION; this way does not work as expected (imho)
^^ my $v = "hello" if 0;
^^
^^ Example Program:
^^
^^ for my $i (1 .. 3) {
^^ my $v = "hello" if 0;
^^ print "v somehow defined: '$v', i = '$i'\n" if defined $v;
^^ $v = "bye";
^^ }
^^
^^ Sample Output:
^^
^^ v somehow defined: 'bye', i = '2'
^^ v somehow defined: 'bye', i = '3'
^^
^^
^^ When the 2-line snippet is used instead, the program produces no output, as
^^ I was expecting.
^^
^^ It's as if not only the assignment (i.e. '= "hello"') part of the line is
^^ subject to the conditional clause (false in this case), but also the
^^ declaration (i.e. 'my') part of the line, too. Hence, the variable is not
^^ re-declared each iteration, but retains its previous value. But if that
^^ were truly the case, then it seems to me Perl should complain when $v is
^^ assigned to "bye" since the variable was never declared (I have both
^^ 'strict' and 'warnings' on) which it doesn't. Although I suppose the
^^ interpreter can't evaluate the conditional clause until runtime (even though
^^ in this case the condition is static); maybe that's why?
"my" has two effects: one at compile time (telling the compiler you're going
to use a variable with such-and-such a name), and one at runtime: it sets
the value of said variable ('undef', unless assigned to).
Considering that the run time effect doesn't happen (due to the 'if 0' part),
and that Perl will reuse the variable (you would have gotten a different
result if you entered the block by recursion instead of a loop), you're
getting what you observed.
^^ Anyone else bothered by this behavior? This seems like a nasty feature.
It's a feature that was used to create "state" variables; variable that
won't be initialized each time a loop has entered. Before calling it a
nasty feature, ask yourself 'why do I write my $v = "hello" if 0' in the
first place? What did you think it should have done instead?
^^ Took me quite awhile before I realized some of my for-loop iterations were
^^ interfering with each other...
Anyway, in perl 5.10, 'my $v = "hello" if 0' will trigger a warning.
And 5.10 will have not only have local(), our(), and my(), but also state(),
to declare state variables.
It will probably not do what you did with 'my $v = "hello" if 0', but
that's because I don't know why you wrote it in the first place.
Abigail
--
A perl rose: perl -e '@}>-`-,-`-%-'
------------------------------
Date: 23 Sep 2007 13:53:40 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: why do these snippets have different behavior?
Message-Id: <slrnffcrti.8no.abigail@alexandra.abigail.be>
_
Bill H (bill@ts1000.us) wrote on VCXXXV September MCMXCIII in
<URL:news:1190485710.111722.6330@y42g2000hsy.googlegroups.com>:
::
:: Curious - what is the benefit of putting the if at the end of the
:: line?
Why does it have to have a benefit?
:: print "v somehow defined: '$v', i = '$i'\n" if defined $v;
::
:: versus
::
:: if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
What's the benefit of putting the print inside a different scope?
Abigail
--
:;$:=~s:
-:;another Perl Hacker
:;chop
$:;$:=~y
:;::d;print+Just.
$:;
------------------------------
Date: Sun, 23 Sep 2007 10:23:48 -0400
From: "Chris M." <please_no_more@spam.net>
Subject: Re: why do these snippets have different behavior?
Message-Id: <s-udncmb7dCa6mvbnZ2dnUVZ_oaonZ2d@comcast.com>
"Ben Morrow" <ben@morrow.me.uk> wrote in message
news:98kgs4-e97.ln1@osiris.mauzo.dyndns.org...
>
> Quoth "Chris M." <please_no_more@spam.net>:
>> The following two versions don't have the same effect:
>>
>> # 2-LINE VERSION; this way works as expected
>> my $v;
>> $v = "hello" if 0;
>>
>> # 1-LINE VERSION; this way does not work as expected (imho)
>> my $v = "hello" if 0;
>
> This has been a known, though undocumented, way of implementing an
> equivalent to C's 'static' variables for a long time. The official
> position from the perldocs is that the behaviour is undefined. 5.10 will
> have 'state' variables, which give explicit and documented access to
> equivalent behaviour.
>
>> When the 2-line snippet is used instead, the program produces no output,
>> as
>> I was expecting.
>
> The second statement is of course completely irrelevant, and is in fact
> optimized away:
>
> ~% perl -MO=Deparse -e'my $x; $x = 2 if 0;'
> my $x;
> '???';
> -e syntax OK
> ~%
>
> ('???'; from Deparse means 'there used to be a statement here, but it
> got optimized away so I don't know what it said').
>
>> It's as if not only the assignment (i.e. '= "hello"') part of the line is
>> subject to the conditional clause (false in this case), but also the
>> declaration (i.e. 'my') part of the line, too.
>
> This is not quite what happens. 'my' has both run-time and compile-time
> effects: at compile time, it causes a new variable to be declared; this
> happens anyway. At runtime, it causes that variable to be reinitialized;
> this part was accidentally made subject to the 'if 0'. Strictly
> speaking, it's a bug in perl. But some clever people found out about it
> and started depending on it, so it probably can't be fixed for a while
> yet; hence the 'undefined' in the perldocs. As a rule, statements of the
> form
>
> my ... if ...;
>
> or similar should be avoided.
>
>> Hence, the variable is not re-declared each iteration, but retains its
>> previous value. But if that were truly the case, then it seems to me
>> Perl should complain when $v is assigned to "bye" since the variable
>> was never declared (I have both 'strict' and 'warnings' on) which it
>> doesn't. Although I suppose the interpreter can't evaluate the
>> conditional clause until runtime (even though in this case the
>> condition is static); maybe that's why?
>
> Yes. The declaration happens at compile-time, so is unaffected by the
> conditional. If the condition is known at compile-time, the whole
> runtime effect of 'my' is optimized away, and Deparse gets so confused
> it emits code that doesn't compile:
>
> ~% perl -MO=Deparse -Mstrict -e'my $x if 0; print $x'
> use strict 'refs';
> '???';
> print $x;
> -e syntax OK
>
>> Anyone else bothered by this behavior? This seems like a nasty feature.
>
> 5.10 will warn, since the desired behaviour now has a proper syntax:
>
> ~% perl-current -we'my $x if 0;'
> Deprecated use of my() in false conditional at -e line 1.
> ~%
>
>> Took me quite awhile before I realized some of my for-loop iterations
>> were
>> interfering with each other...
>
> What did you hope to achieve with that syntax anyway? Or did you simply
> not realize you were attempting to make a 'my' conditional?
>
> Ben
Thanks for all the info. I had hoped that I was doing the same thing as the
2-line version: initializing a variable whose value would be undef by
default or some valid value if a condition were met. A more realistic
context I had recently fallen into the habit of using it in:
my $val = $hash_ref->{some_key} if exists $hash_ref->{some_key};
I used to code this as:
my $val = (exists $hash_ref->{some_key} ? $hash_ref->{some_key} : undef);
But as my hashes tend to be multiple levels deep, this led to long lines
that were sometimes awkward to split. The post-conditional line seemed much
more natural to split when needed:
my $val =
$hash_ref->{sub_hash1}{sub_hash2}{sub_hash3}{sub_hash4}{sub_hash5}{some_key}
if exists
$hash_ref->{sub_hash1}{sub_hash2}{sub_hash3}{sub_hash4}{sub_hash5}{some_key};
Hence my for-loop headaches...
Lesson learned.
--Chris
------------------------------
Date: Sun, 23 Sep 2007 18:59:31 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: why do these snippets have different behavior?
Message-Id: <35mis4-6f3.ln1@osiris.mauzo.dyndns.org>
Quoth Bill H <bill@ts1000.us>:
>
> It would seem if you start with the "if" it would parse faster than if
> you end with it. Since, from what I read, perl compiles your code when
> you run it, it would seem to be easier on the compiler to know ahead
> of time that the following lines are conditional, instead of compiling
> the line and then finding out it is conditional. For example:
>
> if (2 == 3){print "Never print this line\n";}
>
> would never get compiled (I would assume), but
>
> print "Never print this line\n" if 2 == 3;
>
> would get compiled and then thrown away when it reached the if
> statement. I know this is non-sense code but it illustrates an extreme
> example.
>
> If I'm wrong, let me know.
You are wrong. Not only are you completely wrong in detail (the two
compile to almost exactly the same code, the only difference being that
the first has a new scope for the body of the if, and in both cases, the
whole lot is compiled and the dead branch dropped by the optimizer
later) but this is a completely stupid direction to approach the problem
from. The only sensible question is which is more readable.
Ben
------------------------------
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 V11 Issue 878
**************************************
