Re: RFC on a new module 'Grep::Query'

Hi Ron (and others), I think I've tightened things up according to your suggestions; I've split regular user install t tests vs xt/author tests, I reference metacpan and I also have a decent prereq list in Makefile plus smaller bits and pieces that caught my eye. If nothing breaks I'll submi

Re: RFC on a new module 'Grep::Query'

Hi Ken On 03/08/16 21:30, kenn...@olwing.se wrote: Hi Ron (and others), I think I've tightened things up according to your suggestions; I've split regular user install t tests vs xt/author tests, I reference metacpan and I also have a decent prereq list in Makefile plus smaller bits and pieces

Re: RFC on a new module 'Grep::Query'

Hi Ron, thank you for responding! If you don't mind, I have some follow up questions and comments :-) First a question about deps and how I treated them - maybe you can have some advice on that too... Most simply see, my comments in Makefile.PL. But in short: I've set my deps to NOT request

Re: RFC on a new module 'Grep::Query'

Hi Ken On 31/07/16 19:09, Kenneth Ölwing wrote: Hi Ron, thank you for responding! If you don't mind, I have some follow up questions and comments :-) First a question about deps and how I treated them - maybe you can have some advice on that too... Most simply see, my comments in Makefile.PL.

Re: RFC on a new module 'Grep::Query'

Hi Ken On 31/07/16 19:09, Kenneth Ölwing wrote: Hi Ron, thank you for responding! If you don't mind, I have some follow up questions and comments :-) Sure. First a question about deps and how I treated them - maybe you can have some advice on that too... Most simply see, my comments in Mak

Re: RFC: Auto::Log - a new perl module to log messages easily by redirecting STDOUT to a file

Hi Balaji, > I wanted your comments and some suggestions. I am planning on publishing a > Perl module that I have written and successfully used for some time now. I > hope it is useful to others as well. There are a number of places where you can get feedback on module ideas: http://prepan.org

