[23308] in Perl-Users-Digest
Perl-Users Digest, Issue: 5528 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 19 14:08:02 2003
Date: Fri, 19 Sep 2003 11:05:13 -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, 19 Sep 2003 Volume: 10 Number: 5528
Today's topics:
A (probable) error in perltoot ( perl5/5.8.0/pod/perlt (Himanshu Garg)
Cgi.pm process POST & GET <matt@userve.net>
Re: Cgi.pm process POST & GET <thepoet@nexgo.de>
Re: How can I comment out a large block of perl code? <hrg@sama.ru>
Re: Intermediate Page w/ CGI Script <flavell@ph.gla.ac.uk>
Re: Intermediate Page w/ CGI Script <flavell@ph.gla.ac.uk>
Re: list-parsing problem <uri@stemsystems.com>
Re: list-parsing problem (Tad McClellan)
Re: Little survey for Unix users (Chris Marshall)
Re: Little survey for Unix users <shemond@hotmail.com>
Re: Little survey for Unix users <emschwar@pobox.com>
Re: Little survey for Unix users <emschwar@pobox.com>
Re: Little survey for Unix users <flavell@ph.gla.ac.uk>
Re: locale games - looking for portable ways to get a l <billy@arnis-bsl.com>
Re: Opening file units recursively (Anno Siegel)
Re: Order of evaluation of expressions <nospam-abuse@ilyaz.org>
Re: Outlook Address Books and Perl? (John M. Gamble)
Perl regular expression does not work on 5.8.0 <stefan.rupp@inform-ac.com>
Re: Perl regular expression does not work on 5.8.0 <thepoet@nexgo.de>
Re: referencing, closures, classes <x12code-del@del-yahoo.com>
Re: referencing, closures, classes <emschwar@pobox.com>
Re: referencing, closures, classes <usenet@dwall.fastmail.fm>
Re: referencing, closures, classes <uri@stemsystems.com>
regexp help - match on two backslashes (Daniel Ems)
Re: regexp help - match on two backslashes <shondell@cis.ohio-state.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 19 Sep 2003 04:03:06 -0700
From: himanshu@gdit.iiit.net (Himanshu Garg)
Subject: A (probable) error in perltoot ( perl5/5.8.0/pod/perltoot.pod, line number 756 )
Message-Id: <a46e54c7.0309190303.2dae7886@posting.google.com>
Dear Perl Programmers,
I tried out the code given in :-
http://www.perldoc.com/perl5.8.0/pod/perltoot.html#Aggregation
The following line :-
printf "%s is really %s.\n", $him->name, $him->fullname;
gives the following output :-
Tommy is really Fullname=HASH(0x804c9b8).
This happens because fullname returns an object reference as follows :-
sub fullname
{
my $self = shift;
return $self->{FULLNAME};
}
Therefore the line should probably be :-
printf "%s is really %s.\n", $him->name, $him->fullname->as_string;
Please correct me if I am wrong.
Thank You
Himanshu.
------------------------------
Date: Fri, 19 Sep 2003 14:13:10 +0100
From: "Matt Churchyard" <matt@userve.net>
Subject: Cgi.pm process POST & GET
Message-Id: <3f6af7c9$1@news.userve.net>
Hello,
I am writing an application which passes a session id
around on the querystring. This works fine until I submit
a form, at which point the current session is dropped and a
new one is created.
I presume this is because CGI.pm only processes the POST data
and not the query string when its gets a POST request. Is there any
way of forcing CGI.pm to always process the query string?.
--
Thanks,
Matt
------------------------------
Date: Fri, 19 Sep 2003 15:49:36 +0200
From: "Christian Winter" <thepoet@nexgo.de>
Subject: Re: Cgi.pm process POST & GET
Message-Id: <3f6b0970$0$23095$9b4e6d93@newsread2.arcor-online.net>
"Matt Churchyard" <matt@userve.net> wrote:
[...]
> I presume this is because CGI.pm only processes the POST data
> and not the query string when its gets a POST request. Is there any
> way of forcing CGI.pm to always process the query string?.
"perldoc CGI" explains how to do that, it's under the
headline "MIXING POST AND URL PARAMETERS". The
short answer is: use url_param() instead of param()
to read the parameters given via GET in a mixed
request. But plz read the docs as well :)
HTH
-Christian
------------------------------
Date: Fri, 19 Sep 2003 15:24:20 +0500
From: "Yury Kopyl" <hrg@sama.ru>
Subject: Re: How can I comment out a large block of perl code?
Message-Id: <bkel3l$4cf$1@berg.samara.net>
Dan Jacobson -> "How can I comment out a large block of perl code?" :
DJ> $ perldoc -q 'How can I comment out a large block of perl code?'
DJ> says to use =begin comment text, =end comment text, but I find the
DJ> =end comment text does not stop the comment, printing only "1":
DJ> print 1;
DJ> =begin comment text
DJ> all of this stuff
DJ> here will be ignored by everyone
DJ> =end comment text
DJ> print 2;
DJ> Wait, he meant to say use a =cut instead of =end comment text!
I use next construction:
=rem
bla-bla-bla
=cut
Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Nemiroff ?????]
------------------------------
Date: Fri, 19 Sep 2003 10:48:52 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Intermediate Page w/ CGI Script
Message-Id: <Pine.LNX.4.53.0309191046290.3762@ppepc56.ph.gla.ac.uk>
On Thu, 18 Sep 2003, Glenn Jackman wrote:
> If your web server supports it, use a non-parsed headers script
If this was a web servers configuration or CGI group, I would tell you
that Apache doesn't demand the complication of using NPH scripts in
order to support incremental output.
But as it isn't, I suppose I'd better not :-}
--
(apologies if yesterday's attempt to post this does finally show up)
------------------------------
Date: Fri, 19 Sep 2003 10:56:08 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Intermediate Page w/ CGI Script
Message-Id: <Pine.LNX.4.53.0309191049450.3762@ppepc56.ph.gla.ac.uk>
On Thu, 18 Sep 2003, Pete Butler wrote:
> I'm working on a CGI application using Perl. My client would like the
> user to get some sort of "processing request" page immediately upon
> clicking "Submit", because right now, he occasionally sees a delay
> between clicking "Submit" and getting the results page. Is there a
> good way to do this with CGI?
No different in Perl than in any other CGI programming language, and
a requirement typically addressed in CGI FAQs and discussed on CGI
programming group(s). What did you think of the previously-discussed
solutions that you found while researching the topic prior to deciding
to post a question? [hint!]
> And, of course, both options above require me to fire off a CGI script
> in the first place. Since I suspect that the performance issues
> driving my client's request are caused by starting CGI scripts when
> the server is under load,
You haven't told us whether the wait is typically 5 seconds or 5
minutes or what. Different solutions might be applicable.
> I suspect we'd go from this scenario:
>
> -Press Submit
> -Wait wait wait
> -See results page
>
> To this one:
>
> -Press Submit
> -Wait wait wait
> -See "please wait" page
> -Wait wait wait
> -See results page
Yup, that's very perceptive. The startup overhead might be a
significant part of the whole processing (you haven't told us enough
to be sure).
> Is there a solution here I'm overlooking?
Researching FAQs and previous discussions? :-{
> (Short of using mod_perl or fastcgi to improve performance, which
> aren't available to me. Or switching to PHP; it's too late in the
> game for me to re-write everything from the ground up.)
Sometimes, when you rule out all the applicable technical solutions,
you are left with the original problem - as we can see.
<announcement mode=public-service>
In case you hadn't noticed, CGI questions aren't generally welcomed
here (c.l.p.misc) unless they have some specifically Perl content -
and that's irrespective of whether you're programming them _in_ Perl.
perlfaq9 has further pointers.
</>
cheers
------------------------------
Date: Fri, 19 Sep 2003 13:19:12 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: list-parsing problem
Message-Id: <x7oexgrk4w.fsf@mail.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:
AS> undef $coll{ $first}->{ $second}; # undef brings the key
>> i will have to copy that for some future talk at yapc: "where to not use
>> undef"
AS> I hope you'll acknowledge my contribution. Oh, wait... should I
AS> patent it?
will the euro laws allow it?
AS> I may be lacking in esthetic sensibility, but how is it uglier
AS> than "$coll{ $first}->{ $second} = undedf"? What do you use when
AS> you want a key but no value? I don't know a satisfactory idiom.
why do you need no value here? i would assign 1 so you don't need to use
exists. only when i can assign () and create a bunch of keys (with a
slice) do i generate keys with no values.
as an aside, i dislike undef as a function in general. it leads to undef
@array which leads to defined @array which is dead wrong. i only use
undef for a value generator and never as a function.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Class in Boston - Sept 2003 -- http://www.stemsystems.com/class
------------------------------
Date: Fri, 19 Sep 2003 09:21:13 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: list-parsing problem
Message-Id: <slrnbmm46p.fuq.tadmc@magna.augustmail.com>
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> I hope you'll acknowledge my contribution. Oh, wait... should I patent it?
That's no way to get ahead.
You should release it under the viral GPL as well as sell it yourself
for a period long enough for its use to become widespread.
Then you should leave the software business and convert to
the lawsuit business.
Then you should sue not only the companies that distributed it, but
also every user that has installed it.
Then everybody will love you and your stock price will go up.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 19 Sep 2003 03:20:55 -0700
From: c_j_marshall@hotmail.com (Chris Marshall)
Subject: Re: Little survey for Unix users
Message-Id: <cb9c7b76.0309190220.a2526af@posting.google.com>
Abigail <abigail@abigail.nl> wrote in message news:<slrnbmlaea.esh.abigail@alexandra.abigail.nl>...
> Steve Hémond (shemond@hotmail.com) wrote on MMMDCLXX September MCMXCIII
> in <URL:news:_muab.9341$hF3.1237617@news20.bellglobal.com>:
> -- I'm not willing to start a religious war, but, what is your prefered editor
> -- for works such as Perl programming? (Vi(m) or Emacs?)
>
>
> Real (wo)men use 'cat'. Wussies use 'ed'. Vi and Emacs are for poofs.
>
>
>
Reminds me of a userfriendly strip:
http://ars.userfriendly.org/cartoons/?id=19990508
------------------------------
Date: Fri, 19 Sep 2003 03:43:55 -0400
From: Steve =?ISO-8859-1?Q?H=E9mond?= <shemond@hotmail.com>
Subject: Re: Little survey for Unix users
Message-Id: <dZBab.7941$BT1.408723@news20.bellglobal.com>
David H. Adler wrote:
> In article <slrnbml6hi.efm.tadmc@magna.augustmail.com>, Tad McClellan
> wrote:
>> Steve Hémond <shemond@hotmail.com> wrote:
>>
>>> what is your prefered editor
>>> for works such as Perl programming? (Vi(m) or Emacs?)
>>
>>
>> Yes.
>
> First of all, I'm with Tad on this one.
>
> Secondly, this isn't on topic.
>
> Let's not start yet another huge thread on preferred editors, ok?
>
> Thanks
>
> dha
>
lol, that's what I thought, sorry!! :-)
------------------------------
Date: Fri, 19 Sep 2003 11:00:04 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Little survey for Unix users
Message-Id: <etovfropvcb.fsf@wormtongue.emschwar>
tadmc@augustmail.com (Tad McClellan) writes:
> Steve Hémond <shemond@hotmail.com> wrote:
>> what is your prefered editor
>> for works such as Perl programming? (Vi(m) or Emacs?)
>
> Yes.
Only sometimes.
-=Eric (ed is the STANDARD EDITOR!!!!!)
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: Fri, 19 Sep 2003 11:01:04 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Little survey for Unix users
Message-Id: <etor82cpvan.fsf@wormtongue.emschwar>
Abigail <abigail@abigail.nl> writes:
> Real (wo)men use 'cat'. Wussies use 'ed'. Vi and Emacs are for poofs.
Luuuxury! Real (Wo)Men use 'dd'. l4m3rz use 'cat'. The rest
continues as you say.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: Fri, 19 Sep 2003 18:44:16 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Little survey for Unix users
Message-Id: <Pine.LNX.4.53.0309191838540.4262@ppepc56.ph.gla.ac.uk>
On Fri, 19 Sep 2003, Eric Schwartz wrote:
> -=Eric (ed is the STANDARD EDITOR!!!!!)
We have a user who still uses EDT, or rather, an emulation of EDT in
vi which he got from somewhere to ease the transition from VAX/VMS to
Ultrix, and that was about 2 OSes back. Which only goes to prove the
point that editors are a very personal thing and not worth
flamefesting over.
ttfn
------------------------------
Date: Fri, 19 Sep 2003 18:27:57 +0300
From: Ilja Tabachnik <billy@arnis-bsl.com>
Subject: Re: locale games - looking for portable ways to get a list of valid locales
Message-Id: <bkf79u$15c5m$1@ID-33095.news.uni-berlin.de>
Joseph Brenner wrote:
...
>
> So I would *think* that what I need is some way of getting a list of
> valid locales, and I don't see any way of doing that out on CPAN.
...
IMHO, the portable way (for Unix-like systems) is just to use
the locale(1) command, say @all_locales = `locale -a`.
The locale(1) and it's '-a' switch is defined in SUSv2 (and 3 ?)
HTH
Ilja.
------------------------------
Date: 19 Sep 2003 10:19:26 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Opening file units recursively
Message-Id: <bkel7e$k4k$1@mamenchi.zrz.TU-Berlin.DE>
John Ramsden <john_ramsden@sagitta-ps.com> wrote in comp.lang.perl.misc:
> john_ramsden@sagitta-ps.com (John Ramsden) wrote in message
> news:<d27434e.0309180412.76bea366@posting.google.com>...
> >
> > I have an application that reads a list of pathnames, and the
> > list can contain "include" lines each of which specifies the
> > path of a file to go off and process, just like recursive C
> > includes.
>
> Many thanks for the replies, which mentioned several interesting
> points that I'll investigate.
>
> On digging around the web shortly after posting I came across
> http://www.stonehenge.com/merlyn/UnixReview/col19.html, which
> explains the use of IO::File to do exactly the what I described.
> (I would have mentioned this earlier, but Google delays several
> hours before one's posts are visible.)
>
> But the 'my $fh' solution is probably even simpler than using
> IO::File.
Well, the column is more than five years old, quite possibly lexical
filehandles[*] weren't around then, or rather, weren't handled as smoothly.
The advantage of lexical filehandles is that the solution is now straight-
forward. Most programmers would write something similar in any recursive
language where filehandles can be held in variables.
It is much harder when you are stuck with global filehandles; recursion
doesn't look so attractive then. Once you have the recursive solution,
however, it can be retro-fit to package filehandles when you realize that
you can localize such a filehandle by localizing its typeglob. That
localizes everything under the name, including the filehandle. If you
now use
local *FH;
open FH, ...;
instead of
open my $fh, ...;
and read from "FH", recursion works as well with a package filehandle.
It should even work under Perl 4, though I didn't try. Code below, if
anyone has the opportunity and is so inclined...
[1] "Lexical filehandle" is short for "reference to a typeglob that contains
a filehandle, held in a lexical variable". They're so magic, they
glow in the dark.
Anno, who hasn't written Perl 4 for a long time
-------------------------------------------------------------
sub copy_including_4 {
no strict 'vars'; # for Perl 5 compatibility
local *FH;
open FH, $_[ 0] or die "Can't read $_[ 0]: $!";
while ( <FH> ) {
if ( /^#include\s*(.*)/ ) {
©_including_4( $1);
} else {
print;
}
}
}
------------------------------
Date: Fri, 19 Sep 2003 16:56:42 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Order of evaluation of expressions
Message-Id: <bkfcga$1er1$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
David Combs
<dkcombs@panix.com>], who wrote in article <bkdtkp$2j8$1@reader2.panix.com>:
> In article <Xns93EEEC3E82233sdn.comcast@206.127.4.25>,
> Eric J. Roode <REMOVEsdnCAPS@comcast.net> wrote:
> What I believe to be true is that when dealing
> with *reals*, addition doesn't necessarily
> commute, ie a + b doesn't necessairly equal b + a,
> because of the limited precision of reals.
Of course it commutes. It is the associativity (a+b)+c = a+(b+c)
which breaks; this contributes if you want to sum more than 2 numbers.
[And of course associativity holds for "reals"; it is the floating
point arithmetic where it breaks. ;-]
Just a small clarification,
Ilya
------------------------------
Date: Fri, 19 Sep 2003 15:58:14 +0000 (UTC)
From: jgamble@ripco.com (John M. Gamble)
Subject: Re: Outlook Address Books and Perl?
Message-Id: <bkf92m$ara$3@e250.ripco.com>
In article <ZZqdnczS8eFx3_qiXTWc-w@speakeasy.net>,
Mark <nospam@thanksanyway.org> wrote:
>
>"James Willmore" <jwillmore@cyberia.com> wrote:
>> http://search.cpan.org/
>> search keyword: outlook
>>
>> first item thats shows is: mbx2mbox
>
>Yes, but the several Perl modules that "read" an OE
>address book, actually require that the data be exported
>from OE first. OE only exports its address book as
>comma-separated values (*.CSV). Unfortunately, this is
>a useless format, since data fields in the OE address book
>fields can (and often will) contain commas. The output
>cannot be parsed reliably.
>
>So I was hoping for a Perl module that can actually read
>the OE address book's binary format directly.
>
There's some not-bad documentation on how to get this
information via OLE on the Microsoft's technical web
site. There are some knowledge assumptions, so you'd
have to do a little experimentation.
A couple of years ago i went through Microsoft's web site
and found the OLE calls necessary to send mail. I posted
my rough results on the perlmonks site. The code there
doesn't answer your question, but it's be a good
demonstration of setting up the OLE object properties for
Outlook.
--
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
------------------------------
Date: Fri, 19 Sep 2003 14:42:36 +0200
From: Stefan Rupp <stefan.rupp@inform-ac.com>
Subject: Perl regular expression does not work on 5.8.0
Message-Id: <bketju$vfn8$1@ID-177415.news.uni-berlin.de>
Good afternoon,
we have a perl regular expression which always worked for us on
Solaris(SPARC) HPUX(IA64) and Debian GNU/Linux(i386). But now I have to
install a software on a RedHat based GNU/Linux i386 box and the same
expression does not work any longer.
See the following script:
----------------------------------------------------------
#!/usr/bin/perl
print "Enter lines with 'key = value'\n";
while ( <STDIN> ) {
if ( /^\s*([^\s=]+)\s*=\s*([^\"]\S*|\".*\")\s*/ ) {
print "Match! key = '$1', value = '$2'\n";
}
else {
print "No match.\n";
}
}
----------------------------------------------------------
On Debian (Woody) with Perl 5.6.1 it works, it matches lines like
a = b
On HPUX(IA64) with Perl 5.8.0 it works as well. On RedHat 9 with Perl
5.8.0 however, it does not match at all.
What am I doing wrong?
Any help is appreciated!
Regards,
Stefan
--
Stefan Rupp Phone: +49 (0) 2408 9456-44
Inform GmbH Fax: +49 (0) 2408 9456-45
Pascalstr. 23, 52076 Aachen, Germany E-Mail: stefan.rupp@inform-ac.com
------------------------------
Date: Fri, 19 Sep 2003 15:15:05 +0200
From: "Christian Winter" <thepoet@nexgo.de>
Subject: Re: Perl regular expression does not work on 5.8.0
Message-Id: <3f6b015a$0$25820$9b4e6d93@newsread4.arcor-online.net>
"Stefan Rupp" <stefan.rupp@inform-ac.com> wrote:
> if ( /^\s*([^\s=]+)\s*=\s*([^\"]\S*|\".*\")\s*/ ) {
Hi,
in some circumstances the [^\s] doesn't work in the standard
distribution of perl shipped with redhat 9, due to some utf8
bug. Upgrading your perl version or disabling utf8 support
for your locale should solve this.
HTH
-Christian
------------------------------
Date: Fri, 19 Sep 2003 10:36:09 -0500
From: David McDivitt <x12code-del@del-yahoo.com>
Subject: Re: referencing, closures, classes
Message-Id: <rg8mmvkri83vpt2drntrjdl4sm52glud2u@4ax.com>
>Subject: Re: referencing, closures, classes
>Date: Fri, 19 Sep 2003 00:12:42 GMT
>
>David McDivitt wrote:
>
>...
>
>
>>
>> 5 use warnings;
>> 6 use strict;
>> 7
>> 8 sub animalInFood
>> 9 {
>> 10 my $x = shift();
>> 11 return sub #what the hell does return sub mean?
>> 12 { #no description given anywhere
>
>
>The "return sub {...}" is returning a code reference to the anonymous
>sub consisting of the code between the braces (see perldoc -f sub to see
>what the sub function does). Bear in mind that when there is no
>semicolon or ending brace, the Perl expression isn't over yet -- it
>continues on subsequent lines. In this case, that anonymous sub is a
>closure because it uses $x, a lexical variable which was already defined
>in the scope of the sub at the time the sub was defined. You will note
>that if you call the returned code reference, it remembers the value of
>the in-scope lexical at the time the sub was defined. There is no magic
>to this, and actually, it barely warrants the special name "closure"
>(which name, as far as I can tell, might as well be any made-up name, as
>the ordinary concept of "closure" seems to bear no relation to this).
>It is simply a matter of the normal behavior of scoped lexical
>variables. Each time "animalInFood" is called, another anonymous code
>reference consisting of a sub with $x already in its scope with the
>value is has at the moment is created. When that code reference is
>executed later, it remembers its $x. That's all there is to it. For
>fun, try writing closures which modify their already-in-scope variables.
>
>
>> 13 my $y = shift();
>> 14 print( "There is a $x in my $y!\n" );
>> 15 };
>> 16 }
>> 17
>> 18 my &$flyInFood = animalInFood( "fly" );
>> 19 my &$frogInFood = animalInFood( "frog" );
>> 20
>> 21 &$flyInFood( "soup" );
>> 22 &$frogInFood( "coffee" );
>>
>> There is a fly in my soup!
>> There is a frog in my coffee!
>> fig 13.8
>>
>> You can see that "animalInFood returns closures because when we assign
>> variable "$flyInFood" the closure returned by passing "animalInFood" the
>> word "fly", then call "animalInFood" again with the value "frog". Each
>> closure is stored in a reference. These references are used at lines 21 and
>> 22 to invoke each closure. Note that the closure invoked at line 21 prints a
>> string containing the word "fly", which was passed to the first call to
>> "animalInFood". Similarly, the closure invoked at line 22 prints a string
>> containing the word "frog", which was passed to the second call to
>> "animalInFood".
>>
>> ********************************
>>
>> I don't know what I'm supposed to get from this. It is not well written in
>> my opinion and I fail to get the point of even reading it. Closures seem to
>> be very important however, and understanding closures would seem to help one
>> understand classes, too. Thanks
>
>
>Well, it seems fairly clear to me, but I do think it would be better to
>describe the phenomenon as simply the expected behavior of scoped
>lexical variables, just exactly like what happens in any other scope. I
>don't know how important they are -- I guess they can be pretty
>important for generating obfuscated code, maybe. And they do let you
>create truly private variables which absolutely nothing can touch other
>than your own methods when you create modules. But that probably isn't
>very important either (hey, someone can just modify the code of your
>module if they really want to, so what did it really gain? Oh, yeah, it
>obfuscated it to the point where they couldn't understand it anyway, so
>maybe it did keep your module private :-).).
The problem I was having was the "return sub" syntax. This is what does the
closure. The syntax is given one time and one time only in the coding
example, but is not described in the book. The author does this often and
that's why his book is bad.
------------------------------
Date: Fri, 19 Sep 2003 10:58:55 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: referencing, closures, classes
Message-Id: <etoznh0pve8.fsf@wormtongue.emschwar>
David McDivitt <x12code-del@del-yahoo.com> writes:
> The problem I was having was the "return sub" syntax. This is what does the
> closure.
No it's not. Remember, there is no "return sub" syntax. There's
"sub {...}", which declares an anonymous sub, and returns a reference
to it, and 'return <foo>', which returns a value or list of values.
It's the sub {...} declaration which creates the closure; the return
just returns the subref which the sub {...} creates.
> The syntax is given one time and one time only in the coding
> example, but is not described in the book. The author does this often and
> that's why his book is bad.
Among other reasons. Sounds like you need a better book, which the
regulars here have already pointed you towards.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: Fri, 19 Sep 2003 17:32:09 -0000
From: "David K. Wall" <usenet@dwall.fastmail.fm>
Subject: Re: referencing, closures, classes
Message-Id: <Xns93FB89B19F6EAdkwwashere@216.168.3.30>
Eric Schwartz <emschwar@pobox.com> wrote:
> David McDivitt <x12code-del@del-yahoo.com> writes:
>> The problem I was having was the "return sub" syntax. This is
>> what does the closure.
>
> No it's not. Remember, there is no "return sub" syntax. There's
> "sub {...}", which declares an anonymous sub, and returns a
> reference to it, and 'return <foo>', which returns a value or list
> of values. It's the sub {...} declaration which creates the
> closure; the return just returns the subref which the sub {...}
> creates.
I don't see why anonymous subroutines were used to introduce
closures, anyway. Other than the syntax used to call the subroutine,
what difference does it make whether the subroutine has a name or
not? As Matija Papec pointed out, Damian Conway's _Object Oriented
Perl_ book defines a closure as just a subroutine that refers to one
or more lexical variables declared outside the subroutine itself.
But Larry uses anonymous subroutines in the Camel (p 259 in the 3rd
ed), too.
Using anonymous subroutines to *introduce* closures seems like
unnecessary obfuscation to me. Introduce the idea with as few
complications as possible, *then* show how to make them more
powerful.
Or am I missing something?
--
David Wall
------------------------------
Date: Fri, 19 Sep 2003 17:53:38 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: referencing, closures, classes
Message-Id: <x7brtgr7fh.fsf@mail.sysarch.com>
>>>>> "DKW" == David K Wall <usenet@dwall.fastmail.fm> writes:
DKW> I don't see why anonymous subroutines were used to introduce
DKW> closures, anyway. Other than the syntax used to call the subroutine,
DKW> what difference does it make whether the subroutine has a name or
DKW> not? As Matija Papec pointed out, Damian Conway's _Object Oriented
DKW> Perl_ book defines a closure as just a subroutine that refers to one
DKW> or more lexical variables declared outside the subroutine itself.
DKW> But Larry uses anonymous subroutines in the Camel (p 259 in the 3rd
DKW> ed), too.
you can't generate multiple closures with named subs. you can only have
one sub with a given name so it is a limiting factor.
{ my $foo = 4 ;
sub bump_foo { return ++$foo}
}
that is a closure by your rule (and many others). i prefer to use the
term where anon subs are used since closures are meant to carry private
data around. the above code really just hides $foo (even if it is
carried by the sub in its pad).
in fact there was a bug report on p5p regarding named closures not being
garbage collected properly whereas anon ones worked fine.
DKW> Using anonymous subroutines to *introduce* closures seems like
DKW> unnecessary obfuscation to me. Introduce the idea with as few
DKW> complications as possible, *then* show how to make them more
DKW> powerful.
DKW> Or am I missing something?
writing a better section on it would be better. you need anon subs to
make closures useful. but you should cover anon subs and code refs first
and later introduce closures. then you teach the stuff incrementally.
as for the 'return sub' syntax, how many times have we seen print <<FOO
and newbies think <<FOO is a part of the print syntax? again, that is
the result of cargo cult learning and bad books.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Class in Boston - Sept 2003 -- http://www.stemsystems.com/class
------------------------------
Date: 19 Sep 2003 10:15:38 -0700
From: danielems@myfastmail.com (Daniel Ems)
Subject: regexp help - match on two backslashes
Message-Id: <abb5f0c6.0309190915.735cab15@posting.google.com>
Hello,
Apologies if this is the wrong place to post this question...
What regular expression can I use to match two backslashes?
I am actually using grep (on a windows machine), and I have tried
every combination of escaped backslashes I can think of...
Thanks for the help
Daniel Ems
------------------------------
Date: 19 Sep 2003 13:24:02 -0400
From: Ryan Shondell <shondell@cis.ohio-state.edu>
Subject: Re: regexp help - match on two backslashes
Message-Id: <xcwznh0r8st.fsf@psi.cis.ohio-state.edu>
danielems@myfastmail.com (Daniel Ems) writes:
> Hello,
>
> Apologies if this is the wrong place to post this question...
>
> What regular expression can I use to match two backslashes?
/\Q\\/
perldoc -f quotemeta
--
perl -e '$;=q,BllpZllla_nNanfc]^h_rpF,;@;=split//,
$;;$^R.=--$=*ord for split//,$~;sub _{for(1..4){$=
=shift;$=--if$=!=4;while($=){print chr(ord($;[$%])
+shift);$%++;$=--;}print " ";}}_(split//,$^R);q;;'
------------------------------
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.
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 5528
***************************************
