Re: IO::ALL (Was: check for errors on close())
Sam Vilain writes: Eric Wilhelm wrote: Just spent way too much time trying to find a bug when it turns out that I just had a full disk. So, food for thought for today: close() does not always return true. close(FILE) or die file error: $!; You don't already check the return value of every system call? I don't. Too tedious? That, and it makes the code look messier than needs be; a lexical variable going out of scope is very clean. Just use IO::All. I've looked at IO::All a bit, but never actually tried it -- it looks sufficiently daunting that I've never put the effort in to learn it rather than using something I was already familiar with. Possibly, if it really is as easy to use as it claims, it just suffers from too much documentation. I'll consider it the next time I'm writing a script that does a lot of stuff with files, but if reading from one file once is the only IO a script does then this seems like a massive prerequiste to pull in: suddenly I've added a big prereq to a project, and confused other coders in the team who know Perl but don't know IO::All, just to write 2 lines of code instead of 3 -- that doesn't seem worth it. Normally I don't buy the but I don't want to use a non-standard module cos that adds dependencies argument, but in this case I think it makes a big difference. Some of the things Ingy's doing in IO::All do look to be more Perl-ish than the current built-in Perl ways of achieving them, and I think I read Larry saying he'll incorporate some of them in Perl 6, which would be mos welcome. Sam (or any other IO::All users reading this), what's your experience of IO::All? How much effort has it saved you? Does it make your code look too confusing for other coders (I'm thinking of the overloaded comparison operators being used for something other than comparison, for instance)? Have you ever found it to be 'too clever', automating something in an inappropriate way? And finally, an implementation question, which, while not strictly relevant to a user of IO::All, does seem on-topic for a module authors' mailing list: does the Spiffy thing make sense to you? (I get the feeling that there's something I'm missing, or that I'm not clever enough to understand it.) For comparision, I've recently started using Path::Class, which is an excellent module. This also adds a non-standard dependency to file-handling tasks that other coders on my team may not have met before, and it doesn't do anything that isn't possible with core modules. But it's sufficiently well focussed that I could grasp it in one go, and see clear benefits; it feels natural, with objects representing obvious things and having intuitive interfaces: my code is definitely cleaner for using it, and I'm not worried that my co-workers will have trouble with it. (Actually, possibly one of the reasons I'm liking using Path::Class is that while it theoretically is a better interface to using File::Spec, we weren't using File::Spec previously, but concatenating and interpolating strings, awkwardly and non-cross-platformily; so it's a definite improvement.) Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Bootstrapping a module community
What's the best way to spread the word about a new module? I've got a few modules that I think a lot of people would find useful. They're still in active development (pre-1.0) but I'd like as many people as possible to try them so I can get feedback from the community. How do I spread the word about these modules? It there was a relevant, active mailing list, I'd probably be home free. For example, if I had a mod_perl-related module, posting to the mod_perl mailing list would be an obvious choice. Unfortunately, there are no appropriate mailing lists for my modules. I tried posting to comp.lang.perl.announce once, but didn't get any response. Maybe not many people read that group these days? It could also be that no one is interested, but at least one of my modules performs a common task that I know a lot of people are interested in (there are many existing CPAN modules that do the same thing). So, what's left? Writing an article for perl.com? Starting my own mailing list? (Then how do I get people to notice that list? :) Any other suggestions for bootstrapping, if not a community, then at least a handful of like-minded programmers? -John
Re: Bootstrapping a module community
What's the best way to spread the word about a new module? I've got a few modules that I think a lot of people would find useful. They're still in active development (pre-1.0) but I'd like as many people as possible to try them so I can get feedback from the community. How do I spread the word about these modules? It would be a lot easier to help you if we knew the specifics of the modules you're talking about. xoa
Installing Scripts into sbin Directory
Dear all, I wonder if there is any way to install scripts into sbin directory? I'm using ExtUtils::MakeMaker. I know that GNU autoconf can make a difference between user executables and system administrator executables, and by FHS 2.2 system administrator executables should be put into the sbin directory. Is there any way for me to install system administrator scripts there, at least, under UNIX? -- Best regards, imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug pgpD0qBEO6gMG.pgp Description: PGP signature
Re: Bootstrapping a module community
On 4/24/05 10:56 AM, Andy Lester wrote: It would be a lot easier to help you if we knew the specifics of the modules you're talking about. Well I was really trying to keep the question more general, but I can give you two specific examples. The first is my object/relational database mapper thingie. I don't know what the formal name for it is, but it's in roughly the same family as Class::DBI, Alzabo, Tangram, etc. I think this module has the most potential for wide-spread interest, judging by how much activity there is surrounding the current mindshare leader, Class::DBI. The second is an object-oriented interface to HTML, with a focus on HTML forms and fields. I developed this one because there was nothing like it in CPAN at all (which surprised me). The lack of similar modules makes this even harder to promote. -John
Re: Bootstrapping a module community
The first is my object/relational database mapper thingie. I don't know what the formal name for it is, but it's in roughly the same family as Class::DBI, Alzabo, Tangram, etc. I think this module has the most potential for wide-spread interest, judging by how much activity there is surrounding the current mindshare leader, Class::DBI. Your first goal will be explaining in 25 words or fewer why your mapper thing is better than Class::DBI. When you have a module space as overloaded as that, you've got to do some marketing. Don't expect that you'll put your module out there, set up some lists, and people will come flocking to it. So what are the high points? Why should someone use yours instead of Class::DBI? Or even switch from Class::DBI?
Re: Bootstrapping a module community
On Sun, Apr 24, 2005 at 10:48:28AM -0400, John Siracusa wrote: What's the best way to spread the word about a new module? I've got a few modules that I think a lot of people would find useful. They're still in active development (pre-1.0) but I'd like as many people as possible to try them so I can get feedback from the community. How do I spread the word about these modules? There's always 'freshmeat.net', 'perlmonks.org', and your 'use.perl.org' journal. There is also the old fashioned network of personal networking. Hang out on other module mailing lists (or Perlmonks or use.perl.org) and become a respected contributor. Then people will be interested it check it simply because /you/ wrote it. Perhaps you already have that reputation, but hang out on different lists than I do. :) Mark -- http://mark.stosberg.com/
Re: IO::ALL (Was: check for errors on close())
* Smylers [EMAIL PROTECTED] [2005-04-24 13:55]:
Sam (or any other IO::All users reading this), what's your
experience of IO::All? How much effort has it saved you? Does
it make your code look too confusing for other coders (I'm
thinking of the overloaded comparison operators being used for
something other than comparison, for instance)? Have you ever
found it to be 'too clever', automating something in an
inappropriate way?
Im not an IO::All user; Im posting to empasize this plea for
comments. I havent taken to it for the exact reasons Smylers
mentioned: both its (arbitrary-feeling) overloaded semantics and
the use of Spiffy seem too hair-raising to seriously consider it.
I would be very interested to hear from someone who has actually
used it in a large codebase that gets pummelled day-in day-out.
How does it pan out in practice?
For comparision, I've recently started using Path::Class, which
is an excellent module.
Yep, that one rocks. :-) Reminds me I should go add a review on
CPAN Ratings
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Bootstrapping a module community
* John Siracusa [EMAIL PROTECTED] [2005-04-24 18:50]:
Assuming I do that, there's still the question of venue.
How/why/where will people read it in the first place? Should I
just add it to the POD for the module?
That you should, irrespective of where you choose to promote it.
When I see a module that tries to solve a problem many others
already address, it is always helpful to see that the author is
aware of prior art and has an understanding of how his work
differs and where it might be better suited. Ideally, you would
include a blurb comparing yours to each other significant
competing module in that space.
Regardless of promotional venue, if your modules have any value,
such care will definitely help you get traction sooner.
Re venue:
I think use Perl is a good place to advertise yourself. Just
write about it in your journal and people will pick up on it. It
is particularly well-suited because theres no guilt at all
attached. If you take the time to write a larger article along
the lines of the rationale section your POD should include,
Perlmonks Meditations section would be another good venue; that
is how I heard of Tom Moertels terrific Test::LectroTest, f.ex.
Perl.com in my opinion should be reserved for modules which are
clearly already building momentum in mindshare. If you got a lot
of positive reaction elsewhere and are getting questions and
general interest, then Perl.com is a great way to cross the
chasm to the pragmatists.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Bootstrapping a module community
On Sun, Apr 24, 2005 at 12:46:25PM -0400, John Siracusa ([EMAIL PROTECTED]) wrote: So what are the high points? Why should someone use yours instead of Class::DBI? Or even switch from Class::DBI? Assuming I do that, there's still the question of venue. How/why/where will people read it in the first place? Should I just add it to the POD for the module? That's a big assumption. You may find that there's nothing in your module that makes it worth pursuing, for one. However, if there's good stuff in there, then think about how you're going to market it. It IS marketing. The venue will come out of the why. You may market differently if its advantage is that it's simpler than if its advantage is that it's more powerful. Maybe it appeals to PHP folks coming over to Perl. But without the underlying framework of why, you can't know where to go. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Bootstrapping a module community
John Siracusa writes: The first is my object/relational database mapper thingie. ... The second is an object-oriented interface to HTML, with a focus on HTML forms and fields. I developed this one because there was nothing like it in CPAN at all (which surprised me). Ah, now you mention those, I remember this morning reading your reviews of them on the Cpan Ratings RSS feed -- so that bit of marketing reached at least me! OK, so I haven't used either of them, but at least I had a look at them to see if they were the kind of thing that'd be of use to me. It's quite possible there are other people also reading that feed who did likewise and then actually went on to use the modules. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: Bootstrapping a module community
On 4/24/05 5:12 PM, Smylers wrote: John Siracusa writes: The first is my object/relational database mapper thingie. ... The second is an object-oriented interface to HTML, with a focus on HTML forms and fields. I developed this one because there was nothing like it in CPAN at all (which surprised me). Ah, now you mention those, I remember this morning reading your reviews of them on the Cpan Ratings RSS feed -- so that bit of marketing reached at least me! Yeah, I figured I knew an easy way to bootstrap the ratings process, at least :) -John
