On Sat, Apr 03, 2021 at 09:54:52AM -0400, James E Keenan wrote:
> Hello,
>
> I'm interested in adopting the Devel-NYTProf distribution. If you can grant
> me the privilege I will release the next version.
> I've had some correspondence with Tim Bunce about this. On March 2
Hello Neil, James, and fellow co-maints.
Count me as affirmative. Thanks James!
I'll also give a preemptive approval for Cache::Memcached::libmemcached as
well, in case you're interested :)
Tim.
> On 6 Jul 2020, at 13:44, Neil Bowers wrote:
>
> Hi James,
>
> I’m one of the PAUSE admins.
>
Seems good to me.
Thanks for all the house-keeping Neil!
Tim.
On Wed, Jun 08, 2016 at 08:24:21AM +0100, Neil Bowers wrote:
> Hi Maki-san and CODEREPOS,
>
> I’m emailing you wearing my PAUSE admin hat: I’m working on resolving
> conflicts caused by PAUSE now considering package names
On Sat, Jun 22, 2013 at 07:05:11PM +0200, David Baird wrote:
As it happens, I've been extremely busy, setting up a new business. But I
appreciate my delay has been
frustrating for you. I've just uploaded the new version of CDBI::FB which
should free up the DBI::Test
namespace.
On Wed, Nov 19, 2003 at 12:15:44AM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Geo::GSHHS::PurePerl
I'm suggesting the *::PurePerl namespace, so that if somebody
writes an implementation in C (which
On Fri, Nov 14, 2003 at 07:01:23PM -0500, Rudy Lippan wrote:
Good day,
I am planing on releasing Palm::Ztxt_XS on CPAN. Palm::Ztxt_XS is an XS
interface to the ztxt library used with the weasel book reader
(http://gutenpalm.sourceforge.net/). There is a similar module
Palm::ZText (not on
On Fri, Nov 14, 2003 at 06:17:58AM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: List::SkipList
description: Implementation of SplitLists (aka Treaps)
Maybe this is a bumb question, but
why call the module
On Fri, Nov 14, 2003 at 09:17:26AM -0800, Reece Hart wrote:
Tim-
For some reason I thought Bio:: was a registered namespace and that this implied
a closed namespace
(i.e., anything in CPAN's Bio:: tree had to come from bioperl's developers). I
see now that both are
incorrect.
On Thu, Nov 13, 2003 at 03:45:41PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: SQLayer
DSLIP: RdpOb
description: Very simple DBI extension.
userid: STELLAR (Andrei V. Shetuhin)
chapterid:
On Wed, Nov 12, 2003 at 11:06:35AM -0800, Kees Cook wrote:
I'd like to register a namespace for remote system management modules.
I have plans for IBM ASMA control, HP TTRC control, NUMAQ power control,
Pulizzi IPC power control, VASENET, and possible IPMI.
I figured that using the
DBI extensions normally live in the DBIx::* namespace.
The SQL::* namespace is mainly for module that manipulate SQL.
Tim.
On Sat, Nov 08, 2003 at 02:46:06PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid:
On Sun, Nov 09, 2003 at 04:53:03PM +0100, demerphq wrote:
Other module names I considered were Data::Streamer
Data::Dumper::Streamer and Data::Serialize and also preserving the
BFDump name. After discussions with various people from Perlmonks
the consensus was that
On Fri, Nov 07, 2003 at 06:55:21PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Data::Stream
DSLIP: bdhhp
description: Stream a data dump to a filehandle
userid: YVES (Yves)
chapterid:6
There's a Spreadsheet::* namespace with things like
Spreadsheet::ParseExcel::Utility and Spreadsheet::WriteExcel.
So perhaps Spreadsheet::TieExcel would be good.
Tim.
On Wed, Nov 05, 2003 at 08:02:05AM +0100, Simone Cesano wrote:
Hello,
I am thinking about uploading a module to CPAN.
It
On Thu, Nov 06, 2003 at 08:43:19AM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: IO::Shaper
DSLIP: adpOp
description: Simple Multiplexing TCP Traffic Shaper
userid: BHOLZMAN (Benjamin Holzman)
On Wed, Oct 29, 2003 at 01:06:27PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: DBIx::Composer
DSLIP: adpOp
description: Composing and executing of SQL statements
userid: PLISCO (Igor Plisco)
On Fri, Oct 24, 2003 at 12:05:05AM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Image::Schedule
DSLIP: RdpOp
description: creates schedule image with labelled events
userid: RAHUNT (Rebecca A
On Wed, Oct 22, 2003 at 07:24:11AM +0200, Andreas J Koenig wrote:
That said, there is indeed a painful delay in the production of the
modulelist. The software I have written to produce new module lists is
very broken and I'd need a whole lot of consecutive days to redesign
it so that the
On Wed, Oct 15, 2003 at 01:17:33PM +0100, Steve Hay wrote:
Is the Module List
(http://www.perl.com/CPAN/modules/00modlist.long.html) ever going to get
updated again, or has that been abandoned now?
It is currently monstrously out-of-date (27 Aug 2002), which seems to
prevent me from
On Tue, Oct 21, 2003 at 04:09:16AM +0800, Autrijus Tang wrote:
On Tue, Oct 21, 2003 at 05:05:32AM +1000, Ricky Buchanan wrote:
Could you suggest an appropriate namespace for this file? Other
than Mutt::Aliases, which creates a new root namespace which I
understand is Generall Bad Form, I
On Mon, Oct 06, 2003 at 02:40:23PM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Alien
DSLIP: adpfp
description: Top level for external dependencies on CPAN
userid: ABERGMAN (Arthur Bergman)
On Mon, Oct 06, 2003 at 04:19:52PM +0100, Arthur Bergman wrote:
On Monday, October 6, 2003, at 04:06 pm, Tim Bunce wrote:
There's no need (or mechanism) to register the name of a namespace,
only the module(s) within it, e.g., Alien::zlib.
But I think there should be an Alien.pm
On Tue, Sep 30, 2003 at 01:28:48PM -0700, Brad Fitzpatrick wrote:
Hello,
I'm a new CPAN contributor (BRADFITZ) and need help picking a name for a
module.
I'd like to upload the client library for memcached. (which is in use by
LiveJournal, Slashdot, soon Wikipedia, and others...)
On Thu, Sep 25, 2003 at 08:46:06PM -0700, Marc M. Adkins wrote:
I've got a script and some supporting classes for converting POD-enabled
Perl into fake C++ that doxygen (an open-source documentation producer) can
handle. I currently have the classes named doxy::???. I don't see a
top-level
On Mon, Sep 15, 2003 at 09:42:23PM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Data::Strify
description: stringify nested data
Data::StringifyNested seems much more self explanatory.
Tim.
On Wed, Aug 20, 2003 at 11:52:24AM -0400, Kurt Starsinic wrote:
On Aug 13, Mark Overmeer wrote:
* Kurt Starsinic ([EMAIL PROTECTED]) [030813 15:30]:
On Aug 13, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid:
On Wed, Aug 20, 2003 at 09:58:28PM -0800, Ovod-Everett, Toby wrote:
I developed a module to make interacting with masks more pleasant (both generating
masks from a list of constants, breaking the mask back into constants, and
explaining the mask in terms of a minimal list of constants). It
On Sun, Aug 17, 2003 at 08:13:12AM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: DBIx::GlobalCache
DSLIP: adpfp
description: Global cache of statements
userid: APOCAL (Apocalypse)
chapterid:
This very sound email thread on [EMAIL PROTECTED] raises
important issues.
Is [EMAIL PROTECTED] the best forum for it?
It seems odd that the search.cpan.org code isn't Open Source in
the sense that, as far as I'm aware, people can't see the code and
so can't send patches etc.
Tim.
-
Extensions to the DBI live in the DBIx:: namespace.
There are many modules that also aim to provide a simplified
interface to the DBI. Please compare yours with them and, if
you think yours offers significant new functionality over
any of them, please resubmit with a new (better) name in the
On Mon, Aug 11, 2003 at 02:58:59PM -0700, Darren Duncan wrote:
Hello, this request for comment is in particular aimed at those of you who use
databases and/or DBI with Perl.
Thanks to a topic covered in Piers Cawley's most recent Perl 6 Summary (generic
Parrot code generators), I think I
Thaks. How does it relate to DBD::Multiplex?
Tim.
On Tue, Jun 17, 2003 at 10:51:22PM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: DBIx::DBCluster
DSLIP: bdpOp
description: Distributes load among
On Wed, Jun 18, 2003 at 11:52:18AM +0100, Tim Bunce wrote:
Thaks. How does it relate to DBD::Multiplex?
And this explains current plans for DBD::Multiplex enhancements:
http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8safe=offthreadm=20030513222318.GI29922%40dansat.data-plan.comrnum
On Mon, Jun 16, 2003 at 04:31:06AM +0200, Perl Authors Upload Server wrote:
Can't we use UNIVERSAL::isa()? Yes, and no. If you already have an
object, then isa() will let you know if it inherits from a given
class. But what do we do if we know nothing of the inheritance tree
On Thu, Jun 12, 2003 at 01:08:38PM -0400, Richard Naugle wrote:
At 01:05 AM 6/11/2003 -0800, Sean M. Burke wrote:
At 07:56 AM 2003-06-10 -0400, Richard Naugle wrote:
[...]I agree with Doc::US_DOD[...]
It just occurred to me to wonder... looking back at your original request
for module list
I'm happy for it to be in the module list, but I'd really appreciate
it if you could add a section to the docs that compares and contrasts
it with the SQL::Statement (SQL::Parser).
Look at it this way... if you don't you'll be spending far longer
answering emails from people asking how it
I don't think any of these belong in the Module List. The main standard
was reasonable to include, just, maybe. But these others are not worth it.
Note that having a Module List entry is totally unrelated to L... working
in pod. And as someone else said recently (sorry, forgot who and can't find
On Thu, Jun 05, 2003 at 07:18:21PM -0700, William R Ward wrote:
Kurt Starsinic writes:
On Jun 05, Sean M. Burke wrote:
At 06:20 PM 2003-06-05 -0700, William R Ward wrote:
I really hope the admins don't accept this new US_DOD:: top-level
domain. I think it should go under the
On Thu, Jun 05, 2003 at 06:34:09AM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Military::STD2167A
DSLIP: Rdpnb
description: Defense System Software Development Standard
userid: SOFTDIA (Samson
On Wed, Jun 04, 2003 at 06:54:16AM +1000, Stanley Hopcroft wrote:
Dear Gentlemen,
I am sorry to ask such a stupid question but what should I do,
On Tue, Jun 03, 2003 at 02:38:33PM +0100, Tim Bunce wrote:
On Tue, Jun 03, 2003 at 03:18:20AM -0800, Sean M. Burke wrote:
modid
On Thu, May 29, 2003 at 01:21:18PM -0700, William R Ward wrote:
[EMAIL PROTECTED] (Arthur Bergman) writes:
On mndag, maj 5, 2003, at 18:47 Europe/Stockholm, Perl Authors Upload
Server wrote:
The following module was proposed for inclusion in the Module List:
modid:
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
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
I think WebService::Mappoint would be the current recommended name
for modules providing an interface to web services. (Net::Google
and Net::Amazon predate the Webservice namespace.)
Tim.
On Wed, May 28, 2003 at 10:33:29PM +0200, Perl Authors Upload Server wrote:
The following module was
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 have
On Tue, Apr 01, 2003 at 11:25:32AM -0800, Eric Weaver wrote:
Tim Bunce wrote:
On Tue, Apr 01, 2003 at 07:44:43AM -0800, Eric C. Weaver wrote:
[...]
Just who's authoritative here? Autrijus or you?
No one. I said if you are willing ... would be appreciated.
If not, don't.
Tim
The Devel:: namespace is meant for modules used during
development/debugging, but not ordinarily used in production.
Tim.
On Sun, Mar 30, 2003 at 08:12:37PM +0800, Autrijus Tang wrote:
On Sun, Mar 30, 2003 at 11:37:43AM +0200, Arthur Bergman wrote:
I think Tie::FunctionID is wrong since the
We have Oracle::* and others. An Informix::* namespace seems
best for this.
The DBIx::* space is best for modules that are not database specific.
Tim.
On Sun, Mar 30, 2003 at 09:28:08AM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module
Sub::ThisFunction
Sub::CalledAs
Tim.
On Mon, Mar 31, 2003 at 07:45:48AM -0500, Eric J. Roode wrote:
On Sun, Mar 30, 2003 at 08:12:37PM +0800, Autrijus Tang wrote:
On Sun, Mar 30, 2003 at 11:37:43AM +0200, Arthur Bergman wrote:
I think Tie::FunctionID is wrong since the fact that the
On Mon, Mar 31, 2003 at 07:24:55AM -0800, Eric C. Weaver wrote:
Tim Bunce wrote:
We have Oracle::* and others. An Informix::* namespace seems
best for this.
Too late. Besides, I *already* renamed it from DBIx::Perform to make
AURIJUS happy.
The DBIx::* space is best for modules
On Mon, Mar 31, 2003 at 08:42:06AM -0800, Eric C. Weaver wrote:
Tim Bunce wrote:
On Mon, Mar 31, 2003 at 07:24:55AM -0800, Eric C. Weaver wrote:
Tim Bunce wrote:
We have Oracle::* and others. An Informix::* namespace seems
best for this.
Too late. Besides, I *already* renamed it from
On Tue, Apr 01, 2003 at 04:29:14AM +0800, Autrijus Tang wrote:
On Mon, Mar 31, 2003 at 09:09:29PM +0100, Tim Bunce wrote:
It's up to [EMAIL PROTECTED] to avoid it setting any precedents.
I mistakenly looked at DBIx::OracleSequence and DBIx::MSSQLReporter in
the module list and thought
On Tue, Mar 25, 2003 at 10:37:53AM +0100, Arthur Bergman wrote:
On tisdag, mar 25, 2003, at 07:36 Europe/Stockholm, Robert Spier wrote:
Robert, has anybody talked with you if and how RT could work for
managing module namespace requests? You probably know how the process
currently is
There was talk of using RT to manage requests.
Tim.
On Fri, Mar 21, 2003 at 09:59:06AM +0100, Johan Vromans wrote:
Philip Newton [EMAIL PROTECTED] writes:
But the fact that [EMAIL PROTECTED] appears like a black hole fairly
often is not new.
Does anyone have any idea how many module
Thanks. I'll look into it.
Tim.
On Thu, Mar 13, 2003 at 01:00:39PM +1100, [EMAIL PROTECTED] wrote:
Hi
Could you please pass this onto whoever is responsible for this ---
I personally not interested in the DBI modules but I have been installing
them for developers.
The
On Tue, Mar 04, 2003 at 03:19:39PM +0100, Andreas J. Koenig wrote:
Many suggestions have come over the years that we should somehow flag
abandoned modules as such. Finally I came up with the simplest
possible idea:
We have already the flags
S - Support Level:
m - Mailing-list
On Tue, Feb 25, 2003 at 05:34:52PM -0500, Casey West wrote:
It was Tuesday, February 25, 2003 when Kurt Starsinic took the soap box, saying:
: On Feb 25, Casey West wrote:
: I'm writing a set of modules that deal with scripture (bible)
: specifications and standards, as well as a few for
On Wed, Jan 08, 2003 at 10:42:55AM -0800, Darren Duncan wrote:
... ramble, ramble, ramble ...
Anyway, here are some new ideas I thought of for a framework name:
- Cipher
- CipherDB
- DBCipher
- ResolveDB
- DBResolver
- InterpreDB
-
On Tue, Jan 07, 2003 at 04:46:40PM -0600, _brian_d_foy wrote:
In article [EMAIL PROTECTED], Perl Authors
Upload Server [EMAIL PROTECTED] wrote:
The following module was proposed for inclusion in the Module List:
modid: DBX
i think anything built on DBI should go into DBIx.
On Wed, Jan 08, 2003 at 01:04:24PM +, Tim Bunce wrote:
On Tue, Jan 07, 2003 at 04:46:40PM -0600, _brian_d_foy wrote:
In article [EMAIL PROTECTED], Perl Authors
Upload Server [EMAIL PROTECTED] wrote:
The following module was proposed for inclusion in the Module List:
modid
On Tue, Jan 07, 2003 at 10:18:29AM -0800, Darren Duncan wrote:
On Tue, 7 Jan 2003, Tim Bunce wrote:
On the other hand, I don't really think that my distribution should be
branded; despite anything I may have written, what I am doing is meant to
be a generic way of talking to databases
On Mon, Jan 06, 2003 at 10:46:09AM -0800, Darren Duncan wrote:
Tim Bunce said:
Frameworks of multiple closely related modules are encouraged to
have a catchy 'brand name' at the top level rather than fit into
an existing namespace. e.g., Alzabo and Tangram.
Tim.
Thanks, I appreciate
Frameworks of multiple closely related modules are encouraged to
have a catchy 'brand name' at the top level rather than fit into
an existing namespace. e.g., Alzabo and Tangram.
Tim.
On Mon, Jan 06, 2003 at 07:56:49AM +0100, Perl Authors Upload Server wrote:
The following module was proposed
On Sat, Jan 04, 2003 at 01:06:09PM +0100, Andreas J. Koenig wrote:
On Sat, 4 Jan 2003 05:31:10 +0100, Perl Authors Upload Server
[EMAIL PROTECTED] said:
DBI::Simple should be included in the DBI namespace because it's
really just an extension of the DBI.
The DBI::* namespace
On Sat, Jan 04, 2003 at 10:27:23AM -0800, _brian_d_foy wrote:
In article [EMAIL PROTECTED], Hendrik Van
Belleghem [EMAIL PROTECTED] wrote:
I' writing a module that basically access a Connectix/Logitech QuickCam. I
checked with rhizo's #perl and the perlmonks CB for a good name for the
On Sun, Jan 05, 2003 at 01:50:14AM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Device::QuickCam
DSLIP: RdhOg
description: interface to QuickCam
userid: BEATNIK (Hendrik Van Belleghem)
On Fri, Dec 20, 2002 at 03:35:35PM +0100, [EMAIL PROTECTED] wrote:
Hi Tim,
regarding OpenBSD::Uptime - I think OpenBSD::SysInfo will be a more suitable
name; I just find myself implementing some further functionality, and
consolidating these things into a SysInfo module seems like a
On Sat, Dec 28, 2002 at 02:00:53PM -0500, Tom Scanlan wrote:
How about NetInfo::Discovery? Or were you actually looking for a Netx
namespace?
NetInfo:: seems like a useful home for modules that provide information about a
network (like topology).
Tim.
-Tom Scanlan
On Sat, 28 Dec
On Mon, Dec 30, 2002 at 11:11:20AM -0500, Tom Scanlan wrote:
To avoid confusion we could call it NetInfo(not_the_protocol)::.
On a more serious note, we could go the long route and use NetworkInfo::.
Sounds good to me.
Tim.
On Wed, Dec 18, 2002 at 08:10:09PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: OpenBSD::Uptime
DSLIP: Rdcfg
description: Get uptime of OpenBSD systems
userid: SCHNEE (Schneelocke)
Gr, is there a good reason these messages aren't CC'd to the requestor?
Then when people reply they wouldn't have to remember to manually add
the [EMAIL PROTECTED]
Tim.
On Wed, Dec 18, 2002 at 08:10:09PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for
On Wed, Dec 18, 2002 at 09:18:42PM +0100, [EMAIL PROTECTED] wrote:
Hi,
regarding OpenBSD::Uptime - I think OpenBSD::SysInfo will be a more suitable
name; I just find myself implementing some further functionality, and
consolidating these things into a SysInfo module seems like a natural
On Sat, Nov 30, 2002 at 11:42:43AM -0500, Kurt D. Starsinic wrote:
On Nov 30, brian d foy wrote:
In article [EMAIL PROTECTED], Chocolate Boy
[EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Chocolate Boy
[EMAIL PROTECTED] wrote:
I've noticed that most requests for CPAN
Seems reasonable. No need for the extra 'Tools' level.
Tim.
On Tue, Nov 19, 2002 at 11:58:36AM -, Wim wrote:
As there are no other comments, could we agree on the namespace
Simulation::SynSim ?
Wim
_brian_d_foy [EMAIL PROTECTED] said:
In article [EMAIL PROTECTED], Wim [EMAIL
Just because a module uses a network protocol doesn't mean it should go into Net::
Seems much better to just use a Fax:: category:
Fax::Hylafax
or Fax::HylafaxFOO where FOO describes what this module offers in
relation to Hylafax.
Tim.
On Tue, Nov 19, 2002 at 02:46:59PM +0100,
The 'Tools' second-level names seems superfluous to me.
Especially as SynSim is a set of modules.
Tim.
On Tue, Nov 12, 2002 at 04:26:06PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Simulation::Tools::SynSim
Seems like a good fit for the new WebService:: category.
But how does it relate to
http://search.cpan.org/author/SAMV/Lingua-Translate-0.06/lib/Lingua/Translate.pm
Tim.
On Fri, Nov 08, 2002 at 07:49:54PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for
On Wed, Oct 30, 2002 at 11:51:28AM -0600, _brian_d_foy wrote:
In article [EMAIL PROTECTED], Alberto Simes/epl
[EMAIL PROTECTED] wrote:
Well.. I didn't rationalize a lot about the Library namespace
because I've done that a long time ago, and nobody answered them.
I have a bunch of
Okay by me.
Tim.
On Wed, Oct 30, 2002 at 04:44:44PM +0100, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Remedy::ARSTools
DSLIP: bdpOp
description: Provides object interface to ARSperl
userid: AHICOX
I'm happy to see an InfoSys:: category alongside WebService::
You could argue that the distinction between the two is based on
an implementation detail that may change for a given service.
In which case we could drop WebService:: and keep the more general
InfoSys:: but I think we could live
Can you post docs, or a url?
Tim.
On Fri, Oct 25, 2002 at 09:10:55AM -0700, chris berning wrote:
Brian,
yes the module goes both ways. It will create
a well formed XML document based on query results.
The module is for importing data from one data(XML)
structure to another(SQL
Automatic:: is not really a good category name for a module or
framework of modules.
And 'trunk' doesn't really describe what it does. Something along the
lines of HTML::HiddenFormData may be better.
Tim.
On Wed, Oct 23, 2002 at 09:42:04AM -0400, Richard F. Rebel wrote:
Hello,
As
The DBI::* namespace is reserved for modules that form part of the DBI.
The DBIx::* namespace is for modules that extend the functionality of the DBI.
So DBIx::SimpleTools would be better, only SimpleTools isn't a
very meaningful module name.
There are many DBI related modules that seem to
On Tue, Oct 22, 2002 at 07:49:52PM -0500, _brian_d_foy wrote:
I'm working on some modules for Freenet (www.freenetproject.org) and would
like to register a namespace. It appears that someone suggested the
Net::Freenet:: namespace a few months ago
On Fri, Sep 20, 2002 at 01:22:53PM -0500, _brian_d_foy wrote:
In article [EMAIL PROTECTED], Mark Veltzer
[EMAIL PROTECTED] wrote:
First Meta is indeed the name of the consulting company that I run but the
name Meta is exactly right for what I need. I wanted a name without any
On Thu, Sep 12, 2002 at 07:11:24PM -0400, brian d foy wrote:
On Fri, 13 Sep 2002, Tim Bunce wrote:
i see your point about Net::*. it's hard to tell how low-level is low
though. :)
:)
WebService::FreeDB
can't that just fit under WWW::* somehow?
I think WWW::* is best kept
Something like a WebService::* category seems to be needed, where
the name of the module is the name of the service.
So I'd suggest WebService::FreeDB.
Tim.
On Mon, Sep 09, 2002 at 05:25:38PM +0200, Henning Mersch wrote:
Hi everyone !
I wrote a perl-module - and think it should be named
The name's not very enlightening, the description line is truncated,
and you've not told us what it actually does different to the
multitude of other logging modules on CPAN (or given URLs).
Tim.
On Thu, Aug 15, 2002 at 01:04:21PM +0200, Perl Authors Upload Server wrote:
The following module
We're trying to keep the XML::* namespace free from applications of XML.
Tim.
On Mon, Aug 12, 2002 at 06:27:02PM +0200, Perl Authors Upload Server wrote:
The next version of the Module List will list the following module:
modid: XML::OCS
DSLIP: cdpOp
description: OCS
On Sat, Aug 03, 2002 at 09:15:21AM +0800, Stas Bekman wrote:
Tim Bunce wrote:
How about Debug::OnFaultTrace, or Debug::AutoFaultTrace?
I think this name describes the best its functionality:
Debug::FaultAutoBackTrace
Okay.
But long names are painful, any preferrable shortcuts
On Fri, Aug 02, 2002 at 05:13:00AM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Debug::SIGSEGVTrace
DSLIP: adhOa
description: Extract A Backtrace on SegFault
userid: STAS (Stas Bekman)
On Fri, Aug 02, 2002 at 07:31:53PM +0800, Stas Bekman wrote:
I think the name shouldn't contain SEGV since that's just one of the
causes of a core. Another fairly common one is a Bus Error.
What signals result in the core dump? BUS SEGV PIPE ABRT? any others?
On FreeBSD:
$ man 2
Now http://introspector.sourceforge.net/
Since it's Interface to the GCC Compiler and the abstract says
The Introspector's scope was originally just the GCC C compiler,
but will be expanded to include the extraction of meta-data from
different compilers and interpreters.
The programs
The name shouldn't include 'Storable' since that's an implementation detail.
Something like IPC::Queue seems more reasonable.
Have you looked at BerkeleyDB's Queue API?:
http://search-beta.cpan.org/author/PMQS/BerkeleyDB-0.19/BerkeleyDB.pod#COMMON_OPTIONS
(scroll back a couple of pages)
Tim.
On Thu, Jul 25, 2002 at 04:42:06PM +0200, Perl Authors Upload Server wrote:
The following module was proposed for inclusion in the Module List:
modid: Petal
DSLIP: bmpOa
description: Perl Template Attribute Language
userid: JHIVER (Jean-Michel Hiver)
On Thu, Jul 25, 2002 at 01:01:59PM -0500, James G Smith wrote:
I'm working on a fairly complex web application framework that
combines AxKit, Template Toolkit, and possibly HTML::Mason, under
mod_perl.
Some of the goals include rapid prototyping of form-driven
applications (looking at
If you don't intend turning into something prolog like then perhaps:
Math::Predicate
Math::PredicateLogic
Otherwise something like Language::Prolog... would be reasonable.
But have you looked at and/or offered to help develop this on?
On Mon, Jul 29, 2002 at 10:50:27AM +0200, Perl Authors Upload Server wrote:
The next version of the Module List will list the following module:
modid: ADT
DSLIP: cdhhp
description: Abstract Data Type top level
userid: ABERGMAN (Arthur Bergman)
chapterid:6
On Tue, Jul 30, 2002 at 06:01:36PM +0300, Jarkko Hietaniemi wrote:
I think Template::Petal will work just fine. XML::Template I do
not like, XML:: is quickly becoming is as information-free as Sys::
Agreed.
Tim.
On Tue, Jul 30, 2002 at 05:03:32PM +0200, Arthur Bergman wrote:
On tisdag, juli 30, 2002, at 04:49 , Tim Bunce wrote:
Isn't very descriptive. What is it?
Tim.
I wrote that in my proposal some time ago
Umm, Google found this for me:
There is a need for a new set of data type
1 - 100 of 227 matches
Mail list logo
