[27786] in Perl-Users-Digest
Perl-Users Digest, Issue: 9150 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 12 18:05:57 2006
Date: Wed, 12 Apr 2006 15:05:07 -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 Wed, 12 Apr 2006 Volume: 10 Number: 9150
Today's topics:
(and, ) just how is perl6 coming along? when maybe try (David Combs)
Re: CGI.pm annoying xHTML output <john@castleamber.com>
Re: CGI.pm annoying xHTML output (Anno Siegel)
Re: CGI.pm annoying xHTML output <xx087@freenet.carleton.ca>
Re: CGI.pm annoying xHTML output (Anno Siegel)
Re: CGI.pm annoying xHTML output <uri@stemsystems.com>
Re: Class::Std - how to indicate construction failure (Anno Siegel)
Re: Class::Std - how to indicate construction failure <abigail@abigail.nl>
Re: Class::Std - how to indicate construction failure (Anno Siegel)
Re: Is language Perl have stack, or I must write it? <tadmc@augustmail.com>
New Lingua::EL::Poly2Mono module <bpaux03@gmail.com>
Ruby, Ruby-on-Rails, etc? (vs P6 and via P6?) (David Combs)
Re: Ruby, Ruby-on-Rails, etc? (vs P6 and via P6?) <eflorac@imaginet.fr>
Re: XML 1.1 parser, compliant in Perl <jgibson@mail.arc.nasa.gov>
Re: XS progamming question xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 Apr 2006 15:09:41 -0400
From: dkcombs@panix.com (David Combs)
Subject: (and, ) just how is perl6 coming along? when maybe tryable, usable, reliable?
Message-Id: <e1jj9l$ahv$1@panix3.panix.com>
And, of course, I have to also ask: how's perl6 coming along?
When maybe tryable?
Usable for personal projects?
Reliable "enough" for "real" projects?
Thanks,
David
------------------------------
Date: 12 Apr 2006 16:06:50 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <Xns97A3710C1E1EBcastleamber@130.133.1.4>
FrankB <you.can@request.yes> wrote:
> John Bokma brought next idea :
[..]
>> If you have put use strict;
>
> Which was not the case
But it's a good thing to do it. Ages ago, different language, I typed
width as widht once, which was quite hard to track down, since it got
initialized with zero, which sometimes was the same value as width, and
sometimes not.
>> and use warnings; before use CGI ..., yes.
>
> Which is the case.
>>
>> Also, I recommend to call the variable $cgi instead of $q (or $query).
>
> And that's another tip.
>
> Thanks.
You're welcome :-)
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: 12 Apr 2006 17:49:23 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <4a4st3Frgre0U1@news.dfncis.de>
FrankB <you.did@request.net> wrote in comp.lang.perl.misc:
> Glenn Jackman formulated the question :
> > At 2006-04-11 06:56AM, FrankB <you.can@request.net> wrote:
> >> Hello,
> >>
> >> when creating a form with CGI.pm, no matter if it is
> >> use CGI;
> >> $q = new CGI qw /:all -debug/;
> >
> > Those lines should read:
> > use CGI qw/:all -debug/;
> > my $q = new CGI;
>
> Ok.
The second line should really read
my $q = CGI->new;
Avoid indirect object notation where possible, especially when there are
no arguments to the call.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 12 Apr 2006 18:54:11 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <slrne3qj6j.o2k.xx087@smeagol.ncf.ca>
At 2006-04-12 01:49PM, Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> > Glenn Jackman formulated the question :
> > > use CGI qw/:all -debug/;
> > > my $q = new CGI;
>
> The second line should really read
>
> my $q = CGI->new;
>
> Avoid indirect object notation where possible, especially when there are
> no arguments to the call.
I was going to quibble over your use of "should", but then I read
"perldoc perlobj". Now, I agree.
--
Glenn Jackman
Ulterior Designer
------------------------------
Date: 12 Apr 2006 19:27:19 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <4a52kmFqa74hU1@news.dfncis.de>
Glenn Jackman <xx087@freenet.carleton.ca> wrote in comp.lang.perl.misc:
> At 2006-04-12 01:49PM, Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> > > Glenn Jackman formulated the question :
> > > > use CGI qw/:all -debug/;
> > > > my $q = new CGI;
> >
> > The second line should really read
> >
> > my $q = CGI->new;
> >
> > Avoid indirect object notation where possible, especially when there are
> > no arguments to the call.
>
> I was going to quibble over your use of "should", but then I read
> "perldoc perlobj". Now, I agree.
The trouble is that indirect object notation does look nice, especially
with a constructor named "new".
my $pet = new Pet name => 'rover', kind => 'dog';
Also, Perl almost always gets it right. I guess that's why it doesn't seem
to die out like other deprecated constructs. But there *is* guesswork
involved in the interpretation. Like all constructs that rely on the
DWIMmer it should be avoided in production code.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Wed, 12 Apr 2006 15:27:51 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <x764leoaq0.fsf@mail.sysarch.com>
>>>>> "GJ" == Glenn Jackman <xx087@freenet.carleton.ca> writes:
GJ> At 2006-04-12 01:49PM, Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
>> > Glenn Jackman formulated the question :
>> > > use CGI qw/:all -debug/;
>> > > my $q = new CGI;
>>
>> The second line should really read
>>
>> my $q = CGI->new;
>>
>> Avoid indirect object notation where possible, especially when there are
>> no arguments to the call.
GJ> I was going to quibble over your use of "should", but then I read
GJ> "perldoc perlobj". Now, I agree.
it has been known and documented for a long time that they are
vulnerable and that direct calls are better. it is amazing how many
cpan modules still use indirect object calls in their code and pod. and
that includes modules written by some very good perl hackers. many
newbies copy the indirect style from example code and never end up
reading perldoc perlobj. i also like the look of direct calls over
indirect.
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
------------------------------
Date: 12 Apr 2006 15:13:55 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Class::Std - how to indicate construction failure
Message-Id: <4a4jpjFr2medU1@news.dfncis.de>
Dave Weaver <zen13097@zen.co.uk> wrote in comp.lang.perl.misc:
> I'm experimenting with using Class::Std to implement 'inside-out'
> objects.
>
> In the 'normal' style Perl objects, it's traditional for the
> constructor to return undef if the construction fails. In Class::Std
> the user-level meat of the construction phase is put in the BUILD
> method, but in reading the docs I see no way that the BUILD method can
> pass back a failure status (other than by die-ing) to the code that
> wants to constuct the object.
>
> For example, using old-style Perl objects,
>
> my $obj = MyFileObject->new({ file => 'test.txt' });
>
> would return undef if, for example, the passed file couldn't be found.
>
> What is the correct way to do this construct-time checking using
> Class::Std? Do I have to override new() ?
In _PBP_, section Error Handling, Damian Conway recommends throwing exceptions
instead of returning special values. So the idea would be to die() in BUILD
and, if necessary, catch the error through "eval { Class->new(...) }".
On the other hand, Class::Std is not the only module on CPAN that supports
inside-out classes, and not necessarily the best one. Last time I looked
there were Class::InsideOut and Object::InsideOut. Take a look at them
if they fit your needs better.
If you are serious about studying inside-out classes you should also
build at least one small (but more than trivial) class hierarchy directly,
creator, destructor and all, if only to see what it is the pre-made classes
save you.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 12 Apr 2006 20:26:29 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Class::Std - how to indicate construction failure
Message-Id: <slrne3qojl.ba.abigail@alexandra.abigail.nl>
Dave Weaver (zen13097@zen.co.uk) wrote on MMMMDCVII September MCMXCIII in
<URL:news:443d0223$0$665$fa0fcedb@news.zen.co.uk>:
:) I'm experimenting with using Class::Std to implement 'inside-out'
:) objects.
IMNSHO, I think the best method to learn what 'Inside Out Objects'
are is to implement them without modules.
Once you know what they're about, you can make a judgement on what
you're willing to sacrifice in order to able to use a module.
I've looked at several of the modules implemented Inside Out Objects,
and I've found them ranging from overly complicated to completely
missing the point of Inside Out Objects.
:) In the 'normal' style Perl objects, it's traditional for the
:) constructor to return undef if the construction fails.
Really?
I think that constructors should construct, and nothing else. Which
means that the only reason the constructor can fail is the program
running out of memory. Which is a nontrappable "very fatal error".
Abigail
--
perl -wle'print"Êõóô áîïôèåò Ðåòì Èáãëåò"^"\x80"x24'
------------------------------
Date: 12 Apr 2006 21:27:30 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Class::Std - how to indicate construction failure
Message-Id: <4a59m2Fr03kvU1@news.dfncis.de>
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Dave Weaver (zen13097@zen.co.uk) wrote on MMMMDCVII September MCMXCIII in
> <URL:news:443d0223$0$665$fa0fcedb@news.zen.co.uk>:
> :) I'm experimenting with using Class::Std to implement 'inside-out'
> :) objects.
Hey, a smiley as quotation marker.
> IMNSHO, I think the best method to learn what 'Inside Out Objects'
> are is to implement them without modules.
>
> Once you know what they're about, you can make a judgement on what
> you're willing to sacrifice in order to able to use a module.
>
> I've looked at several of the modules implemented Inside Out Objects,
> and I've found them ranging from overly complicated to completely
> missing the point of Inside Out Objects.
>
> :) In the 'normal' style Perl objects, it's traditional for the
> :) constructor to return undef if the construction fails.
>
> Really?
>
> I think that constructors should construct, and nothing else. Which
> means that the only reason the constructor can fail is the program
> running out of memory. Which is a nontrappable "very fatal error".
Ah, but he's talking about Class::Std, which doesn't support the
separation of creation and initialization very well. The question
was really how to deal with errors in BUILD, which is initialization,
not creation. Having to deal with run time errors in initialization
is common.
On the other hand, having separate ->init and ->new methods (or whatever
they're called) isn't particular to inside-out classes. Traditional
classes would benefit from the separation just as well. It isn't
seen very often, probably because the disadvantages of a combined
creator/initializer only become apparent with multiple inheritance.
With single inheritance it is possible to slip by, using the parent's
->new to create an object blessed in your class, but initialized for
the parent. Then you insert your own data into the existing structure,
(often in rather unclean ways). That gives you another ->new that
initializes its objects. Only when there is yet another parent class
to initialize it becomes a problem that you can't do that without
creating another object.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Wed, 12 Apr 2006 13:49:06 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Is language Perl have stack, or I must write it?
Message-Id: <slrne3qit2.9l6.tadmc@magna.augustmail.com>
<info@perot.com> <info@perot.com> wrote:
> Is language Perl have stack, or I must write it?
perldoc -f push
perldoc -f pop
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 11 Apr 2006 22:59:54 GMT
From: "Sprout" <bpaux03@gmail.com>
Subject: New Lingua::EL::Poly2Mono module
Message-Id: <IxMHFn.12HJ@zorch.sf-bay.org>
A few days ago I posted a new module on the CPAN called
Lingua::EL::Poly2Mono, for converting polytonic Greek text to
monotonic.
This could be useful for websites with Greek texts, since they can
on-the-fly provide monotonic equivalents for clients without polytonic
fonts.
------------------------------
Date: 12 Apr 2006 15:05:25 -0400
From: dkcombs@panix.com (David Combs)
Subject: Ruby, Ruby-on-Rails, etc? (vs P6 and via P6?)
Message-Id: <e1jj1l$daj$1@panix3.panix.com>
I go to bookstores and each time it seems like there's
yet another book on ruby or "ruby on rails", etc.
The rails books says how it makes web-sites "so much easier",
eg even easier than with perl (5, I assume).
So, what is this rails stuff -- and I assume that
larry et al are adding whatever's needed to P6
such whatever advantages one (is supposed to) get via
ruby and rails, etc, is *yet more easily* done with P6?
Thanks,
David
------------------------------
Date: Wed, 12 Apr 2006 23:11:33 +0200
From: Emmanuel Florac <eflorac@imaginet.fr>
Subject: Re: Ruby, Ruby-on-Rails, etc? (vs P6 and via P6?)
Message-Id: <pan.2006.04.12.21.11.33.556232@imaginet.fr>
Le Wed, 12 Apr 2006 15:05:25 -0400, David Combs a écrit :
>
> So, what is this rails stuff -- and I assume that larry et al are adding
> whatever's needed to P6 such whatever advantages one (is supposed to) get
> via ruby and rails, etc, is *yet more easily* done with P6?
It gets more easily done with Perl5 : see Catalyst, jifty, Maypole, they
provide functionality similar or even better than RoR.
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
------------------------------
Date: Wed, 12 Apr 2006 09:13:00 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: XML 1.1 parser, compliant in Perl
Message-Id: <120420060913005014%jgibson@mail.arc.nasa.gov>
In article <6qko32tpb8arbele4s4r11gvauvpuub3k4@4ax.com>, robic0 wrote:
> This is my next release here.
> I got no response to Net::Telnet wrapper code.
> I want to post this huge chunk of code but I will not if the
> arrogance continues..
Please do not post any more code. We are not worthy.
------------------------------
Date: 12 Apr 2006 15:45:48 GMT
From: xhoster@gmail.com
Subject: Re: XS progamming question
Message-Id: <20060412115743.494$bn@newsreader.com>
"Ferry Bolhar" <bol@adv.magwien.gv.at> wrote:
> Ilya Zakharevich:
>
> > Check it yourselves. Removing globs from symbol tables has no effect
> > on already compiled code referencing these globs - the code tree
> > already contains C pointers to the globs (I mean access to global
> > vars, arrays, hashes, subroutines etc), it won't go through symbol
> > tables again.
>
> Uh, oh. This brings me to another question.
>
> The doc says the "BEGIN blocks are compiled and executed first
> in order of appearance.
What part of the docs say that?
>
> sub aa {
> print 12;
> }
>
> BEGIN {
> delete $main{aa};
> }
>
> aa();
>
> I would expect that at the time BEGIN is compiled and then
> executed, the remaining code is not yet compiled and therefore,
> there is no glob *main::aa which could be deleted!
Filling out of the symbol table is part of the compilation process.
aa() is compiled, and a reference (pointer, something) to it is stuffed
into the symbol table. Otherwise, what would be the point of compiling it
if it could not be found later? BEGIN is compiled, and executed
immediately upon compilation, deleting the entry for aa in the symbol
table.
> Why does
> this work nevertheless?
What do you mean by "work" in this context?
>
> And it doesn't work when the 'sub aa...' is placed _after_ the BEGIN -
> no errors, but "12" is printed when running. Does this mean that the
> sequence in which subs and a BEGIN appears in a program is of
> importance? The docs do not clearify this behaviour.
Obviously it does mean that the sequence is important, at least if you are
in the habit of deleting subs from within BEGIN blocks.
>
> What exactly happens when Perl reads a script in, _before_ BEGIN
> blocks are compiled?
Perl does not read a script in before BEGINs are compiled. They are
compiled while it is being read in.
foo.pl starts out with:
BEGIN {
warn "foo";
};
followed by thousands of lines of white space.
running "strace perl foo.pl" gives this (formatted for interpretation):
...
read(3, "BEGIN {\n warn \"foo\";\n};\n "..., 4096) = 4096
##just read the BEGIN
write(2, "foo at foo.pl line 2.\n", 22foo at foo.pl line 2.
) = 22
## Just executed the warning in side the BEGIN (and so must have compiled
it)
read(3, " \n "..., 4096) = 4096
brk(0) = 0x62a000
brk(0x64b000) = 0x64b000
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
read(3, " "..., 4096) = 4096
...
##Goes on the read (and compile) the rest of the program
> I think (and it seems so) that the lexical
> analysis and parsing (tokenizing) phase must take place at this time
> already - even for code outside of BEGIN blocks. Is this true?
For code which is lexically *before* the BEGIN blocks, yes, that is true.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 9150
***************************************
