[31723] in Perl-Users-Digest
Perl-Users Digest, Issue: 2986 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 12 00:09:28 2010
Date: Fri, 11 Jun 2010 21:09:08 -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, 11 Jun 2010 Volume: 11 Number: 2986
Today's topics:
Re: access to files in multiple combinations of folders <jurgenex@hotmail.com>
Re: binmode for readling the whole file? sln@netherlands.com
Re: binmode for readling the whole file? <john@castleamber.com>
Re: binmode for readling the whole file? <uri@StemSystems.com>
Re: binmode for readling the whole file? sln@netherlands.com
Re: binmode for readling the whole file? <tadmc@seesig.invalid>
Re: Converting HTML to PDF with Webkit (was: suggest <hjp-usenet2@hjp.at>
Re: Converting HTML to PDF with Webkit <rvtol+usenet@xs4all.nl>
File::Slurp/IO::String/wantarray interaction bug <no.email@please.post>
Re: File::Slurp/IO::String/wantarray interaction bug <no.email@please.post>
Re: File::Slurp/IO::String/wantarray interaction bug <uri@StemSystems.com>
Re: graphics <john@castleamber.com>
Re: graphics <mvdwege@mail.com>
Re: graphics <rvtol+usenet@xs4all.nl>
Re: How to read a given number of lines? <rvtol+usenet@xs4all.nl>
How to return the line number that right next to a matc <pengyu.ut@gmail.com>
Re: How to return the line number that right next to a <rvtol+usenet@xs4all.nl>
Re: Why does perl allow so many different ways of doing <cwilbur@chromatico.net>
Re: Why does perl allow so many different ways of doing <thepoet_nospam@arcor.de>
Re: Why does perl allow so many different ways of doing <rvtol+usenet@xs4all.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 11 Jun 2010 19:04:33 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: access to files in multiple combinations of folders?
Message-Id: <kmq5161t7ilrvnl89dvician9bh9d0om2e@4ax.com>
Geoff <geoff@invalid.invalid> wrote:
>On Fri, 11 Jun 2010 04:34:53 -0700, Jürgen Exner
>>Do you have a question that is related to Perl, too?
>
>yes, in the sense that I am looking for an alternative to the use of
>.htaccess, and this could be Perl. PHP or Javascript.
...or C or Lisp or Fortran or Haskell or any other of hundreds of
programming languages.....
That doesn't make your question a C or Lisp or Fortran question.
jue
------------------------------
Date: Fri, 11 Jun 2010 13:39:55 -0700
From: sln@netherlands.com
Subject: Re: binmode for readling the whole file?
Message-Id: <5j7516hfccm1r119c5cvnsuon5ghc59d87@4ax.com>
On Fri, 11 Jun 2010 12:48:17 -0500, John Bokma <john@castleamber.com> wrote:
>Tad McClellan <tadmc@seesig.invalid> writes:
>
>> Use binmode on binary files.
>>
>> Do not use binmode on text files.
>
>/unless/ you want the data as it is on disk, for example to
>calculate a check sum.
>
Semantics! You wouldn't create a check sum on a text file.
Otherwise it wouldn't be a text file, it would be
a binary file.
-sln
------------------------------
Date: Fri, 11 Jun 2010 16:07:01 -0500
From: John Bokma <john@castleamber.com>
Subject: Re: binmode for readling the whole file?
Message-Id: <87eigd6zyi.fsf@castleamber.com>
sln@netherlands.com writes:
> On Fri, 11 Jun 2010 12:48:17 -0500, John Bokma <john@castleamber.com> wrote:
>
>>Tad McClellan <tadmc@seesig.invalid> writes:
>>
>>> Use binmode on binary files.
>>>
>>> Do not use binmode on text files.
>>
>>/unless/ you want the data as it is on disk, for example to
>>calculate a check sum.
>>
> Semantics! You wouldn't create a check sum on a text file.
> Otherwise it wouldn't be a text file, it would be
> a binary file.
Is that so? So if I calculate a MD5 digest over a text file to check its
integrity it magically becomes a binary file? Even if I add the checksum
to the end of the text file, it still can be a text file.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Fri, 11 Jun 2010 17:55:56 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: binmode for readling the whole file?
Message-Id: <87ljal5j4j.fsf@quad.sysarch.com>
>>>>> "JB" == John Bokma <john@castleamber.com> writes:
JB> sln@netherlands.com writes:
>> On Fri, 11 Jun 2010 12:48:17 -0500, John Bokma <john@castleamber.com> wrote:
>>
>>> Tad McClellan <tadmc@seesig.invalid> writes:
>>>
>>>> Use binmode on binary files.
>>>>
>>>> Do not use binmode on text files.
>>>
>>> /unless/ you want the data as it is on disk, for example to
>>> calculate a check sum.
>>>
>> Semantics! You wouldn't create a check sum on a text file.
>> Otherwise it wouldn't be a text file, it would be
>> a binary file.
JB> Is that so? So if I calculate a MD5 digest over a text file to check its
JB> integrity it magically becomes a binary file? Even if I add the checksum
JB> to the end of the text file, it still can be a text file.
it matters on winblows. if you just open a text file with no binmode and
pass the handle to a checksum sub, it will not calculate a proper sum
for the file itself. the cr/lf pairs will become newlines and the sum
will be different than if done on the raw file.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 11 Jun 2010 17:12:10 -0700
From: sln@netherlands.com
Subject: Re: binmode for readling the whole file?
Message-Id: <20k516dpbnhduu5d45v16uvknq6009je9u@4ax.com>
On Fri, 11 Jun 2010 16:07:01 -0500, John Bokma <john@castleamber.com> wrote:
>sln@netherlands.com writes:
>
>> On Fri, 11 Jun 2010 12:48:17 -0500, John Bokma <john@castleamber.com> wrote:
>>
>>>Tad McClellan <tadmc@seesig.invalid> writes:
>>>
>>>> Use binmode on binary files.
>>>>
>>>> Do not use binmode on text files.
>>>
>>>/unless/ you want the data as it is on disk, for example to
>>>calculate a check sum.
>>>
>> Semantics! You wouldn't create a check sum on a text file.
>> Otherwise it wouldn't be a text file, it would be
>> a binary file.
>
>Is that so? So if I calculate a MD5 digest over a text file to check its
>integrity it magically becomes a binary file? Even if I add the checksum
>to the end of the text file, it still can be a text file.
Haha! Its funny but after you validate the integrity with a checksum, it
reads different when read in text mode depending on the OS.
Semantics..
-sln
------------------------------
Date: Fri, 11 Jun 2010 20:31:02 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: binmode for readling the whole file?
Message-Id: <slrni15ofn.4s9.tadmc@tadbox.sbcglobal.net>
sln@netherlands.com <sln@netherlands.com> wrote:
> On Fri, 11 Jun 2010 12:48:17 -0500, John Bokma <john@castleamber.com> wrote:
>
>>Tad McClellan <tadmc@seesig.invalid> writes:
>>
>>> Use binmode on binary files.
>>>
>>> Do not use binmode on text files.
>>
>>/unless/ you want the data as it is on disk, for example to
>>calculate a check sum.
>>
> Semantics! You wouldn't create a check sum on a text file.
I create checksums on text files fairly often.
> Otherwise it wouldn't be a text file, it would be
> a binary file.
Nonsense!
What makes you think that taking a checksum changes a file's type?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Fri, 11 Jun 2010 21:03:54 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Converting HTML to PDF with Webkit (was: suggestions for printing out a few records of a lengthy file)
Message-Id: <slrni1524q.vkh.hjp-usenet2@hrunkner.hjp.at>
On 2010-06-10 07:02, Chris Nehren <apeiron@invalid.isuckatdomains.net> wrote:
> On 2010-06-09, Peter J. Holzer scribbled these
> curious markings:
>> On 2010-06-08 07:57, Dr.Ruud <rvtol+usenet@xs4all.nl> wrote:
>>> On the related subject of creating nice PDFs:
>>> we are using webkit for that for the last few years,
>>> we create many-many thousands a day,
>>> and we are very happy with the results.
>>
>> Sounds interesting. Which perl module do you use (there are several on
>> CPAN, but the descriptions don't look promising)?
>
> Not a module, per se, but I've had success with wkhtmltopdf. See
> http://code.google.com/p/wkhtmltopdf/ for more info.
Thanks, but after playing with it for a bit I found two problems:
1) It pretends to be a screen device, not a printing device (so for a
stylesheet which contain both @media print and @media screen sections
it chooses the wrong ones).
2) It sometimes makes a pagebreak in the middle of a line (so the upper
half of the line is on page 1 and the lower half of the line is on
page 2).
It looks like the tool renders the page the same way as a browser on
screen and then cuts the result into pages.
hp
------------------------------
Date: Sat, 12 Jun 2010 01:58:39 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Converting HTML to PDF with Webkit
Message-Id: <4c12cdb0$0$22942$e4fe514c@news.xs4all.nl>
Peter J. Holzer wrote:
> On 2010-06-10 07:02, Chris Nehren <apeiron@invalid.isuckatdomains.net> wrote:
>> On 2010-06-09, Peter J. Holzer scribbled these curious markings:
>>> On 2010-06-08 07:57, Dr.Ruud <rvtol+usenet@xs4all.nl> wrote:
>>>> On the related subject of creating nice PDFs:
>>>> we are using webkit for that for the last few years,
>>>> we create many-many thousands a day,
>>>> and we are very happy with the results.
>>>
>>> Sounds interesting. Which perl module do you use (there are several on
>>> CPAN, but the descriptions don't look promising)?
>>
>> Not a module, per se, but I've had success with wkhtmltopdf. See
>> http://code.google.com/p/wkhtmltopdf/ for more info.
>
> Thanks, but after playing with it for a bit I found two problems:
>
> 1) It pretends to be a screen device, not a printing device (so for a
> stylesheet which contain both @media print and @media screen sections
> it chooses the wrong ones).
> 2) It sometimes makes a pagebreak in the middle of a line (so the upper
> half of the line is on page 1 and the lower half of the line is on
> page 2).
>
> It looks like the tool renders the page the same way as a browser on
> screen and then cuts the result into pages.
This should help:
--print-media-type
"page-break-inside: avoid;"
http://www.smashingmagazine.com/2007/02/21/printing-the-web-solutions-and-techniques/
http://code.google.com/p/wkhtmltopdf/issues/detail?id=9
http://code.google.com/p/wkhtmltopdf/issues/detail?id=57
http://search.cpan.org/~tbr/WKHTMLTOPDF-0.02/lib/WKHTMLTOPDF.pm
--
Ruud
------------------------------
Date: Fri, 11 Jun 2010 22:57:58 +0000 (UTC)
From: kj <no.email@please.post>
Subject: File::Slurp/IO::String/wantarray interaction bug
Message-Id: <huuf1m$9kt$1@reader1.panix.com>
Consider the following demo script:
# first line
# second line
use File::Slurp 'slurp';
use IO::String;
{
my $string = slurp( $0 );
my $io_string = IO::String->new( $string );
printf ">>>%s<<<\n", scalar $io_string->READLINE;
printf ">>>%s<<<\n", scalar $io_string->READLINE;
}
{
my $io_string = IO::String->new( slurp( $0 ) );
printf ">>>%s<<<\n", scalar $io_string->READLINE;
printf ">>>%s<<<\n", scalar $io_string->READLINE;
}
__END__
The only difference between the two blocks is that the first one
assigns the value returned by slurp( $0 ) to the intermediate
lexical variable $io_string, while the second one uses this value
directly.
As far as I can tell, the output of both blocks should be identical,
but they are not even close. The output I get for the script above
is:
>>># first line
<<<
>>># second line
<<<
>>># first line
<<<
>>><<<
Note that in the second block, the second line never gets printed;
it is treated as an empty string.
Stepping through the code with the debugger, I narrowed down the
problem to the first line in the definition of IO::String::READLINE:
sub READLINE
{
goto &getlines if wantarray;
goto &getline;
}
Somehow, in the failing cases, the wantarray in the first line of
READLINE evaluates to true, even though the original calling
environment clearly specifies the scalar keyword. Therefore getlines
gets inappropriately called, rather than the correct getline.
How can the *really* force a scalar environment? (Clearly, the
scalar keyword is not doing the job here.)
FWIW, I'm using perl v5.10.0 on Ubuntu Linux.
TIA!
~K
------------------------------
Date: Fri, 11 Jun 2010 23:34:51 +0000 (UTC)
From: kj <no.email@please.post>
Subject: Re: File::Slurp/IO::String/wantarray interaction bug
Message-Id: <huuh6r$314$1@reader1.panix.com>
In <huuf1m$9kt$1@reader1.panix.com> kj <no.email@please.post> writes:
>Consider the following demo script:
># first line
># second line
>use File::Slurp 'slurp';
>use IO::String;
>{
> my $string = slurp( $0 );
> my $io_string = IO::String->new( $string );
> printf ">>>%s<<<\n", scalar $io_string->READLINE;
> printf ">>>%s<<<\n", scalar $io_string->READLINE;
>}
>{
> my $io_string = IO::String->new( slurp( $0 ) );
> printf ">>>%s<<<\n", scalar $io_string->READLINE;
> printf ">>>%s<<<\n", scalar $io_string->READLINE;
>}
>__END__
>The only difference between the two blocks is that the first one
>assigns the value returned by slurp( $0 ) to the intermediate
>lexical variable $io_string, while the second one uses this value
>directly.
>As far as I can tell, the output of both blocks should be identical,
>but they are not even close. The output I get for the script above
>is:
>>>># first line
><<<
>>>># second line
><<<
>>>># first line
><<<
>>>><<<
>Note that in the second block, the second line never gets printed;
>it is treated as an empty string.
>Stepping through the code with the debugger, I narrowed down the
>problem to the first line in the definition of IO::String::READLINE:
>sub READLINE
>{
> goto &getlines if wantarray;
> goto &getline;
>}
>Somehow, in the failing cases, the wantarray in the first line of
>READLINE evaluates to true, even though the original calling
>environment clearly specifies the scalar keyword. Therefore getlines
>gets inappropriately called, rather than the correct getline.
>How can the *really* force a scalar environment? (Clearly, the
>scalar keyword is not doing the job here.)
OK, I found out one more detail. If I replace the original second block
{
my $io_string = IO::String->new( slurp( $0 ) );
printf ">>>%s<<<\n", scalar $io_string->READLINE;
printf ">>>%s<<<\n", scalar $io_string->READLINE;
}
with
{
my $io_string = IO::String->new( scalar slurp( $0 ) ); # <- only this line changed
printf ">>>%s<<<\n", scalar $io_string->READLINE;
printf ">>>%s<<<\n", scalar $io_string->READLINE;
}
now the output is identical for both blocks.
Still, this is quite a curveball. I see that in the original
version, the call to slurp was happenning in a list context, and
this probably messes up the string that actually gets used to define
the IO::String object. But still, this does not explain why READLINE
believes its in a list context. (I'm sorry that I can't show this
easily; one needs to step there with the debugger).
~K
------------------------------
Date: Fri, 11 Jun 2010 21:22:29 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: File::Slurp/IO::String/wantarray interaction bug
Message-Id: <87zkz12gfe.fsf@quad.sysarch.com>
>>>>> "k" == kj <no.email@please.post> writes:
k> In <huuf1m$9kt$1@reader1.panix.com> kj <no.email@please.post> writes:
>> Consider the following demo script:
>> # first line
>> # second line
>> use File::Slurp 'slurp';
most people use the read_file sub. slurp is just an alias to it for
backwards compatability.
>> use IO::String;
why do you play with io::string? perl's open can do that builtin these
days. it does require a scalar var and can't do it on data but that
isn't much of an issue.
and a general question, what are you trying to do here??
>> {
>> my $string = slurp( $0 );
>> my $io_string = IO::String->new( $string );
>> printf ">>>%s<<<\n", scalar $io_string->READLINE;
>> printf ">>>%s<<<\n", scalar $io_string->READLINE;
>> }
>> {
>> my $io_string = IO::String->new( slurp( $0 ) );
all sub/method calls pass list context to their arguments. remember,
those args get set into the @_ array so that makes sense. otherwise you
couldn't pass in an array and it would be converted to its count which
is usually not wanted in @_.
>> printf ">>>%s<<<\n", scalar $io_string->READLINE;
>> printf ">>>%s<<<\n", scalar $io_string->READLINE;
>> }
printf also like other funcs which can take a list of args, has list
context for everything past the format arg.
k> OK, I found out one more detail. If I replace the original second block
k> {
k> my $io_string = IO::String->new( slurp( $0 ) );
k> printf ">>>%s<<<\n", scalar $io_string->READLINE;
k> printf ">>>%s<<<\n", scalar $io_string->READLINE;
k> }
k> with
k> {
k> my $io_string = IO::String->new( scalar slurp( $0 ) ); # <- only this line changed
well, now it slurps the file to a scalar and not a list of lines.
and the IO::Scalar docs disagree with your call:
new [ARGS...]
Class method. Return a new, unattached scalar handle. If any
arguments are given, they're sent to open().
open [SCALARREF]
Instance method. Open the scalar handle on a new scalar, pointed
to by SCALARREF. If no SCALARREF is given, a "private" scalar is
created to hold the file data.
Returns the self object on success, undefined on error.
so you aren't even calling it correctly. you need to pass it a scalar
ref and you are passing it a scalar value or a scalar. maybe it can
handle that but it doesn't say that in the docs (at least what i read).
k> Still, this is quite a curveball. I see that in the original
k> version, the call to slurp was happenning in a list context, and
k> this probably messes up the string that actually gets used to define
k> the IO::String object. But still, this does not explain why READLINE
k> believes its in a list context. (I'm sorry that I can't show this
k> easily; one needs to step there with the debugger).
as i said, see the docs for printf. after the format it expects a list
so that call will be in list context.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 11 Jun 2010 13:50:20 -0500
From: John Bokma <john@castleamber.com>
Subject: Re: graphics
Message-Id: <87ljal76ab.fsf@castleamber.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 10 Jun 2010 22:37:56 +0200 Mart van de Wege <mvdwege@mail.com> wrote:
>
> MvdW> I used SVG::TT:Graph to generate the graphs, Image::Magick to
> MvdW> convert them to PNG, Template Toolkit to build LaTex files
> MvdW> referring to the images, and LaTeX::Driver to render the LaTeX to
> MvdW> PDF.
>
> MvdW> Works like a charm, even if the toolchain is long. LaTeX::Driver is a
> MvdW> bit finicky if you don't clean up your working directory though.
>
> Any chance you can publish your toolchain to convert a series of PNG
> files to a PDF file?
While most likely not an answer to your question, some time ago I wrote
this:
http://johnbokma.com/mexit/2009/02/24/jpeg-to-pdf-using-perl.html
to create a pdf with one JPEG per page.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Fri, 11 Jun 2010 22:02:21 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: graphics
Message-Id: <86pqzxbanm.fsf@gareth.avalon.lan>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 10 Jun 2010 22:37:56 +0200 Mart van de Wege <mvdwege@mail.com> wrote:
>
> MvdW> I used SVG::TT:Graph to generate the graphs, Image::Magick to
> MvdW> convert them to PNG, Template Toolkit to build LaTex files
> MvdW> referring to the images, and LaTeX::Driver to render the LaTeX to
> MvdW> PDF.
>
> MvdW> Works like a charm, even if the toolchain is long. LaTeX::Driver is a
> MvdW> bit finicky if you don't clean up your working directory though.
>
> Any chance you can publish your toolchain to convert a series of PNG
> files to a PDF file?
>
Hmm. Sure thing, but it's in three fairly substantive package files. Do
you want that posted here, or in a private mail?
Also, I may have to anonymise our company name, which is referred to
quite often in variables and directory/file names.
So tell me, how do you want it?
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sat, 12 Jun 2010 00:53:27 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: graphics
Message-Id: <4c12be67$0$22936$e4fe514c@news.xs4all.nl>
Huub wrote:
> I'm using Perl to print from database, which works great. Now I'd like to
> print a .JPG picture with it. However, searching CPAN I find a LOT of
> graphics modules. Any recommendation which one to use for this?
WebKit is great for this.
http://code.google.com/p/wkhtmltopdf/
--
Ruud
------------------------------
Date: Sat, 12 Jun 2010 01:15:40 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: How to read a given number of lines?
Message-Id: <4c12c39c$0$22936$e4fe514c@news.xs4all.nl>
Peng Yu wrote:
> I want to give a given number of lines. Current, I have to write the
> following code to read, for example, 3 lines. Is there a subroutine to
> read a given number of lines in an array?
>
> $line1=<IN>;
> $line2=<IN>;
> $line3=<IN>;
$ echo -e 'a\nb\nc\nd\ne\n' | perl -wle'
sub get_lines {
my ( $fh, $max, $aref )= @_;
my $count;
while ( ++$count <= $max and defined( my $line= <$fh> ) ) {
push @$aref, $line;
}
return $count;
}
my @lines;
get_lines +STDIN, 2, \@lines;
print for @lines;
'
a
b
--
Ruud
------------------------------
Date: Fri, 11 Jun 2010 20:57:22 -0700 (PDT)
From: Peng Yu <pengyu.ut@gmail.com>
Subject: How to return the line number that right next to a match?
Message-Id: <b83c2c19-6f70-47fc-8343-1e3487262e4e@g19g2000yqc.googlegroups.com>
After I did a regex match, I want to figure out what the line number
is after the match in (). Is there an easy way to do it?
$string =~ /xxxx(somepattern)yyyy/;
------------------------------
Date: Sat, 12 Jun 2010 06:00:54 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: How to return the line number that right next to a match?
Message-Id: <4c130676$0$22917$e4fe514c@news.xs4all.nl>
Peng Yu wrote:
> After I did a regex match, I want to figure out what the line number
> is after the match in (). Is there an easy way to do it?
>
> $string =~ /xxxx(somepattern)yyyy/;
Do you mean that your $string contains multiple lines?
Otherwise see $. in perlvar, as you have been told before.
--
Ruud
------------------------------
Date: Fri, 11 Jun 2010 17:15:31 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Why does perl allow so many different ways of doing essentially the same thing?
Message-Id: <86zkz15kzw.fsf@mithril.chromatico.net>
>>>>> "PY" == Peng Yu <pengyu.ut@gmail.com> writes:
PY> Rather than being hypothetically saying there are different ways
PY> of coding for different parameter values. I'd like to see what
PY> the best code is for reading three lines and what is the best
PY> code is for reading 10000 lines?
PY> And I would like to know how much time and effort it would
PY> require to know the different between the different code and how
PY> much actually difference (say in performance or whatever
PY> metrics) can be gained by careful choosing different ways.
You're a programmer, and programming is as much empirical art as
theoretical science. Try it and see, and learn something.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Fri, 11 Jun 2010 20:21:01 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Why does perl allow so many different ways of doing essentially the same thing?
Message-Id: <4c127e8f$0$6886$9b4e6d93@newsspool2.arcor-online.net>
Peng Yu wrote:
> According to Programming Perl, more than one way may not always be
> better. But I just don't see more than one way is better at all.
More than one way is not always better, but cluttering the
namespaces with tons of seldom needed shortcuts for short -
and only in certain cases efficient - idioms doesn't sound very
appealing to me either.
It reminds me a bit of a discussion back in the old days in
college in the basic x86 assembly language lecture. People were
complaining all over why there needed to be a difference between
long jumps and short jumps. Of course, all of those who complained
also wrote excruciatingly long and complicated code blocks.
The answer from our professor was along the lines of: as
sophisticated as your computer may look, it's only a dumb machine
that knows nothing about how to solve a problem in the best
possible way. For a program to be efficient, it needs to
stick to rules like not jumping wildly all over memory or not
pushing unneccessary items on the stack only to retrieve them
and push them again because the needed value turns out to be
the third-to-last each time that piece of your code is run.
Your job in programming is to come as close as possible to
the most efficient code to solve a certain problem. You can
either, as we do here in assembly language, work close to
the real data and algorithms that the computer runs and
fine-tune what it does to perfectly match the problem. On
the other hand, you could use a higher level language to
solve the same problem and use built-in functions instead of
coding them yourselves, but then you'd have to hope that whoever
implemented those built-ins anticipated your exact needs when
they wrote them - would you risk that to solve a time critical
problem?
He continued to point out that there were some semi-builtins
for often encountered problems in the form of macro libraries,
but it also became clear for everyone, after thinking up all
kinds of shortcuts which might come in handy, that the resulting
language wouldn't really be assembly language anymore and that
there were in fact problems where assembly language was the best
possible means to solve them.
I'd say the same is true for Perl. Its power lies in the fact
that it gives the possibility to work one step closer to the
machine than with other competing languages like e.g. Java, C#
or PHP.
A good example for that is one topic I stumble over in my daily work
quite often: webservices. Perl definitely is not my tool of
choice to quickly click together standardized webservices or
to consume and validate them with graphical output. There are
libraries and apps written in C#, Java and what else that do
that though. However, nearly every second webservice instance
I have to connect to is in some way non-standard, starting from
lacking DTDs to really broken nesting, wrong data types etc.
Those click-and-forget tools all do the same thing in such a
case, they throw an error and give up. With Perl, it's a trifle
to program a filter or proxy that pre-processes the data, checks
for errors and, most importantly, modifies the underlying data to
eliminate them.
Perl, in my mind, is a such a powerful language due to its loose
typing, flexible OOP concepts and simple yet powerful commands. A
variable can contain what both is a simple hash and a powerful object
at the same time, and an XML document can both be a nested structure
and a plain concatenation of characters. Where I have access to one
of them, the other is never far away.
If too many implementation details were hidden, people would use
Perl in the same way as all the library-centered languages, and if
features were inefficient in certain cases, they'd demand to change
the implementation of the feature instead of learning to use the
basics. Perl would be just another Python/Javascript/C# with funny
variable names, arrows and braces (though, admittedly, if one looks
more closely at Java-/ECMAScript implementations, those can in parts
also be quite flexible and allow lots of different ways to do the
same thing).
Seeing that we already have those languages, I for my part love it
that Perl tries to focus on what it does best: let the programmer
decide how to solve simple problems efficiently, give them the tools
to wrap and distribute often needed solutions as classes and modules
and, if some module turns out a gem everyone uses, include it in
the core distribution.
-Chris
------------------------------
Date: Sat, 12 Jun 2010 02:36:03 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Why does perl allow so many different ways of doing essentially the same thing?
Message-Id: <4c12d673$0$22942$e4fe514c@news.xs4all.nl>
Peng Yu wrote:
> The following thread shows many ways of reading a given number of
> lines.
>
> http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/478db847f15ce016/fe47580f819866cb?lnk=gst&q=pengyu.ut#fe47580f819866cb
>
> But I doubt that having multiple ways of doing the same thing really
> give us any advantages over other languages.
Who is your "us"?
> Essentially this can be
> encapsulate in a subroutine, which is easy for refactoring and code
> transformation.
Indeed, and in Perl, such subroutines are easy to write. Many of them
are already written, see CPAN.
> Is there any study with concrete data demonstrates how this multiple-
> way-of-doing-the-same-thing philosophy actually can help programmer
> improve productivity?
I have no idea what you try to mean by that. Most reasonable people tend
to reuse and follow what others already did, and build on from there.
--
Ruud
------------------------------
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 2986
***************************************
