[23135] in Perl-Users-Digest
Perl-Users Digest, Issue: 5356 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 14 09:05:46 2003
Date: Thu, 14 Aug 2003 06:05:11 -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 Thu, 14 Aug 2003 Volume: 10 Number: 5356
Today's topics:
Re: 'make' implemented in Perl <abigail@abigail.nl>
Re: 'make' implemented in Perl <tzz@lifelogs.com>
Re: 'make' implemented in Perl <tzz@lifelogs.com>
Re: 'make' implemented in Perl <abigail@abigail.nl>
Re: 'make' implemented in Perl <bart.lateur@pandora.be>
finding subdirectories without parsing every file (Helen)
Re: finding subdirectories without parsing every file <noreply@gunnar.cc>
Re: FrontPage and perl (gnarred)
Re: Help w/ BNB Survey Script <-- <REMOVEsdnCAPS@comcast.net>
Re: Help w/ BNB Survey Script <-- <noreply@gunnar.cc>
Re: how big can a scalar get? (gnarred)
Re: I need GD for Redhat 9 <devdas@users.sourceforge.net>
Re: Newbie question !! <mikeflan@earthlink.net>
Re: Perl and recursive copying? <tore@aursand.no>
Re: Perl and recursive copying? (James E Keenan)
Re: please critique...random link generator <abigail@abigail.nl>
Re: please critique...random link generator <bart.lateur@pandora.be>
Re: please critique...random link generator <abigail@abigail.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 14 Aug 2003 09:02:02 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: 'make' implemented in Perl
Message-Id: <slrnbjmk0a.92t.abigail@alexandra.abigail.nl>
Ted Zlatanov (tzz@lifelogs.com) wrote on MMMDCXXXV September MCMXCIII in
<URL:news:4nadadyrb8.fsf@lockgroove.bwh.harvard.edu>:
== On Thu, 14 Aug 2003, merlyn@stonehenge.com wrote:
==
== >>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
== > Ted> This comes up periodically in Perl discussion lists, and
== > Ted> usually the answer is "just wait for XYZ, it will do this and
== > Ted> more." I'm not sure what the current XYZ is/are, especially
== > Ted> regarding why XYZ hasn't yet replaced 'make' in CPAN installs
== > Ted> and standard Perl usage. I'm very interested in any
== > Ted> information, as I have needed tighter integration between Perl
== > Ted> and 'make' many times.
== >
== > There already *is* one.
== >
== > <http://search.cpan.org/author/NI-S/Make-1.00/>
== >
== > 11 April 1999 for the release date.
==
== Right, and there's also make.pl and Cons as I mentioned. Thanks for
== the info!
==
== Now, my question is why CPAN is still relying on the old-fashioned
== external make. Parrot seems to be aimed towards using the new Make
== you mention above, which is very good news indeed. Maybe it's just
== easier not to change CPAN? :)
==
That has nothing to do with CPAN. It's up to each module author to
decide how his/her module gets installed. Most people decide to go
the usual way, which includes the use of a 'make'.
If you don't have a working 'make', install one. If you can't install
software for whatever reason, you can't install a Perl based make either.
If you think not using a traditional make is the way to go, please
lobby each individual CPAN module author.
Abigail
--
#!/opt/perl/bin/perl -- # No trailing newline after the last line!
BEGIN{$|=$SIG{__WARN__}=sub{$_=$_[0];y-_- -;print/(.)"$/;seek _,-open(_
,"+<$0"),2;truncate _,tell _;close _;exec$0}}//rekcaH_lreP_rehtona_tsuJ
------------------------------
Date: Thu, 14 Aug 2003 07:03:08 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: 'make' implemented in Perl
Message-Id: <4n1xvozekz.fsf@lockgroove.bwh.harvard.edu>
On 14 Aug 2003, abigail@abigail.nl wrote:
> That has nothing to do with CPAN. It's up to each module author to
> decide how his/her module gets installed. Most people decide to go
> the usual way, which includes the use of a 'make'.
I think most modules (99.99%?) use Makefile.PL, which currently means
having to use `make' but, because of what Perl can do internally,
could be replaced. Let's assume for the moment that `make' is still
useful for compiling modules with C code; I'm talking about pure Perl
modules. For those, "perl Makefile.PL; make; make install" could be
simply "perl Makefile.PL install" or something similar.
Now the question becomes, "why not keep make for everything if it's
still needed for 50% (or whatever portion has C code) of the
modules?" I think you have to start somewhere, and that the
migration to 100% Perl-based Makefile.PL interpretation should be as
easy as possible.
> If you don't have a working 'make', install one. If you can't
> install software for whatever reason, you can't install a Perl based
> make either.
Not if the Perl-based make is a part of the core (like
ExtUtils::MakeMaker). You and Eric are saying it's no big deal to
install `make.' It's not a big deal for experienced users, but at the
very least it's a hassle for new Perl users on the Windows platform.
> If you think not using a traditional make is the way to go, please
> lobby each individual CPAN module author.
I understand the magnitude of such an undertaking, and am not
proposing modifying all CPAN modules, but rather the interpretation
of Makefile.PL when the module is installed.
Ted
------------------------------
Date: Thu, 14 Aug 2003 07:15:35 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: 'make' implemented in Perl
Message-Id: <4nwudgxzfs.fsf@lockgroove.bwh.harvard.edu>
On 14 Aug 2003, tassilo.parseval@rwth-aachen.de wrote:
> Also sprach Ted Zlatanov:
>> Now, my question is why CPAN is still relying on the old-fashioned
>> external make.
>
> Because it generally works. The whole of CPAN currently consist of
> modules which are installed using ExtUtils::MakeMaker. This one
> produces a Makefile that does the right thing for all imaginable
> platforms. Changing that would surely cause problems for a
> considerable number of the many thousand CPAN distributions.
I'm all for stability, but CPAN modules do have tests. It's not too
crazy to modify the CPAN.pm framework and then do regression testing,
is it? If anything, internalizing the Makefile.PL parsing instead of
always relying on an external `make' will make things faster, easier,
and simpler. ExtUtils::MakeMaker is the key here.
The Makefile generated from "perl Makefile.PL" in such a framework
could be just a wrapper for "perl Makefile.PL <action>" for backwards
compatibility...
> However, there is Module::Build which will sooner or later replace
> ExtUtils::MakeMaker. It no longer relies on make but instead
> produces a framework that will obey to
>
> perl Build.PL
> ./Build
> ./Build test
> ./Build install
>
> The first line will produce a Perl script 'Build' that contains all
> the functionality that was previously specified in Makefile.
That's the fourth alternative to make and second make-replacement CPAN
module mentioned so far (Make being the other one). I hope a clear
winner emerges. My opinion is that the existing Makefile.PL has to be
migrated or interpreted seamlessly for CPAN installs, so replacing
ExtUtils::MakeMaker is harder than extending it given the number of
modules and authors.
> Of course, such a change in the build process only makes sense when
> other tools can deal with it. For instance, h2xs wont yet create a
> module skeleton for Module::Build. I am not sure about CPAN.pm
> either. Current release might already be able to deal with those
> modules, but older ones certainly aren't.
There's also the documentation written, volumes and volumes of it in
soft- and hardcopy, that would have to be modified. I'd rather see
the existing Makefile.PL parsed than a new system replacing it.
Ted
------------------------------
Date: 14 Aug 2003 11:25:14 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: 'make' implemented in Perl
Message-Id: <slrnbjmscq.apl.abigail@alexandra.abigail.nl>
Ted Zlatanov (tzz@lifelogs.com) wrote on MMMDCXXXV September MCMXCIII in
<URL:news:4n1xvozekz.fsf@lockgroove.bwh.harvard.edu>:
%% On 14 Aug 2003, abigail@abigail.nl wrote:
%%
%% > That has nothing to do with CPAN. It's up to each module author to
%% > decide how his/her module gets installed. Most people decide to go
%% > the usual way, which includes the use of a 'make'.
%%
%% I think most modules (99.99%?) use Makefile.PL, which currently means
%% having to use `make' but, because of what Perl can do internally,
%% could be replaced. Let's assume for the moment that `make' is still
%% useful for compiling modules with C code; I'm talking about pure Perl
%% modules. For those, "perl Makefile.PL; make; make install" could be
%% simply "perl Makefile.PL install" or something similar.
No. Then you are not understanding 'make', which tries to do its utter
best not to create something that is already there.
%% Now the question becomes, "why not keep make for everything if it's
%% still needed for 50% (or whatever portion has C code) of the
%% modules?" I think you have to start somewhere, and that the
%% migration to 100% Perl-based Makefile.PL interpretation should be as
%% easy as possible.
%%
%% > If you don't have a working 'make', install one. If you can't
%% > install software for whatever reason, you can't install a Perl based
%% > make either.
%%
%% Not if the Perl-based make is a part of the core (like
%% ExtUtils::MakeMaker). You and Eric are saying it's no big deal to
%% install `make.' It's not a big deal for experienced users, but at the
%% very least it's a hassle for new Perl users on the Windows platform.
That is not an argument. It would if Perl was the only software that
makes use of 'make', but the fast majority of software requires 'make'
to build. The users of a Windows platform would be more helped with
getting 'make', than with Perl circumventing the use of 'make'.
You are trying the wrong solution to a problem. The problem is Windows
not being equipped with 'make'. The fix isn't for one particular piece
of software spending lots of efforts not to use make (and which will
work in just a few cases). The fix is to install 'make' on Windows.
But if you think there's a better way: code speaks more than words.
Abigail
--
$_ = "\x3C\x3C\x45\x4F\x54\n" and s/<<EOT/<<EOT/ee and print;
"Just another Perl Hacker"
EOT
------------------------------
Date: Thu, 14 Aug 2003 12:18:15 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: 'make' implemented in Perl
Message-Id: <cfvmjvgbvbg52jgv0l7tusldb43kak3qsv@4ax.com>
Tassilo v. Parseval wrote:
>> Now, my question is why CPAN is still relying on the old-fashioned
>> external make.
>
>Because it generally works.
But OTOH, ExtUtils::MakeMaker is pretty much broken.
--
Bart.
------------------------------
Date: 14 Aug 2003 00:45:26 -0700
From: helen@helephant.com (Helen)
Subject: finding subdirectories without parsing every file
Message-Id: <33517f44.0308132345.24a560a8@posting.google.com>
Hi
Is there any way to get the subdirectories of a directory without
having to sort through all the files in a directory?
I'm actually building a little perl script that looks at the
directories and then prints out a directory tree (as a webpage).
I've been using file::find to generate the directory tree but it's too
slow. I think the problem is that it looks at each file in the
directory. I'm not interested in what's in the directory, I just want
to know what the subdirectories are.
It takes about 30 seconds to build the directory tree on some of the
larger sites and the directory searching seems to be where the
bottlekneck is. That's compared to around 5 seconds to just download
the file.
Thanks :)
Helen
------------------------------
Date: Thu, 14 Aug 2003 15:02:01 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: finding subdirectories without parsing every file
Message-Id: <bhg17o$bqc7$1@ID-184292.news.uni-berlin.de>
Helen wrote:
> Is there any way to get the subdirectories of a directory without
> having to sort through all the files in a directory?
<snip>
> I've been using file::find to generate the directory tree but it's
> too slow.
How about posting some code that shows how you've made use of File::Find?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 14 Aug 2003 00:47:39 -0700
From: gnarred@yahoo.com (gnarred)
Subject: Re: FrontPage and perl
Message-Id: <2edd058c.0308132347.10085e7d@posting.google.com>
jgamble@ripco.com (John M. Gamble) wrote in message news:<bhe1rh$k0p$1@e250.ripco.com>...
> Are there any known "gotchas" when developing with FrontPage
> and perl? The ISP provides perl for the server side, and my
> friend's husband is very insistent about using FrontPage for
> designing the website.
>
> It's not my first choice, but i'm willing to go along. So...
>
> Anything i should look out for (excluding the usual MS-bashing)?
> This will be my first foray into FrontPage.
I've worked on a large web site maintained via Frontpage and I can
tell you this: if you edit and upload files apart from Frontpage you
will eventually run into problems. If you're going to use Frontpage as
your HTML editor be sure you don't edit & upload too many files with a
different editor or FTP program (or, alter Frontpage-generated files
with a Perl CGI). Frontpage may also delete files that aren't in the
web it's trying to upload, so be careful.
gnarred
------------------------------
Date: Thu, 14 Aug 2003 04:49:03 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Help w/ BNB Survey Script <--
Message-Id: <Xns93D73B382F10Dsdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bhfc44$3nbn$1@ID-
184292.news.uni-berlin.de:
> 1) Lori and you said in effect that all authors of free scripts are
> morons. That is obviously not true.
It's true to a first-order approximation.
> 2) I'm sure it's true that many of the free scripts are badly written
I agree with Uri: "most".
> and provided without support and/or maintenance. Sad, but natural.
I don't see that as particularly "natural". If one thinks one's code is
good enough and general enough to share with the world at large, I would
think that it's more "natural" to accept constructive criticism for it, and
to provide bug fixes and documentation for it.
> That's how it is. And, still, somebody who shares his or her work with
> the world is not automatically a moron, even if s/he does not provide
> free support etc. in addition to the free code.
I suppose not. But it is pretty moronic to throw non-working code out
there, or code that is inadequately documented, or code that has bugs that
one refuses to fix, or code that is sufficiently confusing that ordinary
people have problems using it.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPztbGmPeouIeTNHoEQIMwgCdH/yRFLgUgp1cJj6synz36Uc9ENcAoKNr
v+nBdN3509nT1hzvVksV+zZd
=7+Tw
-----END PGP SIGNATURE-----
------------------------------
Date: Thu, 14 Aug 2003 14:47:23 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Help w/ BNB Survey Script <--
Message-Id: <bhg0c9$bilv$1@ID-184292.news.uni-berlin.de>
Eric J. Roode wrote:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in
> news:bhfc44$3nbn$1@ID- 184292.news.uni-berlin.de:
>
>> 1) Lori and you said in effect that all authors of free scripts
>> are morons. That is obviously not true.
>
> It's true to a first-order approximation.
Even if you turned from _all_ to _approximation_, are you really sure
of that? I'm certainly not.
One of my "free scripts" is provided within a SourceForge project.
There are about 65,000 such projects. Are you telling me that
"approximately" all the free software there is crap, and the
developers morons? ;-)
Two free scripts I'm using are MHonArc (http://www.mhonarc.org) and
Links (http://www.gossamer-threads.com/scripts/links/).
Etc., etc.
To be honest, I don't get it. I don't get it at all.
This is a Usenet group where an open source software (aka Perl) is
discussed. Instead of making such patronizing, generalizing statements
about free scripts and their authors, wouldn't it be much more
appropriate to acknowledge the power implied in the spreading of free
software, and encourage more of the kind?
Don't let your justified indignation with Matt Wright colour all you
say and do!!
>> and provided without support and/or maintenance. Sad, but
>> natural.
>
> I don't see that as particularly "natural". If one thinks one's
> code is good enough and general enough to share with the world at
> large, I would think that it's more "natural" to accept
> constructive criticism for it, and to provide bug fixes and
> documentation for it.
I believe that many authors make their software available in the hope
1) it will be useful for others
2) it will be further developed by others
but _without_ being ready to assist, at least not for free.
> it is pretty moronic to throw non-working code out there, or code
> that is inadequately documented, or code that has bugs that one
> refuses to fix, or code that is sufficiently confusing that
> ordinary people have problems using it.
Yes, of course. With whom are you discussing now, btw? Reacting to a
precipitate statement is not equal to advocating all sorts of bad
behaviour.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 14 Aug 2003 00:54:29 -0700
From: gnarred@yahoo.com (gnarred)
Subject: Re: how big can a scalar get?
Message-Id: <2edd058c.0308132354.7eb19a4d@posting.google.com>
"Vassilis Tavoultsidis" <ixanthi@ixanthi.remove.gr> wrote in message news:<bhd6rj$n0$1@nic.grnet.gr>...
> What happens if I make a simple scalar variable big? What memory problems it
> can give me and what is the limit?
>
> e.g.
>
> $t = "";
> $maxlen = 100000;
> while (length($t) < $maxlen)
> {
> $t = $t.$i."|";
> };
Just one question: what is $i set to? Also, you don't need the ; after
the ending bracket of the while loop.
You might also try:
$t = "$i|" x $maxlen;
Of course, if $i is your counter, you can do this:
print join('', map { "$_|" } 0..$maxlen);
gnarred
------------------------------
Date: 14 Aug 2003 10:39:35 GMT
From: Devdas Bhagat <devdas@users.sourceforge.net>
Subject: Re: I need GD for Redhat 9
Message-Id: <slrnbjmpm3.48f.devdas@evita.devdas.geek>
On Thu, 07 Aug 2003 12:56:50 +0100, Simon Andrews <simon.andrews@bbsrc.ac.uk>
poured into the usenet group comp.lang.perl.misc:
>
> Jim Rendant wrote:
>> I downloaded the GD module from CPAN and tried to compile it on redhat 9 and
>> it fails. Where can I get a pre-compiled version of this module?
>
> Don't know about RH9, but I've just managed to get GD installed on RH8,
> and it was a right pain! The latest perl GD module won't work because
> the gd-lib version on RH8 (and I think 9) is too old. I managed to
Right. I did this for RH 7.3:
Download the RedHat Rawhide GD source rpm.
rpm --rebuild gd-2.0.12-src.rpm
Install the binary.
Install XFree86-devel, libpng-devel, libjpeg-devel and freetype-devel and
gd-devel.
#perl -MCPAN -e'install GD'
Works fine for me.
Devdas Bhagat
------------------------------
Date: Thu, 14 Aug 2003 12:31:44 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Newbie question !!
Message-Id: <3F3B81C4.9AA56DAF@earthlink.net>
Wesley Tam wrote:
> Hi !
>
> What is the different between ??
>
> #!/usr/bin/perl -w
> and
> #!/usr/bin/perl
>
> I'm newbie, I just start to learn perl
>
> Thanks
You might want to learn posting rules also.
Re: Newbie question !! is not a good subject.
Use something more descriptive.
Mike
------------------------------
Date: Thu, 14 Aug 2003 10:58:35 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: Perl and recursive copying?
Message-Id: <pan.2003.08.14.08.58.31.631290@aursand.no>
On Thu, 14 Aug 2003 00:20:21 +0000, Kyle Witherspoon wrote:
> For now, I'm trying to have it copy the contents of
> /usr/apache/joe
> to /usr/apache/bill.
Why don't you use 'cp -R /usr/apache/joe/* /usr/apache/bill/.'?
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: 14 Aug 2003 05:46:36 -0700
From: jkeen@concentric.net (James E Keenan)
Subject: Re: Perl and recursive copying?
Message-Id: <b955da04.0308140446.4267b42f@posting.google.com>
Kyle Witherspoon <kylewitherspoon@hotmail.com> wrote in message news:<9BA_a.12846$mB5.905077@twister.southeast.rr.com>...
> I'm trying to write a web based perl script that writes a self
> replicating website.
> For now, I'm trying to have it copy the contents of
> /usr/apache/joe
> to /usr/apache/bill.
>
> So I need it to programmatically create bill and copy the entire
> contents of joe...I'm using Perl 5.6.0 and none of the File::Copy
> commands are working, or I am doing it wrong..anyone have a bone to
> throw? thanks
You'll have to show us your code in order for us to determine what's going wrong.
------------------------------
Date: 14 Aug 2003 09:04:28 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: please critique...random link generator
Message-Id: <slrnbjmk4s.92t.abigail@alexandra.abigail.nl>
Brian Harnish (bharn_S_ish@te_P_chnologi_A_st._M_com) wrote on MMMDCXXXIV
September MCMXCIII in <URL:news:pan.2003.08.13.22.37.09.305340@te_P_chnologi_A_st._M_com>:
][ On Wed, 13 Aug 2003 17:01:07 -0700, Hudson wrote:
][
][ > Hi everyone,
][ >
][ > Here's a subroutine I made using the fisher yates shuffle from the
][ > perl faq's to print a random number of links to a web page. But I was
][ > wondering if there is a simplier way to do this. The idea was to have
][ > non-repeating links, so that's why I choose this method. Thanks in
][ > advance and all criticism is welcome ;-)
][
][ First, try passing variables to your subroutines, it makes debugging
][ easier. Next, the code did make sense, and after a minute or two of
][ thought, I came up with a scaled down version. Instead of shuffling the
][ whole array, I just randomly take out a piece.
][
][ sub print_random_links {
][ my ($min, $max, @links) = @_;
][ foreach (1..int(rand($max-$min)+$min)) {
][ my $link = splice(@links, rand @links, 1);
][ my $link_us = $link;
][ # ... etc ...
][ # print $link;
][ }
][ }
This has a worst case running time of Omega (@links * $max), where
shuffling has a worst case running time of O (@links).
People often don't realize that splicing out a single element of an
array could mean moving half the array - which takes time linear to
the size of the array.
Abigail
--
perl -MTime::JulianDay -lwe'@r=reverse(M=>(0)x99=>CM=>(0)x399=>D=>(0)x99=>CD=>(
0)x299=>C=>(0)x9=>XC=>(0)x39=>L=>(0)x9=>XL=>(0)x29=>X=>IX=>0=>0=>0=>V=>IV=>0=>0
=>I=>$==-2449231+gm_julian_day+time);do{until($=<$#r){$_.=$r[$#r];$=-=$#r}for(;
!$r[--$#r];){}}while$=;$,="\x20";print+$_=>September=>MCMXCIII=>=>=>=>=>=>=>=>'
------------------------------
Date: Thu, 14 Aug 2003 12:47:21 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: please critique...random link generator
Message-Id: <j41njvod1cvpip6ks27b36fua8eo6jih2u@4ax.com>
Abigail wrote:
>People often don't realize that splicing out a single element of an
>array could mean moving half the array - which takes time linear to
>the size of the array.
Does it? I thought perl arrays consisted of items that are some small
record (30 bytes or so) pointing towards the actual data?
You'd only move these records, not the data it points to.
--
Bart.
------------------------------
Date: 14 Aug 2003 12:53:07 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: please critique...random link generator
Message-Id: <slrnbjn1hi.aqf.abigail@alexandra.abigail.nl>
Bart Lateur (bart.lateur@pandora.be) wrote on MMMDCXXXV September
MCMXCIII in <URL:news:j41njvod1cvpip6ks27b36fua8eo6jih2u@4ax.com>:
-: Abigail wrote:
-:
-: >People often don't realize that splicing out a single element of an
-: >array could mean moving half the array - which takes time linear to
-: >the size of the array.
-:
-: Does it? I thought perl arrays consisted of items that are some small
-: record (30 bytes or so) pointing towards the actual data?
-:
-: You'd only move these records, not the data it points to.
Yes. But still, moving half on N records still take time linear
in the amount of the size of the array.
It isn't about the size of the elements you move, it's about the
amount of elements you move.
Abigail
--
split // => '"';
${"@_"} = "/"; split // => eval join "+" => 1 .. 7;
*{"@_"} = sub {foreach (sort keys %_) {print "$_ $_{$_} "}};
%{"@_"} = %_ = (Just => another => Perl => Hacker); &{%{%_}};
------------------------------
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 5356
***************************************
