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

RFC on a new module 'Grep::Query'

Hi Ken At first, I was surprised by this proposal, since I often use App::Ack (https://metacpan.org/release/ack), but the examples in the docs make a good case for having this module too available to us. Some Suggestions: o Move the pod tests into xt/author, and make any modules used to test

RFC on a new module 'Grep::Query'

Hi, After some rudimentary discussion on module-auth...@perl.org, the name Grep::Query was suggested so I've tentatively used that name, but it's not written in stone. An entry for the module has been made on PrePAN, and a working copy is available at https://github.com/kenneth-olwing/grep-qu

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

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

Hi All: 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. Here is some of the documentation: NAME Auto::Log - a simple Perl extension that allows messages to

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

RFC: Algorithm::Damm

I (m...@cpan.org) am preparing a module ( https://github.com/MidLifeXis/perl-algorithm-damm) implementing the Damm check digit generator (http://en.wikipedia.org/wiki/Damm_algorithm), and am considering the Algorithm::Damm namespace. Are there other recommendations or locations where this would be

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.

RFC: Expanding the ADOPTME process

In the "Four Major problems of CPAN" blog post ( http://blogs.perl.org/users/brendan_byrd/2013/03/the-four-major-problems-with-cpan.html ), Brendan Byrd raises the problem of tracking abandoned modules. In the comments, brian mentions ADOPTME. Setting aside the majority of the post -- which can c

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 ?

RFC: module to split file on approximate size

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. I posted the details here: http://perlmonks.org/?node_id=

RFC: module namespace - librados bindings

I think this is pretty straightforward, but seeing how I'm new I'd like to follow instructions and double check that I'm on the right track here. I'm developing some perl bindings for the Ceph (filesystem) project's RADOS library. I've temporarily named what I've been working on "Ceph::RADOS".

[RFC]RTMP::Client

Hello all - I've written a new module called RTMP::Client that I'm planning to put on CPAN. Take a look at the documentation and tell me what you think. thank you for your time. NAME RTMP::Client - Very Simle RTMP client SYNOPSIS use RTMP::Client qw(rtmp_connect rtmp_play rtmp_call);

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

[RFC] Mediainfo

Hello all - I've written a new module called Mediainfo that I'm planning to put on CPAN. Take a look at the documentation(produced by pod2text) and tell me what you think. thank you for your time. NAME Mediainfo - Perl interface to Mediainfo SYNOPSIS use Mediainfo qw(mediainfo);

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

[RFC] System::Timeout

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 tell me what you think. thank you for your time. NAME System::Timeout - Extend to Allow Timeout after specified seconds SYNOPSIS

Re: Question about RFC 3986 -- Specifying URIs

On Fri, Nov 12, 2010 at 11:05:41AM -0500, Mike Jessie wrote: > My apologies if this has already been asked and answered AND I apologize > further if this is the wrong alias to ask, but here goes: This list is about administration of the CPAN module infrastructure. You wanted the Catalyst mailing

Question about RFC 3986 -- Specifying URIs

if it is technically accurate for us if we reference RFC 3986 as the definitive source for the URI scheme that is accepted/used by our API? This URL to RFC3986 is: http://tools.ietf.org/html/rfc3986 Thanks in advance for any answers or pointers with this. Mike Jessie API

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

RFC: lack of registrations

I have noticed that practically nothing submitted to the modules list has been registered in the last few months, where as prior to that there were typically a dozen new modules each week. Does anyone know the reasons for this? Have the registrars taken an extended leave, or are they focusing

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: [VPM] [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related

Personally when I see AST I think of VMS and A-Synchronous Traps. I notice that a google search shows the achronym AST is used for many computer related things besides abstract syntax trees. The CPAN rules suggest avoiding achronyms. On the other hand I find the name SQL::AbstractSyntaxTree to

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

in addition to > sending it to the discussion list. > > I am writing you today to get second opinions for proposed names on my new module, > which I would like to register as soon as possible. > > The current working title I have, which came out of a productive RFC I did on May >

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

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

ed names on my new module, which I would like to register as soon as possible. The current working title I have, which came out of a productive RFC I did on May 29th, is "SQL::ObjectModel". I did submit that name on June 2nd to get registered; it never got registered, but on the bright s

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]>

[RFC] New module/namespace proposal - CGI::Alert

CGI::Alert is a simple-to-use module: use CGI::Alert '[EMAIL PROTECTED]'; It traps 'die's and warnings, and sends an email notification to the given maintainer. Warnings are never shown to the remote (web) user, but if the script dies, a message is sent to the browser indicating that an erro

RFC for module name

Hi, I want to contribute a module to access the devicetree in Solaris where the information for the tree is assembled from information found in the kernel, configuration files and device files. I am unsure about the naming, which of the two is preferable: Solaris::Devicetree or Solaris::Devic

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

[RFC] new module proposal - Log::Colorize

Hi all, 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 using Escape sequences). The module is very simple but a

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

RFC: a SQL-representing object

Hello (and in particular to database module makers/users), I am at a point in the design/development of my "Rosetta" database abstraction tool where I am considering spitting the framework into more independant pieces than was previously planned, namely splitting up the "core", so that it is easie

RFC on using Cisco::ShowIPRoute name space

Hi, I have a few modules that parse the output from the 'show ip route' command typed at a Cisco router console. Id like to use Cisco::ShowIPRoute::Parser as the module name. It basically has a single entry point thus: use Cisco::ShowIPRoute::Parser; # Router.log holds the outpu

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

RFC Nagios Namespace.

--- Begin Message --- Dear Ladies and Gentlemen, 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. Modules proposed or written include 1 Nagios::util an exporter of subroutines and dat

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

RFC - reserving a namespace hierarchy

se a file specified in a manifest or something, if there is no individual module with the name of the framework. Is this feasable, or would it be beyond what CPAN is intended to be doing? Thank you in advance for any feedback to this RFC. Please cc any replies to [EMAIL PROTECTED] for my archival as I am not subscribed to [EMAIL PROTECTED], in addition to replying directly to [EMAIL PROTECTED] Have a good day. -- Darren Duncan

[RFC] new module proposal

Hi all, I wrote a simple collection of HTML/XML widget generator (like tabs, boxes, paths) using a master class and the subclasses rendering the particular elements with the same API. I searched on CPAN and apparently I've not found similar modules, except CGI::Widget::Tabs (but my implementation d

RFC - Namespace, Config::Directory

Hi all, I'm working on a module to provide an OO-interface to configuration settings stored individually in multiple small files within a directory or set of directories e.g. /proc directory style configs, or qmail environment directories. Multiple directory support allows things like distribu

RFC - WWW::Scraper

TWIMC - WWW:: Scraper is a module for scraping data from various web-based search engines. This module has lived in CPAN for a couple of years as WWW::Search::Scraper. Like the WWW::Search version, WWW::Scraper does the following; 1. Sends query to the target search engine. 2. Scans the resul

[RFC] UML::Sequence Diagrams

o, is it inapproapriate to include the Java sequencing tool on CPAN (it's written in Java)? Thanks, Phil Crow Here's an outline of the rest of this RFC: Current steps for sequencing a Perl program The code in the genericseq script The POD from UML::PerlSeq The svg outp

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

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

Dear Ladies and Gentlemen, I am writing to request your comments on a module that fits into the category of sending Network packets in the SMB protocol (Microsoft file sharing protocol, the protocol used by Samba and Win NT/2000/XP/9x file servers). The module is an XS interface to a small sub

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

RFC: News::yEnc - yEnc decoder

MODULES News::yEnc - yEnc decoder News::yEnc::Decoder - decodes yEncoded files News::yEnc::RC - yEnc file-part database News::yEnc::Entry - an entry in a News::yEnc::RC database >From the News::yEnc POD =head1 NAME News::yEnc - yEnc decoder =head1 S

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

RFC: Acme::Inline?

Hi all, 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 standard Inline module does not allow you to call modules in

Uri update for P/PI/PIERS/SAP-Rfc-0.99.tar.gz

Record update in the PAUSE uploads database: uriid: [P/PI/PIERS/SAP-Rfc-0.99.tar.gz] uri: [http://www.piersharding.com/download/SAP-Rfc-0.99.tar.gz] was [http://www.piershadring.com/download/SAP-Rfc-0.99.tar.gz] Data entered by Piers Harding (PIERS). Please check if they are

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

RFC: Namespace for new module (tab widgets in HTML)

Hello, This is a friendly wake-up message. I posted the message below some weeks ago, but got no response yet. That must have been because of the holidays. Everyone was/is out ofcourse. Did _you_ have a good time? I hope so :-) BTW, this message is slightly modified from the original. This messa

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

RFC: String::Levenshtein

NAME String::Levenshtein - Compute the Levenshtein distance between two strings SYNOPSIS use String::Levenshtein qw(distance prefix_distance); $d = distance ("abcd", "abxc") $d = prefix_distance("Smith", "Smithson") DESCRIPTION String::Levenshtein computes th

RFC LockFile::NetLock

The purpose of this module is to provide a robust and full featured implementation of theFTP/network locking technology outlined by Sean Burke in his June 1, Sys Admin magazine/Perl Journal Article on Resource Locking over Networks.  For those who do not yet haveaccess to the article, it doe

RFC: Unix::ShadowPasswords

Hi! Recently I required access to Solaris shadow passwords for a client project. I could not find an existing wrapper module, so I wrote one. I would appreciate any comments, especially about: - namespace - availability of the shadow password API on other platforms Here is the README: Unix::Sh

RFC: OpenTMS

Hello, As I stated in another post to this forum, I would like to submit an RFC for OpenTMS. Exerpt from Readme file below: NAME OpenTMS - Open Tournament Management System DESCRIPTION OpenTMS is a web based mod_perl application to deal with the management of tournaments

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,

  1   2   >