Re: RFC: Algorithm::Damm

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article , Brian Wightman wrote: > I (m...@cpan.org) am preparing a module ( > https://github.com/MidLifeXis/perl-algorithm-damm) implementing the Damm > check digit generator (http://en

Re: RFC: Expanding the ADOPTME process

On Thu, Mar 14, 2013 at 8:47 AM, Matt S Trout wrote: > > If we decide that the policy side is appropriate, I'm happy enough being > the mechanism (i.e. the one who goes and kicks the PAUSE interface); I'm > sure I can find us a couple more volunteers who people wouldn't be too scared > of having a

Re: RFC: Expanding the ADOPTME process

On Wed, Mar 13, 2013 at 10:19:01AM -0400, brian d foy wrote: > In article > , > David Golden wrote: > > > I think it "improves the universe" by letting the community flag > > abandon-ware in a consistent, centralized way (because it winds up > > mirrored in 06perms). > > I don't think that act

Re: RFC: Expanding the ADOPTME process

On Tue, Mar 12, 2013 at 04:48:04PM -0400, brian d foy wrote: > In article > , > David Golden wrote: > > > That's why I think we make the parallel to our process and criteria > > for 'taking over'. I.e. author not responsive. If the author is > > responsive, then PAUSE admins take no action. >

Re: RFC: Expanding the ADOPTME process

In article , David Golden wrote: > I think it "improves the universe" by letting the community flag > abandon-ware in a consistent, centralized way (because it winds up > mirrored in 06perms). I don't think that actually improves the situation. How is this different than a person judging on hi

Re: RFC: Expanding the ADOPTME process

On Tue, Mar 12, 2013 at 4:48 PM, brian d foy wrote: > If no one wants to take over the module and there's no one to give it > up, does transferring the module improve the universe enough to offset > the extra work we do? I don't think it does. I think it "improves the universe" by letting the com

Re: RFC: Expanding the ADOPTME process

In article , David Golden wrote: > That's why I think we make the parallel to our process and criteria > for 'taking over'. I.e. author not responsive. If the author is > responsive, then PAUSE admins take no action. I don't see any benefit from the work. If you game it out If someone wants

Re: RFC: Expanding the ADOPTME process

On Sun, Mar 10, 2013 at 1:10 AM, brian d foy wrote: >> (1) Anyone can propose that any distribution (and it's contained >> packages) have ADOPTME be added as co-maint on the grounds of it being >> abandoned > > This is the only hard part of the process. I'd consider doing it the > same way that we

Re: RFC: Expanding the ADOPTME process

In article , David Golden wrote: > (1) Anyone can propose that any distribution (and it's contained > packages) have ADOPTME be added as co-maint on the grounds of it being > abandoned This is the only hard part of the process. I'd consider doing it the same way that we handle module takeovers.

Re: RFC: module to split file on approximate size

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article <66c02ce5-d6bd-4ca8-ba53-a9616f4c6...@radarlabs.com>, wrote: > Someone suggested that I take over File::Split since it has had a bug report > for 6 years and it fails all tests

Re: RFC: module to split file on approximate size

On Jun 22, 2012, at 1:01 PM, Matt S Trout wrote: > On Fri, Jun 22, 2012 at 12:49:25PM -0500, brian d foy wrote: >> [[ This message was both posted and mailed: see >> the "To," "Cc," and "Newsgroups" headers for details. ]] >> >> In article >> , >> Adam wrote: >> >>> I need to split files by

Re: RFC: module to split file on approximate size

On Fri, Jun 22, 2012 at 12:49:25PM -0500, brian d foy wrote: > [[ This message was both posted and mailed: see >the "To," "Cc," and "Newsgroups" headers for details. ]] > > In article > , > Adam wrote: > > > I need to split files by size, but they have to be split only on newlines. > > So t

Re: RFC: module to split file on approximate size

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article , Adam wrote: > I need to split files by size, but they have to be split only on newlines. > So the size can be close, but it has to be split in the right spot. > > I propose

Re: RFC: module to split file on approximate size

Adam writes: > I need to split files by size, but they have to be split only on newlines. > So the size can be close, but it has to be split in the right spot. > > I propose using the name File::Split::More, File::Split::Qualifier, or > File::Split::ApproxSize. split -C ?

Re: [RFC] Mediainfo

Is that mean something looks like $obj->fps() ? 在 2011年6月17日 下午4:49，陈钢 写道： > what does "accessor interface" mean? > > > > > 2011/6/17 brian d foy > >> [[ This message was both posted and mailed: see >> the "To," "Cc," and "Newsgroups" headers for details. ]] >> >> In article , ��谨 >> wrote:

Re: [RFC] Mediainfo

what does "accessor interface" mean? 2011/6/17 brian d foy > [[ This message was both posted and mailed: see > the "To," "Cc," and "Newsgroups" headers for details. ]] > > In article , ��谨 > wrote: > > > I've modified the module for provide an accessor interface instead of > hash > > last n

Re: [RFC] Mediainfo

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article , „¬½÷ wrote: > I've modified the module for provide an accessor interface instead of hash > last night. > > Take a look at the new documentation and tell me what you think. I

Re: [RFC] Mediainfo

I've modified the module for provide an accessor interface instead of hash last night. Take a look at the new documentation and tell me what you think. NAME Mediainfo - Perl interface to Mediainfo SYNOPSIS use Mediainfo; my $foo_info = new Mediainfo("filename" => "/root/foo.mp4"

Re: [RFC] Mediainfo

I agree "Media::Info" is a greate idea.That`s just what i want. Thk for that idea. I think the module may be base on "Mediainfo" in the video section. I will get that done later. I think "Mediainfo" is another thing which focus on videos. It`s just a perl interface of the great software called "Me

Re: [RFC] Mediainfo

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article , „¬½÷ wrote: > Hello all - I've written a new module called Mediainfo that I'm planning to > put on CPAN. I'd call it Media::Info and also provide an accessor interface instea

Re: [RFC] System::Timeout

I have thought about it, maybe you are right in many cases. But overloading Perl built-in is just wanted in some situations also. So I update the module last ngiht. Now the module have two sub named "system" and "system_ex", users can take what they prefer. Thanks for your advice. 2011/6/2 brian d

Re: [RFC] System::Timeout

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article , „¬½÷ wrote: > This module is to help people handle these things. > I guess some lazy boys want the module maybe.It`s really troublesome adding > a alarm() after every system()

Re: [RFC] System::Timeout

This module is to help people handle these things. I guess some lazy boys want the module maybe.It`s really troublesome adding a alarm() after every system(), especially in a exist big program. This module will handle everything, include timeout, local %SIG,$@,right exit code,etc. Boys only use Sys

Re: [RFC] System::Timeout

[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article , „¬½÷ wrote: > Hello all - I've written a new module called System::Timeout that I'm > planning toput on CPAN. > > Take a look at the documentation(produced by pod2text) and t

Re: RFC: lack of registrations (modules@perl.org)

At 12:08 PM 2003-08-20 +0200, Beyer Steffen (AE-DA/EFS3) wrote: > I think that there are quite a few people now who are wanting to know. I second this. :-) > Also, would it be practical to authorize extra people to do > registrations? Or is PAUSE now simply conceding namespace based on "first come,

Re: RFC: lack of registrations (modules@perl.org)

Hello Darren Duncan, in a previous mail you wrote: > I have noticed that practically nothing submitted to the modules list > has been registered in the last few months, whereas prior to that there > were typically a dozen new modules each week. Not just months, there are pending registrations whi

Re: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related

I would rather it be SQL::AbstractSyntaxTree because then someone would not have to "know" what AST meant to figure out if that is what needs to be used.

Re: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related

On Tuesday, August 12, 2003, at 02:06 PM, Darren Duncan wrote: Part of my reasoning for asking about a separate C module name is that I intend for the C module to be useable with any programming language, through a binding layer (XS in Perl 5's case, ? in Parrot's case), much as GD or libXML a

Re: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related

Thank you very much to all of you who replied (6 people at least), even though only some of them are quoted below. At 10:41 AM +0100 8/12/03, Ed Avis wrote: > How about just SQL::Tree? > > Since it is a Perl module nobody should think this is a package of SQL > routines for tree handling. > > Bef

Re: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related

At 3:03 PM -0400 8/12/03, Matthew Simon Cavalletto wrote: >I believe the convention is for the portable C library to be named something short >like libSQLOM, with the Perl code either in SQL::ObjectModel or a related namespace >like SQL::ObjectModelXS or SQL::ObjectModel::libSQLOM. Thank you Mat

RE: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related

How about just SQL::Tree? Since it is a Perl module nobody should think this is a package of SQL routines for tree handling. Before you use 'abstract syntax tree' make doubly sure you know what an AST is and how it differs from a concrete syntax tree. I don't! -- Ed Avis <[EMAIL PROTECTED]>

Re: [RFC] new module proposal - Log::Colorize

How about: Text::Illustrate or Text::Exemplify -J --

Re: [RFC] new module proposal - Log::Colorize

Ken Williams said: > > On Friday, June 13, 2003, at 09:06 AM, Enrico Sorcinelli wrote: >> >> lately I've needed to colorize (or highlight) the lines of some IRC >> logs. >> I've searched on CPAN and apparently there isn't any similar module. >> So I wrote a simple script in order to do it. >> The

Re: [RFC] new module proposal - Log::Colorize

On Friday, June 13, 2003, at 09:06 AM, Enrico Sorcinelli wrote: lately I've needed to colorize (or highlight) the lines of some IRC logs. I've searched on CPAN and apparently there isn't any similar module. So I wrote a simple script in order to do it. The output can be in html or to terminal (by

Re: RFC: a SQL-representing object

Hello Tim, and thanks for your reply. It was very helpful. (And also thanks for replying both to me and the module list, which in the past some people didn't do.) On Fri, 30 May 2003, Tim Bunce wrote: > DOM shouldn't imply XML. But you could drop the D and expand the OM into > SQL::ObjectModel,

Re: RFC: a SQL-representing object

On Thu, May 29, 2003 at 07:51:45PM -0700, Darren Duncan wrote: > > So, my first questions are these: 1. Would a DOM-for-SQL be useful in its > own right to other module developers, and therefore grow beyond its > previous intention of being "part of just one framework"; Er, perhaps :-) > 2. What

Re: RFC Nagios Namespace.

Dear Gentlemen, I am writing to thank you for your letters and say, On Wed, May 28, 2003 at 10:47:12AM -0800, Sean M. Burke wrote: > At 02:59 PM 2003-05-28 +0100, Tim Bunce wrote: > >Nagios::* is appropriate here. > > Okiedoke! > > -- > Sean M. Burkehttp://search.cpan.org/~sburke/ > I am

Re: RFC Nagios Namespace.

At 02:59 PM 2003-05-28 +0100, Tim Bunce wrote: Nagios::* is appropriate here. Okiedoke! -- Sean M. Burkehttp://search.cpan.org/~sburke/

Re: RFC Nagios Namespace.

On Wed, May 28, 2003 at 01:53:39AM -0800, Sean M. Burke wrote: > At 04:39 PM 2003-05-28 +1000, Stanley Hopcroft wrote: > >With respect, I think Net:: is less appropriate because while many of the > >Net:: modules deal with or implement a network protocol (::SMTP, ::SNMP, > >::DNS hopefully ::Samb

Re: RFC Nagios Namespace.

Dear Gentlemen, I am very grateful for your contributing to making the world a better place (you have for me) and I thank you most sincerely. On Wed, May 28, 2003 at 11:06:17AM +0100, Tim Bunce wrote: > On Tue, May 27, 2003 at 09:56:02PM -0800, Sean M. Burke wrote: > > >Please would you comment

Re: RFC Nagios Namespace.

On Tue, May 27, 2003 at 09:56:02PM -0800, Sean M. Burke wrote: > At 03:47 PM 2003-05-28 +1000, Stanley Hopcroft wrote: > >Please would you comment on the use of the namespace 'Nagios' for Perl > >modules related to the Nagios (http://www.Nagios.ORG/) availability > >monitoring system. > > Can't we

Re: RFC Nagios Namespace.

At 04:39 PM 2003-05-28 +1000, Stanley Hopcroft wrote: With respect, I think Net:: is less appropriate because while many of the Net:: modules deal with or implement a network protocol (::SMTP, ::SNMP, ::DNS hopefully ::Samba::SMB), 'Nagios' is a program to monitor the availability of services su

Re: RFC Nagios Namespace.

At 03:47 PM 2003-05-28 +1000, Stanley Hopcroft wrote: Please would you comment on the use of the namespace 'Nagios' for Perl modules related to the Nagios (http://www.Nagios.ORG/) availability monitoring system. Can't we have this be under some existing top-level category (Net::Nagios...)? I know

Re: RFC - reserving a namespace hierarchy

On Sat, Mar 29, 2003 at 06:58:48PM -0800, Darren Duncan wrote: > Specifically, while Perl itself does not make any implications that > "Foo" is related to "Foo::Bar" or "Foo::Bar::Baz", I would appreciate > it if the official module list recognized "Rosetta::*" as a reserved > name space hierarchy

Re: RFC Net::Samba, Net::SMB or Samba Perl XS to libsmbclient.

Dear Ladies and Gentlemen, Alain Barbett proposed all this stuff nearly two years ago in his analysis for what became Filesys::Samba. At that time there was no contemporary SMB client library so he provided a very neat object interface to smbclient. Bravo ! However, now there is and I am enjoy

Re: RFC: News::yEnc - yEnc decoder

In article <[EMAIL PROTECTED]>, Steven W McDougall <[EMAIL PROTECTED]> wrote: > C decodes yEncoded what does that have to do with News though? couldn't someone use it apart from a usenet context? -- brian d foy (one of many PAUSE admins), http://pause.perl.org please send all

Re: RFC: Acme::Inline?

In article <[EMAIL PROTECTED]>, Dean Povey <[EMAIL PROTECTED]> wrote: > >why not just name it Inline::Brainfuck? my Inline::TT > >(Template-Toolkit) is also a scary module, but it doesn't have Acme:: > >namespace ;) > I'll give it some thought. I do think it really belongs in Acme though. si

Re: RFC: Acme::Inline?

>why not just name it Inline::Brainfuck? my Inline::TT >(Template-Toolkit) is also a scary module, but it doesn't have Acme:: >namespace ;) I'll give it some thought. I do think it really belongs in Acme though. >Well, I've found Inline::Brainfuck on inline list archives also ... >http:[EMAIL

Re: RFC: Acme::Inline?

At Wed, 28 Aug 2002 22:43:07 +1000, Dean Povey wrote: > I am putting the finishing touches on my Acme::Inline::Brainfuck module, > which allows you call Brainfuck (an 8 instruction turing complete > language - and you thought Perl was obfuscated!) programs from Perl code. > > However, the sta

Re: Fwd: Re: RFC: Acme::No

Robin Berjon wrote: > > -- Forwarded Message -- > Subject: Re: RFC: Acme::No > Date: Sat, 10 Aug 2002 01:43:06 +0200 > From: Robin Berjon <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > > On Thursday 08 August 2002 17:05, Geoffrey Young wr

Re: RFC: Acme::No

On Thursday 08 August 2002 17:05, Geoffrey Young wrote: >I was thinking about releasing Acme::No to CPAN but wanted to make > sure that it follows the spirit of the Acme:: namespace properly. I am not a great specialist of Acme::* modules, but I /think/ it boils down to whether you intend to

Re: RFC: String::Levenshtein

Steven W McDougall wrote at Tue, 04 Jun 2002 18:28:27 +0200: > NAME > String::Levenshtein - Compute the Levenshtein distance between two strings > There's already a module Text::Levenshtein. Greetings, Jnaek

Re: [RFC] Date::MySQL

On 25 Nov 2001, Ask Bjoern Hansen wrote: > [EMAIL PROTECTED] (Rich Bowen) writes: > > > rbowen@rhiannon:~% perl -MDate::ISO -le 'my $d=Date::ISO->new( epoch => > > time ); print $d->iso;' > > 2001-W44-6 > > > > Unfortunately, the "default" ISO date format is this year-week-day > > format. At leas

Re: [RFC] Date::MySQL

[EMAIL PROTECTED] (Rich Bowen) writes: > rbowen@rhiannon:~% perl -MDate::ISO -le 'my $d=Date::ISO->new( epoch => > time ); print $d->iso;' > 2001-W44-6 > > Unfortunately, the "default" ISO date format is this year-week-day > format. At least that's what I gathered from all the web sites that I >

Re: [RFC] Date::MySQL

On Tue, 6 Nov 2001, Jonathan Leffler wrote: > In ISO 8601:1986, the basic format for the complete representation of a > date is 19991231 and the extended format for a date is 1999-12-31 (see > section 5.2.1 Calendar Date and in particular 5.2.1.1 Complete > Representation). > > There is discussio

Re: [RFC] Date::MySQL

On Sun, 4 Nov 2001, Rich Bowen wrote: >On Sat, 3 Nov 2001, Nick Tonkin wrote: >> So does this mean that you would not support extending Date::ISO to >> provide a method to output a date in YYY-MM-DD format by default? It >> sounds like it does. In that case I would have to think that >> creating

Re: [RFC] Date::MySQL

On Sat, 3 Nov 2001, Nick Tonkin wrote: > > So does this mean that you would not support extending Date::ISO to > provide a method to output a date in YYY-MM-DD format by default? It > sounds like it does. In that case I would have to think that > creating Date::MySQL would be appropriate. No, it

Re: [RFC] Date::MySQL

So does this mean that you would not support extending Date::ISO to provide a method to output a date in YYY-MM-DD format by default? It sounds like it does. In that case I would have to think that creating Date::MySQL would be appropriate. ?? Nick ~~~ Nick Tonkin On Fri, 2 Nov 2001,

Re: [RFC] Date::MySQL

On Fri, Nov 02, 2001 at 09:47:05PM -0500, Rich Bowen wrote: > I was sure that there was an iso method, which output the iso formatted > date. > > rbowen@rhiannon:~% perl -MDate::ISO -le 'my $d=Date::ISO->new( epoch => > time ); print $d->iso;' > 2001-W44-6 > > Unfortunately, the "default" ISO da

Re: [RFC] Date::MySQL

On Sat, 3 Nov 2001, Ilmari Karonen wrote: > > On Fri, 2 Nov 2001, Nick Tonkin wrote: > > > > Nevertheless, in order to smooth the ruffled feathers of (my fellow) Brits > > and other Euros, I shall change my module so that it is required to > > provide a format specification. I only have 'us' and

Re: [RFC] Date::MySQL

On Fri, 2 Nov 2001, Nick Tonkin wrote: > > Nevertheless, in order to smooth the ruffled feathers of (my fellow) Brits > and other Euros, I shall change my module so that it is required to > provide a format specification. I only have 'us' and 'eu' at this > point: I suppose 'iso' would be redund

Re: [RFC] Date::MySQL

On Fri, 2 Nov 2001, David Cantrell wrote: > On Thu, Nov 01, 2001 at 02:39:49PM -0800, Nick Tonkin wrote: > > Out of a dozen or so responses I received here, on [EMAIL PROTECTED], and > > in c.l.p.m., over 90% were huffy snipes about only Americans using > > MM-DD-, penned by outraged folks w

Re: RFC: Logging used Perl Modules (was Re: API Design Question)

- James G Smith <[EMAIL PROTECTED]> on 07/02/01 16:08:09 -0500: > How would something like this do: > > NAME > > Apache::Use > > SYNOPSIS > > use Apache::Use (Logger => DB, File => "/www/apache/logs/modules"); > > DESCRIPTION > > Apache::Use will record the modules used over the course of t

Re: RFC: Data::Encrypted

On Mon, 18 Jun 2001, Benjamin Trott wrote: > First let me start by saying that I think this is a really good idea; a > transparent method of storing sensitive data (eg. passwords) in an encrypted > form is a great thing. Thanks! > However, that makes me wonder: how much safer is the data if it

RE: RFC for module name Color::Object.

hi! > > It's been a (long) while and I've been busy with other > projects, so please > > take over Graphics::ColorSpace or Color::Object or whatever > you prefer to > > call it. (Though Color::Object does not seem like the best name.) > > Yes, I agree that Color::Object is not the best of na

Re: RFC for module name Color::Object.

On Thu, May 24, 2001 at 10:06:25PM -0400, Robert Rothenberg wrote: > > It's been a (long) while and I've been busy with other projects, so please > take over Graphics::ColorSpace or Color::Object or whatever you prefer to > call it. (Though Color::Object does not seem like the best name.) Yes,

RE: RFC for module name Color::Object.

It's been a (long) while and I've been busy with other projects, so please take over Graphics::ColorSpace or Color::Object or whatever you prefer to call it. (Though Color::Object does not seem like the best name.) --Rob On 23 May 2001, Alfred Reibenschuh wrote: > >[...] > >I think Graphics:

Re: RFC for module name Color::Object.

On Wed, May 23, 2001 at 06:26:28AM +0200, Andreas J. Koenig wrote: > > On Mon, 19 Mar 2001 12:27:36 +0100, "Alfred Reibenschuh" ><[EMAIL PROTECTED]> said: > > > hi! > > i'd like some comments on how to name this module > > > it presents a OO interface to the user for creation > > an

RE: RFC for module name Color::Object.

hi! > I think this is what Jon Orwant had in mind when he > registered Image::Colorimetry: > > cpan> m Image::Colorimetry > Module id = Image::Colorimetry > DESCRIPTION transform colors between colorspaces > CPAN_USERID JONO (Jon Orwant <[EMAIL PROTECTED]>) > D

Re: RFC for module name Color::Object.

> On Mon, 19 Mar 2001 12:27:36 +0100, "Alfred Reibenschuh" ><[EMAIL PROTECTED]> said: > hi! > i'd like some comments on how to name this module > it presents a OO interface to the user for creation > and modification of colors (RGB,CMYK,HSV,HSL) > the functions return values have

Re: RFC: HTML::MicroMason

> On Sat, 24 Mar 2001 00:18:41 -0500, "M. Simon Cavalletto" <[EMAIL PROTECTED]> >said: > RFC: HTML::MicroMason I'm pleased to announce you a new form available on PAUSE where you can register your namespace. If you still want to register HTML::MicroMason, please go to https://pause.p

Re: RFC: Class::Methods

> On Tue, 15 May 2001 03:24:06 -0400, "M. Simon Cavalletto" <[EMAIL PROTECTED]> >said: > A few minutes with a thesaurus produced a list of candidates, but none > of them really stood out: Class::CodeLibrary, Class::MakeMethods, > Class::MethodGen, Class::MethodMill, Class::MethodSm

Re: RFC: Class::Methods

Please help me rename this module! (A summary of its functionality is included below for reference.) I circulated a prior version under the name "Class::Methods", and Andreas Koenig indicated that was an acceptable namespace for CPAN distribution. But I was somewhat uncomfortable with the name,

Re: RFC: Class::Methods

On 2001-05-11, Andreas J. Koenig wrote: > Better you call it just Class-Methods-*. The reason is you do not use > the Bundle:: namespace anyway and the Bundle:: namespace in turn would > mean something completely different, a directory of modules that are > available separately. I did actually h

Re: RFC: Class::Methods

> On Sun, 6 May 2001 00:44:08 -0400, "M. Simon Cavalletto" <[EMAIL PROTECTED]> >said: > Class::Methods is based on Class::MethodMaker, but has been > substantially revised in order to provide a range of new features. > Although originally posted for review as a possible "version 2" of

Re: RFC on proposed module HTML::Application

On Sat, Feb 17, 2001 at 08:45:49PM -0800, Darren Duncan wrote: > This is a request for comment on a Perl module that I am making, so > to get an idea where it could be useful, and so hopefully you can > provide feedback for its construction. > > The message that I quote below was originally sen

Re: RFC: new modules Tk::DataEditor and Tk::DataEditorDialog

Dominique Dumont <[EMAIL PROTECTED]> writes: > Hello > > Since some people are interested in the possibility to edit the data > displayed by ObjScanner, I've created 2 new widgets to do that. > > The first is Tk::DataEditor: You could consider to name it Tk::ObjEditor, to keep the name similar

Re: [RFC] Audio::SoundFile - Perl interface to libsndfile library

> On Sun, 7 Jan 2001 04:44:16 +0900, Taisuke Yamada <[EMAIL PROTECTED]> said: > and Audio::SoundFile:: seems fairly clear and appropriate. > Anyone has comments/agreement/disagreement on this naming? Sounds good:-) -- andreas

Re: [RFC] need name for "HashOfArrays"

[Quoting Darren Duncan, on December 29 2000, 22:07, in "[RFC] need name for "] > CGI::HashOfArrays - Perl module that implements a hash whose keys can > have either single or multiple values, and which can process > url-encoded data. I would propose to split the functionality. For example, Data

Re: RFC: WebsiteGenerator, etc.

Gunther, in advance I thank you for the time you took to respond. I am seeing what changes I can make so that my contributions are less proprietary and/or out of the more public namespaces. It is good that you spoke up, as I have a better impression of what other people think. On Fri, 29 Dec 20

Re: RFC: WebsiteGenerator, etc.

I apologize in advance for snipping some stuff out. At 12:40 PM 12/28/2000 -0800, Darren Duncan wrote: >This RFC is concerned mainly with what to name my modules so that they fit >into the appropriate name-spaces. Any help is appreciated. Also, when >one has a set of related modules, should I h

Re: RFC: WebsiteGenerator, etc.

This RFC is concerned mainly with what to name my modules so that they fit into the appropriate name-spaces. Any help is appreciated. Also, when one has a set of related modules, should I have a separate RFC letter for each, or one for all? On Thu, 28 Dec 2000, Gunther Birznieks wrote: > You sh

Re: RFC/ANNOUNCE: WebsiteGenerator, FormGenerator, Class-ParamParser

The modules look very cool. However You should be careful as to what modules you've created solve a problem in a particular way that you enjoy using and which ones are truly generic. Some of the following was unclear in your email explanation of the modules. I am worried that some of your C

Re: RFC: New module HTTP::WebTest

> On Sun, 10 Dec 2000 08:25:05 -0800, "Richard Anderson" <[EMAIL PROTECTED]> >said: > This module has been in use at an Internet 100 company for a few months. > I invite your comments on the interface and functionality. The > priorities on the TODO list are adding HTML syntax checking an

Re: RFC

[Quoting Joshua N Pritikin, on September 26 2000, 12:18, in "Re: RFC"] > On Tue, Sep 26, 2000 at 05:30:13PM +0200, [EMAIL PROTECTED] wrote: > > On August 9 I've requested registration of a new module: > > Mail::Procmail. I didn't get any response. > > &g

Re: RFC

On Tue, Sep 26, 2000 at 05:30:13PM +0200, [EMAIL PROTECTED] wrote: > On August 9 I've requested registration of a new module: > Mail::Procmail. I didn't get any response. > > On August 18 I've repeated the question[2] -- still no response. > > If anyone is at the other ens of this mail alias, pl

Re: RFC: How to name date objects module?

> Therefore, being OO and using overloaded operators *DOES* make a > difference to some people, first because most of the Date modules > existing so far are functional All of them, I think? > and second, because there are so > many different Date modules right now that creating a new one > which

Re: RFC: name for std-based passwd generator?

Andreas J. Koenig wrote: > jp> Hi, I've written a module which implements the algorithm for a > jp> password generator, specified in a standards document, namely > jp> FIPS 181 (on-line at http://www.itl.nist.gov/fipspubs/fip181.htm ) > > I'd propose Crypt::RandPasswd. Then, if no one has any ot

Re: RFC: name for std-based passwd generator?

> On Wed, 5 Jul 2000 13:00:33 -0400, John Porter <[EMAIL PROTECTED]> said: jp> Hi, I've written a module which implements the algorithm for a jp> password generator, specified in a standards document, namely jp> FIPS 181 (on-line at http://www.itl.nist.gov/fipspubs/fip181.htm ) jp> Any ideas

Re: RFC: How to name date objects module?

I've already given my opinion on the matter and don't want to keep restating it, so I'll keep it brief, I hope. At 8.28 +0200 2000.06.27, Steffen Beyer wrote: >Hello Chris Nandor, in a previous mail you wrote: >> Note that "Date::Object" tells me not a jot about what the module >> actually doe

Re: RFC: How to name date objects module?

I agree with Chris. On the point of *_XS names. I would encourage people to have both XS/non-XS called the same and choose which to install at install time. I have done this with some of my modules. Graham. On Mon, Jun 26, 2000 at 06:03:00PM -0400, Chris Nandor wrote: > At 23.17 +0200 2000.06.2

Re: RFC: How to name date objects module?

For the record, I strongly agree with everything Chris says here. -Jon Chris Nandor writes: > At 23.17 +0200 2000.06.26, Steffen Beyer wrote: > >Jarkko Hietaniemi wrote: > > > >1> I think that the suggested name for the new OO interface, > >1> Date::Object, is a Very Bad Choice. I severel

Re: RFC: How to name date objects module?

At 23.17 +0200 2000.06.26, Steffen Beyer wrote: >Jarkko Hietaniemi wrote: > >1> I think that the suggested name for the new OO interface, >1> Date::Object, is a Very Bad Choice. I severely dislike embedding > >Exactly *why* do you think so? > >1> either the interface style or the implementation s

Re: RFC for New Module: Term::Scraper

> On Wed, 14 Jun 2000 16:25:28 -0700, [EMAIL PROTECTED] said: > A couple weeks ago I snagged the name Term::Scraper for a module that I'm > working on. This module will be ready for initial upload in the next 2 > weeks. I am requesting comments for the namespace. As it is already listed

  1   2   >