[8878] in Perl-Users-Digest
Perl-Users Digest, Issue: 2494 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 4 18:07:30 1998
Date: Mon, 4 May 98 15:00:39 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 4 May 1998 Volume: 8 Number: 2494
Today's topics:
Re: 1701 days hath September (was: Re: rename funciton) <tchrist@mox.perl.com>
Re: 1701 days hath September (was: Re: rename funciton) (Jim Michael)
Re: cgi-lib.pl or CGI.pm? <yong@shell.com>
Re: cgi-lib.pl or CGI.pm? (brian d foy)
Re: cgi-lib.pl or CGI.pm? (Brian Wheeler)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) (Clinton Pierce)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) (Chris Nandor)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) (Chris Nandor)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) (Craig Berry)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) (Ilya Zakharevich)
Re: CPAN & Module gripes (was Re: Ever Wonder...?) <upsetter@shore.net>
Re: Determining Disk Space (Jason Taylor)
Re: Ever Wonder Why Not Everyone Uses Modules? (Chris Nandor)
Re: Ever Wonder Why Not Everyone Uses Modules? <upsetter@shore.net>
Re: Ever Wonder Why Not Everyone Uses Modules? <tchrist@mox.perl.com>
Re: extracting a sub-string (John Hevelin)
Re: extracting a sub-string <jmscott@ainet.com>
Help choosing names =~ Perl-SQL <glew@cs.wisc.edu>
How check sock? <shurik@iron.Te.NeT.UA>
How do I reuse functions in several programs? <keith@comcore.com>
How to clear browser Cache with perl <sirron@mail.mcoe.k12.ca.us>
Re: How to clear browser Cache with perl (brian d foy)
Re: How to clear browser Cache with perl <brianm@kodak.com>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 4 May 1998 20:37:37 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: 1701 days hath September (was: Re: rename funciton)
Message-Id: <6il8uh$rng$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Charles Margolin <cmargoli@world.northgrum.com> writes:
:Free?? Where I live, the library charges $6.00 per hour.
That's horrible. Not even the grocery stores here in Boulder
charge for Internet accesss. You mean it's not that way
everywhere? :-)
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
Never hit a man with glasses. Hit him with a baseball bat.
------------------------------
Date: Mon, 4 May 1998 21:22:16 GMT
From: genepool@netcom.com (Jim Michael)
Subject: Re: 1701 days hath September (was: Re: rename funciton)
Message-Id: <genepoolEsGBD4.LvB@netcom.com>
Charles Margolin (cmargoli@world.northgrum.com) wrote:
: Jim Michael wrote:
: > Go to the library and log onto the free internet feed.
: Free?? Where I live, the library charges $6.00 per hour.
Where I live, the library is free but I have to walk six miles
uphill both ways in the snow.
Hopefully you would have a friend who could help with method 2.
------------------------------
Date: Mon, 04 May 1998 15:46:50 -0500
From: Yong Huang <yong@shell.com>
To: rjk@coos.dartmouth.edu
Subject: Re: cgi-lib.pl or CGI.pm?
Message-Id: <354E293A.DBC1FFE@shell.com>
Thanks, Sir. I wonder if you could give me a more specific example or reason
why CGI.pm is better than cgi-lib.pl. That is, I don't seme to be fully
convinced yet.
I appreciate your message.
Yong Huang
------------------------------
Date: Mon, 04 May 1998 17:30:12 -0400
From: comdog@computerdog.com (brian d foy)
Subject: Re: cgi-lib.pl or CGI.pm?
Message-Id: <comdog-ya02408000R0405981730120001@news.panix.com>
Keywords: from just another new york perl hacker
In article <354E293A.DBC1FFE@shell.com>, Yong Huang <yong@shell.com> posted:
>Thanks, Sir. I wonder if you could give me a more specific example or reason
>why CGI.pm is better than cgi-lib.pl. That is, I don't seme to be fully
>convinced yet.
use whatever you want. if you prefer to use ancient technology, it's
completely up to you. make sure that you use Mosaic to test your
scripts, though.
--
brian d foy <comdog@computerdog.com>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
Perl Mongers <URL:http://www.pm.org>
there are no plans to make cgi-lib.pl Y2K compliant
------------------------------
Date: 4 May 1998 21:34:47 GMT
From: bdwheele@indiana.edu (Brian Wheeler)
Subject: Re: cgi-lib.pl or CGI.pm?
Message-Id: <6ilc9n$dr$2@flotsam.uits.indiana.edu>
In article <354E293A.DBC1FFE@shell.com>,
Yong Huang <yong@shell.com> writes:
> Thanks, Sir. I wonder if you could give me a more specific example or reason
> why CGI.pm is better than cgi-lib.pl. That is, I don't seme to be fully
> convinced yet.
>
> I appreciate your message.
>
> Yong Huang
>
>
While cgi-lib.pl is kind of outdated, the only thing it won't do is
file upload. CGI_Lite.pm is written in the same 'style' as cgi-lib.pl (except
it is OO instead of procedural) and will handle file uploads.
CGI.pm is hideously bloated and combines CGI, HTML, cookies, etc in
one module...which I think is a mistake (Print works very well for HTML
generation...Do I really need an anchor object?)
use what works for you because 'there is more than one way to do it'
Brian Wheeler
bdwheele@indiana.edu
------------------------------
Date: 4 May 1998 19:26:45 GMT
From: cpierce1@cp500.fsic.ford.com (Clinton Pierce)
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <6il4pl$no33@eccws1.dearborn.ford.com>
In article <u3753hy5.fsf@mailhost.panix.com>,
Jonathan Feinberg <jdf@pobox.com> writes:
>cpierce1@cp500.fsic.ford.com (Clinton Pierce) writes:
>
>> For CPAN to be more useful, IMHO, Module authors (and CPAN maintainers)
>> need to somehow embed dependency information into the modules. That
>> would allow CPAN to present you with the option of downloading the
>> desired module--and its dependencies all in one shot.
>
>Does this not work for you?
>
> # perl -MCPAN -e shell
>
> cpan> install MIME::Parser
>
>The CPAN module does indeed know about dependencies, etc. Try it, if
>you haven't already.
Not if you're behind _very_ thick firewalls, as at Ford Motor Co.
--
+------------------------------------------------------------------------+
| Clinton A. Pierce | "If you rush a Miracle Man, | http://www. |
| cpierce1@ford.com | you get rotten miracles" | dcicorp.com/ |
| fubar@ameritech.net |--Miracle Max, The Princess Bride| ~clintp |
+------------------------------------------------------------------------+
GCSd-s+:+a-C++UALIS++++P+++L++E---t++X+b+++DI++++G++e+>++h----r+++y+++>y*
------------------------------
Date: Mon, 04 May 1998 16:07:00 -0400
From: pudge@pobox.com (Chris Nandor)
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <pudge-0405981607150001@ppp-47.ts-1.kin.idt.net>
In article <6il13g$cr21@eccws1.dearborn.ford.com>,
cpierce1@cp500.fsic.ford.com (Clinton Pierce) wrote:
# In article <6iku8d$cvm@fridge.shore.net>,
# Art Cohen <upsetter@shore.net> writes:
# >Furthermore, if using module x requires a special installation of module
# >y, that makes it all the more unlikely that I'd ever use it on a client's
# >site.
#
# I agree 100%. CPAN is a pain in the ass to use. It's a lot like an
# unordered phone book--potentially useful, but not really.
I am going to search in vain for support for this statement.
# Trying to find a module (library, etc...) to do something simple can be
# overwhelming. If I'm a clueless newbie trying to, say, decode MIME
# E-Mail messages (semi-random example). First, there's no hints in the
# Documentation, other than to hunt around in CPAN.
Since when can clueless newbies be expected to understand useful resources?
# Searching for MIME turns up a plethora of MIME references, but the
# interesting one seems to be MIME::Parser. Clicking on that takes me to a
# listing of MIME-{Base64,Lite,tools,ispmailgate}.*. None of which looks
# anything like the MIME::Parser module I asked for. Going BACK to the
# CPAN.html#mime page gives you no hint that you need "MIME-tools.*".
# Clicking on various README's will eventually turn up MIME-tools as
# being the correct package.
Good, you read the docs, that wasn't so hard, now was it?
# But wait, the comment in CPAN.html says that it's not part of the
# libwww bundle. Do I need libwww? Is it a prerequisite? Clicking on
# libwww bundle says that MIME is _included_ in libwww. So which do I
# want, libwww or MIME-tools. (The descriptions for MIME and libwww
# in regards to MIME:: are contradictory. At least _VERY_ confusing.)
So what does any of this have to do with CPAN? Complain to the module
authors for better docs.
# For CPAN to be more useful, IMHO, Module authors (and CPAN maintainers)
# need to somehow embed dependency information into the modules. That
# would allow CPAN to present you with the option of downloading the
# desired module--and its dependencies all in one shot.
Hello? That is why there are Bundles. If you had installed Bundle::LWP,
you would get all the dependencies for it. Likewise with Bundle::libnet.
No, this is not the most intuitive system. No, it is not perfect. But
learn how to use it before complaining.
"Hello, tech support? Netscape doesn't work on my home computer." "Is
your modem connected?" "My what?"
You say above that clueless newbies should be able to figure it out. Why
on earth should clueless newbies be able to do this? CPAN is made by
programmers for programmers. If you are not a programmer, you won't get
it, and naught a user here will shed a tear.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
MacPerl: Power and Ease (ISBN 1881957322), http://www.ptf.com/macperl/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Mon, 04 May 1998 16:15:20 -0400
From: pudge@pobox.com (Chris Nandor)
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <pudge-0405981615350001@ppp-47.ts-1.kin.idt.net>
In article <6il4pl$no33@eccws1.dearborn.ford.com>,
cpierce1@cp500.fsic.ford.com (Clinton Pierce) wrote:
# In article <u3753hy5.fsf@mailhost.panix.com>,
# Jonathan Feinberg <jdf@pobox.com> writes:
# >cpierce1@cp500.fsic.ford.com (Clinton Pierce) writes:
# >
# >> For CPAN to be more useful, IMHO, Module authors (and CPAN maintainers)
# >> need to somehow embed dependency information into the modules. That
# >> would allow CPAN to present you with the option of downloading the
# >> desired module--and its dependencies all in one shot.
# >
# >Does this not work for you?
# >
# > # perl -MCPAN -e shell
# >
# > cpan> install MIME::Parser
# >
# >The CPAN module does indeed know about dependencies, etc. Try it, if
# >you haven't already.
#
# Not if you're behind _very_ thick firewalls, as at Ford Motor Co.
That is your company's fault for breaking something you need access to.
CPAN.pm just uses standard FTP or HTTP ports. If you can't FTP or HTTP,
then why are you complaining about CPAN anyway?
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
MacPerl: Power and Ease (ISBN 1881957322), http://www.ptf.com/macperl/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: 4 May 1998 20:57:29 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <6ila3p$53b$2@marina.cinenet.net>
Chris Nandor (pudge@pobox.com) wrote:
: # But wait, the comment in CPAN.html says that it's not part of the
: # libwww bundle. Do I need libwww? Is it a prerequisite? Clicking on
: # libwww bundle says that MIME is _included_ in libwww. So which do I
: # want, libwww or MIME-tools. (The descriptions for MIME and libwww
: # in regards to MIME:: are contradictory. At least _VERY_ confusing.)
:
: So what does any of this have to do with CPAN? Complain to the module
: authors for better docs.
CPAN consists entirely of a search/retrieval interface plus the contained
modules. Of these, the modules are by far the more important part. If
the module descriptions suck, then CPAN sucks. And I would argue that
the module descriptions do indeed suck. I've been on wild goose chases
such as the original poster described many times. Most annoying is the
lack of correspondence between described module names and file names in
the actual underlying FTP archives.
: # For CPAN to be more useful, IMHO, Module authors (and CPAN maintainers)
: # need to somehow embed dependency information into the modules. That
: # would allow CPAN to present you with the option of downloading the
: # desired module--and its dependencies all in one shot.
:
: Hello? That is why there are Bundles. If you had installed Bundle::LWP,
: you would get all the dependencies for it. Likewise with Bundle::libnet.
But it can be maddeningly hard to determine what's in each bundle, and
what *bundles* depend on one another (e.g., libwww on libnet), without
either lots of back-and-forth reading or trial and error, or more often
both.
: No, this is not the most intuitive system. No, it is not perfect. But
: learn how to use it before complaining.
I've learned how to use it, as (it seems to me) the original poster has.
May we complain (constructively), now?
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
------------------------------
Date: 4 May 1998 21:27:58 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <6ilbsu$ghj$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Craig Berry
<cberry@cinenet.net>],
who wrote in article <6ila3p$53b$2@marina.cinenet.net>:
> But it can be maddeningly hard to determine what's in each bundle, and
> what *bundles* depend on one another (e.g., libwww on libnet), without
> either lots of back-and-forth reading or trial and error, or more often
> both.
Why do you care? Just
perl -MCPAN -e 'install "Bundle::libwww"'
Ilya
------------------------------
Date: 4 May 1998 21:21:33 GMT
From: Art Cohen <upsetter@shore.net>
Subject: Re: CPAN & Module gripes (was Re: Ever Wonder...?)
Message-Id: <6ilbgt$t1p@fridge.shore.net>
Chris Nandor <pudge@pobox.com> wrote:
: # Trying to find a module (library, etc...) to do something simple can be
: # overwhelming. If I'm a clueless newbie trying to, say, decode MIME
: # E-Mail messages (semi-random example). First, there's no hints in the
: # Documentation, other than to hunt around in CPAN.
: Since when can clueless newbies be expected to understand useful resources?
Maybe because of the volumes of replies on this newsgroup that simply say
"There's a module that does that available on CPAN".
: # interesting one seems to be MIME::Parser. Clicking on that takes me to a
: # listing of MIME-{Base64,Lite,tools,ispmailgate}.*. None of which looks
: # anything like the MIME::Parser module I asked for. Going BACK to the
: # CPAN.html#mime page gives you no hint that you need "MIME-tools.*".
: # Clicking on various README's will eventually turn up MIME-tools as
: # being the correct package.
: Good, you read the docs, that wasn't so hard, now was it?
Probably not, but it didn't seem to give him any useful information. I
have experienced similar frustration trying to figure out which of the
plethora of date and time-related modules will do what I want.
: # But wait, the comment in CPAN.html says that it's not part of the
: # libwww bundle. Do I need libwww? Is it a prerequisite? Clicking on
: # libwww bundle says that MIME is _included_ in libwww. So which do I
: # want, libwww or MIME-tools. (The descriptions for MIME and libwww
: # in regards to MIME:: are contradictory. At least _VERY_ confusing.)
: So what does any of this have to do with CPAN? Complain to the module
: authors for better docs.
The point is that many people on this newsgroup (helpful people to be
sure) simply point newbies to CPAN with no further information about how
to find what they're looking for.
: You say above that clueless newbies should be able to figure it out. Why
: on earth should clueless newbies be able to do this? CPAN is made by
: programmers for programmers. If you are not a programmer, you won't get
: it, and naught a user here will shed a tear.
This is idiotic. It is not valid to assume that "newbie != programmer".
There are plenty of "newbies" (of varying degrees of cluelessness) who
could become a lot more clueful if CPAN were better organized.
--Art
National Ska/Reggae Calendar: www.ziplink.net/~upsetter/ska/calendar.html
Boston Ska Home Page: www.ziplink.net/~upsetter/ska/index.html
------------------------------
Date: Mon, 04 May 1998 19:46:05 GMT
From: jtaylor@ala.net (Jason Taylor)
Subject: Re: Determining Disk Space
Message-Id: <354e1aba.36459139@news.ala.net>
On Mon, 4 May 1998 14:45:51 -0400, "Grinch" <grinch@whoville.com>
wrote:
>Peter A Fein wrote in message <87bttessm0.fsf@bj2-64.rh.uchicago.edu>...
>
>>On unix, try `du`. Easily parseable results too.
>
>
>On Win32, go to www.cygnus.com and install their Gnu tools.
>
>Then, try 'du'. Easily parseable results too. ;-)
>
>-grinch
>
>--
>-----
>"It's not real coffee unless the sugar cubes float." - me
>
>Sherm Pendley
>grinch@whoville.com
>http://www.whoville.com
>
>
>
You can do that or you can read all the files into an array and use
then check the size of all the files and add them together -- I think
this is the only way for NT perl scripts.
------------------------------
Date: Mon, 04 May 1998 15:55:54 -0400
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <pudge-0405981555550001@ppp-47.ts-1.kin.idt.net>
In article <4sz5c2sz.fsf@mailhost.panix.com>, Jonathan Feinberg
<jdf@pobox.com> wrote:
# > As I try to install Data::Dumper, I get this message:
# > gcc: installation problem, cannot exec `cpp': No such file or
# > directory
#
# You might need to do the no-xsub install, as documented in the README
# that accompanies Data::Dumper.
Read the docs? Are you crazy? Next time you'll want me to ask for directions!
In article <6iku8d$cvm@fridge.shore.net>, Art Cohen <upsetter@shore.net> wrote:
# Jonathan Feinberg <jdf@pobox.com> wrote:
#
# : Don't try to install Net::SMTP in isolation. You want libnet.
#
# I should have been more specific... I was installing the whole libnet
# package.
Then you should have installed Bundle::libnet, which includes Data::Dumper.
# : You might need to do the no-xsub install, as documented in the README
# : that accompanies Data::Dumper.
#
# I'll take another look at the docs, but you're not doing anything to
# convince me that using this module will be worth the trouble. I don't know
# or care what Data::Dumper does...
Then don't bother using libnet. If you cannot be bothered to read the
docs, then that is YOUR problem.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
MacPerl: Power and Ease (ISBN 1881957322), http://www.ptf.com/macperl/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: 4 May 1998 21:30:30 GMT
From: Art Cohen <upsetter@shore.net>
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <6ilc1m$t1p@fridge.shore.net>
Chris Nandor <pudge@pobox.com> wrote:
: # : You might need to do the no-xsub install, as documented in the README
: # : that accompanies Data::Dumper.
: #
: # I'll take another look at the docs, but you're not doing anything to
: # convince me that using this module will be worth the trouble. I don't know
: # or care what Data::Dumper does...
: Then don't bother using libnet. If you cannot be bothered to read the
: docs, then that is YOUR problem.
Thanks for being a complete dick, not to mention completely unhelpful.
If you'd bother to read my original post, you'd see that all I wanted to
do was explore alternate ways of sending email. If using Net::SMTP
requires 100% comprehension of two or three completely unrelated modules,
it hardly seems worth the trouble. Some of us have work to do.
People on this newsgroup are quick to say "Don't re-invent the wheel;
there's a module that already does that"... but when figuring out how to
install said module takes ten times longer than it would take to just
write the code to accomplish the task at hand, you'll forgive me for
re-inventing.
--Art
National Ska/Reggae Calendar: www.ziplink.net/~upsetter/ska/calendar.html
Boston Ska Home Page: www.ziplink.net/~upsetter/ska/index.html
------------------------------
Date: 4 May 1998 21:53:49 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Ever Wonder Why Not Everyone Uses Modules?
Message-Id: <6ilddd$344$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Art Cohen <upsetter@shore.net> writes:
:People on this newsgroup are quick to say "Don't re-invent the wheel;
:there's a module that already does that"...
Another problem with that is if it goes on forever, no one will
ever learn how to make wheels.
There are lessons to be learned on both sides here, folks.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
There are many times when you want it to ignore the rest of the string just
like atof() does. Oddly enough, Perl calls atof(). How convenient. :-)
--Larry Wall in <1991Jun24.231628.14446@jpl-devvax.jpl.nasa.gov>
------------------------------
Date: Mon, 4 May 1998 20:46:49 GMT
From: glaurung@netcom.com (John Hevelin)
Subject: Re: extracting a sub-string
Message-Id: <glaurungEsG9q2.4wo@netcom.com>
In article <6ig2sd$pgt$0@206.165.146.171> "Allan M. Due" <alpaca@iname.com> writes:
| "There are two major products that come out of Berkeley: LSD and UNIX. We
| don't believe this to be a coincidence."
| -Jeremy S. Anderson
LSD was developed at Sandoz Laboratories.
UNIX was developed at Bell Laboratories.
I hope the content of your postings is more reliable
than that of your signature.
------------------------------
Date: Mon, 04 May 1998 14:17:10 -0700
From: "Joseph M. Scott" <jmscott@ainet.com>
To: John Hevelin <glaurung@netcom.com>
Subject: Re: extracting a sub-string
Message-Id: <354E3056.7F07@ainet.com>
I always heard this a little differently, it went something more like :
"Berkley is famous for two things : LSD and UNIX, coincidence?"
Aside from this version not getting tangled up with accuracy I always
thought it was a little funnier :-)
Joseph Scott
jmscott@ainet.com
PS - I believe I came across this version in the UNIX Haters book that
we get at Barnes and Noble ( not because we hate unix, but because it
was darn funny! ).
John Hevelin wrote:
>
> In article <6ig2sd$pgt$0@206.165.146.171> "Allan M. Due" <alpaca@iname.com> writes:
>
> | "There are two major products that come out of Berkeley: LSD and UNIX. We
> | don't believe this to be a coincidence."
> | -Jeremy S. Anderson
>
> LSD was developed at Sandoz Laboratories.
>
> UNIX was developed at Bell Laboratories.
>
> I hope the content of your postings is more reliable
> than that of your signature.
------------------------------
Date: Mon, 04 May 1998 15:17:01 -0500
From: Andy Glew <glew@cs.wisc.edu>
To: modules@perl.org, shishir@ora.com
Subject: Help choosing names =~ Perl-SQL
Message-Id: <354E223D.882BDBDC@cs.wisc.edu>
Brief
====
Recommendations solicited for names for a database written
in Perl. Current;y called 'Perl-SQL'.
Detail
=====
I have written a tool that I currently call 'Perl-SQL'.
I would like to share this code.
Pursuant to the recommendations of CPAN style, I seek advice
as to what to call this - where it should fit into the namespace, etc.,
etc.
Details
======
Perl-SQL is currently a program, callable on the command line,
not a module. However, I plan to make it into a module (or set thereof)
some time in the near future. I therefore solicit advice in two regards:
(1) advice as to how to go about naming the command line program,
and its internal sub-modules, and (2) advice as to naming the internal
modules, as well as the possible future module that will provide
the command line functionality from within Perl.
I figure if I get the names right now, less rework will be needed later.
Description
--------------
Perl-SQL is, basically, a database. It takes SQL expressions such as
SELECT t1.count AS count1, t2.count AS count2
FROM "experiment1-profile.db" AS t1
FULL OUTER JOIN "experiment2-profile AS t2
ON t1.address = t2.address
WHERE t1.count > 10 or t2.count > 10
and executes them.
It accepts a variety of ASCII text file database formats, ranging from
SDRs - Singleline Delimited Records
e.g. address,count
1,3
...
(SDRs are a superset of common database formats such
as CSVs (comma separated variables) and TSVs (tab separated variables))
to MNTs - Multiline Named Tuples
e.g. {
address => 1,
count => 2,
}
The "named tuple" file formats, such as MNTs, are quite flexible,
and do not impose the requirement that every tuple (record) of a relation
(database) has the same shape. I.e. it is possible for tuples to have
fields that are completely missing, as well as having null (undef) entries.
I call this the ability to manage "sparse and irregular" databases.
Most commercial databases provide extremely poor support for
sparse and irregular databases. This was a big motivator for my
writing Perl-SQL, since I use sparse and irregular datbases widely in my
work.
Yes: currently I just eval the MNT format as a Perl expression.
Because I do that, I also get the abilitry to have fields whose values
are complex datastructures "for free". I.e. in some ways Perl-SQL
is a poor man's object oriented database.
Perl-SQL supports most SQL 92 arithmetic operators, as well as
supporting Perl-like extensions such as && and **.
Perl-SQL supports SQL aggregate functions, such as SUM, AVG, etc.
It allows you to do things like
SELECT address, count/SUM(count) AS "%age" FROM "database.mnt"
Perl-SQL currently only supports sorted equijoins.
Perl-SQL is singleuser. It has no transactions, no locking, nothing beyond
that of a filesystem. I might add this at some time, but for now don't need it.
Motivation
-------------
Perhaps I should mention why I have written Perl-SQL:
I wrote Perl-SQL to make it easier to manage experimental data.
I wanted standard ASCII text files, so that my data format survives.
I did not want the hassle or expense of maintaining a heavyweight database.
I wanted support for sparse and irregular databases.
I wanted FULL OUTER JOIN, which is basic for comparing
data, which many databases do not yet have.
And, mostly, I want the ability to refer to fields of my data by name
rather than by field number (as in standard UNIX sort and join).
Modules
----------
Currently, Perl-SQL is only a command line program, suitable for use
as a UNIX filter.
It will be desirable, at some time, to fit Perl-SQL under the standard Perl
DBI (DataBase Interface). It may similarly be desirable to allow direct access
to Perl-SQL functionality via a Perl module interface, in the same way that
Sprite, and other database interfaces, did.
Perl-SQL contains the following internal modules.
I realize that I have violated just about every Perl naming convetion:
that's why I am posting this, asking for suggested names:
perl-sql
The actual Perl SQL program.
ag_perl_sql_parser.pm
a parser generated by byacc.
returns a parser object
ag_perl_sql_lexer.pm
a handwritten lexer. returns a lexer object.
dumb_line_re_lexer.pm
a dumb lexer module that fulfills my needs
TBD: I'd like to eliminate it, and use an "official"
Perl lexer module, but found them awkward.
plain_text_database.pm
returns a "ptd" handle object
with various methods.
multiline_named_tuples.pm
singleline_named_tuples.pm
singleline_delimited_records.pm
methods for the various types of
databases implemented
by plain_text_database.pm
nice_IO.pm
used by plain_text_database.pm,
essential creates infinitely ungettable
filehandles. Returns a handle object.
null_handling.pm
misc.pm
helper modules
- not really object oriented.
db_algorithms.pm
implements database algorithms, such as
scan select and sorted merge equijoin
not OO
eval_functions.pm
functions used to evaluate the parse tree
generated by ag_perl_sql_parser.pm
- glue code connecting it to
db_algorithms.pm
Usage
-------
Examples:
perl-sql SELECT var FROM file WHERE condition
Alternatively, if the program is named 'SELECT' or 'DELETE',
(lowercase okay) you can simply do
select var from file where condition
Related Tools
----------------
Perl-SQL is most closely related to Sprite, by shishir@ora.com.
Sprite is also SQL implemented in Perl. Sprite is a much less
complete implementation, doesn't implement anything nearly as
close to full SQL. Sprite does, however, have a proper Perl
module interface.
Perl-SQL, by the way, contains no code from Sprite.
Perl-SQL is similar to tools such as RDB and SHQL, but seems
to have greater ambitions of flexibility, generality, and compatibility
with standard SQL.
Perl-SQL is *not* just an interface to some underlying database package,
neither an existing SQL database, nor to some underlying database library.
Naming
---------
Again, I realize that I violated every Perl naming convention around.
Which would not matter so long as Perl-SQL remains a stand-alone tool, but
which would matter if I ever do try to make it more of a module callable
from other Perl programs. Hence my questions about names:
Q1: is "Perl-SQL" (or "perl-sql") a reasonable name for the package as a whole,
and the outermost tool executable? Or is that too generic, causing confusion with
other interfaces from Perl to the embedded SQL of various SQL databases?
If not Perl-SQL, can anyone sugest any other name? Once again, the key features
as I see them are: (1) ordinary ascii files, (2) SQL with some Perl-like enhancements,
(3) sparse and irregular databases.
Q2: what about the moduleswritten as part of Perl-SQL?:
The following are pretty much internal:
ag_perl_sql_parser.pm
ag_perl_sql_lexer.pm
dumb_line_re_lexer.pm
null_handling.pm
misc.pm
eval_functions.pm
The following potentially could be used outside of
Perl-SQL:
db_algorithms.pm
provides interfaces to algorithms such as
scan_select and sort_merge_join;
e.g. could be attached to a non-SQL
query language interface
plain_text_database.pm
multiline_named_tuples.pm
singleline_named_tuples.pm
singleline_delimited_records.pm
potentially useful for non-SQL query languages
nice_IO.pm
again, useful to anyone who wants infinite unget.
I am tempted, for now, just to put everybody in a module
perl_sql::
but will listen to recomendations that seem likely to make coexistence
in the future easier.
--------
Please email. I don't read these groups normally.
(Or, to be pedantic: please respond to me by email as well as posting a reply
to the newsgroup. If you post only, you won't help me at all.)
------------------------------
Date: 4 May 1998 20:25:37 GMT
From: Alexandr Dubovikov <shurik@iron.Te.NeT.UA>
Subject: How check sock?
Message-Id: <6il881$okr$1@toster.Te.NeT.UA>
Hi guys!
How check socket, alive it or die ?
Alexandr Dubovikov * +380 (0482) 219093
baron@iRC RusNet * shurik@te.net.ua
------------------------------
Date: Mon, 04 May 1998 14:10:37 -0700
From: Keith Vertrees <keith@comcore.com>
Subject: How do I reuse functions in several programs?
Message-Id: <354E2ECD.4D06F7A4@comcore.com>
This is a multi-part message in MIME format.
--------------A24E06DEA59FCEC0E35B3A41
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm new to Perl, and while I can see how it really does make some stuff
that should be easy easy, it seems to make some easy stuff hard. If I
want to write a subroutine that is used in multiple Perl programs, how
do I do it? Modules seem like they might be the answer, but all that I
can "easily" find out about modules is that they go into files with a
.pm suffix. How do I tell my Perl program where it can file the file
that has the .pm suffix so that it can use the function from the file
with the .pm suffix? In C, this would be accomplished by linking a .o
file or via a #include statement.
>From what I can tell about modules, they're written by really smart Perl
people to do all kinds of systemy stuff, but they're hard for a novice
user to deal with.
Tell me I'm wrong...
Thanks,
Keith
--------------A24E06DEA59FCEC0E35B3A41
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Keith Vertrees
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Keith Vertrees
n: Vertrees;Keith
org: Comcore Semiconductor, Inc.
adr: 5075 Shoreham Place;;Suite 260;San Diego;CA;92122;USA
email;internet: keith@comcore.com
title: Principal Engineer
tel;work: 619-535-0074
tel;fax: 619-535-0084
tel;home: 619-350-4666
x-mozilla-cpt: ;7136
x-mozilla-html: TRUE
version: 2.1
end: vcard
--------------A24E06DEA59FCEC0E35B3A41--
------------------------------
Date: Mon, 04 May 1998 13:17:55 -0700
From: Joseph Norris <sirron@mail.mcoe.k12.ca.us>
Subject: How to clear browser Cache with perl
Message-Id: <354E2272.EBD88A67@mail.mcoe.k12.ca.us>
Hello listeros,
Can anyone tell me the way to clear browser cache from a cgi script
written in perl?
Thanks. joseph.
------------------------------
Date: Mon, 04 May 1998 16:35:53 -0400
From: comdog@computerdog.com (brian d foy)
Subject: Re: How to clear browser Cache with perl
Message-Id: <comdog-ya02408000R0405981635530001@news.panix.com>
Keywords: from just another new york perl hacker
[follow-ups set]
In article <354E2272.EBD88A67@mail.mcoe.k12.ca.us>, Joseph Norris <sirron@mail.mcoe.k12.ca.us> posted:
>Can anyone tell me the way to clear browser cache from a cgi script
>written in perl?
if you can do it over HTTP, it will be in the HTTP specification
(referenced in the CGI Meta FAQ). the protocal does not specify
which language most be used.
good luck :)
--
brian d foy <comdog@computerdog.com>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
Perl Mongers <URL:http://www.pm.org>
------------------------------
Date: Mon, 04 May 1998 16:37:35 -0400
From: Brian Mathis <brianm@kodak.com>
To: Joseph Norris <sirron@mail.mcoe.k12.ca.us>
Subject: Re: How to clear browser Cache with perl
Message-Id: <354E270F.E2CDDA72@kodak.com>
Joseph Norris wrote:
>
> Hello listeros,
>
> Can anyone tell me the way to clear browser cache from a cgi script
> written in perl?
>
> Thanks. joseph.
You can't. This is something that must be done on the client side,
where perl would be used on the server side. You might be able to use
Javascript, but this isn't the Javascript group.
Now, just to confuse you...
You could write a script that will run via cron or NT scheduler
(depending on your platform), that will go into your cache dir and
remove all the files. This might cause a corrupt index though, unless
you remove that too (I'm not sure exactly how Netscape manages it's
cache directory).
But, depending on your usage, you might just want to leave the cache
there, or adjust it's size if you are short of disk space, since
Netscape automatically monitors the directory size, and prunes it
accordingly, if neccessary.
Otherwise, for more information on understanding what CGI actually is,
and to get an idea of what's actually possible, check out:
http://www.htmlhelp.com/faq/cgifaq.html
There are also plenty of other CGI resources you should be able to find
via Yahoo!
Brian Mathis
orev
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 2494
**************************************
