Re: Test-only code
On Dec 22, 2009, at 10:33 PM, Geoffrey Leach wrote: I'm working on a new release of Getopt::Auto. There's a fair amount of code in the module that applies only to the tests. It would be nice if that code was not in the installed module. Any suggestions? Maybe persona.pm (from CPAN, by yours truly) would make sense for you. It *would* however add a dependency, which may not be what you want. Liz
Re: RFC: String::Tagged
At 8:43 AM + 1/30/09, Paul LeoNerd Evans wrote: I find myself requiring an object to store a text string, with ways to throw markup or presentation attributes around it, but in such a way that they're easy to edit and change separately from the string data. I.e. the usual embedded HTML / ANSI escapes / etc... are not really suitable. With this in mind, I have come up with String::Tagged. I'd appreciate any thoughts or comments people might have on the API and design before I upload it. Without having looked at implementation, this sounds like it could benefit from my out-of-band data module OOB: http://search.cpan.org/perldoc?OOB Liz
Re: Loading subroutines ad-hoc: extension to load.pm
At 6:49 AM +0200 10/15/08, Shlomi Fish wrote: Why did I receive 9 exact copies of this message? It seems to have affected everybody because http://www.nntp.perl.org/group/perl.module-authors/ shows 8 messages for this thread. Can anyone please fix it? This was definitely not what I intended. As far as I can tell right now, it seems that my mail server never gets a final ack from the x6.develooper.com, causing it to resend. Please note that I'm sending this through my ISP's relay, rather than my own mail server, in the hope we don't get a repeat on this ;-( Liz
Re: Retired modules, still registered
At 5:10 PM +0100 12/12/06, David Landgren wrote: I've been playing around with Sieve, a language for filtering incoming messages. It's rather hateful (but that's a topic for another list), and I serendipitiously encountered Mail::Sieve on a CPAN search. So I thought I'd take a look. Except that it's not there. It appears as a registered module, but the author appears to have pulled it (I haven't checked backpan, as I'm not that interested). http://search.cpan.org/~brong/ Should the distribution be removed from the module list? Since it doesn't really exist any more. Either that, or search.cpan.org should ignore registered modules for which there is no published module. FWIW, I have a set of registered modules on CPAN that I pulled from CPAN some time ago already: NexTrieve NexTrieve::Collection NexTrieve::Collection::Index NexTrieve::DBI NexTrieve::Daemon NexTrieve::Docseq NexTrieve::Document NexTrieve::HTML NexTrieve::Hitlist NexTrieve::Hitlist::Hit NexTrieve::Index NexTrieve::MIME NexTrieve::Mbox NexTrieve::Message NexTrieve::Overview NexTrieve::PDF NexTrieve::Query NexTrieve::Querylog NexTrieve::RFC822 NexTrieve::Replay NexTrieve::Resource NexTrieve::Search NexTrieve::Targz NexTrieve::UTF8 All of these can be unregistered as far as I'm concerned. Liz
Re: OK, so we've decided that the right modules are too hard to find.
At 13:57 +0100 2/15/04, Johan Vromans wrote: Tim Bunce [EMAIL PROTECTED] writes: For those modules that are not on the Module List, (i.e., not in http://www.cpan.org/modules/03modlist.data.gz) and which have a 'significant' existing user base, develop a Fast Track process to get them added to the Module List. Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Liz
Re: proposed Text::Charnames
At 07:25 -0500 2/5/04, Rodent of Unusual Size wrote: i've been looking for this functionality but haven't [yet] found it, so i'm thinking of providing it. the questions are: a) is it already there and ive just missed it, and b) if not, what namespace should it be in? the functionality in question is providing access to the names of ascii (et alia?) control characters. e.g., 0x01 (ctrl/a) is 'soh' (start of header), 0x11 (ctrl/q) is 'xon', et cetera. i'm inclined toward Text::Charnames[::ASCII] or the like. any comments/ suggestions? Wouldn't something like that be generateble from Encode? Or is already part of Encode? Liz
Re: Fwd: Re: New module Mail::SendEasy
At 02:12 -0600 1/28/04, Dave Rolsky wrote: On Wed, 28 Jan 2004, Terrence Brannon wrote: I also tend to agree with him that Mail::Box is a bit over-engineered in the OO department. Do you _really_ need _eleven_ classes for Mail::Message::Field, which in turn are presumably used by the _nine_ Mail::Message::Head classes? maybe you should ask him on the Mail::Box mailing list. Well, he's already chimed in on this discussion, so I know he's on this list ;) Yes, but is this list the most appropriate place to discuss Mail::Box? I think the Mail::Box list is more appropriate in that respect. Liz
Re: Possible module for 'safer' signal handling....
At 10:09 + 1/12/04, Tim Bunce wrote:
On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote:
eval {
local $SIG{ALRM} = sub { ... };
}
Either way your Sys::SigAction is sufficient. The only thing it's
lacking that Sys::Signal has is the automatic restoration of the old
value when the object is destroyed. It would be trivial to add a
variant of sig_set_action() to do that for those that want it.
Something along the lines of:
sub sig_set_action_auto_restore {
my $class = shift;
return bless sig_set_action(@_), $class;
}
sub DESTROY {
shify-sig_set_action();
}
I'm not sure whether this is relevant here, but I seem to recall a
bug reported sometime in the past 3 weeks about signals not being
restored at the right time when using eval. You might want to p5p
archives for that.
Liz
Re: Version Numbers
At 18:34 -0800 1/9/04, David Wheeler wrote: On Jan 9, 2004, at 6:08 PM, A. Pagaltzis wrote: You should probably look at Liz' Devel::Required module first, even though it doesn't yet(!) do what you've sketched -- and particularly because: Yeah, right...in my spare time! :-) Yeah, but I use Module::Build, not ExtUtils::MakeMaker. But maybe I can pilfer some code. Support for Module::Build in Devel::Required is on the TODO list. Patches will be greatly appreciated. I don't think support for it should be that difficult: it all depends on knowing what sub to steal from Module::Build and what to do with which of its parameters. The example of WriteMakefile should be clear, I think ;-) Liz
Re: Version Numbers
At 11:43 +0100 1/10/04, Johan Vromans wrote: Elizabeth Mattijsen [EMAIL PROTECTED] writes: - Is Devel::Required still a good name then? No. And I'd very much like to execute it explictly, instead of implicitly. perl Makefile.PL- generates Makefile perl -MDevel::Panacea Makefile.PL - updates modules, PODs, version numbers, and so on Ok, fair enough. I guess I can make it so that if you had in PERL5OPTS, it would only do its magic when called from Makefile.PL. So I could make it implicit for the lazy ones amongst us. Do we have a name for this beast? Devel::Panacea doesn't seem right either... ;-) Liz
Re: Version Numbers
At 12:15 +0100 1/9/04, Paul Johnson wrote: Elizabeth Mattijsen said: I have an update script that forces me to go through all of the module files of a distribution. It forces me to check things whenever I start a new version. Ooh. Too much work! Here's the relevant parts of a Makefile.PL showing how I automate that. Whenever I use an internal module I always specify the version and that is automatically updated too, as is the version number and date in the pod. (This will probably get mangled by my mailer - the real thing is on CPAN of course.) Under what name? Devel::Cover? Liz
Re: Version Numbers
At 15:00 +0100 1/9/04, A. Pagaltzis wrote: * Elizabeth Mattijsen [EMAIL PROTECTED] [2004-01-09 14:11]: Something like: =head1 DISTRIBUTION INFORMATION This file was packaged with the Foo-Bar-0.01 distribution on Friday January 9th, 2004 on 14:12 CET. The date is a nice touch. I'd definitely include the file's private version in the POD though. It might be better kept under a more generic heading such as VERSION then. Although DISTRIBUTION INFORMATION would still be appropriate if maybe it's phrased like This file is Foo::Bar::Baz 0.07, packaged with the [...] or something. At any rate, regardless of my preferences automating this would be helpful whichever form the POD takes. Maybe it should be configurable; either fully and freely or as a choice between predefined forms. But maybe uniformity is more desirable. I have no arguments and so no firm opinion on that. Hmmm... now there are two catches to implement this in Devel::Required. - Is Devel::Required still a good name then? - How will I be able to distinguish between a developer and a user situation when Makefile.PL is run? Liz
Re: when an object gets possessed by an evil spirit
At 14:21 -0800 12/4/03, Stas Bekman wrote: Tim Bunce wrote: Umm, post_clone_reconstruct() sounds pretty intuitive to me. Thanks Tim. But it _is_ very long Wouldn't post_clone be indicative enough? Liz
Re: bag-o-code release?
At 19:47 -0500 11/19/03, James E Keenan wrote: On Wed, 19 Nov 2003 09:57:08 -0600, Eric Wilhelm wrote: Should I just put everything in a tarball and upload it to CPAN with the hope that someone else could write a makefile and test suite? What happens when the auto-tester finds no tests? At the risk of making the test mavens gag, you could upload a test suite that simply tests whether the object the module creates was constructed, i.e., a simple ok() on the constructor. This of course assumes the file is OO. If it's not, just run h2xs and use its test file which contains a single ok(). The minimal test-suite in my opinion does: use Test::More tests = 2; use_ok( 'module'); # checks for compile errors can_ok( 'module',@subnames); # checks whether there's nothing missing from the API Liz
Re: platform specific module and CPANPLUS / Makefile.PL: new namespace?
At 19:10 +0200 9/18/03, Thomas Dorner wrote: I could just put a die only running under BS2000\n unless $^O eq 'posix-bc'; into the Makefile.PL, but is there a better way? Not that I know of. I use the same approach indirectly for my thread dependent modules. By just including use threads in the Makefile.PL, it will die if run with a Perl that doesn't support threads. And thus make it impossible to be built in that environment. Hope this helps. Liz
Thread::Tie - Tie::Thread ?
Having just releasesd the Thread::Tie module to CPAN, I wonder whether it should be named Tie::Thread instead? My original reasoning for calling it Thread::Tie was that it doesn't implement a specific tie() implementation at all. It just allows you to have the variables (whichever way they are tied) in a seperate thread. Suggestions, comments anyone? Liz P.S. Docs of Thread::Tie can (currently) be found at: http://search.cpan.org/author/ELIZABETH/Thread-Tie-0.01/lib/Thread/Tie.pm
Re: Obsolete, renamed modules?
At 04:22 PM 8/4/02 +1000, Ken Williams wrote: What is the policy with regards to obsolete modules on CPAN? Would it make sense to upload a non-functioning, higher versioned dummy module? E.g. a threads::farm version 0.02, telling you to use Thread::Pool instead? I think it's dangerous to upload a non-functioning replacement. If I were you I'd upload an identical replacement whose only change is the docs telling people it's now obsolete. You can then delete the older versions from CPAN. You probably shouldn't ever delete *every* version of the old module, because then people won't be able to find the migration path. I guess my case is the exception to the rule. Most of these modules I'm thinking about, only lived for a few weeks on CPAN and only function in 5.8.0. So the chance of anybody using them right now is pretty slim. They actually have been removed from CPAN completely for several weeks now already and I've heard no one complain. So I guess I _will_ put non-functioning dummies in there now. In all other cases I will take your advice in just updating the documentation... Thanks for the feedback... Liz
Re: CPAN Upload: E/EL/ELIZABETH/Thread-Needs-0.01.tar.gz
At 01:56 PM 7/29/02 +0200, Arthur Bergman wrote: At 10:44 AM 7/29/02 +0100, Tim Bunce wrote: Thread::Needs isn't a very descriptive name - it's too general. Something like Thread::NeedsModules would be better. I have been thinking maybe it should be called Thread::Modules; use Thread::Modules qw(foo bar baz); #these must be cloned no Thread::Modules qw(don't need this); #these should not be cloned Hmmm... it would be nice if you could mark modules not to be cloned. Unfortunately, at the current state of things, we can only remove module stashes _after_ they have been cloned ;-( Currently the no Thread::Needs removes module names from the hash of module names to be kept. I basically see two ways of dealing with modules in threads currently: an aggresive way (removing _everything_ except the stuff you specify should stay) and a non-aggresive way (just specifying those modules that you know you don't need). The problem with the first is that it may throw away too much. But you will save the most memory that way. The problem with the latter is that you only remove the modules of which you _know_ as an author that they're loaded. But any modules that have been loaded under the hood will remain in memory, even if you don't need them. I think the two approaches should not reside in the same module. I would therefore like to suggest the following: Thread::With and Thread::Without. So: Thread::With - mark modules to remain in thread memory Thread::Without - mark modules to be removed from thread memory Or maybe we should _interfix_ the word Module here? Thread::Module::With - mark modules to remain in thread memory Thread::Module::Without - mark modules to be removed from thread memory Or maybe we should _postfix_ the word Module? Thread::With::Module - mark modules to remain in thread memory Thread::Without::Module - mark modules to be removed from thread memory The no calls of these modules would then simply unmark the modules, either for keeping or removing. I think that would be a cleaner interface. Thread::Without would then be for the faint of heart, and Thread::With would be for the more brave and savvy developers... Liz
Obsolete, renamed modules?
What is the policy with regards to obsolete modules on CPAN? I just realised there are several versions of modules that I uploaded to CPAN still available e.g. through search.CPAN.org, at least with the CHANGELOG and the README. Would it make sense to upload a non-functioning, higher versioned dummy module? E.g. a threads::farm version 0.02, telling you to use Thread::Pool instead? Liz
Re: [CAUTION] Thread-saving modules
At 04:23 PM 7/27/02 +0100, [EMAIL PROTECTED] wrote: Elizabeth Mattijsen [EMAIL PROTECTED] writes: I usually just call UNIVERSAL::isa($_[0], 'your::class::name') in these cases. return unless UNIVERSAL::isa( $_[0],__PACKAGE__ ); Don't you still have a 'subclass problem? Consider some parent class with children A,B,C D. If a 'D' gets DESTROYed correctly at first and then a subsequent spurious DESTROY passes an object that's morphed into a 'C' then you're protection is stuffed. Indeed. But I wouldn't know another method, short of creating a shared hash for remembering which objects got destroyed already, to fix this. In any case, this is a problem in Perl 5.8.0 that needs to be fixed. I'm just suggesting a band-aid in the mean time, which stops the bleeding most of the time... ;-) Liz
Re: [CAUTION] Thread-saving modules
At 04:03 AM 7/23/02 +1000, Ken Williams wrote: return unless ref($_[0]); I usually just call UNIVERSAL::isa($_[0], 'your::class::name') in these cases. That's a good tip. I actually generalized this to: return unless UNIVERSAL::isa( $_[0],__PACKAGE__ ); This will be implemented in Thread::Pool 0.17... ;-) Liz
Resolving log files with Thread::Pool
I was considering creating a simple application of Thread::Pool to resolve log-files, specifically web server log files. I realize that there is a lot of stuff for resolving log files out there already, but I'm more interested in writing an application for Thread::Pool rather than solving the problem of resolving log files per se. I was thinking of naming this module Thread::Pool::LogResolve. Would this make sense? Please note that it is more an example project that might have some usefullness in the end. Liz
