[11291] in Perl-Users-Digest
Perl-Users Digest, Issue: 4891 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 14 05:07:22 1999
Date: Sun, 14 Feb 99 02:00:16 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 14 Feb 1999 Volume: 8 Number: 4891
Today's topics:
database: viewing large result sets in perl? <marnold@novia.net>
Re: database: viewing large result sets in perl? (Abigail)
easily generating SQL queries using perl? <marnold@novia.net>
Re: HELP stripping NEWLINE character (Larry Rosler)
Re: How do I delete a hash element ?? (Larry Rosler)
looking for script for *.nws to *.txt or *.html <alxx@tig.nospam.com.noadds.spammers.sux.au>
Microsoft on Perl <bnelson@netcom.com>
Re: Microsoft on Perl (Michael Rubenstein)
PFR: Comput offset of local time from UTC (Larry Rosler)
Re: PFR: UTC_to_Epoch (Owen Cook)
Re: PFR: UTC_to_Epoch (Matthew Bafford)
Re: Python vs. Perl vs. tcl ? (Tad McClellan)
Re: Speed of Python (Ilya Zakharevich)
Using the distribution environment for development. mlehmann@prismnet.com
Re: Using the distribution environment for development. <mpersico@erols.com>
Re: Using the distribution environment for development. (Ilya Zakharevich)
Vim5 "quickfix" mode as a Perl IDE -- take 2 <stevegt@TerraLuna.org>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Feb 1999 22:11:05 -0600
From: "Matt Arnold" <marnold@novia.net>
Subject: database: viewing large result sets in perl?
Message-Id: <01sx2.23695$O54.26699@newscene.newscene.com>
SYNOPSIS: { There are numerous posts and web pages dedicated to the topic of
querying databases from perl. But all these articles assume that our perl
program is well-equipped to deal with result sets of infinite size. So how
can our perl programs elegantly deal with these large result sets? }
I have a database, and I've written a perl CGI program to query the database
based on user input. In many cases the database result set is too big to be
displayed at one time (e.g. 1000 matching records returned.) I want the
user to view only a small portion of the result set (e.g. view records 1-100
of the 1000 matches.) I then want to offer "Next" and "Prev" buttons which
allow the user to view the next or previous 100 matches. (DejaNews serves
as a good example of what I'm trying to describe.)
What techniques (i.e. clever perl tricks) should I employ to let users
easily browse these very large result sets? I have a few ideas described
below. I would like your comments about these ideas. I'd also like to to
hear any other suggestions you may have.
#1. track $count and $offset in perl
My CGI programs could track a $count and $offset. $count indicates how many
records should be displayed on the page, while $offset indicates the
starting record number. Given a very large result set, perl could ignore
the first $offset records returned, then print the next $count records. All
other records would be ignored.
When the user clicks a "Next" button to view the next 100 matches, the CGI
program would re-execute the SQL query again, then show the matches based on
a new $offset. This means the database is being re-queried with each page.
This approach appears to be the easiest to implement. But if the query is
computationally expensive, this option may not be feasible.
#2. employ $count and $offset trick in SQL
I'm not an SQL whiz, but I'm confident one could use SQL to return only
$count records starting at $offset (perhaps using SQL subqueries or other
techniques).
Like the approach above, the database will be requeried with each hit. But
I suspect it would be more efficient to use the database to limit the
returned results (using SQL) rather than continuously fetching ALL results
and then using perl to ignore the unneeded ones.
Another disadvantage is that the total matches is unknown. My program
wouldn't be able to state "1000 matches found, showing 1-100". The number
of total matches (e.g. 1000) would not be known. Another (albeit a less
expensive) query such as "SELECT COUNT(*) ..." must be performed to fetch
that number.
#3. query once, save results, issue session id
When the user performs a query, one could save the very large result set to
disk locally on the web server. Data can be stored to disk in a convenient
format like a DBM file (persistent hash). The viewing part of our CGI (i.e.
the part which lets the user browse through this big result set) could
quickly fetch subsets from the local DBM.
Not all data would necessarily be saved to disk -- perhaps just a list of
primary keys or other unique identifiers. We could then use this
information to fetch individual records from the database as needed.
Since our CGI programs are "stateless", we'll have to figure out a way of
keeping track of which local file (i.e. which DBM file) goes with which
user. This can probably be done by creating a session id. The local file
can be named according to this session id. And this session id will be
passed "behind the scenes" using "hidden" fields on our forms -- effectively
maintaining "state" from one CGI incarnation to the next.
While this approach is certainly achievable, it's certainly harder than the
above approaches. It may be overkill for small projects.
In conclusion, I'm wondering what is the best way to browse large result
sets in perl? I'm confident I'm not the first perl programmer to raise this
issue. I'm hoping others of you out there can sugguest alternative ideas
which may be easier and/or better.
Thanks,
Matt
------------------------------
Date: 14 Feb 1999 09:37:00 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: database: viewing large result sets in perl?
Message-Id: <7a65fs$op1$3@client2.news.psi.net>
Matt Arnold (marnold@novia.net) wrote on MCMXCIII September MCMXCIII in
<URL:news:01sx2.23695$O54.26699@newscene.newscene.com>:
&& SYNOPSIS: { There are numerous posts and web pages dedicated to the topic of
&& querying databases from perl. But all these articles assume that our perl
&& program is well-equipped to deal with result sets of infinite size. So how
&& can our perl programs elegantly deal with these large result sets? }
I don't think you've raised a single issue that is Perl specific.
Abigail
--
Anyone who slaps a "this page is best viewed with Browser X" label
on a Web page appears to be yearning for the bad old days, before the
Web, when you had very little chance of reading a document written on
another computer, another word processor, or another network.
[Tim Berners-Lee in Technology Review, July 1996]
------------------------------
Date: 13 Feb 1999 22:15:12 -0600
From: "Matt Arnold" <marnold@novia.net>
Subject: easily generating SQL queries using perl?
Message-Id: <y4sx2.23721$O54.27167@newscene.newscene.com>
Many of you query SQL-based databases using perl. In some cases, you even
give the user a web page where they can key in their own search criteria in
an HTML form. Before the search can take place, this search criteria must
somehow be converted to SQL. I realize that the resulting SQL can be quite
varied from one application to the next, but I'll propose that the resulting
SQL most typically takes the form: "SELECT * FROM database WHERE
<search_conditions>". Therefore, the problem becomes one of effeciently
converting the user-submitted search criteria into an SQL WHERE clause.
(But feel free to disagree with me. I'm sure you will; this is Usenet,
after all.)
Does anyone have any tricks for easily and elegantly converting this
user-submitted search criteria into SQL? Of course, brute-force programming
techniques can apply. But this can get ugly very quickly when the user
wants the option to search on a few dozen fields. It gets even uglier when
you allow nearly a dozen different search operators (e.g. =, !=, <, >, etc.)
on each of these fields. I am looking for ideas which lend themselves
towards simplicity and code reusability.
For purposes of discussion, I came up with an example perl program (included
at the end of this message). Based on input made to fields on an HTML form,
it churns out the appropriate SQL query. You can test it out at
http://www.novia.net/~marnold/sql/form.html This example sucks and
probably shouldn't be used for anything. But it helps to demonstrate the
problem.
Does anyone out there have a module, code fragment, tool, or other resource
they use to create SQL based on form input? I'm too lazy to reinvent this
particular wheel. And laziness is, after all, one of the virtues of a perl
programmer.
Thanks,
Matt
----------------------------------------
<!-- minimal form used to demonstrate process.cgi (shown below) -->
<!-- please view it in action at
http://www.novia.net/~marnold/sql/form.html -->
<FORM METHOD="post" ACTION="process.cgi">
First Name:
<SELECT NAME="firstname_compare">
<OPTION VALUE="=">=</OPTION>
<OPTION VALUE="!=">!=</OPTION>
<OPTION VALUE=">">></OPTION>
<OPTION VALUE="<"><</OPTION>
<OPTION VALUE=">=">>=</OPTION>
<OPTION VALUE="<="><=</OPTION>
<OPTION VALUE="starts">Starts With</OPTION>
<OPTION VALUE="contains">Contains</OPTION>
</SELECT>
<INPUT TYPE="text" NAME="firstname"><BR>
Last Name:
<SELECT NAME="lastname_compare">
<OPTION VALUE="=">=</OPTION>
<OPTION VALUE="!=">!=</OPTION>
<OPTION VALUE=">">></OPTION>
<OPTION VALUE="<"><</OPTION>
<OPTION VALUE=">=">>=</OPTION>
<OPTION VALUE="<="><=</OPTION>
<OPTION VALUE="starts">Starts With</OPTION>
<OPTION VALUE="contains">Contains</OPTION>
</SELECT>
<INPUT TYPE="text" NAME="lastname"><BR>
<INPUT TYPE="submit" VALUE="So what would the SQL look like">
</FORM>
----------------------------------------
#!/usr/bin/perl -w
# see this program in action at http://www.novia.net/~marnold/sql/form.html
use strict;
use CGI;
my $cgi = new CGI;
print $cgi->header('text/plain');
# list of which potential, user-submitted fields we should watch for
my @input_fields = ("firstname", "lastname", "address", "address2",
"city", "state", "zip", "country", "continent", "hemisphere",
"planet", "system", "quadrant", "galaxy", "universe", "plane");
my $where_clause = make_where_clause(@input_fields);
print "SELECT * FROM foobar $where_clause\n";
##########
# takes a list of field names (which potentially contain content) as input
# returns a properly formatted SQL where clause (which could also be
nothing)
sub make_where_clause {
my @fields_to_check = @_;
my @conditions = (); # list for our conditions, starts empty
foreach my $field (@fields_to_check) {
if (my $value = $cgi->param($field)) { # if the field had user input in
it
my $operator = $cgi->param($field."_compare");
if ($operator eq "contains") {
push @conditions, "$field like '%$value%'"; # e.g. "name like
'%Matt%'"
}
elsif ($operator eq "starts") {
push @conditions, "$field like '$value%'"; # e.g. "name like
'Matt%'"
}
else { # all other types of operators: =, !=, >, <, >=, <=
push @conditions, "$field $operator '$value'"; # e.g. "name !=
'Matt'"
}
} # end if
} # end foreach
# turn our list of conditions into an SQL where clause
# each condition is separated by an "AND"
if (scalar @conditions == 0) { # if there are no conditions
return ""; # then there is no where clause, return empty
}
else { # else there's 1 or more condition
my $clause = "WHERE (\n";
while (scalar @conditions > 1) { # if there's more than 1 condition
$clause .= " " . (pop @conditions) . " AND\n"; # put an "AND" after
it
}
return $clause .= " " . (pop @conditions) . "\n);\n";
}
}
----------------------------------------
------------------------------
Date: Sat, 13 Feb 1999 21:29:58 -0800
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: HELP stripping NEWLINE character
Message-Id: <MPG.112fff29bc7bcc1a989a38@nntp.hpl.hp.com>
In article <ySrx2.54767$641.93119@news.san.rr.com> on Sat, 13 Feb 1999
19:59:42 -0600, Steven T. Henderson <stevenhenderson@prodigy.net>
says...
> >I am using s/\n/<br>/sg;
> try it without the trailing 's' (right before the 'g').
Total irrelevance. The '/s' affects *only* whether '.' matches "\n".
As there are no '.'s in the regex, the presence or absence of the '/s'
makes no difference whatever.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sat, 13 Feb 1999 21:20:15 -0800
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: How do I delete a hash element ??
Message-Id: <MPG.112ffce728df597b989a37@nntp.hpl.hp.com>
In article <qwmx2.1238$_B2.28000@newsfeed.slurp.net> on Sat, 13 Feb 1999
21:54:30 GMT, Craig Berry <cberry@cinenet.net> says...
> Larry Rosler (lr@hpl.hp.com) wrote:
> : Abigail> Did you search for 'delete' in the man page?
> :
> : The technical term for your response is 'begging the question'.
> :
> : He might have searched for 'undefine', 'remove', 'erase', 'expunge',
> : 'cancel', 'efface', or 'obliterate', and not found it. But 'delete'
> : *would* have found it, because that's the answer.
>
> But in this case, it was a fair question; after all, he used 'delete' in
> the subject line of his query. Asking grep the same question he asked us
> would have found it. :)
I agree.
In looking at the question and at Abigail's response, I overlooked the
subject line, which is the only place that he used 'delete'. In the
body of the question, he used only 'undef' and 'remove', which is why
they appear first in my list of synonyms.
My newsreader already shows the Subject in red, but the font is too
small. I will change it. :-)
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sun, 14 Feb 1999 17:21:44 +1100
From: "al" <alxx@tig.nospam.com.noadds.spammers.sux.au>
Subject: looking for script for *.nws to *.txt or *.html
Message-Id: <7a5qc3$ai4$1@toto.tig.com.au>
anyone know of a script to convert from *.nws(ms outlook express news files)
to *.txt or *.html
------------------------------
Date: 14 Feb 1999 01:43:38 -0600
From: Bob Nelson <bnelson@netcom.com>
Subject: Microsoft on Perl
Message-Id: <7a5ura$63t$1@renpen.nelson.org>
Catch Microsoft's lukewarm endorsement of Perl at this URL:
http://www.microsoft.com/sitebuilder/magazine/clinick_perl.as
The fact that the praise is so faint from *that* source adds even
more to my enthusiasm for Perl. Well, it would have been shocking
to get the full-fledged endorsement that Perl so richly deserves
from the folks who brought Visual Basic bletchery to the world.
``Hats off to Larry'' from one happy Perl camper, with apologies
to Del Shannon.
--
========================================================================
Bob Nelson -- Dallas, Texas, USA (bnelson@iname.com)
http://www.oldradio.com/archives/nelson/open-computing.html
``Those who don't understand UNIX are condemned to reinvent it, poorly.''
------------------------------
Date: Sun, 14 Feb 1999 09:35:12 GMT
From: miker3@ix.netcom.com (Michael Rubenstein)
Subject: Re: Microsoft on Perl
Message-Id: <36c69423.735662106@nntp.ix.netcom.com>
On 14 Feb 1999 01:43:38 -0600, Bob Nelson <bnelson@netcom.com> wrote:
>Catch Microsoft's lukewarm endorsement of Perl at this URL:
>
>http://www.microsoft.com/sitebuilder/magazine/clinick_perl.as
>
>The fact that the praise is so faint from *that* source adds even
>more to my enthusiasm for Perl. Well, it would have been shocking
>to get the full-fledged endorsement that Perl so richly deserves
>from the folks who brought Visual Basic bletchery to the world.
>
>``Hats off to Larry'' from one happy Perl camper, with apologies
>to Del Shannon.
You're sure reading that page a lot differently than I do. I'd call
it a pretty positive piece. About the most negative thing it says is
If you've gotten this far through my column, you're probably
hinking that Perl is a great language and perhaps you should
onsider using it for your next project. Should you consider
oving away from VBScript -- since Microsoft approves of Perl,
and you can use it in nearly all their products? If you're
starting out as a script developer then I think that VBScript
will be much easier for you to begin with. BASIC was designed
to be an easy language to pick up, and VBScript builds on this
by providing significant features in the BASIC style. In
particular, VBScript 5.0 has classes and regular expressions
that provide the two main features that might lead you to
Perl. The regular expression engine in VBScript uses the Perl
syntax for its regular expressions, so you should be able to
use the regular expression books out there to help you get
going on the wonders of regular expressions. If you are a Perl
developer already, then I think you already know the answer.
Surprise, surprise! Microsoft thinks beginners would do better to
start off with their language than with perl. I'd call this nice
endorsement of perl and, considering the source, a damned weak one of
VBScript.
The page directs the reader to an interview with Larry Wall for more
information and contains links to ActiveState, MKS (the page mentions
MKS's pscript), and www.perl.com.
--
Michael M Rubenstein
------------------------------
Date: Sun, 14 Feb 1999 00:01:46 -0800
From: lr@hpl.hp.com (Larry Rosler)
Subject: PFR: Comput offset of local time from UTC
Message-Id: <MPG.113022bcc07e9727989a39@nntp.hpl.hp.com>
Here's a simple (once you think of it) function that lets perl do the
heavy work of computing the offset of local time from UTC.
#!/usr/local/bin/perl -w
use strict;
# tz_offset: Compute the offset of local time from UTC.
# Larry Rosler, February 13, 1999
# tz_offset() returns the offset of local time from UTC,
# in hours (and fractions). For example, (North American) Eastern
# Standard Time is -5, India Time is +5.5. This convention conforms
# to international usage, but has the opposite sign of that used by
# the Unix TZ environment variable.
sub tz_offset {
my $now = time;
my ($l_min, $l_hour, $l_year, $l_yday) =
(localtime $now)[1, 2, 5, 7];
my ($g_min, $g_hour, $g_year, $g_yday) =
(gmtime $now)[1, 2, 5, 7];
($l_min - $g_min)/60 + $l_hour - $g_hour +
24 * ($l_year - $g_year || $l_yday - $g_yday)
}
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sun, 14 Feb 1999 04:19:28 GMT
From: rcook@pcug.org.au (Owen Cook)
Subject: Re: PFR: UTC_to_Epoch
Message-Id: <36c73a92.2987835@newshost.pcug.org.au>
If I modify what is below as shown, it fails because of strict (which I am
still trying to psych out). Hash out 'use strict', it runs ok.
if I hash out the offending lines and unhash the first line, it runs ok
how do I capture the return value as a variable without upsetting 'use
strict' ?
On Thu, 11 Feb 1999 17:46:34 -0800, lr@hpl.hp.com (Larry Rosler) wrote:
>#!/usr/local/bin/perl -w
>use strict;
######## added next 3 lines here
#print "My sub returned ${\UTC_to_Epoch(1998,3,11)}\n";
$answer =${\UTC_to_Epoch(1998,3,11)};
print"$answer\n";
># UTC_to_Epoch: Convert UTC date/time to Unix-epoch time.
># Larry Rosler, 11 February, 1999
<lots snipped>
> # Adapted from Astronomical Computing, Sky & Telescope, May, 1984.
> 24 * 60 * 60 * (367 * $year - 678972 - 40587 + int(275 * $mon / 9) +
> $day - int((int(int($year + ($mon < 9 ? -1 : 1) *
> int(abs($mon - 9) / 7)) / 100) + 1) * 3 / 4) -
> int(7 * (int(($mon + 9) / 12) + $year) / 4)) +
> 60 * 60 * $hour + 60 * $min + $sec
>}
------------------------------
Date: Sun, 14 Feb 1999 04:38:18 GMT
From: dragons@scescape.net (Matthew Bafford)
Subject: Re: PFR: UTC_to_Epoch
Message-Id: <slrn7cckim.gr6.dragons@Server.Network>
On Sun, 14 Feb 1999 04:19:28 GMT, Owen Cook <rcook@pcug.org.au> wrote:
[snip]
-> how do I capture the return value as a variable without upsetting 'use
-> strict' ?
[snip]
-> ######## added next 3 lines here
->
-> #print "My sub returned ${\UTC_to_Epoch(1998,3,11)}\n";
-> $answer =${\UTC_to_Epoch(1998,3,11)};
-> print"$answer\n";
[snip]
>From perldoc strict:
strict vars
This generates a compile-time error if you access a
variable that wasn't declared via use vars,
localized via my() or wasn't fully qualified.
So, do one of the following
use vars($answer);
$answer = UTC_to_Epoch(1998, 3, 11);
or
# This is the prefered method.
my $answer;
$answer = UTC_to_Epoch(1998, 3, 11);
or
$::answer = UTC_to_Epoch(1998, 3, 11);
or even
$main::answer = UTC_to_Epoch(1998, 3, 11);
BTW, the ${\FOO} bit isn't needed outside of double quotes (and in your
case, printf would be better).
HTH!
--Matthew
------------------------------
Date: Sun, 14 Feb 1999 01:46:21 -0600
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: Python vs. Perl vs. tcl ?
Message-Id: <d0v5a7.7l6.ln@magna.metronet.com>
Jonathan Stowe (gellyfish@btinternet.com) wrote:
: Worry not I am working on a version of FlameReader (tm) that will act as a
: filter to your newsfeed and will ensure that the appropriate flameage
: is inserted as necessary. It can be configured so that both inward and
: outward feeds can be filtered as required - just think the luxury of a
: flamewar without any typing on your (or anyones) part.
Yes but, would the target of the flame believe that they were
being flamed by a person rather than by a program?
Now that would be something!
Hey! What language are you gonna write that in?
It better be the *right* one or this thread could end up
slipping into the abyss...
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: 14 Feb 1999 08:03:40 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Speed of Python
Message-Id: <7a600s$8dl$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Markus Stenberg
<mstenber@cc.Helsinki.FI>],
who wrote in article <al81zjy8vvo.fsf@myntti.helsinki.fi>:
> Perl:
> @x = <>; import sys
> x = sys.stdin.readlines()
>
> Just for laughs, timings on largest text file I could find (~11M of ping
> data):
> Obviously.. Python is still faster in array-building stuff though, by
> factor of (roughly) 2.5, apparently.
Here is my data: (Solaris, thus Perl is mymalloc, stdstdio)
Python
2.66u 0.58s 0:04.54 71.3% # Discard: getting into cashe.
1.90u 0.65s 0:03.26 78.2%
1.88u 0.55s 0:02.79 87.0%
2.01u 0.39s 0:02.71 88.5%
1.86u 0.50s 0:02.52 93.6%
Perl
2.47u 0.75s 0:03.62 88.9%
2.41u 0.73s 0:03.25 96.6%
2.29u 0.82s 0:03.13 99.3%
2.34u 0.77s 0:03.14 99.0%
As you see, the difference is nowhere close to 150% times, 20% is a
better estimate. As TomC noticed, with the current implementation
Perl's <> copies stuff twice: once to put things on stack, second time
to put this into an array.
I advocated it long time ago to optimize one of these steps away (as
split currently does), it is not hard to implement.
Ilya
------------------------------
Date: Sun, 14 Feb 1999 05:01:15 GMT
From: mlehmann@prismnet.com
Subject: Using the distribution environment for development.
Message-Id: <7a5lao$l1h$1@nnrp1.dejanews.com>
I am trying to use the h2xs tool during development from step one.
It I want to create a package called Spelling::Phred I type
h2xs -XA -n Spelling::Phred
and I get the response:
Writing Spelling/Phred/Phred.pm
Writing Spelling/Phred/Makefile.PL
Writing Spelling/Phred/test.pl
Writing Spelling/Phred/Changes
Writing Spelling/Phred/MANIFEST
Which is great. I start toying with the Phred.pm file and coding to my hearts
content.
Then I want to incrementally test it. But I have other modules that are
integrated with this one, and they are also in development. Phred refers to
Ghoti (sounds like fish is one uses English phonics). Ghoti is created in a
similar manor.
Now Spelling::Phred and Spelling::Ghoti are ready for incremental testing and
minor/major refinement. But its a major pain to perform a
make install
in each subdirectory each time I make a change. Oh, and it I go to the
Spelling directory and type "make install" I install my Spelling.pm module as
well as everything below Spelling that I had in existence when I typed "perl
Makefile.PL" at the Spelling directory level.
Suddenly this handy technique is turning into a nightmare. This has to be a
very common situation, so I'd like (and probably many other readers) would
like to hear some war stories of what worked and did not work for developing
multiple packages concurrently.
So far I have found that if I make a ./Spelling directory, copy Phred.pm and
Ghoti.pm into that directory and then set my PERL5LIB environment variable to
point to the directory in which "Spelling" resides, I can test. When I am
done testing, I have to copy everything back to the proper directories in the
distribution so that I can put it into a distributable format for
installation. That requires a lot of mental book keeping.
What is your experience.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Sun, 14 Feb 1999 00:27:11 -0500
From: "Matthew O. Persico" <mpersico@erols.com>
Subject: Re: Using the distribution environment for development.
Message-Id: <36C65EAF.DE6CCD00@erols.com>
There are a number of possibilites, this being perl, after all. The key
to remember is that (in my experience), all of these will work under two
conditions:
1) You are not using any 'C' code in your modules. If you are using the
hard-core XS stuff, then you are stuck with install to put everything
where it truly belongs.
2) You are not using autosplit in your modules. If you don't know what
it is, then you're not using it an you are fine. If you do and you are,
then you'll realize what a pain to would be to move all that stuff by
hand. If you don't and you are, then stop that!
With that said, here are two options:
1) Do one good install for your module. Then, find where it is installed
and create a symlink back to where you keep the copy you are working on.
2) Create a shell script or a makefile that sits in the highest level
and, when invoked, goes into each directory and invokes the proper make
install command.
Of these, I'd advocate the second.
--
Matthew O. Persico
http://www.erols.com/mpersico
http://www.digistar.com/bzip2
------------------------------
Date: 14 Feb 1999 06:25:15 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Using the distribution environment for development.
Message-Id: <7a5q8b$797$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to
<mlehmann@prismnet.com>],
who wrote in article <7a5lao$l1h$1@nnrp1.dejanews.com>:
> Which is great. I start toying with the Phred.pm file and coding to my hearts
> content.
>
> Then I want to incrementally test it. But I have other modules that are
> integrated with this one, and they are also in development. Phred refers to
> Ghoti (sounds like fish is one uses English phonics). Ghoti is created in a
> similar manor.
>
> Now Spelling::Phred and Spelling::Ghoti are ready for incremental testing and
> minor/major refinement. But its a major pain to perform a
>
> make install
What for? Just create a script/alias which does
env PERL5OPT=-Mblib=../Spelling-Ghoti-0.03 make test
if you are in Phred directory, similarly for Ghoti directory.
Or put it into your test script
BEGIN { eval { require Spelling::Ghoti; 1 }
or eval 'use blib "../Spelling-Ghoti-0.03"' }
use Spelling::Ghoti qw(pigs fly);
Or even make it smarter, so that it globs '..' and find the latest
version of Spelling::Ghoti.
Ilya
------------------------------
Date: Sun, 14 Feb 1999 06:05:44 GMT
From: Steve Traugott <stevegt@TerraLuna.org>
To: stevegt@terraluna.org
Subject: Vim5 "quickfix" mode as a Perl IDE -- take 2
Message-Id: <7a5p3l$nqb$1@nnrp1.dejanews.com>
VIM 5.X makes a great Perl IDE.
I posted the following message in comp.editors last June describing how; I'm
following up now to fix some cut-and-paste errors (and set the record
straight in the DejaNews archives -- I keep looking up my own broken
instructions there and trying to use them.) ;-)
The important bits here are vnoremap, inoremap, cindent, cinkeys,
errorformat, makeprg, smartindent, syntax on, and the error_reformat
perl script.
My latest version of .vimrc:
============================
version 5.0
vnoremap # X^H#
inoremap # X^H#
set autowrite
set background=dark
set cindent
set cinkeys=0{,0},:,!^F,o,O,e
set errorformat=%f:%l:\ %m
set guifont=10x20
set hidden
set history=5000
set makeprg=perl\ %\ 2>&1\ \\\|\ error_reformat
set mouse=" "
set shiftwidth=2
set smartindent
set tabstop=2
set viminfo='200,%
syntax on
~/bin/error_reformat
====================
#!/usr/nas/bin/perl
# Steve Traugott stevegt@terraluna.org
# Wed Jun 3 23:14:36 PDT 1998
#
# reformats perl compiler errors for consumption by VIM 5
#
# use these in your .vimrc:
# set errorformat=%f:%l:\ %m
# set makeprg=perl\ %\ 2>&1\ \\\|\ error_reformat
#
while(<>)
{
/(.*) at (.*) line (\d+)(.*)/ && do
{
$message = $1 . $4;
$file = $2;
$line = $3;
print "$file:$line:$message\n";
next;
};
print;
}
============= Old message ============
I wanted to use VIM 5.X (www.vim.org) as a Perl IDE, so I tried something like
what Guenter tried (below), and it didn't work either. I didn't ever figure
out what the original problem was, but the following settings and script work
great instead.
This, along with VIM 5.X's syntax-driven color highlighting, embedded Perl
interpreter, and good multi-buffer management make VIM a *fantastic* tool for
doing large-project Perl development.
Thank you VIM crew!!!
Steve
.vimrc
======
version 5.0
vnoremap # X^V^H#
inoremap # X^V^H#
set cinkeys=0{,0},:,!^F,o,O,e
"set cinkeys=0{,0},:,0#,!^F,o,O,e
set errorformat=%f:%l:\ %m
set hidden
set history=500
set makeprg=perl\ %\ 2>&1\ \\^V|\ error_reformat
set shiftwidth=2
set smartindent
set viminfo='50
syntax on
~/bin/error_reformat
====================
#!perl
# Steve Traugott stevegt@terraluna.org
# Wed Jun 3 23:14:36 PDT 1998
#
# reformats perl compiler errors for consumption by VIM 5
#
# use these in your .vimrc:
# set errorformat=%f:%l:\ %m
# set makeprg=perl\ %\ 2>&1\ \\^V|\ error_reformat
#
while(<>)
{
/(.*) at (.*) line (\d+)(.*)/ && do
{
$message = $1 . $4;
$file = $2;
$line = $3;
print "$file:$line:$message\n";
next;
};
print;
}
guenter@arithmos.com wrote in comp.editors:
> I thought I'd try out Vim's quickfix mode for my programming language of
> choice, perl. I ':source' these lines:
> set makeprg=perl\ -w\ %
> set shellpipe=2>&1\|tee\ /tmp/perlerr
> set errorfile=/tmp/perlerr
> set errorformat=%m\ at\ %f\ line\ %l\%*[,.]
> and now I can say ':make' while editing a perl script and it runs
> perl. When I say ':cf' it reads in the errorfile and shows the first
> error on the command line at the bottom - so far so good.
> However, it doesn't jump to the indicated line as I would expect from
> the help text.
> E.g. when I am editing file 'x', do a ':make' and a ':cf', and the error
> says
> Missing right bracket at ./x line 87, at end of line
> then I expected Vim to jump to line 87 since I am in the right file.
> Am I doing something wrong or did I just misunderstand the help
> information?
> If I can get it to jump to the right line, then the next thing to do is
> write a perl post processor that finds the column number so I can jump
> to the exact spot.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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 4891
**************************************
