Re: Parse::Lex abandoned?
Eric Wilhelm wrote: How do you get enhancements to an existing module released if the maintainer cannot be contacted? (or refuses to reply or is just being unreasonable, etc.) Would anti-pollution laws help or hurt CPAN? How do you get more authors to do their homework before reinventing the wheel? How do you determine if an old module is perfect, unused, or unmaintained? How do you solve a problem like CPAN? How do you catch a cloud and pin it down? I'm thinking a CPAN wiki might help with some of these. :) At least in terms of documenting goings on and shared frustrations or efforts. Not as much with the MIA authors thing, though at least people would be free to note how and when they last attempted (and failed) to get some kind of response, which is useful to see. -ofer
Re: Guide for creating Perl modules
José Castro wrote: Hi, guys. I recently wrote a guide for creating Perl modules. It's available on perlmonks, at http://perlmonks.org/?node_id=431702. (If you want to I can also send it here) I just realized a note to this list would be in order, so here it is :-) Enjoy, jac PS: Yes, thoughts are welcome :-) -- Jose Alves de Castro <[EMAIL PROTECTED]> http://jose-castro.org/ You mention three ways to create a distribution skeleton (h2xs, Module::Starter, and ExtUtils::ModuleMaker), but don't comprehensively explain the differences, or how to decide which to use. The pargraph "Looks pretty much the same as the result of h2xs, right? But don't let that fool you! Apart from the new files that test your POD documentation, the contents of those files are different from the ones generated with h2xs. Give a try to both systems and check out the differences." isn't very useful. Other than that, it's a good guide. The thing that bothers me is that there are too many of them. This is best illustrated by looking at the collection of links you've assembled at the bottom - which I greatly appreciate, btw. I know perl culture thrives on TIMTOWTDI, but sometimes it can drive me crazy. Wish there was one definitive place to check for all the info I needed. Or maybe two - one objective (here is the process of using PAUSE) and one subjective (here is some advice, and a comparison of skeleton creators, etc). Remember, the point of this is to guide intimidated newbies into becoming productive members of perl society. If they have to track down and mentally assimilate fifteen web pages of varying authority, wisdom, and timeliness, they're going to end up confused. As I still am. :) -ofer
Re: plugin manager module - namespace suggestions please
Baltasar Cevc wrote:
A. Pagaltzis wrote:
> * Baltasar Cevc <[EMAIL PROTECTED]> [2005-03-10 13:25]:
>> use Modularizer;
> Well, I can't think of anything really helpful right now, but I
> have to register that that name is pretty horrible. It should
> definitely be in Module:: and mention Plugin somehow. Maybe
> something like Module::Plugin::Framework (or ::PluginFramework),
> though I don't know about that.
Thanks for your informations.
I agree on the first point ;-)
However, Module:: does not seem like a matching "category" to me.
Apart from some modules that could live anywhere else, too,
Module:: contains modules related to packaging, locating and
extending perl modules.
The approach of the code I wrote is to split up an application
into modules or plugins or whatever one may call it.
Framework sounds good and matches what the code does, I would say.
Greetings from the finally sunny city of Regensburg, Germany
Baltasar
App::Pluggable? Or, reconsidering your words ("Module::Pluggable
concentrates on bringing some modules together, whereas my module is
written from the point of view of somebody splitting an application into
modules"), perhaps App::Modular.
Lastly, since it looks like your functionality automatically loads
modules on deman, perhaps App::AutoLoading.
Wow. I've always been OCD about properly naming
variables/functions/modules/tables/columns/etc. I can see this group
becoming addicting.
-ofer
Re: what namespace for future new module ?
A. Pagaltzis wrote: * Cédric Bouvier <[EMAIL PROTECTED]> [2005-03-10 10:25]: Thank you for the hint. I quickly looked on CPAN and there doesn't seem to be many modules under Cluster::, besides Cluster::Init which is more geared towards High Availability. I don't find Cluster:: sounds right. Parallel: alone isn't sufficient since this involves multiple computers, not just multiple processes. I think something in Net:: would be most appropriate. And while cluster is the means to do this, what you're doing as such is usually referred to as distributed execution or some such. So maybe Net::ComputeDistributed? It's a little long, but I think it's absolute precise in describing the purpose. Regards, I think it's a mouthful, and still not quite right. There is currently no Distrib:: or Distributed:: namespace. How about starting one? Like Parallel::, but implying across hosts, not just procs, as A. Pagaltzis so well puts it. In your case, your module could be Distributed::Simple. And just to add yet another chef to the kitchen, there's also "Grid", as in grid computing, which is a more specific application of distributed computing. -ofer
Re: RFC: some thoughts about daemons and related modules
A. Pagaltzis wrote: * Baltasar Cevc <[EMAIL PROTECTED]> [2005-03-09 14:45]: would the solution be to extend something like Proc::Daemon or to "downgrade" Net::Daemon (which seems more similar to what I thought about). I think ideally Proc::Daemon should be extended to cover all common functionality, and Net::Daemon updated to extend Proc::Daemon. That assumes reasonably compatible APIs of course, or one might possibly support both API styles in both modules if they are disparate -- so long as it doesn't break backward compatibility. Of course you shouldn't hesitate to copy stuff back from Net::Daemon to Proc::Daemon if desirable. Can someone explain what appears to be the general purpose of the Proc:: namespace? I can interpret 'proc' many ways, so I'm not exactly sure. -ofer
Re: RFC: some thoughts about daemons and related modules
Baltasar Cevc wrote: Hi everybody, yesterday, when writing the core of another daemon intended to run on one of the servers I administer, I caught myself copy-pasting code from other daemons. Not some lines but more or less the whole main part. After a bit of thinking, I realized that there must be a better solution. Probably hidden somewhere in CPAN. However, even after searching quite a long time; I haven't found one. None - or should I rather say that I found a whole bunch of them? There are modules (App::Control, Proc::PID::File, File::PID etc.), all of them doing just one thing, exactly in the standard Unix manner. But at least as far as I can see, in this specific case, it leads into having quite some code a in every daemon which is more or less redundant. (slight tangent) Pidfile manipulation is genericly useful, even outside of daemons. For example, I have normal, command-line applications that use pidfiles to ensure only one instance is run at a time, to prevent screw-ups if our scheduling software goes wacky. I also use a pid-collection-file for another app I wrote. It runs dozens of processes on dozens of remote machines, and as each process starts up, it adds it host and pid info to the collective file. That way, if the main process crashes or is killed, I can use a quick utility I wrote to read through the pid-colleciton-file and track down and kill the remote child processes. In other words, I'd love to see this type of stuff available outside the context of daemon class. :) You said you encountered "App::Control, Proc::PID::File, File::PID etc." as part of your research. What did you learn about them? Can you write up a quick comparison? Are any of them actually useful? (so looking forward to that cpan wiki - coming soon, I believe) -ofer
Re: Parallel::Simple - bound args syntax
Buddy Burden wrote:
Ofer,
In my case, it's much easier to pick off the first entry than the list.
Why?
my $opts = @_ && ref $_[-1] eq 'HASH' ? pop : {};
my ($proj, @files) = @_;
(from some code of mine; I have many functions defined like this)
-- Buddy
Ok, fine. That was a total bluff on my part. :)
-ofer
Re: Parallel::Simple - bound args syntax
A. Pagaltzis wrote: * Ofer Nave <[EMAIL PROTECTED]> [2005-03-02 03:55]: I hate to force people to create an anonymous hash when it can be implied. Plus I'm already checking for hashref as the first param to allow options to be specified, so I'd have to change that... to what, I don't know. Ah, I forgot about that. Of course the optional hash of options is usually passed last... (DBI comes to mind; I'm sure there are more? Can't think of any right now.) Regards, DBI takes a quasi-fixed list of params, not the open list/hash contents that prun accepts. In my case, it's much easier to pick off the first entry than the list. I am still (and always) open for additional suggestions... in the meantime, I'm going to implement your [ $subref, @args ] syntax and try to think of a sane way to test forking code. -ofer
Re: Parallel::Simple - bound args syntax
A. Pagaltzis wrote:
* Ofer Nave <[EMAIL PROTECTED]> [2005-03-01 23:45]:
I realize that since I can tell listrefs apart from strings and
code refs, I could allow this:
prun(
$coderef1,
$coderef2 => [ $arg1, $arg2, $arg3 ],
);
Which would run $coderef1 once, but run $coderef2 three times,
once for each arg. If you wanted to pass more than one arg at
a time, you could create sublists:
Leave it out.
It looks like a great idea to you right now with the one or two
examples you developed this on, but you'll get sick of it very
quickly if you start to use it on a larger scale. Don't try to be
too clever, it will bite you once in maintenance mode.
I've done things like that several times in the past and they
always end up obfuscating the code more than they help. This is
really something that must be solved on the language level, à la
currying and compositing operators, not on the level of
individual APIs by overloading the semantics of various data
types.
If you feel it is really important to make this particular use
case easier, use an API like this:
prun(
$coderef1,
[ $coderef2, $arg1 ],
[ $coderef2, $arg2 ],
[ $coderef2, $arg3 ],
);
whose meaning is reasonably easy to guess without having to study
the documentation too closely.
For reducing redundancy, this allows you to fall back on regular
Perl idioms:
prun(
$coderef1,
map( [ $coderef2, $_ ], $arg1, $arg2, $arg3, ),
);
Now the prun() function has one fewer interface conventions, and
I can understand half of what's going on with my regular Perl
knowledge before I've even read your docs.
There is also precedent in taking an anonymous array with a
coderef in the first slot as a shortcut for "call this code with
these parameters"; offhand I remember that Tk does it this way
but there were other places I saw it. I believe that is because
it is a pretty natural notation.
And your code also has less to guess, because the number of
arguments doesn't change depending on whether I pass arguments to
some coderefs or not.
That seems reasonable.
For similar reasons, I would suggest that you don't allow named
subs as in
prun(
foo => $coderef1,
bar => $coderef2,
);
but rather require
prun( {
foo => $coderef1,
bar => $coderef2,
} );
so that you only have to check one easily expressed condition.
I hate to force people to create an anonymous hash when it can be
implied. Plus I'm already checking for hashref as the first param to
allow options to be specified, so I'd have to change that... to what, I
don't know.
-ofer
Re: Parallel::Simple - bound args syntax
Mark Stosberg wrote:
On Tue, Mar 01, 2005 at 02:40:36PM -0800, Ofer Nave wrote:
# getting fancy with arg binding
my @hosts = qw( foo bar baz );
prun( map { my $host = $_; sub { test_host( $host ) } } @hosts )
or die( Parallel::Simple::errplus() );
I think this is simpler, because I can guess what it does without
reading more documentation.
My idea of simple here is clarifying the call some:
my @host_tests;
for qw( foo bar baz ) {
push @host_tests, sub { test_host( $_ ) };
}
prun (@host_tests) or die( Parallel::Simple::errplus() );
I don't think that's going to do what you expect. The values in $_ are
not going to be captured in the anonymous sub because $_ is a global
variable. That's why I created a new lexical variable to capture the
value on each loop inside the closure.
It's not clear your code refs would interact with arguments that may
already be passed into them, before they get to prun().
It's also not 'normal' to mix hash and list calling styles, or to use a
code ref for a hash key.
The mixed hash/list calling styles is a seperate discussion - that was
already part of the initial design, and not part of the topic of this
email, which is whether or not the args binding feature is an
appropriate addition for the module. Also, I'm not using code refs as
keys anywhere. Simply putting a code ref on the left side of a =>
operator won't stringify it.
In summary, I don't think the suggested addition would be 'simple'.
Ah, that's the real question! I'm still not convinced either way, but
I'm leaning towards including it.
-ofer
Parallel::Simple - bound args syntax
I just started using Parallel::Simple in some production code (good to
exercise it before releasing it), and came across a situation where I
wanted to call the same function a variable number of times based on the
number of args in a list. This is what Parallel::ForkControl's forte
is, but in keeping with wanting a Simpler interface, I used my prun
function:
# getting fancy with arg binding
my @hosts = qw( foo bar baz );
prun( map { my $host = $_; sub { test_host( $host ) } } @hosts )
or die( Parallel::Simple::errplus() );
However, that looks ugly - and ugly isn't simple. So I thought of how I
could support this case, and I realize that since I can tell listrefs
apart from strings and code refs, I could allow this:
prun(
$coderef1,
$coderef2 => [ $arg1, $arg2, $arg3 ],
);
Which would run $coderef1 once, but run $coderef2 three times, once for
each arg. If you wanted to pass more than one arg at a time, you could
create sublists:
prun(
$coderef1,
$coderef2 => [ [ $arg1a, $arg1b], [ $arg2a, $arg2b ] ],
);
And it would just work. You could still use named style, too, of course:
prun(
foo => $coderef1,
bar => $coderef2 => [ $arg1, $arg2, $arg3 ],
);
So.. I don't think there's any question that this is useful. The
question is - is this too complicated for a ::Simple module? Or does it
fit right in, because it let's you do far more complex logic with a
simple, concise syntax?
-ofer
Re: Divide by 0? Was: Re: Introduction Letter
Austin Schutz wrote: I suppose I could try to create a use divide 0/undef/inf/crap pragma. Then you could do whatever you want. You'd still get a surprise if you ever forgot it though.. I think that's the best answer. Not a good idea for most programs, wonderful idea for math programs - which can simply say "use infinity;" or something along those lines at the top. BTW-I'm reading Perl 6 Now, and I believe there was mention there about Perl 6 having support for infinity and possibly other equally strange notions. I'm at work, though, so I don't have access to the book right now. -ofer
Re: new module: Parallel::Simple
Ofer Nave wrote: Well, I'm off to learn the Test::* libraries. It's about time, I say. 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? -ofer
Re: Introduction Letter
Andrew Savige wrote:
BTW, this slip-up is also a good advertisement for ensuring that your
test suite tests all examples given in your documentation to ensure
that they actually work.
Hey, good point. I'll start with that, then.
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.
I did a simple test on Linux.
This is file crash.c:
---
#include
int main(int argc, char* argv[])
{
return 5 / atoi(argv[1]);
}
---
After compiling with:
cc crash.c
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
Perl is catching this one it seems. However, using this one:
sub div_by_zero { warn "sleeping"; sleep(60) }
then manually killing the child process (with SIGTERM), produces:
parent, my pid 12356
child, my pid 12357
sleeping at g2.pl line 3.
12356: rv=0 sig=15
It's pretty rare and no biggie to me, but if I were implementing it
I would check the signal value in addition to the return value.
That's why I wanted to get this on CPAN. I knew others could point out
things I'd never think of. ;)
I just checked my code. Here's what it's doing right now:
$child_registry{$child}[1] = $? >> 8;
$successes++ if ( $? == 0 );
I'm only saving the 8-bit exit value for the user to inspect, BUT I'm
only considering the execution successful if all 16 bits are off, so
that means your crash example above would be marked as a failure, even
though the exit value is 0.
It seems like categorizing non-zero $? values as failures is still a
good idea, but since it is possible that a block could fail and still
return 0, that will confuse users inspecting the return value trying to
figure out what went wrong. The obvious solution is give the user all
16 bits, instead of $? >> 8 for them.
Which sucks, cause no one likes doing the $? >> 8 part. It's ugly. I
was hoping to Keep It Simple by doing it for them.
-ofer
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
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: better SEE ALSO sections
Mark Stosberg wrote: 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 I've been thinking for a while that it would be great to have a CPAN wiki for things like: 1) articles comparing sets of similarly themed/purposed modules 2) guide to namespaces (if your module ties a list, should it go under Tie:: or List::? both of which are existing namespaces; and what the hell is B, Class, and Devel for? Not always obvious to the new-comer... generally requires becoming familiar with several modules in the namespace, and then the purpose *sometimes* becomes apparent) 3) perhaps even a full directory of all modules, DMOZ style (manually maintained by interested volunteers) For example, I recently started looking for a module that would simplify file locking for me. I know how to use flock, but sometimes I don't feel like dealing with the technical details - I just want a locked file, and I want it now. (similiar motivation prompted my Parallel::Simple module :) A cpan search turned up: IO::File::flock( IO-File-flock-0.10 26 Apr 2004 ) IO::File::flock( IO-File-Lockable-0.31 16 Jul 2004 ) IO::LockedFile::Flock ( IO-LockedFile-0.23 20 Feb 2003 ) File::Flock( File-Flock-104.111901 19 Nov 2004 ) What are the differences? Is one more actively maintained? Is one more popular, and therefore better tested? 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. But without information, a newbie like me is taking a stab in the dark. I know the cpan has a minimally working ratings/review system, as well as the cpan testers system - both of which are great (testers more than ratings), but that's too limited. The wiki could evolve new conventions and new structures for information faster than the CPAN developers, and allow anyone to contribute with almost no barrier to entry. For a language specifically marketed to lazy programs, this might be a perfect fit. 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. Incidentally, I settled on IO::LockedFile. Very simple interface, good for many purposes. -ofer
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
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
to determine whether you are now the parent or child...
almost like
just calling fork yourself. :)
Provides control over how many child processes to allow, and
blocks
new forks until some previous children have exited. Let's child
determine the process exit value. Provides a trigger
mechanism to
run callbacks when certain events happen (child start, child
exit,
and start blocking). You must supply a callback for the
child exit
event to inspect the exit value of the child.
Conclusion: While also designed for repetitive, looped tasks,
it is
far more flexible, being a thin wrapper around fork rather than
taking over child creation and management entirely. Useful
mostly
if you want to limit child processes to a certain number at a
time
and/or if the native system calls scare you.
Parallel::Jobs
Different in that it executes shell commands as opposed to
subrou-
tines or code blocks. Provides all the features of the open3
func-
tion, including explicit control over STDIN, STDOUT, and
STDERR on
all 'jobs'. Lets you monitor jobs for output and exit events
(with
associated details for each event).
Conclusion: Great for shell commands! Not great for not
shell com-
mands.
AUTHORS
Written by Ofer Nave <[EMAIL PROTECTED]>. Sponsered by Shopzilla,
Inc. (formerly BizRate.com).
COPYRIGHT
Copyright 2005 by Shopzilla, Inc.
This program is free software; you can redistribute it and/or
modify it
under the same terms as Perl itself.
See http://www.perl.com/perl/misc/Artistic.html
-ofer
Lincoln A. Baxter wrote:
Hello Ofer,
Motivate us!
Tell the list why we should look at it. What does it do? How does it
solve a problem that is not already solved, or solves it better?
I get the sense from the brief comment you made about IO:: that it has
to do with some mechanism for implementing parallel IO?
Pasting the POD is often a good way to do this.
Lincoln
On Sun, 2005-02-27 at 16:28 -0800, Ofer Nave wrote:
Hello everyone.
I just subscribed to this list, I just recently received my PAUSE
account, and I just finished writing/documenting/testing the first perl
module that I've written for CPAN. I'd like to know what is considered
a good set of practices for new modules with regards to:
1) naming
2) requesting feedback on design/implementation
3) announcing the module
4) informing authors of similar modules
In this case, the I've already named the module Parallel::Simple, but I
imagine things would be trickier if I want to call it IO:: something or
create a new top-level namespace.
Here's the module, if anyone is interested:
http://ofernave.com/pm/
I've already sent copies to my local perl mongers group and posted it on
comp.lang.perl.modules, and I've gotten a little bit of feedback on it.
I'm comfortable with the design as it stands right now, and only need
write some formal tests before it will be ready for its first upload.
-ofer
Introduction Letter
Hello everyone. I just subscribed to this list, I just recently received my PAUSE account, and I just finished writing/documenting/testing the first perl module that I've written for CPAN. I'd like to know what is considered a good set of practices for new modules with regards to: 1) naming 2) requesting feedback on design/implementation 3) announcing the module 4) informing authors of similar modules In this case, the I've already named the module Parallel::Simple, but I imagine things would be trickier if I want to call it IO:: something or create a new top-level namespace. Here's the module, if anyone is interested: http://ofernave.com/pm/ I've already sent copies to my local perl mongers group and posted it on comp.lang.perl.modules, and I've gotten a little bit of feedback on it. I'm comfortable with the design as it stands right now, and only need write some formal tests before it will be ready for its first upload. -ofer
