[30597] in Perl-Users-Digest
Perl-Users Digest, Issue: 1840 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Sep 6 03:09:43 2008
Date: Sat, 6 Sep 2008 00:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 6 Sep 2008 Volume: 11 Number: 1840
Today's topics:
Re: "Selling" Perl (i.e. getting the boss to let me ins <john@castleamber.com>
Re: "Selling" Perl (i.e. getting the boss to let me ins <vilain@NOspamcop.net>
Re: "Selling" Perl (i.e. getting the boss to let me ins <willem@stack.nl>
Re: "Selling" Perl (i.e. getting the boss to let me ins <john@castleamber.com>
Re: "Selling" Perl (i.e. getting the boss to let me ins <cwilbur@chromatico.net>
Re: Complex (for me) reference deconstruction sjcampbl@gmail.com
Re: Complex (for me) reference deconstruction <tadmc@seesig.invalid>
Re: Complex (for me) reference deconstruction <mark.clementsREMOVETHIS@wanadoo.fr>
Re: Data type mismatch warning using DBI <whynot@pozharski.name>
FAQ 7.16 How do I create a static variable? <xemoth@gmail.com>
Re: FAQ 7.16 How do I create a static variable? <jurgenex@hotmail.com>
new CPAN modules on Sat Sep 6 2008 (Randal Schwartz)
Re: submit to FormMail.pl throwing some error. <john@castleamber.com>
Re: submit to FormMail.pl throwing some error. <jimsgibson@gmail.com>
Re: submit to FormMail.pl throwing some error. <joost@zeekat.nl>
Re: submit to FormMail.pl throwing some error. <john@castleamber.com>
Re: submit to FormMail.pl throwing some error. <fawaka@gmail.com>
Re: submit to FormMail.pl throwing some error. <mark.clementsREMOVETHIS@wanadoo.fr>
Re: submit to FormMail.pl throwing some error. <vsrawat@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 5 Sep 2008 23:17:05 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <Xns9B10BA015DE56castleamber@130.133.1.4>
Willem <willem@stack.nl> wrote:
> John Bokma wrote:
> ) Wouldn't amaze me if those managers had in many cases a point. Sorry
> about ) that news, it's probably not what you want to hear :-D
>
> s/news/opinion/ :-)
>
> ) For the record, I am a freelance developer, and have learned a long
> time ) ago that productivity is sooner limited by that gray stuff
> between the ) ears than anything else. Probably because I had so often
> to make do what ) was available.
> )
> ) I would have no problem with coding in Notepad. Of course I would
> miss ) some things (and probably would write some small Perl scripts
> to fix ) that), but most of my coding is typing out stuff. Thinking
> happens (here) ) on paper :-).
>
> Most of my work consists of working on existing code, finding out
> where to make changes, finding out how things work, and then making
> small changes in several places. In such cases, certain features are
> invaluable.
Which ones?
> In any case, you're talking about 'problem coding on other than
> favourite
> editor' while I'm talking about 'being faster in favourite editor'.
I don't think that I am faster in my favourite editor TextPad, than in,
say for example Vim (I am learning Emacs, but if I have edited a few files
in it, I don't think I am faster or slower compared to TextPad).
Of course, if I have to switch from TextPad to, say Kate, today, I have to
get used to Kate. But after some time (a week or so), IMO I *should* be as
fast as with TextPad.
> So if most of your work is typing out stuff then, yes, you won't be
> much faster in another editor. But if most of your work is *editing*
> stuff, then I *will* be much faster, in my opinion.
I don't see why yet. The time I had to use vim a lot was on a huge (650+
inhouse Perl modules) code maintainance project. I was very used to
TextPad back then, but in no time I was splitting windows in vim, and
jumping to lines with issues.
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: Fri, 05 Sep 2008 17:39:42 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <vilain-ED6B0E.17394205092008@comcast.dca.giganews.com>
In article <864p4u6yww.fsf@mithril.chromatico.net>,
Charlton Wilbur <cwilbur@chromatico.net> wrote:
> >>>>> "W" == Willem <willem@stack.nl> writes:
>
> W> Some managers believe that the opinions of a developer, on issues
> W> such as the correlation between editor familiarity and
> W> productivity, should not be taken seriously. Those aren't
> W> serious managers and I would stay away.
>
> Indeed. On the other hand, this is what interviews are for: they are
> just as much for the potential employee to evaluate the company as for
> the company to evaluate the potential customer. I've turned down jobs
> because they were needlessly restrictive about work environment and
> development environment, because I know what I like and I know what I
> find annoying, and I don't really want to spend 8 hours a day being
> annoyed because my manager thinks my comfort level with the tools I'm
> using is less important than a foolish consistency on everyone's desktop.
>
> I mean, we're working with *text files*. "Standardizing" on a single
> editor, or even on a single platform, is dim. The group I work in has
> people on Macs, Windows, and Linux, and I couldn't tell you what most of
> the people use for editors. This is a good thing.
>
> Charlton
Yeah, they all might be on different platforms, but I'll bet you all
conform to a "coding standard". Stuff like parens on separate lines,
indents are 2 spaces, put spaces around ( ), etc. A friend is rather
picky about "his" coding standards and managed to get a lot of them
implemented in the startup where he worked. It saved a lot when looking
through their huge code-base.
And what about standardizing on the comments for fixing bugs? This guy
also commented his code with the specific bug in their tracking database
as well as other relevant info. When their bugtrack system went south
due to a dim-witted sysadmin inept building move, much of the bugs could
be retrieved from the comments in the code base.
Sometimes standards are a good thing. Just don't ever make me use
Windows. I charge 100x for working on Windows.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]
------------------------------
Date: Sat, 6 Sep 2008 00:48:56 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <slrngc3kro.gv1.willem@snail.stack.nl>
John Bokma wrote:
) Willem <willem@stack.nl> wrote:
)> Most of my work consists of working on existing code, finding out
)> where to make changes, finding out how things work, and then making
)> small changes in several places. In such cases, certain features are
)> invaluable.
)
) Which ones?
Search, replace, macro recording on the fly, diffing between split
windows, and all the syntax highlighting and autoindenting and such.
Plus the simple extensibility with a scripting language, which a vi
user already knows most of, because it's basically the same as the
editing commands.
Of course, most editors have that stuff, but if you use all of it, it
takes a lot more time to learn all the relevant keyboard shortcuts to
do the things you want to do.
)> In any case, you're talking about 'problem coding on other than
)> favourite
)> editor' while I'm talking about 'being faster in favourite editor'.
)
) I don't think that I am faster in my favourite editor TextPad, than in,
) say for example Vim (I am learning Emacs, but if I have edited a few files
) in it, I don't think I am faster or slower compared to TextPad).
The big advantage vim has over most other editors is that it can be
completely controlled from thust the basic alphanumeric keys, so you don't
have to lift your hands from the main part of the keyboard to do stuff.
Then there is the advantage that all the editing commands can be used
in conjunction with all the movement commands, making possible a lot
of advanced editing shortcuts that most other editors don't have.
Downside is the steep learning curve of having to memorize all the
commands, so switching *to* vim is usually not recommended.
) Of course, if I have to switch from TextPad to, say Kate, today, I have to
) get used to Kate. But after some time (a week or so), IMO I *should* be as
) fast as with TextPad.
I'm not familiar with Kate but I assume they are both quite similar.
Vim, on the other hand, is quite different as mentioned before. Of
course, ths modern versions have mouse menus and stuff, but it's the
keyboard commands that set it apart. Not using the mouse -> BIG speedup.
)> So if most of your work is typing out stuff then, yes, you won't be
)> much faster in another editor. But if most of your work is *editing*
)> stuff, then I *will* be much faster, in my opinion.
)
) I don't see why yet. The time I had to use vim a lot was on a huge (650+
) inhouse Perl modules) code maintainance project. I was very used to
) TextPad back then, but in no time I was splitting windows in vim, and
) jumping to lines with issues.
Were you using the keyboard commands, or the menu entries ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: 6 Sep 2008 01:33:48 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <Xns9B10D12EF8019castleamber@130.133.1.4>
Willem <willem@stack.nl> wrote:
> John Bokma wrote:
[..]
> Of course, most editors have that stuff, but if you use all of it, it
> takes a lot more time to learn all the relevant keyboard shortcuts to
> do the things you want to do.
Another thing a lot of editors share is the ability to redefine the
keyboard shortcuts (Although it's something I try to avoid).
> The big advantage vim has over most other editors is that it can be
> completely controlled from thust the basic alphanumeric keys, so you
> don't have to lift your hands from the main part of the keyboard to do
> stuff.
Only thing I can think off that requires the mouse in TextPad is moving
the splitter. But I don't mind to move my hands away from the keyboard
now and then, I have no problems with the mouse, and some things I do
faster with it.
> Downside is the steep learning curve of having to memorize all the
> commands, so switching *to* vim is usually not recommended.
Heh, I can't see why.
> ) Of course, if I have to switch from TextPad to, say Kate, today, I
> have to ) get used to Kate. But after some time (a week or so), IMO I
> *should* be as ) fast as with TextPad.
>
> I'm not familiar with Kate but I assume they are both quite similar.
Nor am I (on purpose, but I've used it a few times, some time ago), and
no idea how similar they are. But that was somewhat my point :-)
> Vim, on the other hand, is quite different as mentioned before.
I can't see why, or maybe I am too used to vi/vim :-).
> Of
> course, ths modern versions have mouse menus and stuff, but it's the
> keyboard commands that set it apart. Not using the mouse -> BIG
> speedup.
To me that depends on what I am doing, and I think that I am experienced
enough with my current editor that I automatically make the right
decision between keyboard and mouse.
> ) I don't see why yet. The time I had to use vim a lot was on a huge
> (650+ ) inhouse Perl modules) code maintainance project. I was very
> used to ) TextPad back then, but in no time I was splitting windows in
> vim, and ) jumping to lines with issues.
>
> Were you using the keyboard commands, or the menu entries ?
Keyboard. I don't use the mouse much while editing in TextPad except
when it works faster (or is the only way)
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: Fri, 05 Sep 2008 22:54:43 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <86y72656h8.fsf@mithril.chromatico.net>
>>>>> "JB" == John Bokma <john@castleamber.com> writes:
>> In such cases, certain
>> features are invaluable.
JB> Which ones?
Incremental search. Search & replace using regular expressions. Code
narrowing or folding (depending on what your editor calls it).
Parenthesis/brace/bracket matching.
Secondarily, Emacs keybindings for keyboard navigation. I imprinted
on them over a decade ago; they're in my muscle memory now.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Fri, 5 Sep 2008 15:29:09 -0700 (PDT)
From: sjcampbl@gmail.com
Subject: Re: Complex (for me) reference deconstruction
Message-Id: <96a07b2c-dc08-4587-9254-d758b7eec30c@c65g2000hsa.googlegroups.com>
Ok, I think I understand. Thanks for the help.
So...
for $r (@{$t->{rows}}) {
{rows} is a hash key within a hash referenced by $t
$t->{rows} contains an array reference
@{$t->{rows}} de-references this array reference, returning an actual
array
$r is an element of this array and contains a reference to a hash
thus...
$r->{cells}[1]{data}
{cells} is a hash key within the hash referenced by $r
$r->{cells} contains a reference to an array
[1] is the 2nd array element referenced by $r->{cells} and contains a
hash reference
{data} is a hash key referenced by the hash referenced by $r->{cells}
[1]
{data} is apparently not yet another reference, but an actual data
element
------------------------------
Date: Fri, 5 Sep 2008 18:15:30 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Complex (for me) reference deconstruction
Message-Id: <slrngc3fci.v5g.tadmc@tadmc30.sbcglobal.net>
sjcampbl@gmail.com <sjcampbl@gmail.com> wrote:
> Ok, I think I understand. Thanks for the help.
>
> So...
>
> for $r (@{$t->{rows}}) {
>
> {rows} is a hash key within a hash referenced by $t
> $t->{rows} contains an array reference
> @{$t->{rows}} de-references this array reference, returning an actual
> array
Almost.
It does not return an actual array. It returns a list.
See:
perldoc -q difference
What is the difference between a list and an array?
> $r is an element of this array
$r is an element of this list.
> thus...
>
> $r->{cells}[1]{data}
>
> {cells} is a hash key within the hash referenced by $r
> $r->{cells} contains a reference to an array
> [1] is the 2nd array element referenced by $r->{cells} and contains a
> hash reference
> {data} is a hash key referenced by the hash referenced by $r->{cells}
> [1]
You've gotten all of that right though.
You are on your way!
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Sat, 06 Sep 2008 05:56:38 +0000
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: Complex (for me) reference deconstruction
Message-Id: <48c21b96$0$871$ba4acef3@news.orange.fr>
Tad J McClellan wrote:
> sjcampbl@gmail.com<sjcampbl@gmail.com> wrote:
>> Ok, I think I understand. Thanks for the help.
>>
>> So...
>>
>> for $r (@{$t->{rows}}) {
>>
>> {rows} is a hash key within a hash referenced by $t
>> $t->{rows} contains an array reference
>> @{$t->{rows}} de-references this array reference, returning an actual
>> array
>
>
> Almost.
>
> It does not return an actual array. It returns a list.
>
> See:
>
> perldoc -q difference
>
> What is the difference between a list and an array?
>
Hmmm... OK - I've read the faq above and it says:
"
An array has a changeable length. A list does not. An array is
something you can push or pop, while a list is a set of values.
"
But you *can* pop etc a dereferenced arrayref.
mark@hermes:~$ perl -Mstrict -Mwarnings -le 'my $c=[qw(a b c)];print pop
@{$c}; print "@{$c}"'
c
a b
mark@hermes:~$
So - the snippet of code above initializes an arrayref, and then pops
its dereferenced value. According to the faq this would make the
deferenced value an array since I can pop it.
Am I missing something?
thanks,
Mark
------------------------------
Date: Fri, 05 Sep 2008 22:14:46 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Data type mismatch warning using DBI
Message-Id: <62d8p5xbqb.ln2@carpet.zombinet>
Peter Jamieson <ldolan@thinkinghatbigpond.net.au> wrote:
*SKIP*
> When this happens the script contiues to run and on looking at the db
> the particular record is absent. What I would like to happen is for
> my script to die when the above warning occurs so that I can examine
> the input file to see what was causing the data type mismatch and
> rectify the error.
Look through C<perldoc DBI> for word I<RaiseError> (description is in
L<ATTRIBUTES COMMON TO ALL HANDLES> section).
BTW, consider validating your input.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
------------------------------
Date: Fri, 5 Sep 2008 20:49:50 -0700 (PDT)
From: Owen <xemoth@gmail.com>
Subject: FAQ 7.16 How do I create a static variable?
Message-Id: <ae2aac97-af13-449b-8c71-5d92ee03cef5@b30g2000prf.googlegroups.com>
On reading this FAQ (posted to this forum yesterday) I didn't
understand what was going on.
Why would you want to do this? Would not a global variable suffice?
Or put another way, how would using a global variable fail but a
static variable fulfil a requirement.
Sorry if this is a basic question, but I just can't get my head around
it.
TIA
Owen
------------------------------
Date: Fri, 05 Sep 2008 21:31:36 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: FAQ 7.16 How do I create a static variable?
Message-Id: <jl14c49l807g6jo58rkvu3mrgc0eh338kl@4ax.com>
Owen <xemoth@gmail.com> wrote:
>On reading this FAQ (posted to this forum yesterday) I didn't
>understand what was going on.
>
>Why would you want to do this? Would not a global variable suffice?
>Or put another way, how would using a global variable fail but a
>static variable fulfil a requirement.
A global variable is visible and can be altered, well, globally, which
usually is A Bad Thing(TM).
A static variable is local to a specific subroutine and cannot be
accessed or changed outside of this sub, thereby ensuring that it still
has the same values as the last time the sub defined it instead of some
rouge piece of outside code.
jue
------------------------------
Date: Sat, 6 Sep 2008 04:42:22 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sat Sep 6 2008
Message-Id: <K6rBqM.19r7@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Array-Tour-0.06
http://search.cpan.org/~jgamble/Array-Tour-0.06/
Base class for Array Tours.
----
BDB-Wrapper-0.18
http://search.cpan.org/~hikarine/BDB-Wrapper-0.18/
Wrapper module for BerkeleyDB.pm
----
Biblio-Thesaurus-0.32
http://search.cpan.org/~ambs/Biblio-Thesaurus-0.32/
Perl extension for managing ISO thesaurus
----
Bundle-DBD-PO-0.07
http://search.cpan.org/~steffenw/Bundle-DBD-PO-0.07/
A bundle to install all DBD::PO related modules
----
Business-PayPal-NVP-1.03
http://search.cpan.org/~scottw/Business-PayPal-NVP-1.03/
PayPal NVP API
----
CGI-Application-Plugin-Config-Any-0.03
http://search.cpan.org/~mab/CGI-Application-Plugin-Config-Any-0.03/
Add Config::Any Support to CGI::Application
----
CGI-Application-Plugin-Config-Any-0.04
http://search.cpan.org/~mab/CGI-Application-Plugin-Config-Any-0.04/
Add Config::Any Support to CGI::Application
----
CGI-Application-Plugin-Config-Any-0.10
http://search.cpan.org/~mab/CGI-Application-Plugin-Config-Any-0.10/
Add Config::Any Support to CGI::Application
----
Cache-CacheFactory-1.07_03
http://search.cpan.org/~sgraham/Cache-CacheFactory-1.07_03/
factory class for Cache::Cache and other modules.
----
Class-MethodCache-0.04
http://search.cpan.org/~nuffin/Class-MethodCache-0.04/
Manipulate Perl's method resolution cache
----
Compress-LZF-3.4
http://search.cpan.org/~mlehmann/Compress-LZF-3.4/
extremely light-weight Lempel-Ziv-Free compression
----
DBD-PO-0.07
http://search.cpan.org/~steffenw/DBD-PO-0.07/
DBI driver for PO files
----
DBIx-Class-RDBOHelpers-0.06
http://search.cpan.org/~karman/DBIx-Class-RDBOHelpers-0.06/
DBIC compat with Rose::DBx::Object::MoreHelpers
----
Data-SimplePaginator-0.3
http://search.cpan.org/~jbuhacoff/Data-SimplePaginator-0.3/
data pagination without assumptions (I think)
----
Data-SimplePaginator-0.3.1
http://search.cpan.org/~jbuhacoff/Data-SimplePaginator-0.3.1/
data pagination without assumptions (I think)
----
Data-Validation-0.2.56
http://search.cpan.org/~pjfl/Data-Validation-0.2.56/
Check data values for conformance with constraints
----
DateTime-Format-Natural-0.73
http://search.cpan.org/~schubiger/DateTime-Format-Natural-0.73/
Create machine readable date/time with natural parsing logic
----
Deliantra-1.22
http://search.cpan.org/~mlehmann/Deliantra-1.22/
Deliantra suppport module to read/write archetypes, maps etc.
----
Deliantra-Client-0.9976
http://search.cpan.org/~mlehmann/Deliantra-Client-0.9976/
----
Devel-Modlist-0.801
http://search.cpan.org/~rjray/Devel-Modlist-0.801/
Perl extension to collect module use information
----
ExPar-1.00
http://search.cpan.org/~harlinh/ExPar-1.00/
Extended Parameters command line parser.
----
ExPar-1.00
http://search.cpan.org/~hlhamilt/ExPar-1.00/
Extended Parameters command line parser.
----
Fey-ORM-0.10
http://search.cpan.org/~drolsky/Fey-ORM-0.10/
A Fey-based ORM
----
Games-Risk-0.4.0
http://search.cpan.org/~jquelin/Games-Risk-0.4.0/
classical 'risk' board game
----
Games-Risk-0.4.1
http://search.cpan.org/~jquelin/Games-Risk-0.4.1/
classical 'risk' board game
----
Geometry-Primitive-0.10
http://search.cpan.org/~gphat/Geometry-Primitive-0.10/
Primitive Geometry Entities
----
Getopt-ExPar-1.00
http://search.cpan.org/~hlhamilt/Getopt-ExPar-1.00/
Extended Parameters command line parser.
----
Getopt-ExPar-1.01
http://search.cpan.org/~hlhamilt/Getopt-ExPar-1.01/
Extended Parameters command line parser.
----
Graphics-Color-0.13
http://search.cpan.org/~gphat/Graphics-Color-0.13/
Device and library agnostic color spaces.
----
Graphics-Color-0.14
http://search.cpan.org/~gphat/Graphics-Color-0.14/
Device and library agnostic color spaces.
----
HTML-DOM-0.018
http://search.cpan.org/~sprout/HTML-DOM-0.018/
A Perl implementation of the HTML Document Object Model
----
HTML-FormFu-ExtJS-0.04
http://search.cpan.org/~perler/HTML-FormFu-ExtJS-0.04/
Render and validate ExtJS forms using HTML::FormFu
----
HTML-Template-Pro-0.71
http://search.cpan.org/~viy/HTML-Template-Pro-0.71/
Perl/XS module to use HTML Templates from CGI scripts
----
IO-Async-0.17
http://search.cpan.org/~pevans/IO-Async-0.17/
a collection of modules that implement asynchronous filehandle IO
----
Kephra-0.3.10.1
http://search.cpan.org/~lichtkind/Kephra-0.3.10.1/
crossplatform, GUI-Texteditor along perllike Paradigms
----
Lingua-StarDict-Gen-0.06
http://search.cpan.org/~jjoao/Lingua-StarDict-Gen-0.06/
----
Math-GSL-0.11_01
http://search.cpan.org/~leto/Math-GSL-0.11_01/
Perl interface to the GNU Scientific Library (GSL)
----
MooseX-ClassAttribute-0.05
http://search.cpan.org/~drolsky/MooseX-ClassAttribute-0.05/
Declare class attributes Moose-style
----
MooseX-Singleton-0.11
http://search.cpan.org/~drolsky/MooseX-Singleton-0.11/
turn your Moose class into a singleton
----
Object-Boolean-0.02
http://search.cpan.org/~bduggan/Object-Boolean-0.02/
Represent boolean values as objects
----
PAR-Repository-0.16
http://search.cpan.org/~smueller/PAR-Repository-0.16/
Create and modify PAR repositories
----
POE-Component-Server-SimpleHTTP-1.48
http://search.cpan.org/~bingos/POE-Component-Server-SimpleHTTP-1.48/
Perl extension to serve HTTP requests in POE.
----
Parse-CPAN-MirroredBy-0.02
http://search.cpan.org/~adamk/Parse-CPAN-MirroredBy-0.02/
Parse MIRRORED.BY
----
SVN-Agent-0.03
http://search.cpan.org/~bosu/SVN-Agent-0.03/
simple svn manipulation.
----
Scalar-Util-Refcount-1.0.1
http://search.cpan.org/~jnixon/Scalar-Util-Refcount-1.0.1/
Show an object's reference count
----
Scalar-Util-Refcount-1.0.2
http://search.cpan.org/~jnixon/Scalar-Util-Refcount-1.0.2/
Show an object's reference count
----
Search-QueryParser-SQL-0.001
http://search.cpan.org/~karman/Search-QueryParser-SQL-0.001/
turn free-text queries into SQL WHERE clauses
----
Sleep-0.0.3
http://search.cpan.org/~stuifzand/Sleep-0.0.3/
A library for making REST web applications.
----
Spreadsheet-Read-0.28
http://search.cpan.org/~hmbrand/Spreadsheet-Read-0.28/
Meta-Wrapper for reading spreadsheet data
----
Spreadsheet-WriteExcel-2.24
http://search.cpan.org/~jmcnamara/Spreadsheet-WriteExcel-2.24/
Write to a cross-platform Excel binary file.
----
String-RewritePrefix-0.002
http://search.cpan.org/~rjbs/String-RewritePrefix-0.002/
rewrite strings based on a set of known prefixes
----
Sys-Statistics-Linux-0.37
http://search.cpan.org/~bloonix/Sys-Statistics-Linux-0.37/
Front-end module to collect system statistics
----
Task-Kensho-0.0.1
http://search.cpan.org/~perigrin/Task-Kensho-0.0.1/
A Glimpse at an Enlightened Perl
----
Text-CSV-1.09
http://search.cpan.org/~makamaka/Text-CSV-1.09/
comma-separated values manipulator (using XS or PurePerl)
----
TheSchwartz-Simple-0.04
http://search.cpan.org/~miyagawa/TheSchwartz-Simple-0.04/
Lightweight TheSchwartz job dispatcher using plain DBI
----
Time-Stats-0.3
http://search.cpan.org/~pmichaud/Time-Stats-0.3/
Easy timing info
----
file_tabulardata-0.01
http://search.cpan.org/~xerxes/file_tabulardata-0.01/
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: 5 Sep 2008 23:09:43 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <Xns9B10B8C0DBB1Fcastleamber@130.133.1.4>
Joost Diepenmaat <joost@zeekat.nl> wrote:
> John Bokma <john@castleamber.com> writes:
>
>> V S Rawat <vsrawat@gmail.com> wrote:
>>
>>> my file ContactUs.html is kept in /www
>>
>> Tip: you might want to rename it to contact-us.html
>
> Maybe, but the're no technical reason to do so.
Hence tip. A technical reason might be that your webserver is case-
sensistive because the underlying filesystem is. A non-techincal one:
CamelCase is supposed to be less readable (and a technical one might be
that keyword-keyword is rewarded by SEs versus KeywordKeyword
>>> FormMail.pl is kept in /www/cgi-bin
>>
>> Advice: you might want to keep your cgi-bin side by side with www, not
>> *in* www (i.e. your DOCUMENT_ROOT),
>
> Again, there's no real reason to do so.
Yes there is: security for one.
> And separating files out by
> "type" can really mess up your website/code structure.
Why?
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: Fri, 05 Sep 2008 16:57:45 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <050920081657450616%jimsgibson@gmail.com>
In article <48c192b4$0$199$e4fe514c@news.xs4all.nl>, Leon Timmermans
<fawaka@gmail.com> wrote:
> On Sat, 06 Sep 2008 01:16:05 +0530, V S Rawat wrote:
>
> > I am creating a website.
> >
> > The website root is /www at server.
> >
> > my file ContactUs.html is kept in /www
> >
> > FormMail.pl is kept in /www/cgi-bin
> > It was downloaded from
> > http://nms-cgi.sourceforge.net/formmail_compat-3.14c1/FormMail.pl No
> > changes done.
> >
> > .FormMail.conf is also at /www
> >
>
> Oy vey! That script is mess. Please do yourself a favor and get something
> better.
In what way is that script a "mess"? The NMS scripts are touted for
robustness and security. Yours is the first criticism I have
encountered. The script source file is certainly neat enough.
I have not used any NMS scripts or studied them in any detail, but they
are frequently recommended by others.
What do you recommend as being better? And why?
--
Jim Gibson
------------------------------
Date: Sat, 06 Sep 2008 02:13:05 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <87bpz2nnce.fsf@zeekat.nl>
John Bokma <john@castleamber.com> writes:
> Joost Diepenmaat <joost@zeekat.nl> wrote:
>> John Bokma <john@castleamber.com> writes:
>>> V S Rawat <vsrawat@gmail.com> wrote:
>>>> my file ContactUs.html is kept in /www
>>> Tip: you might want to rename it to contact-us.html
>>
>> Maybe, but the're no technical reason to do so.
>
> Hence tip. A technical reason might be that your webserver is case-
> sensistive because the underlying filesystem is.
In which case it won't matter what the case is.
> A non-techincal one: CamelCase is supposed to be less readable (and
> a technical one might be that keyword-keyword is rewarded by SEs
> versus KeywordKeyword
I'll grant you that.
>>>> FormMail.pl is kept in /www/cgi-bin
>>>
>>> Advice: you might want to keep your cgi-bin side by side with www, not
>>> *in* www (i.e. your DOCUMENT_ROOT),
>>
>> Again, there's no real reason to do so.
>
> Yes there is: security for one.
Bah. The only thing you're protecting against with this is bad system
management. And that can will mess up security no matter where you
place your CGI scripts.
>> And separating files out by
>> "type" can really mess up your website/code structure.
>
> Why?
One reason is, that I want my scripts to be portable. For instance. I
would like to refer to an image using a relative URL from a CGI: print
q{ <img src="foo.png">} I don't want to have to find out where the
images are just because I just moved the whole app to some other
directory.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 6 Sep 2008 00:51:52 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <Xns9B10CA12FFC70castleamber@130.133.1.4>
Joost Diepenmaat <joost@zeekat.nl> wrote:
> John Bokma <john@castleamber.com> writes:
>
>> Joost Diepenmaat <joost@zeekat.nl> wrote:
>>> John Bokma <john@castleamber.com> writes:
>>>> V S Rawat <vsrawat@gmail.com> wrote:
>>>>> my file ContactUs.html is kept in /www
>>>> Tip: you might want to rename it to contact-us.html
>>>
>>> Maybe, but the're no technical reason to do so.
>>
>> Hence tip. A technical reason might be that your webserver is case-
>> sensistive because the underlying filesystem is.
>
> In which case it won't matter what the case is.
Yes, it does. Imagine being on the phone with someone...
>> Yes there is: security for one.
>
> Bah. The only thing you're protecting against with this is bad system
> management.
Say hello to virtual hosting.
> And that can will mess up security no matter where you
> place your CGI scripts.
Yes, and a nuclear war makes things even worse. Security is about reducing
probabilities.
>>> And separating files out by
>>> "type" can really mess up your website/code structure.
>>
>> Why?
>
> One reason is, that I want my scripts to be portable. For instance. I
> would like to refer to an image using a relative URL from a CGI: print
> q{ <img src="foo.png">} I don't want to have to find out where the
> images are just because I just moved the whole app to some other
> directory.
Pfft. Well, I won't put my custom Perl modules in the same directory as
the images, the Perl program, configuration file(s), templates, etc and
all under the document root. YMMV, but it sounds very odd to me, and I
would never recommend such a set up.
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: 06 Sep 2008 01:19:03 GMT
From: Leon Timmermans <fawaka@gmail.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <48c1da87$0$182$e4fe514c@news.xs4all.nl>
On Fri, 05 Sep 2008 16:57:45 -0700, Jim Gibson wrote:
> In article <48c192b4$0$199$e4fe514c@news.xs4all.nl>, Leon Timmermans
> <fawaka@gmail.com> wrote:
>
>
> In what way is that script a "mess"? The NMS scripts are touted for
> robustness and security. Yours is the first criticism I have
> encountered. The script source file is certainly neat enough.
It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.
> I have not used any NMS scripts or studied them in any detail, but they
> are frequently recommended by others.
Given the fact that it is a drop-in replacement for that awful script
from "Matt's script archive" this architecture is unavoidable, but that
doesn't make it pretty to look at.
> What do you recommend as being better? And why?
There is a version of it that is split out, that is already infinitely
better.
Regards,
Leon
------------------------------
Date: Sat, 06 Sep 2008 06:00:11 +0000
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <48c21c6b$0$925$ba4acef3@news.orange.fr>
Leon Timmermans wrote:
> On Fri, 05 Sep 2008 16:57:45 -0700, Jim Gibson wrote:
>
>> In article<48c192b4$0$199$e4fe514c@news.xs4all.nl>, Leon Timmermans
>> <fawaka@gmail.com> wrote:
>>
>>
>> In what way is that script a "mess"? The NMS scripts are touted for
>> robustness and security. Yours is the first criticism I have
>> encountered. The script source file is certainly neat enough.
>
> It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.
Where I work (a Java and 4GL shop) there is a Java class with 12500
lines. One of its methods has *8000* lines composed of the same 20 or so
lines of code copied-and pasted and modified for different data values.
On one occasion the compiler even refused to compile it
(MethodTooComplexException or somesuch). This is an extreme example but,
unfortunately, fairly typical. Fortunately *I* don't have to maintain it :)
Mark
------------------------------
Date: Sat, 06 Sep 2008 12:33:03 +0530
From: V S Rawat <vsrawat@gmail.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <g9t9v5$bil$1@aioe.org>
On 9/6/2008 6:49 AM India Time, _Leon Timmermans_ wrote:
> On Fri, 05 Sep 2008 16:57:45 -0700, Jim Gibson wrote:
>
>> In article <48c192b4$0$199$e4fe514c@news.xs4all.nl>, Leon Timmermans
>> <fawaka@gmail.com> wrote:
>>
>>
>> In what way is that script a "mess"? The NMS scripts are touted for
>> robustness and security. Yours is the first criticism I have
>> encountered. The script source file is certainly neat enough.
>
> It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.
>
>> I have not used any NMS scripts or studied them in any detail, but they
>> are frequently recommended by others.
>
> Given the fact that it is a drop-in replacement for that awful script
> from "Matt's script archive" this architecture is unavoidable, but that
> doesn't make it pretty to look at.
>
>> What do you recommend as being better? And why?
>
> There is a version of it that is split out, that is already infinitely
> better.
Where can I find a better/ sleaker version to download and use for free?
>
> Regards,
>
> Leon
Thanks.
--
Rawat
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1840
***************************************
