Re: Introduction Letter
On Sun, 2005-02-27 at 16:28 -0800, Ofer Nave wrote: 2) requesting feedback on design/implementation For reviews there's also the code-review-ladder: http://lists.netthink.co.uk/listinfo/code-review-ladder -- Bye, -Torsten
Re: Introduction Letter
Andrew Savige wrote:
[...]
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought not
until I noticed HTML::Parser uses this style. Alternatives are
I like this style.
CamelCase style (a la XML::Parser, for example):
{ UseReturn = 1 },
I think this is yucky. Its use is eschewed for variable names (perlstyle
says that it's harder for non-native English speakers) so I don't see
that it has any legitimate use for hash keys (which are nothing more
than second-class variable names).
or dash-option style (a la CGI, for example):
{ -use_return = 1 },
I'm not too fond of this either. I've always felt that it's trying to
emulate command line switches, poorly. It fails on multi word names. A
longword switch should be written as --use-return, at least according to
long-standing tradition. It grates on my nerves when I see switches that
mix dashes and underscores like --use_return. That just feels wrong, as
if the author isn't aware of prior art.
And so if you accept my hypotheses that --use-return is the Right Thing,
then you can't specify that as a hash key bareword. Hence I judge it to
be a failure.
So I would tend to consider that { use_return = 1 } is the preferred
way. I certainly find it to be the most appealing from a visual point of
view.
I'm damned if I can find a reference clearly stating which one of
these three styles is preferred. Can anyone point me to a reference
on this?
Nor can I, but my gut feeling is that most of the modules I use on a
regular basis use the first form.
David
Re: Introduction Letter
* Andrew Savige [EMAIL PROTECTED] [2005-02-28T04:22:04]
This function synonym:
sub run { prun( @_ ) }
is better implemented as:
sub run { prun }
...which, in turn, is better implemented as
sub run { goto prun }
because it will never have to return to run. The return value of prun
will be returned directly.
Or, finally:
*run = \prun
which will just make calls to run invoke prun directly.
--
rjbs
pgp66ooVqWZSK.pgp
Description: PGP signature
Re: Introduction Letter
* Andrew Savige [EMAIL PROTECTED] [2005-02-28 10:25]:
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought
not until I noticed HTML::Parser uses this style.
File::Find also uses this. So do a large number of OO modules
which use named parameters. This style follows accepted naming
practice for variables and subs/methods.
Alternatives are CamelCase style (a la XML::Parser, for
example):
Yuck. We look down on that in variable and sub/method names; why
would we prefer it for hash keys?
or dash-option style (a la CGI, for example):
Ech! This meme should be killed with great prejudice. It makes
code noisy for no good reason. Try reading the source of a
complex Tk GUI and tell me if you don't think it looks ugly and
messy. Four thumbs down to this idea.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
RE: Introduction Letter
Title: RE: Introduction Letter messy. Four thumbs down to this idea. You have four thumbs Aristotle? Must make for a crowded space bar eh? ;-) Yves
Re: Introduction Letter
On Mon, 28 Feb 2005, Torsten Schoenfeld wrote: http://lists.netthink.co.uk/listinfo/code-review-ladder That box was having hardware problems last week. The maypole lists were on the box (now they're on SrcFrg), so maybe this has moved somewhere else too. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: Introduction Letter
* Orton, Yves [EMAIL PROTECTED] [2005-02-28 14:45]: messy. Four thumbs down to this idea. You have four thumbs Aristotle? Must make for a crowded space bar eh? Heh, got me. I was referring to thumbs + big toes, wrongly assuming the toes are called thumbs in English. I actually had to rummage around in my memory when it occured to me that they're not called the same as thumbs in German either. It is becuase there are no separate words for toes or thumbs in Greek. The thumb is just the big finger, and the toes are fingers of the foot, and the big toe is referred to as big finger of the foot. So basically, four big fingers down to the idea. Okay, that was very offtopic. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Introduction Letter
On Mon, 28 Feb 2005, Andrew Savige wrote:
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought not
This is pretty common. Pretty much every module I've written uses it ;)
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Introduction Letter
Andrew Savige wrote:
--- Ofer Nave wrote:
Here's the POD for my new Parallel::Simple module:
Interface
-
To me, offering both:
Parallel::Simple::run()
and:
Parallel::Simple-run()
just makes the interface bigger -- more for the user to read and
grok -- without any benefit (at least, none I can see). Suggest
you drop the second form (which does not currently work correctly
because the class name is passed as the first parameter and is not
being shifted). Ditto for offering the run() synonym for prun().
I realized last night that it's impossible for me to support both
syntaxes with anything better than a total hack, so I'm throwing it
out. In fact, I've replaced all occurances of the word 'method' with
'function'. It's no an OO module, it doesn't need method calling
syntax. I just tried to put it in initially because 'class methods'
seem all the rage now, and I thought I'd just follow the example of
those I respect.
I've also now removed any traces of the run() synonym. You're right -
why complicate things with no benefit.
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought not
until I noticed HTML::Parser uses this style. Alternatives are
CamelCase style (a la XML::Parser, for example):
{ UseReturn = 1 },
or dash-option style (a la CGI, for example):
{ -use_return = 1 },
I'm damned if I can find a reference clearly stating which one of
these three styles is preferred. Can anyone point me to a reference
on this?
I've seen all three. They're all good, so I'm up for using any one of
them. I chose all-lowercase initially to match the identifer naming
conventions.
Your example:
die( Parallel::errplus );
should be written:
die( Parallel::errplus() );
to avoid bareword error under use strict.
Again, I copied that convention from the greats - in this case,
DBI::errstr. In the examples, Tim never includes the parentheses.
What's funny is that I actually like the parentheses, since I strive to
avoid any ambiguity, but I left them off here because I was trying to
make my first CPAN module as perl-ish as possible - when in Rome and all
that. I'll add parentheses back on.
Incidentaly, the above should have read die( Parallel::Simple::errplus
);. I left out the 'Simple::'. Amazing where you find bugs nowadays. :)
Implementation
--
Just a couple of micro-optimizations I noticed.
This function synonym:
sub run { prun( @_ ) }
is better implemented as:
sub run { prun }
This special form of sub call makes current @_ visible to called
subroutine. I suppose the primitive-obsessed might prefer:
*Parallel::Simple::run = \prun;
After sending my email out, I discovered that realpath() is an alias in
the Cwd module and hit the source to see how it's being done. They're
using the function aliasing style, which I believe is the fastest (
*alias = \function ), so I changed my code to that style. Of course,
five minutes ago I got rid of the alias entirely (per your suggestion),
so this is no longer relevant.
In a couple of places, I noticed:
/HASH/o
The /o modifier is meaningless here and should be removed.
Ok.
You get the return code here:
$child_registry{$child}[1] = $? 8;
yet miss getting if it died hard from a signal via:
$? 127;
Further getting whether it dumped core via:
$? 128;
is probably overkill. Not sure how this would affect your interface,
but I've seen cases where a process crashes yet returns a $? 8
of zero while $? 127 is 11 (SIGSEGV).
Seriously? Is there anywhere I can learn more about this?
-ofer
Re: Introduction Letter
Ofer, With all due respect to Andrew, please remember that his is but one opinion. I've also now removed any traces of the run() synonym. You're right - why complicate things with no benefit. I didn't see anything wrong with the concept. Personally I would have done it the other way around (i.e. make prun a synonym for Parallel::Simple::run), but that's a minor point. To me, run is a perfectly reasonable name for the function when fully qualified, but it makes sense not to export (even only when requested) such a simple function name into the global namespace. In fact, I might go even further and name it par_run or somesuch. But that's just me. Oh, and I do agree with the comments about using *Parallel::Simple::run = \prun; instead of the way you've done it. That's the proper way to create a synonym IMHO. What's funny is that I actually like the parentheses, since I strive to avoid any ambiguity, but I left them off here because I was trying to make my first CPAN module as perl-ish as possible - when in Rome and all that. I'll add parentheses back on. Using the without parends style is perfectly valid. It won't cause a bareword error unless the subroutine is undefined. Many people prefer it. I personally use both ... I know that would drive many people crazy as inconsistent, but I actually feel that sometimes it seems more natural with and sometimes without. Bottom line is go with whichever you personally prefer. Seriously? Is there anywhere I can learn more about this? Try perlfunc system just for a start. -- Buddy
Re: Introduction Letter
Buddy Burden wrote: Ofer, With all due respect to Andrew, please remember that his is but one opinion. I've also now removed any traces of the run() synonym. You're right - why complicate things with no benefit. I didn't see anything wrong with the concept. Personally I would have done it the other way around (i.e. make prun a synonym for Parallel::Simple::run), but that's a minor point. To me, run is a perfectly reasonable name for the function when fully qualified, but it makes sense not to export (even only when requested) such a simple function name into the global namespace. In fact, I might go even further and name it par_run or somesuch. But that's just me. True, but my own thoughts were already somewhat in tune with Andrew's suggestion. Having two names was cluttering the docs, with the only benefit being the lack of the redundant 'p' on fully-qualified calls. Oh, and I do agree with the comments about using *Parallel::Simple::run = \prun; instead of the way you've done it. That's the proper way to create a synonym IMHO. What's funny is that I actually like the parentheses, since I strive to avoid any ambiguity, but I left them off here because I was trying to make my first CPAN module as perl-ish as possible - when in Rome and all that. I'll add parentheses back on. Using the without parends style is perfectly valid. It won't cause a bareword error unless the subroutine is undefined. Many people prefer it. I personally use both ... I know that would drive many people crazy as inconsistent, but I actually feel that sometimes it seems more natural with and sometimes without. Bottom line is go with whichever you personally prefer. Personally, I almost always prefer parens on function calls. For built-ins, my philosophy is more complicated, and I won't go into it here. :) I've added them for the docs, since the point of docs is to make things as clear as possible. Users can always do their own thing, as usual. :) Seriously? Is there anywhere I can learn more about this? Try perlfunc system just for a start. No, I'm familiar with the make-up of the 16-bit return value of the system call. What I want to learn more about is the possibility that a process could crash and yet return a 0 exit code. I had not thought that possible, and hence, had seen no need to test for $? 127. -ofer
better SEE ALSO sections (was: Re: Introduction Letter)
On Mon, Feb 28, 2005 at 08:57:04AM -0500, Christopher Hicks wrote: This is a phenomenal initial cut of a POD. The review of relevant other modules in SEE ALSO and the philisophical differences with each deserves particular note. Bravo. I share your appreciation. I agree that this part of the documentation is frequently sub-optimal from a users perspective, especially when a new alternative appears when they are several standard options. For example (and not to pick on a particular module), here's one that was just released today: http://search.cpan.org/~jbuhacoff/Data-SimplePaginator-0.1/lib/Data/SimplePaginator.pm I was hoping for more of a comparison with Data::Page, which is similar but already established. Mark
Re: better SEE ALSO sections (was: Re: Introduction Letter)
On Mon, Feb 28, 2005 at 04:05:09PM -0500, Mark Stosberg ([EMAIL PROTECTED]) wrote: I was hoping for more of a comparison with Data::Page, which is similar but already established. AND at 100% Devel::Cover coverage, thanks to yours truly! :-) xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: better SEE ALSO sections
Andy Lester wrote: On Mon, Feb 28, 2005 at 04:05:09PM -0500, Mark Stosberg ([EMAIL PROTECTED]) wrote: I was hoping for more of a comparison with Data::Page, which is similar but already established. AND at 100% Devel::Cover coverage, thanks to yours truly! :-) xoxo, Andy I've never heard of Devel::Cover, so I just looked it up - BAD ASS! Arg. I've been using perl since 1999, and I still haven't integrated what many of you would consider the core set of tools into my personal toolbox. Many of the modules you use on a daily basis I might not have even heard of before. I sometimes wish there was a simple check list - here's the list of modules you should learn, in this order, before you can call yourself a professional perl programmer. Well, I'm off to learn the Test::* libraries. It's about time, I say. -ofer
Re: Introduction Letter
* Buddy Burden [EMAIL PROTECTED] [2005-02-28 19:20]:
I've also now removed any traces of the run() synonym. You're
right - why complicate things with no benefit.
I didn't see anything wrong with the concept. Personally I
would have done it the other way around (i.e. make prun a
synonym for Parallel::Simple::run), but that's a minor point.
Personally, I would pick yet another different approach: call the
function run, but export it as prun. When qualified with
Parallel::Simple::, even the very short run identifier is clear
and unambiguous. When exported, however, a simple run is more
likely to clash than prun and might be harder to search the
source for too.
Oh, and I do agree with the comments about using
*Parallel::Simple::run = \prun;
Note that this is how exporting works -- the only difference is
that the left and right hand side of the assignment refer to
symbols in different packages. So there's a sort of natural
precedent for my preference of exporting with a longer name...
Try
perlfunc system
just for a start.
Surely you mean
perldoc -f system
? :)
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: better SEE ALSO sections
A. Pagaltzis wrote: * Ofer Nave [EMAIL PROTECTED] [2005-02-28 22:55]: I've been thinking for a while that it would be great to have a CPAN wiki for things like: [...] I enjoyed writing the Parallel::* comparison, and I believe it is useful, but honestly, it doesn't belong in the SEE ALSO section of my module. It belongs someplace neutral, someplace that can be maintained and expanded by the whole community. This is somewhat of a permathread on this list. It has been a topic of discussion several times before in the time I've been subscribed (I sort of kicked off one them). So far nothing tangible and successful has really come from it. There's the recently opened CPAN::Forum may or may not offer something useful. There is some kind of unofficial CPAN wiki somewhere, I think. The problem is that documents like your (excellent) comparison require a lot of time and effort. They don't happen easily or naturally. Someone has to care enough. I openly admit I haven't invested much effort in developing an idea and/or pursuing one; and I conclude that I'm the norm, since not much is happening. The problem is, this is a hard problem to solve. Really, the format doesn't matter, be it a wiki, Perlmonks section, perl.org subsite, regular web forum, mailing list, namespace for review PODs on CPAN, or whichever of the myriad of other suggestions. It simply requires a lot of volunteers willing to do a lot of work to study modules in depth, compare them, and write up their experiences. Where the writeups end up is irrelevant so long as they have a coherent location they can be referred from; the hard part is the process of getting those writeups prepared and written. *That*'s why we still don't have a solution. It's not a technical problem. Regards, Valid points, but I disagree on one - I think it IS partly a technical problem. Jimmy Wales tried to start a free online encyclopedia called Nupedia before Wikipedia was a twinkly in his eye, and it failed miserably after getting 24 articles total. The problem was a technical one - you had to submit articles, have them reviewed and approved, etc. When Wikipedia was launched, it had 1000 articles within a month, because the form factor was right - want to change something? The edit button is right at the top. Go for it. Making something easier makes it more likely that people will do it. You might have only 5 volunteers that are willing to submit reviews like the one I wrote as patches to existing POD. But I bet you have 50 who are willing to add notes about modules they know about to existing reviews on a whim while reading the existing review page. You say It simply requires a lot of volunteers. As difficulty goes down, volunteers appear. They're already there, but they're below the current threshold. Don't recruit - lower the threshold. And a good domain name helps. Like wiki.cpan.org. It takes all of two minutes to install MediaWiki. I just did it, and I'm a poor excuse for a sysadmin. BTW-Part of the problem is that there is SO much already out there, and it's overwhelming, so some people just get turned off by not know where to start or what it all means. Would be nice to see one big map with all major perl rescoures (in reverse domain name order): com cpanforum.com perl.oreilly.com perl.com perldoc.com theperlreview.com tpj.com org perl.apache.org cpan.org bookmarks.cpan.org kobesearch.cpan.org lists.cpan.org mirrors.cpan.org pause.cpan.org ratings.cpan.org search.cpan.org testers.cpan.org parrotcode.org perl.org apprentice.perl.org archive.perl.org books.perl.org bugs.perl.org dbi.perl.org dev.perl.org faq.perl.org history.perl.org jobs.perl.org lists.perl.org nntp.perl.org planet.perl.org use.perl.org perlfoundation.org perldoc.perldrunks.org perlmonks.org pm.org poniecode.org yapc.org This is just me fooling around for 15 minutes trying to come up with everything I can find that is official or quasi-official. I'm sure I missed a few lesser-known subdomains of perl.org and cpan.org. As an intermediate perl programmer with a strong desire to learn what's out there, and see how I can participate in the perl community, I find this all very overwhelming. I can probably write one line descriptions of more than half the sites listed above, but it has taken months of web surfing and hanging out to be able to do just that, and be able to skim through that list with a partial sense of understanding, instead of seeing it all blur into one confusing mess. -ofer
Divide by 0? Was: Re: Introduction Letter
On Tue, Mar 01, 2005 at 11:43:31AM +1100, Andrew Savige wrote:
running this Perl program:
use strict;
sub div_by_zero { exec(./a.out $_[0]); die should not be here }
defined(my $pid = fork()) or die fork: $!;
if ($pid == 0) {
warn child, my pid $$\n;
div_by_zero(0); # sig 8
# div_by_zero(); # sig 11
exit;
}
warn parent, my pid $$\n;
waitpid($pid, 0);
my $rv = $? 8;
my $sig = $? 127;
warn $$: rv=$rv sig=$sig\n;
produces:
parent, my pid 12091
child, my pid 12092
12091: rv=0 sig=8
Replacing div_by_zero() above with:
sub div_by_zero { 5 / shift }
produced:
parent, my pid 12133
child, my pid 12134
Illegal division by zero at g2.pl line 2.
12133: rv=255 sig=0
This is not related to the original topic, but I've always
wondered this: In math a number divided by 0 is undefined. Why is it
that in a language which has an undefined value does the interpreter
poop out rather than just having the intuitively obvious behavior of
returning undef? Is that really by design, or just a legacy quirk they're
afraid to fix?
Austin
Re: Divide by 0? Was: Re: Introduction Letter
Austin Schutz wrote: This is not related to the original topic, but I've always wondered this: In math a number divided by 0 is undefined. Why is it that in a language which has an undefined value does the interpreter poop out rather than just having the intuitively obvious behavior of returning undef? Is that really by design, or just a legacy quirk they're afraid to fix? Austin Which would you prefer? $ perl -le '$x=1/0; print $x+1' Illegal division by zero at -e line 1. or $ perl -le '$x=1/0; print $x+1' 1 It only makes sense if undef in any arithmetic operation always gives undef, which means that all variables have to be explicitly initialized to zero before you can perform any arithmetic on them. That breaks tons of useful idioms and generally adds programming overhead. You shouldn't confuse undefined meaning not definable (math) with not yet defined (Perl). David
a Perl/CPAN wiki (was: Re: better SEE ALSO sections)
On Mon, Feb 28, 2005 at 04:36:34PM -0800, Ofer Nave wrote: Valid points, but I disagree on one - I think it IS partly a technical problem. Jimmy Wales tried to start a free online encyclopedia called Nupedia before Wikipedia was a twinkly in his eye, and it failed miserably after getting 24 articles total. The problem was a technical one - you had to submit articles, have them reviewed and approved, etc. When Wikipedia was launched, it had 1000 articles within a month, because the form factor was right - want to change something? The edit button is right at the top. Go for it. I agree that the wiki format can be a great one for creating a low barrier to entry for collaborative documentation writing. I've witnessed work really well for darcs ( http://www.scannedinavian.org/DarcsWiki/ ) and CGI::Application. ( http://www.cgi-app.org/ ). After working a good deal on both of those wikis, I've convinced that even more subtle details of the format can make a different. The darcs wiki is much more pleasant to work on-- it feels easier to use. I'm more likely to contribute there. I'm rather satisifed as user of that software-- it's running the MoinMoin wiki: http://moinmoin.wikiwikiweb.de/ So what does it take to get wiki.cpan.org or wiki.perl.org set up? I suppose a first order of business would be to arrange hosting space, and one more volunteers to set up and administer the wiki. Mark -- http://mark.stosberg.com/
Re: Divide by 0? Was: Re: Introduction Letter
# The following was supposedly scribed by # David Golden # on Monday 28 February 2005 07:07 pm: Which would you prefer? $ perl -le '$x=1/0; print $x+1' Illegal division by zero at -e line 1. or $ perl -le '$x=1/0; print $x+1' 1 I like the one where you get the mathematically-correct (or at least mathematically-useful) infinity. $perl -le 'use bigint; $x = 1/0; print $x+1' inf $perl -le 'use bigint; $x = 1/0; print 1/$x' 0 --Eric -- Everything should be made as simple as possible, but no simpler. -- Albert Einstein - http://scratchcomputing.com -
Re: testing Parallel::Simple
# The following was supposedly scribed by # Ofer Nave # on Monday 28 February 2005 07:50 pm: Incidentally, I sorta picked a tough module to start learning how to write tests for. Does anyone have advice on how to write tests for my Parallel::Simple module? I was just thinking of writing some tests for Getopt::Helpful and was wondering if something using IPC::Run might do the trick. The idea was to write a series of little programs that should behave in a given way (print something, die, or warn with a usage message) for some set of arguments and doing a string-match against their outputs. This is really an ill-formed idea right now but: ($stdout, $stderr, $code) = run_prog($prog, '--arg' , 'val'); ok($stdout eq arg - val); ($stdout, $stderr, $code) = run_prog($prog, '--nonarg' , 'val'); ok($code == 1); # error code (as expected) ($stdout, $stderr, $code) = run_prog($prog, '--help' , 'arg'); ok($stderr =~ m/arg/); # help messages on stderr I'm not sure if there's a test module that already does this or not. Any suggestions? (maybe Test::Cmd)) --Eric -- Politics is not a bad profession. If you succeed there are many rewards, if you disgrace yourself you can always write a book. -- Ronald Reagan - http://scratchcomputing.com -
Re: testing Parallel::Simple
Eric Wilhelm wrote: This is really an ill-formed idea right now but: ($stdout, $stderr, $code) = run_prog($prog, '--arg' , 'val'); ok($stdout eq arg - val); ($stdout, $stderr, $code) = run_prog($prog, '--nonarg' , 'val'); ok($code == 1); # error code (as expected) ($stdout, $stderr, $code) = run_prog($prog, '--help' , 'arg'); ok($stderr =~ m/arg/); # help messages on stderr I'm not sure if there's a test module that already does this or not. Any suggestions? (maybe Test::Cmd)) --Eric Check out Test::Output. That combined with system() might do what you need. David
Re: better SEE ALSO sections
--- Ofer Nave wrote: Most importantly... which one do the senior perl guys rely on? If Randal Schwartz and Dave Rolsky use a module regularly and can't imagine living without it, then that's probably the module I should be learning if I want to be a better programming. I don't know about Randal and Dave, but Mark Fowler lists his favourites in a delightful format at: http://www.perladvent.org/ And the Phalanx 100 at: http://qa.perl.org/phalanx/ lists the 100 most popular CPAN modules. Then there's gav's CPAN wiki http://cpan.thegav.com/ which seems fairly quiet. Perl Monks have a module review section: http://www.perlmonks.org/?node=Module%20Reviews which is also fairly quiet (as is Simon's code review ladder). The bottom line is that module reviews are time-consuming and you won't find many people with the time to do it. A better idea is to isolate small pieces of your module code that you're unhappy with and post multiple small questions to Perl Monks. Shamless plug: since you are a relative newbie, you might find this article: http://www.perlmonks.org/?node_id=418891 an interesting read, especially the section Testability and Test Suite. /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: better SEE ALSO sections
Andrew Savige wrote: Shamless plug: since you are a relative newbie, you might find this article: http://www.perlmonks.org/?node_id=418891 an interesting read, especially the section Testability and Test Suite. Also check out the perl-qa mailing list for all kinds of testing quality issues. http://lists.perl.org/showlist.cgi?name=perl-qa
Mail::Preconfigured
Oh wise and potent module namers...
I have a module that uses Net::SMTP_auth and basically implements the
following interface:
# This assumes settings (such as [EMAIL PROTECTED])
# are found in your ~/.mrmailer.conf (or /etc/...)
my $mail = Mail::MrMailer-new()
... # productive stuff
if($error) {
# you'll be the only one to get this:
$mail-maildie(error happened: $error);
}
# you'll get a bcc of this:
$mail-send_msg({to = $recip, cc = $mail-var('boss')},
join(\n,
Everything is okay.,
I'm taking tomorrow off., ,
--Eric,
));
This is really intended for cron and other fully-automatic
(webserver/daemon triggered) jobs where you want mail to be sent via an
external smtp server (and don't want to mess with sendmail.) Because
of the YAML config file support, you can define the owner's (your)
address and smtp username/password info in a single place instead of in
every script.
The usual questions apply:
How useful is this?
What should I name it?
I've looked at:
Email::Send::SMTP::Auth
too messy, no config-file support
Mail::Send*
too full-service/procedural
I've also played with the idea of defining some signal handlers or other
IO-magic which would allow you to send mail on a standard die() call or
maybe use some kind of severity threshold to only send warnings which
go above a given threshold. (but maybe that's another module?)
Maybe it goes in IO::?
--Eric
--
It is a mistake to allow any mechanical object to realize that you are
in a hurry.
-- Ralph's Observation
-
http://scratchcomputing.com
-
Re: better SEE ALSO sections
Hi, plug http::/www.cpanforum.com while not a wiki tries (in the TODO list at least) answer some of what you are looking for. Specifically I though of setting up - with the help of the users - groups of moudules or categorizes from within th list of all the modules on CPAN and then allow discussion per such larger group. I think these groups could be overlapping as there are modules that will fit several categories. While it is not a wiki and does not allow co-editing of documents it can let you write articles comparing sets of similarly themed/purposed modules. Gabor
