[13908] in Perl-Users-Digest
No subject found in mail header
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 10 17:45:00 1999
Date: Mon, 8 Nov 1999 12:08:02 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <942091681-v9-i1304@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 8 Nov 1999 Volume: 9 Number: 1304
Today's topics:
Re: It is always like this here? (Abigail)
Re: It is always like this here? <emschwar@rmi.net>
Re: It is always like this here? <wyzelli@yahoo.com>
Re: It is always like this here? (Abigail)
Re: It is always like this here? (Kragen Sitaker)
Re: It is always like this here? <wyzelli@yahoo.com>
Re: It is always like this here? <gellyfish@gellyfish.com>
Re: It is always like this here? (Eric Bohlman)
Re: It is always like this here? <wyzelli@yahoo.com>
Re: It is always like this here? <emschwar@rmi.net>
Large hash: advice? <jon@midnightbeach.com>
Re: Large hash: advice? (Alan Barclay)
Re: Large hash: advice? (Kragen Sitaker)
Re: length (number of items) of an array <gellyfish@gellyfish.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 5 Nov 1999 09:31:59 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: It is always like this here?
Message-Id: <slrn825uaf.dk.abigail@alexandra.delanet.com>
Wyzelli (wyzelli@yahoo.com) wrote on MMCCLVII September MCMXCIII in
<URL:news:tDAU3.21$aq3.4009@vic.nntp.telstra.net>:
'' Kragen Sitaker <kragen@dnaco.net> wrote in message
'' news:0xoU3.28525$23.1514419@typ11.nn.bcandid.com...
'' >
'' > It is verifiably true that learning to read documentation will help
'' > people. But I do suspect that the growing numbers of occasional
'' > programmers will behave differently and come up with different support
'' > systems than those of us who do it full-time.
'' >
'' It is also verifiably true that the computer industry has in general
'' produced some of the worst documentation for any product, and Perl tends to
'' be on the low end in terms of quality. (Probably justifiably so...).
Odd. There aren't many free products that come with 1200+ pages of
documentation - in several different formats. And I disagree that the
documentation is `on the low end in terms of quality'.
Abigail
--
sub _'_{$_'_=~s/$a/$_/}map{$$_=$Z++}Y,a..z,A..X;*{($_::_=sprintf+q=%X==>"$A$Y".
"$b$r$T$u")=~s~0~O~g;map+_::_,U=>T=>L=>$Z;$_::_}=*_;sub _{print+/.*::(.*)/s}
*_'_=*{chr($b*$e)};*__=*{chr(1<<$e)};
_::_(r(e(k(c(a(H(__(l(r(e(P(__(r(e(h(t(o(n(a(__(t(us(J())))))))))))))))))))))))
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 05 Nov 1999 12:27:42 -0700
From: Eric The Read <emschwar@rmi.net>
Subject: Re: It is always like this here?
Message-Id: <xkfzowshh75.fsf@valdemar.col.hp.com>
abigail@delanet.com (Abigail) writes:
> Wyzelli (wyzelli@yahoo.com) wrote on MMCCLVII September MCMXCIII in
> <URL:news:tDAU3.21$aq3.4009@vic.nntp.telstra.net>:
> '' It is also verifiably true that the computer industry has in general
> '' produced some of the worst documentation for any product, and Perl tends to
> '' be on the low end in terms of quality. (Probably justifiably so...).
>
> Odd. There aren't many free products that come with 1200+ pages of
> documentation - in several different formats. And I disagree that the
> documentation is `on the low end in terms of quality'.
There are two points I'd like to make here:
1) Quantity != Quality. Just because Perl has 1200+ pages of
documentation doesn't mean that they're any good. Mind you, in
general, I think they're quality documents, but you can't argue from
volume here.
2) Just because they're accurate doesn't mean they're usable. The Perl
documentation is poorly indexed, and suffers from the "I know how it
works, I just don't remember the syntax" problem UNIX manpages have
been justifiably criticized for for years now.
-=Eric
--
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart
------------------------------
Date: Sat, 6 Nov 1999 12:20:40 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: It is always like this here?
Message-Id: <5IMU3.30$aq3.6820@vic.nntp.telstra.net>
Eric The Read <emschwar@rmi.net> wrote in message
news:xkfzowshh75.fsf@valdemar.col.hp.com...
>
> There are two points I'd like to make here:
>
> 1) Quantity != Quality. Just because Perl has 1200+ pages of
> documentation doesn't mean that they're any good. Mind you, in
> general, I think they're quality documents, but you can't argue from
> volume here.
Well put.
>
> 2) Just because they're accurate doesn't mean they're usable. The Perl
> documentation is poorly indexed, and suffers from the "I know how it
> works, I just don't remember the syntax" problem UNIX manpages have
> been justifiably criticized for for years now.
Also well put.
>
> -=Eric
> --
A case in point: ActivePerl's documentation for Sort (in perlfunc) ** mine
**
sort SUBNAME LIST
sort BLOCK LIST
sort LIST
Sorts the LIST and returns the sorted list value. If SUBNAME or BLOCK is
omitted, sort()s in standard string comparison order.
** Assumes prior knowledge about what a LIST, BLOCK or SUBNAME is, and what
is 'standard string comparison order' **
If SUBNAME is specified, it gives the name of a subroutine
** Do I have to specify the SUBNAME or is it given to me ??**
that returns an integer less than, equal to, or greater than , depending on
how the elements of the array are to be ordered. (The <=> and cmp operators
are extremely useful in such routines.)
** <=> and cmp? What the hell are they? Where the hell do I go looking for
that info? What do they do? **
SUBNAME may be a scalar variable name (unsubscripted), in which case the
value provides the name of (or a reference to) the actual subroutine to use.
In place of a SUBNAME, you can provide a BLOCK as an anonymous, in-line sort
subroutine.
** This sentence implies so much prior knowledge that I won't even try to
pull it apart! **
In the interests of efficiency the normal calling code for subroutines is
bypassed, with the following effects: the subroutine may not be a recursive
subroutine, and the two elements to be compared are passed into the
subroutine not via @_ but as the package global variables $a and $b (see
example below). They are passed by reference, so don't modify $a and $b. And
don't try to declare them as lexicals either.
** One of the few references anywhere to the fact that $a and $b should not
be used. **
Yes I know the answers to some of the questions I asked there, but many
readers don't, and won't find any help elsewhere in the documentation
either.
You wanna try a search on 'SUBNAME' to see if t gets explained? No
glossary! Or maybe it's there, I just don't know how to find it, and if I
can't find it, how can I learn it? I know.. I'll ask in c.l.p.m... WOW...
those bastards flamed me!!! :^)
It has always struck me as somewhat odd that one of the few operating
systems that supports true long file naming, persists in shortening names
into jargon, which often is difficult to relate to the original phrase.
Consider.. the chapters are called things like:
perlop, perlfunc, perlhist, perlre etc
Now, since they are in the Perl documentation, surely the 'perl' bit is
irrelevant, and the other bit could be lengthened into what it really means?
Operators, Functions, History, Regular Expressions....
Then the newbies might actually be able to find what they are looking for,
without a tedious 'is it in this one?' approach. (That includes me)
Not to criticise Perl per se, since 1200+ pages of documentation is a lot,
and written in a consistent style by many different people, with many
examples. But examples do not make up for the absence of a clear
explanation of what a function is actually doing, rather than just how to
use it.
Maybe that's why the pointers to how to find something in the FAQ or
documentation are so helpful... It does actually help people to find stuff.
Wyzelli
------------------------------
Date: 5 Nov 1999 21:37:10 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: It is always like this here?
Message-Id: <slrn8278q5.dk.abigail@alexandra.delanet.com>
Wyzelli (wyzelli@yahoo.com) wrote on MMCCLVIII September MCMXCIII in
<URL:news:5IMU3.30$aq3.6820@vic.nntp.telstra.net>:
[] Eric The Read <emschwar@rmi.net> wrote in message
[] news:xkfzowshh75.fsf@valdemar.col.hp.com...
[] >
[] > There are two points I'd like to make here:
[] >
[] > 1) Quantity != Quality. Just because Perl has 1200+ pages of
[] > documentation doesn't mean that they're any good. Mind you, in
[] > general, I think they're quality documents, but you can't argue from
[] > volume here.
[]
[] Well put.
But lack of quantity would mean low quality. The argument of low quality
cannot be based on volume.
[] > 2) Just because they're accurate doesn't mean they're usable. The Perl
[] > documentation is poorly indexed, and suffers from the "I know how it
[] > works, I just don't remember the syntax" problem UNIX manpages have
[] > been justifiably criticized for for years now.
[]
[] Also well put.
[]
[] A case in point: ActivePerl's documentation for Sort (in perlfunc) ** mine
[] **
[]
[] sort SUBNAME LIST
[] sort BLOCK LIST
[] sort LIST
[] Sorts the LIST and returns the sorted list value. If SUBNAME or BLOCK is
[] omitted, sort()s in standard string comparison order.
[] ** Assumes prior knowledge about what a LIST, BLOCK or SUBNAME is, and what
[] is 'standard string comparison order' **
[] If SUBNAME is specified, it gives the name of a subroutine
[] ** Do I have to specify the SUBNAME or is it given to me ??**
[] that returns an integer less than, equal to, or greater than , depending on
[] how the elements of the array are to be ordered. (The <=> and cmp operators
[] are extremely useful in such routines.)
[] ** <=> and cmp? What the hell are they? Where the hell do I go looking for
[] that info? What do they do? **
[] SUBNAME may be a scalar variable name (unsubscripted), in which case the
[] value provides the name of (or a reference to) the actual subroutine to use.
[] In place of a SUBNAME, you can provide a BLOCK as an anonymous, in-line sort
[] subroutine.
[] ** This sentence implies so much prior knowledge that I won't even try to
[] pull it apart! **
[]
[] In the interests of efficiency the normal calling code for subroutines is
[] bypassed, with the following effects: the subroutine may not be a recursive
[] subroutine, and the two elements to be compared are passed into the
[] subroutine not via @_ but as the package global variables $a and $b (see
[] example below). They are passed by reference, so don't modify $a and $b. And
[] don't try to declare them as lexicals either.
[] ** One of the few references anywhere to the fact that $a and $b should not
[] be used. **
[]
[] Yes I know the answers to some of the questions I asked there, but many
[] readers don't, and won't find any help elsewhere in the documentation
[] either.
[]
[] You wanna try a search on 'SUBNAME' to see if t gets explained? No
It's explained, right there:
If SUBNAME is specified, it gives the name of a subroutine
If you don't know what a subroutine is, there's an entire manpage
dedicated to it. And yes, it will assume that you know what LISTs and
BLOCKs are. The paragraph about "sort" is not an entry point to learn
Perl. Or do you expect from a quality book to open it on a random page,
and have it explain everything mentioned on the page right there, doing
this over and over again for each page? You *got* to be kidding.
[] glossary! Or maybe it's there, I just don't know how to find it, and if I
[] can't find it, how can I learn it? I know.. I'll ask in c.l.p.m... WOW...
[] those bastards flamed me!!! :^)
[]
[] It has always struck me as somewhat odd that one of the few operating
[] systems that supports true long file naming, persists in shortening names
[] into jargon, which often is difficult to relate to the original phrase.
[]
[] Consider.. the chapters are called things like:
[] perlop, perlfunc, perlhist, perlre etc
There is of course a very good reason for that. Not the fact that Perl
runs on systems with long file names, but the fact Perl also runs on
systems that don't have long file names.
[] Now, since they are in the Perl documentation, surely the 'perl' bit is
[] irrelevant, and the other bit could be lengthened into what it really means?
[]
[] Operators, Functions, History, Regular Expressions....
[]
[] Then the newbies might actually be able to find what they are looking for,
[] without a tedious 'is it in this one?' approach. (That includes me)
It looks like you have stripped the redundant 'perl' of your documentation
set, and where unable to do 'man perl', which on the very first pages
starts a list listing all other man pages, which short explainations
what they are.
[] Not to criticise Perl per se, since 1200+ pages of documentation is a lot,
[] and written in a consistent style by many different people, with many
[] examples. But examples do not make up for the absence of a clear
[] explanation of what a function is actually doing, rather than just how to
[] use it.
Well, if you think it can be done better, could you rewrite the section
about sort, such that it no longer uses any assumed knowledge? Just as
a proof of concept, cause I don't think it's possible to write a usable
reference guide that way. But you might be able to convince me otherwise.
It's easy to critize the documentation. Writing documentation is under
appreciated. However, writing documenation doesn't require deep knowledge
of the Perl internals or excellent coding skills. Submit patches to the
documentation - see if you can do better.
I also think that the documentation could be done better in certain ways;
but it's a lot better than you suggest it is.
Abigail
--
echo "==== ======= ==== ======"|perl -pes/=/J/|perl -pes/==/us/|perl -pes/=/t/\
|perl -pes/=/A/|perl -pes/=/n/|perl -pes/=/o/|perl -pes/==/th/|perl -pes/=/e/\
|perl -pes/=/r/|perl -pes/=/P/|perl -pes/=/e/|perl -pes/==/rl/|perl -pes/=/H/\
|perl -pes/=/a/|perl -pes/=/c/|perl -pes/=/k/|perl -pes/==/er/|perl -pes/=/./;
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Sat, 06 Nov 1999 07:41:41 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: It is always like this here?
Message-Id: <VYQU3.40555$23.1764388@typ11.nn.bcandid.com>
In article <slrn825uaf.dk.abigail@alexandra.delanet.com>,
Abigail <abigail@delanet.com> wrote:
>Wyzelli (wyzelli@yahoo.com) wrote on MMCCLVII September MCMXCIII in
><URL:news:tDAU3.21$aq3.4009@vic.nntp.telstra.net>:
>'' It is also verifiably true that the computer industry has in general
>'' produced some of the worst documentation for any product, and Perl tends to
>'' be on the low end in terms of quality. (Probably justifiably so...).
>
>Odd. There aren't many free products that come with 1200+ pages of
>documentation - in several different formats. And I disagree that the
>documentation is `on the low end in terms of quality'.
I agree that the documentation for Perl is complete, generally quite
well-written, and almost entirely correct.
I think it possible that it could benefit from a different scheme of
organization and better indexing, and also some slightly more
task-oriented documentation -- of which perlipc and perltoot are
sterling examples in my book. I also think that I'm talking about a
*lot* of work.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: Sun, 7 Nov 1999 00:02:45 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: It is always like this here?
Message-Id: <j_WU3.55$aq3.8769@vic.nntp.telstra.net>
Abigail <abigail@delanet.com> wrote in message
news:slrn8278q5.dk.abigail@alexandra.delanet.com...
> []
> [] Well put.
>
> But lack of quantity would mean low quality. The argument of low quality
> cannot be based on volume.
Umm, pardon my semantics but isn't that paragraph self contradictory?
>
> It's explained, right there:
> If SUBNAME is specified, it gives the name of a subroutine
No it isn't. What is 'it'? The the undefined 'SUBNAME'? Or the entity to
which 'SUBNAME' has just been defined? Or something else entirely? With a
bit of fooling around I may be able to get it to work, or I may not.
>
> There is of course a very good reason for that. Not the fact that Perl
> runs on systems with long file names, but the fact Perl also runs on
> systems that don't have long file names.
What does that really have to do with the naming of the chapters in the
documentation? I was making a point about naming trends which I see in the
Unix environment, not compatibility with filesystems.
> It looks like you have stripped the redundant 'perl' of your documentation
> set, and where unable to do 'man perl', which on the very first pages
> starts a list listing all other man pages, which short explainations
> what they are.
I have done nothing to my documentation. It is as supplied by ActiveState.
> Well, if you think it can be done better, could you rewrite the section
> about sort, such that it no longer uses any assumed knowledge? Just as
> a proof of concept, cause I don't think it's possible to write a usable
> reference guide that way. But you might be able to convince me otherwise.
No I think I have to agree with you there. Aside from the obvious
implication that I do not have the necessary knowledge to even start. But a
reference guide is is generally a more advanced set of documentation than
your base documentation. Perl's would certainly qualify as the reference
style, particularly considering the vast number of examples included
therein.
>
> It's easy to critize the documentation. Writing documentation is under
> appreciated. However, writing documenation doesn't require deep knowledge
> of the Perl internals or excellent coding skills. Submit patches to the
> documentation - see if you can do better.
I think I was also criticising IT documentation in general, as it is mostly
difficult to use when starting on a new subject.
>
> I also think that the documentation could be done better in certain ways;
> but it's a lot better than you suggest it is.
Maybe you are right there too, or maybe you have taken my criticism as more
than I intended.
I was more intending a comment about one of the reasons there would tend to
be so many questions to which the answers are covered in the documentation.
But having over 20 years in this field it ceases to surprise me that I can
spend 10 minutes reading a manual to solve a problem for a client on a
system which I have never seen before, (and charge them for my time), when
they could not understand the documents at all.
My comment is this: most IT documentation (and particularly Perl's since
that is what this ng is about) is aimed at an audience with a certain level
of prior knowledge. Many of Perl's (particularly newer) users do not have
(or even come close to) that level of knowledge. That will result in many
users asking questions to which the answer is in the documentation. That in
turn will result in many of the more experienced ng users replying with
'read the FAQ' or 'read the documentation' type responses (snappy or
otherwise).
And that means: "Yes, it is always like this in here! So learn to live with
it. Learn what you can, read a lot, lurk a bit, try to be intelligent with
your questions, and develop a thick skin"
Oh and I guess if someone replies "check FAQ x", go check FAQ x!
:^)
Wyzelli
------------------------------
Date: 6 Nov 1999 17:00:34 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: It is always like this here?
Message-Id: <801mri$b4n$1@gellyfish.btinternet.com>
On Sun, 7 Nov 1999 00:02:45 +0930 Wyzelli wrote:
>
> Abigail <abigail@delanet.com> wrote in message
> news:slrn8278q5.dk.abigail@alexandra.delanet.com...
>>
>> There is of course a very good reason for that. Not the fact that Perl
>> runs on systems with long file names, but the fact Perl also runs on
>> systems that don't have long file names.
>
> What does that really have to do with the naming of the chapters in the
> documentation? I was making a point about naming trends which I see in the
> Unix environment, not compatibility with filesystems.
>
I dont quite know what you mean by 'naming trends .. in the Unix environment'
but I believe that naming the manpages 'perlblah' is actually the right
and polite thing to do where there might be hundreds of different packages
installed all with their own set of manpages. If you have Tcl installed
on a Unix system with its manpages then you will know what I mean - the
naming of that packages manpages interferes grossly with the ability to
easily find some things - for instance I type 'man proc' hoping to
find information about my systems /proc implementation instead I get some
manpage about a Tcl function.
With the Perl way of doing things one can type 'man perl' and get a list of
all the available manpages *in the suggested order of reading* : from
the perl manpage:
(If you're intending to read these straight through for
the first time, the suggested order will tend to reduce
the number of forward references.)
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 7 Nov 1999 06:55:47 GMT
From: ebohlman@netcom.com (Eric Bohlman)
Subject: Re: It is always like this here?
Message-Id: <8037pj$4ag$5@nntp8.atl.mindspring.net>
Wyzelli (wyzelli@yahoo.com) wrote:
:
: Abigail <abigail@delanet.com> wrote in message
: news:slrn8278q5.dk.abigail@alexandra.delanet.com...
: >
: > It's explained, right there:
: > If SUBNAME is specified, it gives the name of a subroutine
:
: No it isn't. What is 'it'? The the undefined 'SUBNAME'? Or the entity to
: which 'SUBNAME' has just been defined? Or something else entirely? With a
: bit of fooling around I may be able to get it to work, or I may not.
"SUBNAME" is an example of what's called meta-syntax; it's conceptually
similar to using "x" in an equation. It is impossible to document
syntactic features of a programming language without using some form of
meta-syntax. It is impractical for documentation to include an
explanation of what meta-syntax is and what particular convention for
meta-syntax the document is using in every single place that meta-syntax
is used.
Just as the concept of "x" serving as a placeholder in an equation can be
difficult for someone just starting to learn algebra ("but what *is*
x?"), the concept of meta-syntax can be difficult for someone just
starting to learn how to program. But meta-syntax isn't just a *Perl*
concept, it's a *programming* concept, and learning to understand it is
part of learning programming in general, just as learning to understand
the *concepts* of assignments, conditionals, loops, etc. is an essential
part of learning programming in general.
Perl's documentation is not written to teach basic programming concepts
to people unfamiliar with them. Rather, it assumes that the reader is
familiar with the concepts but not necessarily with the specific ways in
which Perl implements them. It is *not* intended to help people who do
not understand basic programming concepts write production code, no
matter how many people unfamiliar with basic programming concepts want to
be able to write production code on an "appliance-user" basis. It is
*not* the place where a graphic designer who's discovered that mere HTML
markup skills are no longer enough to get high-paying Web jobs should
turn to first. It was never intended to be that, and cannot be
transformed into that without making it significantly less fit for the
purposes it *was* intended to serve.
In short, Perl's documentation looks quite deficient if you view a
language's documentation as a list of magic incantations you can type to
make useful things happen. *Every* language's documentation looks bad
when viewed that way, but for some reason Perl is the only language whose
documentation gets slammed on those grounds.
------------------------------
Date: Sun, 7 Nov 1999 21:48:49 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: It is always like this here?
Message-Id: <K6eV3.94$aq3.11740@vic.nntp.telstra.net>
Eric Bohlman <ebohlman@netcom.com> wrote in message
news:8037pj$4ag$5@nntp8.atl.mindspring.net...
<snippage of lots of stuff that was implied previously>
> In short, Perl's documentation looks quite deficient if you view a
> language's documentation as a list of magic incantations you can type to
> make useful things happen. *Every* language's documentation looks bad
> when viewed that way, but for some reason Perl is the only language whose
> documentation gets slammed on those grounds.
The reason is that Perl is one of the few languages which are truly useful
to the IT community in general which can be obtained by simple download, and
is thus obtained by thousands of people who do not have that foreknowledge.
With reference to that and my previous comments on the subject of this
thread, and maybe you will understand what I am saying. Most other
languages have to be purchased, or people expect to have to learn at Uni.
And even there the documentation has the same deficiencies.
I made the point earlier that it is not just languages which have these
deficiencies, it is IT documentation in general. Perl seems to suffer
because of it's general availability to people without that core of
knowledge.
It is a little difficult to convey in ng threads but I was not implying that
*I* did not know what 'SUBNAME' meant. I was pointing out a simple example
of implied required prior knowledge.
Yes IT IS ALWAYS LIKE THIS IN HERE!
Wyzelli
------------------------------
Date: 08 Nov 1999 11:00:28 -0700
From: Eric The Read <emschwar@rmi.net>
Subject: Re: It is always like this here?
Message-Id: <xkfeme0g8xv.fsf@valdemar.col.hp.com>
abigail@delanet.com (Abigail) writes:
> But lack of quantity would mean low quality. The argument of low quality
> cannot be based on volume.
But presence of quantity does not mean high quality. The argument of
high quality cannot be based on volume.
All I was saying was that Perl has an Imperial buttload of documentation,
but you can't claim that it's any good, simply by virtue of there being a
lot of it. Likewise, you can't claim it's any bad, by the same virtue.
In fact, you couldn't even claim it was bad if there were only one page
(a la Perl4) of documentation-- inadequate, perhaps, but not necessarily
bad.
-=Eric
--
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart
------------------------------
Date: Fri, 05 Nov 1999 16:06:52 -0800
From: Jon Shemitz <jon@midnightbeach.com>
Subject: Large hash: advice?
Message-Id: <3823711C.2170ED4@midnightbeach.com>
For a site search engine, I generate a hash by word of references to
hashes by filename of references to arrays of word positions. A
concordance. The indexing script writes this concordance to a .pm file,
so that the search script can just use it. But it's ca 1.6M of source,
and takes a long time and lots of memory to load.
The docs don't seem to ever explicitly say this, but it appears that a
tied hash (using dbmopen) can only contain scalars. I did experiments
which seem to confirm this - doing a key by key copy of my concordance
to a tied hash results in HASH(0x?) strings getting stored - is it true?
If so, would someone please suggest some good ways to reduce the CPU and
memory load of this big hash? I've thought that I could generate a
string representation of each word's file/positions hash, much as I do
now, and store that string in the tied hash by words. When the search
script loaded, it would create undefined entries for each word in the
tied hash; whenever an in-memory lookup for a word came up exists but
not defined, I'd eval the string rep. A sort of JIT strategy, and
(perhaps naively) I assume that the total time to eval each string
should be close to the time to interpret the big source file in the
first place.
I'd appreciate any comments on this strategy before I spend some time
coding it.
--
http://www.midnightbeach.com - Me, my work, my writing, and
http://www.midnightbeach.com/hs - my homeschool resource pages
------------------------------
Date: Sat, 06 Nov 1999 01:46:44 GMT
From: gorilla@elaine.drink.com (Alan Barclay)
Subject: Re: Large hash: advice?
Message-Id: <941853141.845842@elaine.drink.com>
In article <3823711C.2170ED4@midnightbeach.com>,
Jon Shemitz <jon@midnightbeach.com> wrote:
>The docs don't seem to ever explicitly say this, but it appears that a
>tied hash (using dbmopen) can only contain scalars. I did experiments
I think they do.
perldoc perlfaq4
How can I store a multidimensional array in a DBM file?
------------------------------
Date: Sat, 06 Nov 1999 20:03:48 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: Large hash: advice?
Message-Id: <EQ%U3.48740$23.1843069@typ11.nn.bcandid.com>
In article <3823711C.2170ED4@midnightbeach.com>,
Jon Shemitz <jon@midnightbeach.com> wrote:
>For a site search engine, I generate a hash by word of references to
>hashes by filename of references to arrays of word positions.
So this is something you want to be able to do @{$hash{$word}{$file}}
on, and get an array of file positions? Or do you need to be able to
do things like keys %{$hash{$word}} on it too? If the former, you
could simply store join ' ', @positions in the tied hash with the key
"$word/$file". If the latter, you could perhaps also store a list of
filenames (separated by slashes or whitespace, perhaps?) under the key
"$word/".
One of the neat things about hashes -- even those like dbm files that
just map strings to strings -- is that you can store
arbitrarily-complex data structures in them without too much trouble.
You just have to come up with a way to encode the keys :)
> A concordance. . . .
>
>The docs don't seem to ever explicitly say this, but it appears that a
>tied hash (using dbmopen) can only contain scalars.
Yes, dbm files map strings to strings.
>If so, would someone please suggest some good ways to reduce the CPU and
>memory load of this big hash? I've thought that I could generate a
>string representation of each word's file/positions hash, much as I do
>now, and store that string in the tied hash by words. When the search
>script loaded, it would create undefined entries for each word in the
>tied hash; whenever an in-memory lookup for a word came up exists but
>not defined, I'd eval the string rep. A sort of JIT strategy, and
>(perhaps naively) I assume that the total time to eval each string
>should be close to the time to interpret the big source file in the
>first place.
>
>I'd appreciate any comments on this strategy before I spend some time
>coding it.
This sounds like it would definitely work. Data::Dumper might help you
creating the string representation.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 6 Nov 1999 16:12:16 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: length (number of items) of an array
Message-Id: <801k10$b22$1@gellyfish.btinternet.com>
On Thu, 04 Nov 1999 20:38:18 GMT Dean Karres wrote:
> In <WPlU3.28186$23.1489064@typ11.nn.bcandid.com> karres@southwind.net (Dean Karres) writes:
>
>>What if you have an array of arrays?
>>[...]
>>How do I find the length of any sub-array? What if it were a 3 or N
>>dimensional array?
>
> Duh! I am answering my own question...
>
> my($i) = 0;
> my(@a) = ( [1,2,3,4],
> [2,3,4],
> [3,4],
> [4],
> []);
>
> print STDOUT "$#a\n\n";
>
> for ($i=0; $i<=$#a; $i++)
> {
> print STDOUT $#{$a[$i]}, "\n";
> }
>
Except you appear to be using $#array to get the number of items in
the array when you want to be using scalar @array -a nd whats with the
C style for :
print scalar(@{$_}),"\n" foreach (@a);
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 1304
**************************************
