[30142] in Perl-Users-Digest
Perl-Users Digest, Issue: 1385 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 23 03:09:44 2008
Date: Sun, 23 Mar 2008 00:09: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 Sun, 23 Mar 2008 Volume: 11 Number: 1385
Today's topics:
(trivial) unshift and shift vs push and pop <g_m@remove-comcast.net>
Re: (trivial) unshift and shift vs push and pop <noreply@gunnar.cc>
Re: (trivial) unshift and shift vs push and pop <joost@zeekat.nl>
Re: (trivial) unshift and shift vs push and pop xhoster@gmail.com
Re: (trivial) unshift and shift vs push and pop <abigail@abigail.be>
Re: FAQ 6.21 What's wrong with using grep in a void con <szrRE@szromanMO.comVE>
Module for text analysis and comparison? <BLOCKSPAMfishfry@your-mailbox.com>
new CPAN modules on Sun Mar 23 2008 (Randal Schwartz)
strawberry perl: Form method not found <nospam@nospam.com>
Re: XML to Database <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 22 Mar 2008 16:32:35 -0400
From: "~greg" <g_m@remove-comcast.net>
Subject: (trivial) unshift and shift vs push and pop
Message-Id: <AZedna6IYPE18XjanZ2dnUVZ_jCdnZ2d@comcast.com>
I have always imagined arrays in Perl as contiguous stretches
of elements (pointers, or annotated pointers) in ram.
And push and pop as adding and removing from the right side,
without affecting more than one element.
Whereas I imagine shift and unshift as moving the whole
lot of them left and right. Which would make unshift and shift
considerably less efficient, time-wise, than push and pop.
Is that true? When modeling a stack, if there's a choice,
is using push and pop always preferable to using unshift and shift?
(For that reason, or any other?)
~greg
------------------------------
Date: Sat, 22 Mar 2008 21:37:29 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: (trivial) unshift and shift vs push and pop
Message-Id: <64l8siF2bn7qvU1@mid.individual.net>
~greg wrote:
> I have always imagined arrays in Perl as contiguous stretches
> of elements (pointers, or annotated pointers) in ram. And push and pop
> as adding and removing from the right side, without affecting more than
> one element.
> Whereas I imagine shift and unshift as moving the whole lot of them left
> and right. Which would make unshift and shift
> considerably less efficient, time-wise, than push and pop.
> Is that true?
The latter can be easily measured with the Benchmark module.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 22 Mar 2008 21:53:17 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: (trivial) unshift and shift vs push and pop
Message-Id: <8763vemqf6.fsf@zeekat.nl>
"~greg" <g_m@remove-comcast.net> writes:
> Whereas I imagine shift and unshift as moving the whole lot of them
> left and right. Which would make unshift and shift
> considerably less efficient, time-wise, than push and pop.
this isn't completely true. see below.
> Is that true? When modeling a stack, if there's a choice, is using
> push and pop always preferable to using unshift and shift? (For that
> reason, or any other?)
perl keeps a pointer to the current head of the array inside the
actually allocated memory block, so a shift() followed by an unshift()
is likely to be just as fast as a pop() followed by a push().
If the allocated block is already full on the relevant side, though, I
suspect push() to be (much) more efficient than unshift() - at least if
standard malloc/re-alloc is used. Also, pop() and push() are the usual
names for stack operations, so if only for that reason you should
probably use them when modelling stacks.
side note: in languages that use linked lists to model stacks, pop and
push modify the start of the list.
See also the AV section in
http://www.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 22 Mar 2008 23:59:48 GMT
From: xhoster@gmail.com
Subject: Re: (trivial) unshift and shift vs push and pop
Message-Id: <20080322195951.141$5Y@newsreader.com>
"~greg" <g_m@remove-comcast.net> wrote:
> I have always imagined arrays in Perl as contiguous stretches
> of elements (pointers, or annotated pointers) in ram.
> And push and pop as adding and removing from the right side,
> without affecting more than one element.
>
> Whereas I imagine shift and unshift as moving the whole
> lot of them left and right. Which would make unshift and shift
> considerably less efficient, time-wise, than push and pop.
>
> Is that true?
The internal data structure allows for buffered space on each end which
means moving/allocating has to take place much less often than on every
push/unshift. However, the space seems to be either more generous or
handled more efficiently for push/pop than shift/unshift, making them
slightly faster (on my version of Perl, on my system, etc.)
On the other hand, running ltrace on simple push loops shows that "memmove"
is called on very push or unshift. I suspect some of these memmoves are
degenerate do-nothings, but since I can't figure out how to map the 5
arguments that ltrace reports to the 3 arguments that memmove takes, I
can't figure out exactly what is happening.
Any way, the empirical time differences seem to be negligible.
> When modeling a stack, if there's a choice,
> is using push and pop always preferable to using unshift and shift?
> (For that reason, or any other?)
If modeling a simple LIFO stack, push and pop are preferable. That is
because "push" and "pop" are the words normally associated with LIFO
stacks.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 23 Mar 2008 00:29:51 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: (trivial) unshift and shift vs push and pop
Message-Id: <slrnfub93u.e9.abigail@alexandra.abigail.be>
_
Joost Diepenmaat (joost@zeekat.nl) wrote on VCCCXVII September MCMXCIII
in <URL:news:8763vemqf6.fsf@zeekat.nl>:
;; "~greg" <g_m@remove-comcast.net> writes:
;;
;; > Whereas I imagine shift and unshift as moving the whole lot of them
;; > left and right. Which would make unshift and shift
;; > considerably less efficient, time-wise, than push and pop.
;;
;; this isn't completely true. see below.
;;
;; > Is that true? When modeling a stack, if there's a choice, is using
;; > push and pop always preferable to using unshift and shift? (For that
;; > reason, or any other?)
;;
;; perl keeps a pointer to the current head of the array inside the
;; actually allocated memory block, so a shift() followed by an unshift()
;; is likely to be just as fast as a pop() followed by a push().
;;
;; If the allocated block is already full on the relevant side, though, I
;; suspect push() to be (much) more efficient than unshift() - at least if
;; standard malloc/re-alloc is used. Also, pop() and push() are the usual
;; names for stack operations, so if only for that reason you should
;; probably use them when modelling stacks.
Perl uses its own malloc.
However, repeatedly pushing should be faster than repeated unshifting.
Whenever the allocated memory for the (C) array of SV pointers is full (or
when a boundary is reached), and the array increases beyond a boundary,
Perl allocates new memory, and copies the pointers over. The new slice
of memory will have about 20% surplus room - so an array can increases
for a while before reallocating is needed again. But this surplus room
will be at the end, so you can have many push()es before reallocating
is needed, but not so many unshift()s.
Abigail
--
$_ = "\x3C\x3C\x45\x4F\x54"; s/<<EOT/<<EOT/e; print;
Just another Perl Hacker
EOT
------------------------------
Date: Sat, 22 Mar 2008 07:03:30 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 6.21 What's wrong with using grep in a void context?
Message-Id: <fs33jj01et8@news2.newsguy.com>
Peter J. Holzer wrote:
> On 2008-03-21 22:45, brian d foy <brian.d.foy@gmail.com> wrote:
>> In article <frvbn902r5m@news2.newsguy.com>, szr
>> <szrRE@szromanMO.comVE> wrote:
>>> PerlFAQ Server wrote:
>>>> 6.21: What's wrong with using grep in a void context?
>>>>
>>>> The problem is that grep builds a return list, regardless of the
>>>> context. This means you're making Perl go to the trouble of
>>>> building a list that you then just throw away. If the list is
>>>> large, you waste both time and space. If your intent is to
>>>> iterate over the list, then use a for loop for this purpose.
>>>>
>>>> In perls older than 5.8.1, map suffers from this problem as
>>>> well. But since 5.8.1, this has been fixed, and map is context
>>>> aware - in void context, no lists are constructed.
>>>
>>> So why not simply make grep context aware too? Seems grep would
>>> benefit from this just as much, if not more, as map.
>>
>> You're missing the point. grep makes no sense in void context because
>> it exists to output a list.
>
> The same is true for map. If it makes no sense for grep, then it also
> doesn't make sense for map. Conversely, if it does make sense for map,
> then it also makes sense for grep.
Exactly true.
>> If you want to go a list to run some block of code, use foreach().
>
> I fully agree with this. foreach is right tool for the job.
Wont argue there.
> However, the wording of the FAQ suggests to me that *conceptually* its
> completely ok to use grep or map instead of foreach, you just
> shouldn't do it for performance reasons (and as of 5.8.1, map has
> been "fixed", so use map instead of foreach at will. TIMTOWTDI!
> Yeah!).
Yep. It's all about TIMTOWTDI, that's what always made Perl great :)
> So I'd rather write that the other way around:
>
> When grep (or map) is used in a void context, its return value is
> discarded. All that remains is the loop over its input list.
> Therefore
>
> grep { X } @arr
>
> and
>
> map { X } @arr
>
> do ultimately the same thing as
>
> do { X } for @arr;
>
> but the latter is clearer.
Yep, though some might argue the map/grep version is more elegant, and
easily chainable & nestible (think working on multi-dim arrays, where
you might nest, with at least the outter most being in voice context.
> Also, grep (and before perl 5.8.1, also map) builds the return list
> even in void context, so using the for loop is likely to be faster,
> too.
>
> On a related note, I agree with szr that grep should be optimized for
> scalar context. Constructs like
>
> my $num_matches = grep /foo/ @arr;
>
> or
>
> if (grep /foo/ @arr) { ... }
Exactly. Especially if each element is a ref, you can do something to
the refs. You can do this with 'map' in an optimized way now it seems.
'map' and 'grep' would do the same thing in this regard, though I don't
know if that warrents the optimization, but it may still be a good idea
to do so if it doesn't harm performance.
> are quite common. Instead of building a list, a simple counter can be
> used. In the second case, grep could even short-circuit and return
> true after the first match (although that is likely to break existing
> code which relies on side-effects).
How about having something along the lines of a pragma to control that
behavior (like use strict/no strict.)
--
szr
------------------------------
Date: Sat, 22 Mar 2008 23:21:08 -0700
From: fishfry <BLOCKSPAMfishfry@your-mailbox.com>
Subject: Module for text analysis and comparison?
Message-Id: <BLOCKSPAMfishfry-DDD37F.23210822032008@comcast.dca.giganews.com>
Is there a CPAN module that does statistical text comparison, ie given
two paragraph-length strings, returns a probability saying if they are
similar or different?
I'm thinking of the kind of module that you'd use to implement your own
Baysian filtering, or trying to determine if two anonymous posts on a
message board are written by the same person; things like that.
------------------------------
Date: Sun, 23 Mar 2008 04:42:19 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sun Mar 23 2008
Message-Id: <Jy62EJ.M9C@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
API-Plesk-1.02
http://search.cpan.org/~nrg/API-Plesk-1.02/
OOP interface to the Plesk XML API (http://www.parallels.com/en/products/plesk/).
----
App-Env-0.07
http://search.cpan.org/~djerius/App-Env-0.07/
manage application specific environments
----
BS-HTTPD-0.02
http://search.cpan.org/~elmex/BS-HTTPD-0.02/
A simple lightweight event based web (application) server
----
CGI-CMS-0.3
http://search.cpan.org/~lze/CGI-CMS-0.3/
Content Managment System that runs under mod_perl and and as cgi script.
----
CGI-RSS-0.7.1
http://search.cpan.org/~jettero/CGI-RSS-0.7.1/
provides a CGI-like interface for making rss feeds
----
CGI-Session-4.29_1
http://search.cpan.org/~markstos/CGI-Session-4.29_1/
persistent session data in CGI applications
----
Catalyst-Model-Jifty-DBI-0.05
http://search.cpan.org/~ishigaki/Catalyst-Model-Jifty-DBI-0.05/
Jifty::DBI Model Class with some magic on top
----
DBI-1.603
http://search.cpan.org/~timb/DBI-1.603/
Database independent interface for Perl
----
DBIx-StORM-0.07
http://search.cpan.org/~lukeross/DBIx-StORM-0.07/
Perl extension for object-relational mapping
----
EekBoek-1.03.11
http://search.cpan.org/~jv/EekBoek-1.03.11/
Bookkeeping software for small and medium-size businesses
----
Fukurama-Class-0.03
http://search.cpan.org/~tobiwan/Fukurama-Class-0.03/
Pragma to extend the Perl-OO (in native Perl)
----
Games-Go-Referee-0.05
http://search.cpan.org/~deg/Games-Go-Referee-0.05/
Check the moves of a game of Go for rule violations.
----
Games-SGF-0.03
http://search.cpan.org/~whitcode/Games-SGF-0.03/
A general SGF parser
----
Getopt-Simple-1.49
http://search.cpan.org/~rsavage/Getopt-Simple-1.49/
Provide a simple wrapper around Getopt::Long.
----
HTML-Menu-TreeView-0.88
http://search.cpan.org/~lze/HTML-Menu-TreeView-0.88/
----
HTML-Strip-Whitespace-0.1.6
http://search.cpan.org/~shlomif/HTML-Strip-Whitespace-0.1.6/
Perl extension for stripping whitespace out of HTML.
----
Module-ScanDeps-0.83
http://search.cpan.org/~smueller/Module-ScanDeps-0.83/
Recursively scan Perl code for dependencies
----
PDF-FDF-Simple-0.12
http://search.cpan.org/~schwigon/PDF-FDF-Simple-0.12/
Read and write (Acrobat) FDF files.
----
POE-0.9999_02
http://search.cpan.org/~rcaputo/POE-0.9999_02/
portable multitasking and networking framework for Perl
----
POE-Component-CPAN-LinksToDocs-No404s-Remember-0.001
http://search.cpan.org/~zoffix/POE-Component-CPAN-LinksToDocs-No404s-Remember-0.001/
non-blocking wrapper around CPAN::LinksToDocs::No404s::Remember module
----
POE-Component-IRC-Plugin-CPAN-LinksToDocs-No404s-Remember-0.001
http://search.cpan.org/~zoffix/POE-Component-IRC-Plugin-CPAN-LinksToDocs-No404s-Remember-0.001/
link to http://search.cpan.org/ documentation from IRC (and check that all links lead to existing docs, remembering which ones work)
----
POE-Component-NonBlockingWrapper-Base-0.001
http://search.cpan.org/~zoffix/POE-Component-NonBlockingWrapper-Base-0.001/
POE based base class for non-blocking wrappers around blocking stuff
----
POE-Component-WWW-OhNoRobotCom-Search-0.001
http://search.cpan.org/~zoffix/POE-Component-WWW-OhNoRobotCom-Search-0.001/
non-blocking POE based wrapper around WWW::OhNoRobotCom::Search module
----
Parse-Marpa-0.205_002
http://search.cpan.org/~jkegl/Parse-Marpa-0.205_002/
(Alpha) Earley's algorithm with LR(0) precomputation
----
Text-Template-Simple-0.53
http://search.cpan.org/~burak/Text-Template-Simple-0.53/
Simple text template engine
----
Tie-File-AnyData-0.01
http://search.cpan.org/~motif/Tie-File-AnyData-0.01/
Access the data of a disk file via a Perl array
----
Tie-File-AnyData-0.02
http://search.cpan.org/~motif/Tie-File-AnyData-0.02/
Access the data of a disk file via a Perl array
----
Tie-File-AnyData-Bio-Fasta-0.01
http://search.cpan.org/~motif/Tie-File-AnyData-Bio-Fasta-0.01/
Accessing fasta records in a file via a Perl array.
----
Tk-ColourChooser-1.51
http://search.cpan.org/~tinita/Tk-ColourChooser-1.51/
Perl/Tk module providing a Colour selection dialogue box.
----
WWW-Pastebin-PastebinCom-Retrieve-0.001
http://search.cpan.org/~zoffix/WWW-Pastebin-PastebinCom-Retrieve-0.001/
The great new WWW::Pastebin::PastebinCom::Retrieve!
----
WWW-Pastebin-PhpfiCom-Retrieve-0.001
http://search.cpan.org/~zoffix/WWW-Pastebin-PhpfiCom-Retrieve-0.001/
retrieve pastes from http://phpfi.com/ website
----
WWW-Pastebin-RafbNet-Retrieve-0.001
http://search.cpan.org/~zoffix/WWW-Pastebin-RafbNet-Retrieve-0.001/
retrieve pastes from http://rafb.net/paste/ website
----
WordNet-SenseRelate-WordToSet-0.03
http://search.cpan.org/~tpederse/WordNet-SenseRelate-WordToSet-0.03/
find sense of a target word most related to given set of words
----
XS-Writer-0.01
http://search.cpan.org/~mschwern/XS-Writer-0.01/
Module to write some XS for you
----
XS-Writer-0.02
http://search.cpan.org/~mschwern/XS-Writer-0.02/
Module to write some XS for you
----
cpan_bot-0.07
http://search.cpan.org/~zoffix/cpan_bot-0.07/
an IRC CPAN Info bot
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Sun, 23 Mar 2008 04:09:12 -0000
From: "Nospam" <nospam@nospam.com>
Subject: strawberry perl: Form method not found
Message-Id: <fs4l5u$873$1@north.jnrs.ja.net>
I am trying to use Strawberry perl, and it says form method cannot be found,
from cpan within strawberry perl it says HTML::Form is uptodate, is this a
known issue?
------------------------------
Date: Sat, 22 Mar 2008 19:07:23 GMT
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: XML to Database
Message-Id: <slrnfuap80.vdu.tadmc@tadmc30.sbcglobal.net>
worlman385@yahoo.com <worlman385@yahoo.com> wrote:
> I though XML Schema is used for defining what kind of Element or
> attribute should appear in an XML document right?
>
> But from above example, XSD schema can also used to describe how XML
> document should be map to a Database table too???
>
> Then XSD can be think of a document that describe how One want to
> manipulate a specific XMLfile?
>
> So, XSD schema to be used to describe anything about data manipulate
> of an XML???
>
> Above is the only use of XSD schema?
This is the Perl newsgroup.
We discuss things related to the Perl programming language here.
Not one of your questions is related to the Perl Programming language.
You are in the wrong newsgroup.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
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 1385
***************************************
