Re: When CPAN shell cannot find a module

[Christopher Hicks]

On Mon, 21 Nov 2005, Ken Williams wrote:
Think about what would happen if Satan uploaded a malicious distribution 
called "PathTools" with a higher version number than mine.  You'd want 
the whole world to get Satan's distribution by default, just so they can 
save a couple keystrokes?


Any ambigious situations such as that could easily be handled by asking 
the user "KWILLIAMS and SATAN both are providing PathTools, which would 
you like?" or having it spit out a list of choices and let the user 
implicitly pick by then doing the "install AUTH/dist...gz" at that point. 
Is there some REAL chance of harm in what we're talking about here that 
couldn't be trivially ameliorated such as here?


My previous suggestion of having an explicit mapping would help avoid 
getting the wrong person's PathTools.  It wouldn't have to track versions 
in the map since "PathTools" could map to KWILLIAMS/PathTools and 
determine the latest from that.  And as I pointed out the issue here isn't 
merely distnames, but common misimpressions.  Being able to "install 
Template::Toolkit" won't cause the universe to blow-up.


Also, "lack of distname support" is overblowing the situation. 
Distnames are supported perfectly fine as long as you put it in the 
proper syntax with author's ID and version.


The proper syntax in this case is unnecessarily complex and utterly 
nonobvious to all but the Perl cognescenti.  That seems a pretty harsh way 
to treat sysadmins stuck with installing Perl-based applications who may 
have no prior Perl experience whatsoever.  If there were some real harm in 
making it easier it might make sense to me, but maybe somebody can share 
with me something that's not a red herring that will help me get it.


--


My aim is to agitate and disturb people. I'm not selling bread, I'm selling
yeast.
   - Miguel de Unamuno, writer and philosopher (1864-1936)

Re: When CPAN shell cannot find a module

[Christopher Hicks]

On Mon, 21 Nov 2005, Chris Dolan wrote:
If CPAN made it easy to install unintended software by mistake, that 
would be a huge security hole.  Some people run cpan as root. 
Defensive programming is absolutely the right thing here.


And how exactly would a shortcut that says "oh you asked for something 
that isn't really a module name, would you like us to install THIS package 
which contains CERTAIN modules anyway?" cause security issues?  I run the 
cpan shell as root all the time.  Its a pain to have to remember the CPAN 
caniptions every time I'm setting up a new random server and the less 
often you deal with it the more likely you will have forgotten it all. 
This is exactly the context where the sort of shortcut that Perl is known 
for should be eximplified but its not.  It may be the individual's first 
exposure to the Perl world.  Let's not make it suck because of weak fears.


PathTools and Template Toolkit are both examples where the thing to type 
into CPAN isn't clear to the newbie sysadmins.  If we had a list of things 
like that for the important modules that have such strangeness then 
there should be any security problem in doing this without prompting since 
those mappings would be official and Known To Be OK.  If I say

install TemplateToolkit
or
install Template::Toolkit
having that map to
install Template
without too much fuss is not only harmless and significantly helpful it 
might even be a security benefit since I won't accidentally install three 
other templating things in the meantime hoping to find the right one.  The 
amount of time saved for sysadmins all over the world without causing 
anyone one iota of actual harm is awe-inspiring.


So, am I really missing something here?  Is there really some chance for a 
harmful mistake being made that can't be trivially mitigated with 
solutions like I mentioned above?


--


There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.

 -- C.A.R. Hoare

Re: When CPAN shell cannot find a module

[Christopher Hicks]

On Sun, 20 Nov 2005, Andreas J. Koenig wrote:
I don't think many people would appreciate getting something installed 
they didn't explicitly ask for.


Hmmm.  I can have extra pain every time I'm installing something to avoid 
occassionally getting something I don't want or I can have pain every 
thousandth time I install something because oopsie I got something extra. 
It doesn't seem like a hard choice to me.  Let's just say your many people 
aren't the same folks as my any people.  ;-)


The lack of distname support due to anal retentive accident avoidance in 
CPAN is utterly odd considering the culture of DWIMery that is so much a 
part of Perl.  I'm not surprised that one person would think this was 
good, but the whole Perl community acquiescing to it is quite a shock.


--


"Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing."  -- Dick Brandon

Physics is like sex. Sure, it may give some practical results, but that's not
why we do it. -- Richard Feynman, physicist and Nobel laureate

Re: Name advice: check license of dependencies

[Christopher Hicks]

On Tue, 1 Nov 2005, Chris Dolan wrote:
Thanks for the feedback Mark and Sam.  I chose Module::License::Report 
and posted my implementation to CPAN this afternoon.


Bravo and thanks.

Further feedback would be VERY welcome, as the module uses a few sketchy 
heuristics to guess at the license.  To mitigate the uncertainty, I made 
it report a confidence number so the user can set a sketchiness 
threshold.  The confidence is just a guess, but it's better than 
nothing.  I'm thinking the next version should use multiple algorithms 
to guess the license and report higher confidence if they all agree.


That sounds even cooler.  Perhaps a flag or a different function names 
could be used to get results as one license with one confidence value or 
multiple licenses per component with each having a seperate confidence. 
Each would have its place.


On a side note, I discovered that using Data::Dumper on my output object 
causes memory use to go through the roof.  I think Data::Dumper is 
chasing into the CPANPLUS data structures and thrashing my machine.  Is 
anyone familiar enough with CPANPLUS internals to know whether 
Data::Dumper problems are well known, or if I've stumbled on some new 
bug?


Data::Dumper is only good for looking at small chunks of stuff.  Its very 
very very inefficient and there have been cases where Data::Dumper failed 
to produce something that could be eval'd back in once upon a time and 
eval'ing the result is inefficient too.  Storable for the win here. 
Storable does everything Data::Dumper does poorly well and oopsy we don't 
care about presenting it visually.  So use Storable for storing. 
Data::Dumper is just for glancing.


--


John Lundin once shaped the electrons thusly:

Ah. Okay, on the "nice to do" list. (Which in practice translates to
"won't do unless it becomes inconvenient or is fixed upstream.")

Re: Perl6 goes where?

[Christopher Hicks]

On Thu, 28 Jul 2005, Philippe 'BooK' Bruhat wrote:

Le jeudi 28 juillet 2005 à 16:32, A. Pagaltzis écrivait:

* Philippe 'BooK' Bruhat <[EMAIL PROTECTED]> [2005-07-28 16:05]:

I thought I heard (or more probably read somewhere) that the
name was 6PAN?


That makes no sense. What is a ???6 Perl Archive Network Okay,
visually, it roughly resembles ???CPAN,??? but I don???t see that as a
good reason to pick a nonsensical initialism???


If found a reference to the name 6PAN here (that was in 2002):
http://www.mail-archive.com/perl6-stdlib@perl.org/msg00135.html

Anyway, isn't "nonsensical" a prerequisite in the Perl world?
Many Perl names started as jokes : Parrot, ponie, CPANTS...


You could have a camel with 6 pans hanging off of him as an icon.  :)

--


"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

[Catalyst] DBIx-Class list, cdbi-talk closure (fwd)

[Christopher Hicks]

This seems like something that the wider world should know about.  For 
those of you that missed it its been a strange few days on the CDBI 
mailing list.


--


"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

-- Forwarded message --
Date: Thu, 28 Jul 2005 17:47:46 +0100
From: Matt S Trout <[EMAIL PROTECTED]>
Reply-To: The elegant MVC web framework <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [Catalyst] DBIx-Class list, cdbi-talk closure

Ok, due to popular demand I've got gabb to set up [EMAIL PROTECTED]
for DBIx-Class discussion (thanks gabb!). I've stopped hacking on it for
a few days while I think through where I want to go with the code, so now
would be the time to make design/feature suggestions!

Also, with the recent unexpected closure of cdbi-talk I (and I guess most of
the other people involved) would be happy to answer Class::DBI questions on
there, at least as a stop-gap measure until a new dedicated cdbi list turns
up.

--
 Matt S Trout   Website: http://www.shadowcatsystems.co.uk
  Technical DirectorE-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.

___
Catalyst mailing list
[EMAIL PROTECTED]
http://lists.rawmode.org/mailman/listinfo/catalyst

Re: Introduction Letter

[Christopher Hicks]

On Sun, 27 Feb 2005, Ofer Nave wrote:
Here's the POD for my new Parallel::Simple module:
NAME
 Parallel::Simple - the simplest way to run code blocks in parallel
SEE ALSO
 Parallel::ForkControl, Parallel::ForkManager, and Parallel::Jobs are
 all similarly themed, and offer different interfaces and advanced fea-
 tures.  I suggest you skim the docs on all three (in addition to mine)
 before choosing the right one for you.  Or you can foolishly trust the
 executive summaries below:
 Parallel::ForkControl
 Only takes one subroutine reference to run, but provides wonderful
 ways to control how many children are forked and keeping activity
 below certain thresholds.  Arguments to the run() method will be
 passed on to the subroutine you specified during construction, so
 there's some run-time flexibility.  It is not yet possible to learn
 anything about what happened to the forked children, such as
 inspecting return or exit values.
 Conclusion: Best for repetitive, looped tasks, such as fetching web
 pages or running a command across a cluster of machines in paral-
 lel.
 Incidentally, Parallel::ForkControl would be far more useful with
 the following two changes:
 o   Support some kind of feedback - return/exit values at a mini-
 mum, or even a single value summary, like the return value of
 my prun method.
 o   Allow the user to specify the Code value in the run method
 instead of during construction.  Then Parallel::ForkControl
 could do everything this module does and more, albeit with a
 more sophisticated interface.
 Parallel::ForkManager
 Unique in the Parallel::* world in that it keeps the user somewhat
 involved in the forking process.  Rather than taking a code refer-
 ence, you call the start() method to fork and test the return value
 to determine whether you are now the parent or child... almost like
 just calling fork yourself.  :)
 Provides control over how many child processes to allow, and blocks
 new forks until some previous children have exited.  Let's child
 determine the process exit value.  Provides a trigger mechanism to
 run callbacks when certain events happen (child start, child exit,
 and start blocking).  You must supply a callback for the child exit
 event to inspect the exit value of the child.
 Conclusion: While also designed for repetitive, looped tasks, it is
 far more flexible, being a thin wrapper around fork rather than
 taking over child creation and management entirely.  Useful mostly
 if you want to limit child processes to a certain number at a time
 and/or if the native system calls scare you.
 Parallel::Jobs
 Different in that it executes shell commands as opposed to subrou-
 tines or code blocks.  Provides all the features of the open3 func-
 tion, including explicit control over STDIN, STDOUT, and STDERR on
 all 'jobs'.  Lets you monitor jobs for output and exit events (with
 associated details for each event).
 Conclusion: Great for shell commands!  Not great for not shell com-
 mands.
This is a phenomenal initial cut of a POD.  The review of relevant other 
modules in SEE ALSO and the philisophical differences with each deserves 
particular note.  Bravo.

--

"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Re: Introduction Letter

[Christopher Hicks]

On Mon, 28 Feb 2005, Torsten Schoenfeld wrote:
 http://lists.netthink.co.uk/listinfo/code-review-ladder
That box was having hardware problems last week.  The maypole lists were 
on the box (now they're on SrcFrg), so maybe this has moved somewhere else 
too.

--

"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Re: CPAN cruft cleanup?

[Christopher Hicks]

On Wed, 23 Feb 2005, Johan Vromans wrote:
   But from what I hear, I'm on my own --
Not completely.
The cpancd[1] package has the functionality in it to find out the latest
version of a series of versions. Although the package is obsolete
(CPAN won't fit on a CD anymore), this function could be useful.
But CPAN might fit on a couple of CD's or a DVD.
--

"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Re: Subclassing a mailer

[Christopher Hicks]

On Sun, 16 Jan 2005, A. Pagaltzis wrote:
* Sam Holden <[EMAIL PROTECTED]> [2005-01-15 17:09]:
Only inherit when you have an ISA relationship.
I just want to chime in to agree.
Inheritance is greatly overrated and widely abused. It is almost
always the very last option you should consider. Aggregation is
way underrated and should be used much more often.
Do you have any evidence of this?  I can guess that this may be the result 
of bulk of OOP education emphasizing inheritence so people presume that 
its the best way when its merely one choice.  Given the complexities of 
inheritence it does require more educational space than aggregation.  But 
I haven't seen the wide abuse you speak of.  In my sphere of influence I 
have to hammer home the importance of semantics in OOP design and I've had 
to dissuade a few eager souls from inheriting where there's isn't an ISA, 
but in reviewing other folk's OOP code I would say that a total lack of 
design sense or standards is much more rampant than inheriting where it 
doesn't make sense.  Since this is a list closely related to CPAN I'm 
particularly curious if there are examples where published modules are 
breaking this rule.

--

"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Re: What name for a printer status supplies module?

[Christopher Hicks]

On Sat, 18 Dec 2004, Terrence Brannon wrote:
David Landgren <[EMAIL PROTECTED]> writes:
The fact that it uses http is incidental. If HP bothered to supply a
half-decent MIB, SNMP would be a good alternative.
What does "MIB" stand for?
Men In Black.  ;)
Oh, you mean the geek version...  MIB stands for Management Information 
Base and encapsualtes an API within an SNMP context for a given type of 
device.  Various RFC's have described this through various versions of 
SNMP: http://www.drunkandretired.com/snmp/ has some good links.

--

"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

RE: DBIx::DBH - Perl extension for simplifying database connectio ns

[Christopher Hicks]

On Tue, 7 Dec 2004, Orton, Yves wrote:
I was given the Henrik or some other hypothetical respondant the benefit 
of the doubt.
I figured that out by the end of reading your email.
:-)
:-]
I thought it was clear I think that this is both doable and worth doing.
Yes yes.  I didn't think there was much disagreement.
--

"Fans of Mozilla's free, open-source Firefox browser make the
ardent Apple faithful look like a bunch of slackers."
- Rebecca Lieb at clickz.com

RE: DBIx::DBH - Perl extension for simplifying database connectio ns

[Christopher Hicks]

On Tue, 7 Dec 2004, Orton, Yves wrote:
To: 'Henrik Tougaard' <[EMAIL PROTECTED]>,
'Martyn J. Pearce' <[EMAIL PROTECTED]>, Tim Bunce <[EMAIL PROTECTED]>
Cc: Sam Vilain <[EMAIL PROTECTED]>, Ken Williams <[EMAIL PROTECTED]>,
Terrence Brannon <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Sheesh.  If you're getting twelves copies of this because you're on both 
mailing lists, getting cc'd and impesonating some of the other cc'ers or 
something I'm sorry.  :)

 DBD::Oracle appears to be closer to Sybase/MySQl: 
"dbi:Oracle:host=myhost.com;sid=ORCL"

It doesn't seem like a stretch of the imagination to see the common fields
"host" and "db" embedded in all three.
Sure.  The basics are pretty universal I suspect despite some 
protestations to the contrary.  Things like Oracle's SID should be able to 
fit in the architecture without bothering the rest of the world which 
doesn't use that.

The fact still remains that the generic "Host" slot could be used for 
this purpose quite easily, as could the "DB" slot.
I really really object to the DB slot being called DB.  Oracle's term 
"tablespace" is much less overused and confusing than database.

Those parameter that make no sense could either be ignored, or somehow 
usefully overloaded.
Absolutely.
This would enable the establishment of a baseline set of connection 
details that all DBD drivers should know how to more or less deal with. 
At bare minimum this would mean one less trivial piece of knowledge to 
remember when working with multiple providers.
Precisely.  Why I do care to memorize twelves DSN creation styles.  Bah.
Coming up with common set of parameters that most DB's are going to 
require and then providing standardized names for them would seem to be 
useful in general. So far I havent seen anyone provide something that a 
given driver Has To Have that doesn't fit into the proposal. (Ie, 
Host,DB,Port). Which _mandatory_ parameter does Informix need that can't 
be shoehorned into one of those?
What does it matter?  Why can't we allow for "extra" bits like SID's 
without breaking the core "global" values?

--

"Fans of Mozilla's free, open-source Firefox browser make the
ardent Apple faithful look like a bunch of slackers."
- Rebecca Lieb at clickz.com

RE: DBIx::DBH - Perl extension for simplifying database connectio ns

[Christopher Hicks]

On Tue, 7 Dec 2004, Henrik Tougaard wrote:
Maybe the number of responses on this thread come from people who
have this itch to scratch.
Huh?  I've only been seeing what got cross-posted on this to 
module-authors until today, but I just subscribed to dbi-usres
n
I have heard Tim Bunce (DBI, DBD::Oracle etc) and Jonathan Leffler 
(DBD::Informix) raise 'Beware, thing are much more complex than you 
think' warnings.
Yeah.
I (DBD::Ingres) have'nt pitched in as Jonathan voiced my concerns quite 
precisely, saying: Beware - DBMS are more different than anyone would 
like. That's why DBI has the scheme it does have - it is flexible but 
not easily codified.
Even if its not easy a solution for migrating DSN creation out of code and 
into a config file would be very worthwhile.

Ingres, like Informix and (I think) Oracle, does'nt have the concept
of 'host' or 'port', using other ways of adressing remote databases.
Given that for most folks the support is needed for the FOSS databases 
ignoring the strange proprietary ways would be better than not having 
DSN's externalized.

It seems to me that you are trying to force an extension onto the DBI 
based on what a small number of RDBMSs accept.
When that small number just happens to be "all the FOSS databases" its a 
large enough small number.

The people who want this seem to use only a few DBDs - perhaps it could 
be added to those?
Maybe.
Personally I'd like to see a solution based on AppConfig.  We have our 
database configs in AppConfig.  The config files look something like:

[global]
connpriority=dot,skippy,marita
dbd=mysql
tablespace=finilever
user=blah
pass=blah
[dot]
host=dot.fini.net
[skippy]
host=skippy.fini.net
user=override
pass=override
[marita]
host=marita.fini.net
dbd=pg
I don't care about Oracle or any of the rest.  Making this work with PG 
and MySQL will solve 90% of the world's problems.  I don't see why it 
couldn't be extended to include whatever parameters where necessary for 
any of the proprietary databases, but if not could somebody explain how?

--

"Fans of Mozilla's free, open-source Firefox browser make the
ardent Apple faithful look like a bunch of slackers."
- Rebecca Lieb at clickz.com

Re: Getopt::Helpful - online help and options

[Christopher Hicks]

On Mon, 15 Nov 2004, khemir nadim wrote:
Chris, Could you please give some info on this. I must say your answer
perplexed me and I don't understand what you mean.
AppConfig has the ability to read configuration from the program, external 
.ini-style files, and the command line in a mostly uniform fashion.  If 
you use it in a "use strict" sort of way you define all of the variables 
and it whines if any are missing.  It allows types to be defined in 
classical getopt style or programatically.  If you wanted to do a database 
lookup to verify a valid command line paramater it "could" be done.  This 
is all very handy IMHO.  We passed this paradigm along to one of my 
clients, the National Weather Service.  One of their staff coders/weather 
doods (Mark Fenbers, cool guy) said "hey, why can't we print usage 
statements" based off what AppConfig was being told.  Given how many 
options some of their scripts have and new ones being added regularly it 
was a hassle to maintain the usage output in coordination with the options 
spec'd and implemented for AppConfig.  So I've been working on contacting 
Andy Lester to see if he'd approve of such a change, but Andy's apparently 
really slammed so the conversation hasn't made it too far yet.

Makes sense now?  :)
--

The whole problem with the world is that fools and fanatics are always so
certain of themselves, and wiser people so full of doubts. -Bertrand
Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)

Re: Getopt::Helpful - online help and options

[Christopher Hicks]

On Fri, 12 Nov 2004, khemir nadim wrote:
Hi, I haven't tested your code (will do this week-end) and I think it's a
good idea.
Ya ya.  We've been talking about extending AppConfig to do something 
similar for a while, but no progress yet.

--

The whole problem with the world is that fools and fanatics are always so
certain of themselves, and wiser people so full of doubts. -Bertrand
Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)

Re: CPAN question

[Christopher Hicks]

On Wed, 10 Nov 2004, Sean Quinlan wrote:
How do we mark uploads as a dev release? Can it be done after it's 
uploaded or is it something in the release before upload that indicates 
it (I browsed YAML .49_01 and didn't see anything)?
The underscore in the filename is the flag.  (Its right there man!  :) )
--

The whole problem with the world is that fools and fanatics are always so
certain of themselves, and wiser people so full of doubts. -Bertrand
Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)

Re: MySQL::Backup?

[Christopher Hicks]

On Thu, 28 Oct 2004, Tim Bunce wrote:
Um, a DBA namespace sounds reasonable as a home for cross-database
DBA support modules. I'd recommend a structure like this:
 DBA::   -- front-end module
 DBA*-- support modules
 DBAPlugin::   -- back-end modules
Sounds good.
But...
And there's always a "but" isn't there?
I'd caution that the "market" for DBA-type APIs that'll work
across multiple DBs is small.
There are so many people using Perl and/or DBI to do these things now that 
I suspect a lot of people would appreciate a standardized solution that 
they don't have to maintain themselves.

Partly because not many people have significant investment in more than 
one database of a similar type, but mostly because the lack of 
standardization of DBA concepts across databases.
Maybe so, but as a developer I have to support dbm, MySQL, PostgreSQL, 
Oracle, and Informix.  (I've got customers on MS-SQL too, but I make sure 
I'm not dealing with it.)  Anyway, having a generic backup solution, query 
performance analysis, load/unload framework would be phenomenal. 
Particularly across SQL databases their is a tremendous potential for 
standardization.  The database vendors have worked for years to 
"differentiate" themselves, but it won't take as many years to brush over 
the differences as it took them to put them in.  Take something that's 
very database-specific: fragmentation.  We can measure fragmentation in N 
different ways for N different databases and the values may or may not be 
comparable, but the "defragment" method could be generic (dump and 
restore) or not.

You'll either end up with a lowest-common-denominator approach that has 
too little functionality, or have so many database-specific flags an 
options and whatnot that there's little benefit in having a "common 
API".
I don't see that.  Take backups as our current example: there's a concept 
that can be implemented in a "lowest-common-denominator" way that's still 
useful and handy.  Giving folks platform-specific options may mean that 
some local versions end up being somewhat complex, but that would still be 
a shorter putt than gen'ing up a custom solution every time.

Alzabo does a lot of cross-database translation now and they are able to 
do it without getting weighed down by rarely used switches.

Having said that, I'd be happy to see this happen if it did :)
Ya ya!
--

There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: MySQL::Backup?

[Christopher Hicks]

On Tue, 26 Oct 2004, _brian_d_foy wrote:
In article <[EMAIL PROTECTED]>, Smylers
<[EMAIL PROTECTED]> wrote:
I think the opposite -- that DBIx:: should be for things that are
generally usable with DBI, where the "I" is independent.  Things such as
backing up tend not to be database-independent.
if we work it right, DBIx::Backup could be independent, while
DBIx::Backup::MySQL implements the MySQL bits. :)
Exactly.  If DBIx::Backup::MySQL has a clean interface it might even 
inspire a generic DBIx::Backup and become the MySQL implementation of 
DBIx::Backup and spark a revolution in database administration.  :)

--

There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: MySQL::Backup?

[Christopher Hicks]

On Tue, 26 Oct 2004, Smylers wrote:
Christopher Hicks writes:
On Tue, 26 Oct 2004, Smylers wrote:
... DBIx:: should be for things that are generally usable with DBI,
where the "I" is independent ...
I agree with Chris much more than Smylers here, but if we go along
with Smylers perspective for a minute then we need /some/ hierarchy
for "database-related things that aren't avertising they're using DBI
for some reason".
Why?
So that database-related things are kept together.
There are several top-level namespaces on Cpan that are simply the names 
of some external software that the modules in that namespace work with.
We have that for Oracle and Sybase, but does that make it easier on people 
trying to find related things?  If something is database related and based 
on DBI I'd like to see it in DBIx.  If its something that is database 
related and its based on some other interface it should be in "Database::" 
or "SQL::"

In particular, there are already many in the MySQL:: namespace:
 http://search.cpan.org/search?m=module&q=MySQL&s=1&n=20
Precedent means a lot more in a court of law than it should elsewhere.
It may not be a perfect namespace, but it certainly isn't terrible, it's 
unambiguous, and surely it's better to keep on using it for similar 
'MySQL'-related modules than to put new ones elsewhere (or persuade all 
the existing ones to move)?
I don't think we can persuade all of the existing ones to move, but if we 
had a general agreement that database related modules should be in a 
handful of namespaces it would seem to be advantageous.  I'd love to see 
see Alzabo. MySQL::Backup, and the other DBI-based modules with strange 
names paces all go in DBIx while the other things (oraperl, postgres, 
etc.) go into Database::.  We have Spreadsheet:: to take care of 
spreadsheets.

The more I think about it DBIx would seem to be the winning place for
this sort of thing.
When I read Mark's message I realized his point is what I'd been wanting
to say in the first place; so the more _I_ think about it, the more
DBIx:: seems like a completely inappropriate place for this module!
How is doing a database backup any less of a DBI extension than DBIx::Copy 
or DBIx::HTMLView?

--

There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: MySQL::Backup?

[Christopher Hicks]

On Tue, 26 Oct 2004, Smylers wrote:
Chris Dolan writes:
Assuming it is based on DBI at its core, your module would fit better
in the DBI extension area.  I think DBIx::Backup::MySQL would be good,
as it would leave room for expansions to databases other than ::MySQL.
I think the opposite -- that DBIx:: should be for things that are
generally usable with DBI, where the "I" is independent.  Things such as
backing up tend not to be database-independent.
I agree with Chris much more than Smylers here, but if we go along with 
Smylers perspective for a minute then we need /some/ hierarchy for 
"database-related things that aren't avertising they're using DBI for some 
reason".  The more I think about it DBIx would seem to be the winning 
place for this sort of thing.

--

There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: [rfc] File::Corruption

[Christopher Hicks]

On Mon, 18 Oct 2004, Lincoln A. Baxter wrote:
Ok, how about File::SATA::Integrity
His motivation was SATA, but the resulting solution isn't SATA specific.
--

"Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing."  -- Dick Brandon

Re: [rfc] File::Corruption

[Christopher Hicks]

On Sun, 17 Oct 2004, Joshua Hoblitt wrote:
is the namespace appropriate?
I'd rather see it called something like "File::DetectCorruption" or 
something that makes it clear that your module isn't here to corrupt 
files.

Otherwise:
You've provided good documenation.  That's wonderful and above average for 
a first release.

I've had good luck with SATA, but I don't use RAID controllers since I'd 
rather put the money into more drives and let Linux do the RAID.  My 
desktop box is an Opteron/SATA/Linux/LVM box with Linux doing RAID1 across 
two drives and its absolutely fabulous.  :)

--

"Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing."  -- Dick Brandon

Re: looking for Andy Wardley, AppConfig maintainer

[Christopher Hicks]

On Sat, 18 Sep 2004, Mark Stosberg wrote:
I would go ahead and write the patches and publish them in the bug 
system for AppConfig: http://rt.cpan.org/NoAuth/Bugs.html?Dist=AppConfig 
Until the author pipes up, other people could find the patch there and 
use it and/or comment on it.
That's a sensible plan.  I was hoping to have some consent before digging 
in, but if its not forthcoming I shouldn't let it deter progress.

--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

DBIx::Series?

[Christopher Hicks]

I've got a module that maintains ordered lists in a database.  My 
tentative name for this is DBIx::Series.  Does that convey any of what I'm 
hoping it does?  Does anyone have a better name suggestion?

To give a fuller example of what this module solves.  Imagine you have a 
table:

+---+
| seriesid| orderkey  | randomdata  |
+---+
| 1   | 1 | randomdata  |
| 1   | 2 | randomdata  |
| 1   | 3 | randomdata  |
| 1   | 4 | randomdata  |
| 2   | 1 | randomdata  |
| 2   | 2 | randomdata  |
| 3   | 1 | randomdata  |
| 3   | 2 | randomdata  |
| 3   | 3 | randomdata  |
| 3   | 4 | randomdata  |
| 3   | 5 | randomdata  |
+---+
So there are three ordered sets in there.  Seriesid defines what a set is. 
The primary key is defined by seriesid,orderkey.  My module allows you to 
take a table like that and remove and reorder the individual sets.

--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

looking for Andy Wardley, AppConfig maintainer

[Christopher Hicks]

I've found a couple of bugs in AppConfig and I've tried contacting the 
author Andy Wardley at [EMAIL PROTECTED] and [EMAIL PROTECTED] for the last 
several months with no luck.  If you know Andy can you poke him and get 
him to send me an email?

I'm proud to say that I've gotten several programmers inside the National 
Weather Service heavily using AppConfig.  They've come up with a small 
list of inconsistancies and possible bugs and a few missing features. 
Having looked at the AppConfig source code I'm reasonably confidant that I 
can make the changes cleanly, but it would seem to be smarter to get some 
consent from the on-record maintainer before going to the trouble of 
writing patches.

Beyond the short list of fixes I'm personally interested in I noticed in 
my research that AppConfig is lacking a Phalanx liason (or whatever the 
designated QA person should be) so I was going to see if Andy was 
interested in me doing that too.

But I haven't gotten any response from him.
--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: Let's eliminate the Module List

[Christopher Hicks]

On Tue, 24 Aug 2004, Simon Cozens wrote:
Repeat after me: browsing is just searching metadata.
For our current purposes I'm willing to go along with that.  Once the 
metadata exists people can do whatever they want with it.  I strongly 
suspect that one of those things will be making something that is vaguely 
yahooish.

This brings to mind an interesting question - shouldn't there be some 
central file of meta data that's automatically generated?  Maybe in 
Storable and XML?  That way people that want to experiment don't have to 
have a full CPAN mirror or dig data out of all of the tar files.

--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: Let's eliminate the Module List

[Christopher Hicks]

On Tue, 24 Aug 2004, Simon Cozens wrote:
I still think sourceforge-like hierchical catagories (Topics) in META.yml
would make for good light-weight search and improved by-catagory browsing
I disagree quite violently with this, but I'm not going to implement 
searching and indexing in a way that precludes it. I think that the 
world moved from browse to search some time in the mid 90s (hell, we're 
even being encouraged to search rather than browse email these days) and 
that this is because browsing is useful if your search engine isn't good 
enough.
Browsing and searching each have their place.  It is conceivable that a 
powerful enough search could emulate browsing.  Consider how much 
discussion has been generated by talk of removing a browse-oriented 
document like the module list.  Some people and activities are more fond 
of browsing than searching.  It may only be 10% of the cases where 
browsing works better than searching, but if I want to answer the question 
- "what are all of the perl web applications" it would take lots of 
searches and result munging to find out what a painless browse could 
produce.  A hierarchical system that people can add into META.yml 
supplemented by an effort to fill in the gaps left by maintainers not 
motivated to fix their META.yml would be a wonderful thing.

--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

RE: Let's eliminate the Module List

[Christopher Hicks]

On Thu, 19 Aug 2004, Hugh S. Myers wrote:
It seems to me that ANY thing that contributes to the solution set of 
'How do I find the module I'm looking for?' needs to be kept until it 
can be replaced with something of equal or greater value.
search.cpan.org seems to be of greater value than the modules list 
according to most of the people that have chimed in.

2. Push hard on the notion of adding a keywords item to the 'standard' 
for pod documentation.
What should those keywords be?  Who decides?  I'm personally much more 
interested in seeing a dmoz-ish hierarchy so related modules can be easily 
found and compared.

--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: Let's eliminate the Module List

[Christopher Hicks]

On Wed, 18 Aug 2004, Randy W. Sims wrote:
I made a suggestion regarding this before that I thought provided a fair 
solution , but 
no one commented. Basically, upon submission of a new module, a notice 
would be auto-posted to some list. If no one replies to that posting 
within some time frame, the module is automatically accepted. If anyone 
does reply, then it requires moderator approval. The moderator(s) isn't 
required to do anything other than monitor the discussion and act 
according to the concesus reached in the discussion. The list members do 
what is currently done on a voluntary basis on module-authors; that is, 
they make name suggestions, discuss prior art, etc.
That sounds good to me!  Are you volunteering to implement it too?  :)
--

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

Re: module name for Wily (a text editor) interface client?

[Christopher Hicks]

On Tue, 3 Aug 2004, Sam Holden wrote:
I would argue that Wily is just as much a way of life as Emacs and Vi.
No doubt.
However, it certainly isn't anywhere near as popular - chances are 
you've never heard of it...
I heard of it when I went to see what the heck a module called "Wily" was 
all about actually.  I did this only a few days ago, but before this 
thread started.

It doesn't warrant a toplevel namespace all to itself - though of course 
my current code uses one :)
You're hardly the only CPANer guilty of this.
There are two Wily modules in existance at the moment (that I know of), 
but they do the same thing - one uses XS to link with the wily libs, 
whereas mine uses pack/unpack to decode the messages itself. But yes, 
there's much less scope for multiple modules (due to the fact that the 
intersection of wily users and perl programmers is small...)
How about TextEditor::WilyPP.  Is PP recognized as pure perl widely 
enough?  If the XS-based module owner could be convinced to switch to 
TextEditor::Wily you'd really be starting a trend.

--

Re: module name for Wily (a text editor) interface client?

[Christopher Hicks]

On Mon, 2 Aug 2004, Smylers wrote:
Christopher Hicks writes:
I would think the existing examples might provide some light on this
but the modules to interface to emacs seem to be in their own Emacs::
space and the vi-related modules seem to be in Vi::.  I'm not sure
what the received wisdom is for the "right way" to do this would be,
but the option based on precedents could only be Wily::.
But 'Vi' and 'Emacs' are arguable more a Way of Life than a mere editor
-- also they are so widely known by many people (especially those with a
Unix background) that there isn't much chance of confusion or ambiguity
with their names.
Plus I can see that there's more of a chance for multiple Emacs and Vi 
related modules than Wily-related ones.

That possibly doesn't apply to 'Wily'.  Or, more to the point, it 
certainly doesn't apply to every possible application that anybody could 
ever want to create a Perl interface to.
Agreed.
There are some 'Excel'-related modules in the Spreadsheet:: namespace.
I think creating an Editor:: namespace for 'Wily' would be reasonable.
I'd rather see TextEdit:: or TextEditor:: than the somewhat ambiguous 
Editor::, but I'd be happy to see a new name space for these sorts of 
things.

--

Re: Ratings and Reviews ne Modules

[Christopher Hicks]

On Sun, 1 Aug 2004, Eric Wilhelm wrote:
If ratings are used to compare modules (as opposed to
judging each according to its merrits), some modules might be
overlooked, especially new modules.
True, and the "popularity metric" that I was proposing would probably only
worsen the situation.
One of the "good ideas" in this thread to me was the application of them 
to search.  I agree that new unreviewed modules might be hurt by this, but 
if the search order let both the review rating and the "recentness" 
influence its order people would tend to be directed to the right place 
sooner.

Seems that a popularity metric and ratings would just help highlight 
this module.
As much as helping you highlight the right module it would hopefully let 
you steer clear of the poorly documented unmaintained module as well.

--

Re: module name for Wily (a text editor) interface client?

[Christopher Hicks]

On Mon, 2 Aug 2004, Sam Holden wrote:
Namespace wise, Text::Wily was suggested on comp.lang.perl.modules, but 
the module itself has almost nothing to do with text - it interfaces to 
a text editor which I think is a very different thing.
I would think the existing examples might provide some light on this but 
the modules to interface to emacs seem to be in their own Emacs:: space 
and the vi-related modules seem to be in Vi::.  I'm not sure what the 
received wisdom is for the "right way" to do this would be, but the option 
based on precedents could only be Wily::.

Text:: may seem inappropriate in one sense, but in any classification 
system you're going to have things that "almost fit" one place, but don't 
fit anywhere else at all.  Going with the "almost fit" is often the right 
choice rather than trying to create perfect categories for everything. 
The worst case for not going with "almost fit" is that you end up with /n/ 
objects in /n/ categories eventually and there's no point in the 
categories anymore.

Speaking of categories, why do we have a "Commercial Software Interfaces", 
but not a "Noncommercial Software Interfaces"?  Is that intentional?

--

Re: Renaming module - Algorithm::SkipList

[Christopher Hicks]

On Sat, 31 Jul 2004, Eric Wilhelm wrote:
Data:: does not seem to be the right place -- it seems to be
about data formats more than data structures.
What about Data::Dumper Data::Iter Data::Match Data::Grouper ? IMO, the 
stuff about formats is in the wrong place s/Data::(Encrypted)/Text::$1/ 
And, maybe we should also s/Data::(Iter)/List::$1/.
Data:: seems like a good place for data structure things that aren't 
inherently lists, hashes, other "standard CS" things, or that cover 
several of those.

Really, IMHO the tree modules and yours and probably others more
should be in some sort of Datastructure:: namespace.
Whoa!  That is way too long.
So, what if List::SkipList becomes Data::SkipList or even
Data::List::SkipList?
That'd be foolish.  The common data types are used so often and widely 
they deserve their own top level names like List:: and Tree::.

Well, I might want to create a tied implementation of it.  Would that be 
named Tie::List::Skiplist, or Tie::Data::List::SkipList ?  Seems that if 
we buy the first one, that List:: should be a toplevel namespace.
Ya.
"The genius of you Americans is that you never make clear-cut
stupid moves, only complicated stupid moves which make us
wonder at the possibility that there may be something to them
which we are missing."
   --Gamal Abdel Nasser
That's great.
--

Re: Ratings and Reviews ne Modules

[Christopher Hicks]

On Fri, 23 Jul 2004, Gabor Szabo wrote:
Do we really need reviews ?
Short of some better sort of solution for helping guide people to the 
better choices of modules.

I am afraid not many people will take the time to do a deep analyzis of 
a module.
It doesn't take many people to provide a statistically large enough sample 
to be useful in helping perl newbies avoid the modules that somebody 
cooked up five years ago and hasn't updated since.

What about a web based discussion board that is module specific ? Easy 
to search, categorized by modules, easy to post - no need to subscribe 
to a zillion mailing lists.
That'd be useful.  A lot of modules might form little communities to save 
them from author neglect if they could find each other.  So many modules 
have no mailing list and the author never responds.  Now I don't blame the 
author for not responding, but without some central place for people to 
congregate and trade patches thing die on the vine that wouldn't have to.

--

Re: Ratings and Reviews ne Modules

[Christopher Hicks]

On Thu, 22 Jul 2004, Eric Wilhelm wrote:
Okay, but we have requirements for both search.cpan.org and
cpanratings.perl.org, right?
Yes.  cpanratings could display more in depth statistics of the various 
modules and also allow for being to view a module as a whole and not just 
one particular verson of a module.

search.cpan.org is the front-end to most module-searching, and I think 
it should stay that way, but should have more visible (read: not so 
deep) links to ratings/reviews and show the "star-bar" in more places.
For instance it would be nice to be able to sort search results by 
ratings.  Or it'd be nice if that were factored in somehow when doing 
search.  Maybe this would iron out the "greatest module since sliced bread 
that people who don't know the secret handshake have never heard about" 
problem.

If these sites have separate maintainers, we should be working on two 
requirements lists.
Some requirements would seem to be related.  For instance, cpanrating may 
need to provide a convenient way to get data that would the be utilized on 
search.cpan.org to make the impact less painful.  Maybe some sort of local 
ratings cache would need to be maintained?

--

Re: getting rid of some unmaintained modules

[Christopher Hicks]

On Fri, 7 May 2004, Mark Stosberg wrote:
> I believe even if you delete them all from your directory, everything
> ever uploaded is still available on 'backpan':

It may still be available, but it's still much less likely that a random 
Perl programmer will dig something out of backpan as compared to finding 
it on every CPAN site in the world.  We can't prohibit people from 
shooting themselves in the foot, but we may be able to avoid dealing with 
a few less shot off feet.

-- 


No, no, you're not thinking, you're just being logical.
-Niels Bohr, physicist (1885-1962)

Re: Submitting a new module? (Linux::ForkControl)

[Christopher Hicks]

On Thu, 13 Nov 2003, Brad Lhotsky wrote:
> Maybe is should live under Parallel::Fork::Control::* ?

How about Parallel::EasyForks or Parallel::ForkEasy?  ;)

-- 


   If you're not part of the solution, you're part of the precipitate.
 - Steven Wright

Re: [Module::Build] Re: How to indicate a dependency in my module

[Christopher Hicks]

On Wed, 12 Nov 2003, Sam Vilain wrote:
> On Tue, 11 Nov 2003 02:29, Michael G Schwern wrote;
> 
>   > YAML was chosen because its human readable and writable, its data
> ^  ^
> So long as you're a FREAK who likes INDENTING and WHITESPACE to
> signify STRUCTURE.
> 
> Is it any surprise that YAML is supported by PYTHON?!
> 
> 

Considering the number of ugly languages that have been spawned from or
inspired by Perl, YAML may turn out to be one of the most respectable in
the long run.  At least it's not procedural like the other ugly children -
PHP and Python.

-- 


"X Windows is to memory as Ronald Reagan was to money."
   -- Unix-Haters Handbook

Re: [Module::Build] Re: How to indicate a dependency in my module

[Christopher Hicks]

On Wed, 12 Nov 2003 [EMAIL PROTECTED] wrote:
> So, if I understand this correctly, you're worried about the build
> process eval'ing the contents of a file I sent you.  Hmm.
> 
> OK, why is that anymore of a concern for eval'ing the perl module I
> also distributed, too?  Isn't that just as big a security hole?  

There are any number of reasons I may be interested in examining your
module for extracting documentation and dependancies without actually
running a single line of your code.  The safer we make this sort of thing
the more things like search.cpan.org and various more recent alternatives
we'll have.

-- 


> What the US needs is a Manhattan Project for alternative energy to oil.
They should threaten their enemies with windmills?
- BabyDave on /.

[OT] chicksoprocity (was Re: module to access w3c validator)

[Christopher Hicks]

On Wed, 29 Oct 2003, Jim Cromie wrote:
> OT - Chris, does your email address get you black-holed a lot ?

Not really.  It does raise eyebrows though.  One client had a female
staffer that felt sexually harassed by needing to use that e-mail address
for tech support questions.  [sigh.]  But that inspired me to finally put 
a site up at my domain again to lampoon all those who just haven't gotten
it.  http://www.chicks.net/

> with the amount of porn-spam these days, and not-quite-there 
> filter-tools (mozilla anyway)
> Ive had to de-junk legit email periodically.

Since this is a Perl mailing list, a plug for MailScanner ( 
http://www.mailscanner.info/ ) seems in order.  It's helped us eliminate 
e-mail viruses and does wonderful spam tagging with the integration of 
RBL's, SpamAssassin, virus scanners, and it's own rule sets to manage it 
all.  Very good stuff.

-- 


No, no, you're not thinking, you're just being logical.
-Niels Bohr, physicist (1885-1962)

RE: module to access w3c validator

[Christopher Hicks]

On Wed, 29 Oct 2003, [EMAIL PROTECTED] wrote:
> Fair points except in this case you wouldn't be doing your clients any
> favours by making their production servers depend on a webservice that has
> no specified interface and no promises about availability.

The whole point of my scenario was that I might need this thing "real
quick" to fix a problem I'm seeing.  How many people need long-term
reliable access to an HTML validator?  Those that need that sort of thing
installed it all long ago, right?  Otherwise, it's just some Perl guy 
trying to make a buck and trying to debug something on some unfamiliar
system.

-- 


No, no, you're not thinking, you're just being logical.
-Niels Bohr, physicist (1885-1962)

RE: module to access w3c validator

[Christopher Hicks]

On Wed, 29 Oct 2003, [EMAIL PROTECTED] wrote:
> If you can get the source then why would you want to do anything using
> SOAP?

Even if I can get the source that doesn't mean it's easy to install.

> If the source has a free enough license you could turn it into a module
> and that's that, if not then just run it locally as a command and
> capture the output. Either of these would be much more reliable than
> remotely calling the w3c's scripts, you wouldn't need to be connected to
> use it and you won't be pounding on the w3c's servers,

All of this presumes that the effort required to install the validator
locally is near zero.  I just went out to look and it honestly doesn't
look too hard to make work, but neither did their css validator which I
gave up on getting installed locally because of fighting with all of the
Java garbage.  YMMV.

Even if the HTML validator is easy to get going that doesn't mean that it
still isn't often easier to not install it.  Honestly I could see using
this module when working on things at remote sites.  It'd certainly be
easier to get the original poster's module installed than trying to figure
out whether OpenSP compiles on HP-UX or wait a month for my client to
approve adding software to their production linux system.  When working
with a few TLA US goverment agencies the "mean time from begging to
getting actual software installed" is about ten months.

To whomever chose to lampoon the original proposal by your "make it a SOAP
service" message, shame on you.  I understand where you're coming from,
but on an international mailing list where a lot of people aren't native
or fluent English speakers, the humor gets lost in the translation.  
Beyond that, what ever happened to the spirit of TIMTOWTDI?  What happened
to "correct Perl is any Perl that gets the job done before you get fired"?  
People coming to this mailing list with earnest questions deserve honest
answers, not harassment.

-- 


"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Re: Another sticky module naming issue

[Christopher Hicks]

On Fri, 22 Aug 2003, Johan Vromans wrote:

> Isn't it rather premature to start asking everyone to provide META.yaml
> files while the file format and contents are still under development?

Most of the people on this list would presumably be able to keep up with 
the evolution, no?  And if we don't play with it more there won't be any 
evolution to worry about.  :)

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: Another sticky module naming issue

[Christopher Hicks]

On Thu, 21 Aug 2003, darren chamberlain wrote:
> It seems to me that part of the problem is that modules don't contain
> enough metadata.  This is starting to change, with META.yaml support
> being added to the CPAN indexer, but there is still not enough.

Does anybody have a list of modules that are currently being updated that 
don't contain META.yaml files?  My local CPAN mirror is offline because of 
"disk issues" at the moment so I couldn't even check this myself if I had 
time.  :)

> I think it would be interesting for someone to set up a site where
> people can add and edit module metadata.  So, for example, when someone
> discovers a module they'd never heard of that does something neat, they
> can add the metadata that would have helped them find the module in the
> first place.

Yes, yes, yes.  Do it and I will contribute!

> For bonus points, make this metadata exportable as YAML so that it could
> be searched locally.  Perhaps this metadata file could be updated daily
> and distributed via CPAN or SourceForge.  Users could use CPAN::Metadata
> (or whatever) to search the metadata.

That's brilliant.  Who's going to do it?!!?!?

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: Another sticky module naming issue

[Christopher Hicks]

On Thu, 21 Aug 2003, Nicholas Clark wrote:
> The first solution that sprang into my mind was a "CPAN cookbook" but
> who wants to write that?  Presumably there are better solutions.

It doesn't have to be a book necessarily.  A "CPAN Pilot" in some tiki
with a dedicated group of Perlers would help.  If enough people rate their
favorite modules it would be a good starting indication of what's worth
including and not.  (Not that popularity should be the only consideration,
but it would be a better first pass than nothing.)  I've never taught a
class to experienced Perl folks where I didn't introduce them to a dozen
modules they had never heard of.  I get the daily e-mails from use.perl
announcing new modules and I had heard of only one of the modules folks
just mentioned in relation to this deferred variable definition stuff.  

Part of that is that I've never needed something like it, but a big part
of it is because there's no good guide.  And if people that program Perl
everyday can't keep track, how can we expect newbs to?  Just look at all
the nasty Perl that makes it out there as CGI scripts (to this day).  It
makes Matt's scripts look well written in some cases.  awstats is a good
example of this sadly and my most recent.  It's pure Perl, yay.  It's easy
to install and use.  There are lots of features.  It's flexible and
intelligent.  It gets updated on sourceforge quite often.  But have you
seen the code?  I thought about adding in the ability for it to pull stats
from a database and after priting out hundreds of pages of very C-like
awstats.pl code I decided it was way too much trouble in the short term.

Here's a related thought for making active Perlers lives easier.  Ages ago
O'Reilly put out the four volume boxed set with the bulk of the volumes
being various module pods in two thick tomes.  And A good portion of my
printer's life has gone to printing out newer pods to carry with me to
read.  Most of these get recycled ultimately because of being out of date
or they get buried in a project file that I never open again.  If there
were a way for people to make their own module reference book and keep it
up to date, indexed, and such it would be a Good Thing right?  Having this 
stuff print right and be manageable is very helpful even for those of who 
aren't afraid to read books on the screen.

So, I think there are a variety of better solutions.  We just need some 
volunteers!

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: what to do with dead camels ?

[Christopher Hicks]

On Mon, 4 Aug 2003, Nicholas Clark wrote:

> How much do you hate mailman for all those "here is a reminder of your
> mailing list memberships" messages?

They're only slightly irritating and I get a dozen of them every month.  
If they wouldn't show up on lists that I'd actually been active on I'd 
probably read some lists more often.

> Happy mailman day? Or curse mailman day?

Whatever mailman day.  After deleting six thousand spam per month, 
deleting a dozen mailman messages is going to hurt you?

> I can see this as a really good way to piss people off.

It's possible to use it to piss people off, but people can procmail it or 
do other things and if it were done right it would help weed out dead wood 
on CPAN and that's helpful.

As I understand it this wouldn't affect module authors who have updated
versions or clicked somewhere saying "I haven't whithered away at my desk
yet".  And it wouldn't have to be sent out except maybe every quarter (or
longer for people that didn't respond to the previous ping).  It doesn't 
seem that would generate much flack.

Maybe the e-mail should do something informative like list how many years, 
months and days it's been since a given module has been updated.  Some 
weak souls might be guilted into pushing out bug fixes sooner.

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: What search.cpan.org & PAUSE produce (Fork from: what to do with dead camels?)

[Christopher Hicks]

On Mon, 4 Aug 2003, James E Keenan wrote:
> May I begin a separate thread for a line of discussion coming up under
> the dead camels?

Sure.

> I'm going to present empirical observations only; it would be premature
> to make suggestions for changes until we heard from more contributors.

It's never stopped us before.  :)  Bru-hahahaha.

> Searching via "All":
> 1st distro appearing is Test::More as part of Palm-Progect-2.0.1 by Michael
> Graham.  Schwern's Test::More appears 4th on list.

(A) Do we have any idea what tha algorithm it's using is?

(B) Could we make an exception/improvement to the algorithm which makes 
the "real module" come up first?

> Searching via "Modules":
> 1st distro appearing is Test::More as part of CPAN-1.76 by Andreas J Konig.
> Schwern's Test::More does not come up at all among 471 entries found.
> 
> Searching via ""Distributions":
> Test::More does not come up at all

(C) Couldn't we have a seperate box that comes up on the side of the 
search results that shows the version/date of the last three releases of a 
given module X if the search string put in is reasonably obviously 
referring to a specific module.  So it might look something like this 
when searching for "Foo::Bar", "Foo-Bar", or "foo bar":

1) Irrelevant ResultModule Foo::Bar
2) Useless Result v0.1  4-1-1870
3) Misleading Result  v0.2  4-1-1970
4) Ancient Result v0.3  4-1-2003
5) Irrelevant Result
6) Irrelevant Result
7) Useful Result too low to see
8) Distracting Result

> Issue 2:  Which links PAUSE builds when an author uploads a module whose POD
> contains links?

I'd love to know the answer to this too.

> Do others observe similar phenomena? Is it problematic for you?

Ironically, search.cpan.org is phenomenal for browsing perl module docs,
but it's really strange and bewildering when it comes to searching them.

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: what to do with dead camels ?

[Christopher Hicks]

Sorry for beating the dead horse a little more, but here goes...

On Tue, 5 Aug 2003, Nicholas Clark wrote:
> On Tue, Aug 05, 2003 at 01:27:47AM -0400, Christopher Hicks wrote:
> > Maybe the e-mail should do something informative like list how many years, 
> > months and days it's been since a given module has been updated.  Some 
> > weak souls might be guilted into pushing out bug fixes sooner.
> 
> If there are no bugs, there is no need for bug fixes.

Agreed.

> MJD gets very irritated with people asking whether certain of his
> modules are abandoned, simply because the most recent version is old.

If all module writers wrote like MJD there'd be no need for this disussion 
or this list.  :)

> Why are you assuming that all stable code has known but unfixed bugs?

I'm not.  But I've dealt with a variety of different CPAN modules that 
were avaiable as updated from the authors site that took ages (as in a few 
years IIRC) to make it to CPAN.  How many months of watching this sort of 
thing go on is considered acceptable before taking the module and 
uploading it myself?

> If anything, have rt.perl.org send out ping messages about new (but
> unresponded to) bugs, or maybe open but serious bugs, because these do
> have content

That's be nice to include and maybe the message could be sent more often 
to those with unassigned bugs in their modules.

> But *do not* send out an "all's well" message, which will get filtered
> with the spam to /dev/null, because crying wolf like this will cause
> people to miss subsequent real, serious, messages.

Sheesh.  It's not crying wolf.  It's saying "here's the status of your
stuff".  When you get a monthly statement from your bank they're not
crying wolf.  They're keeping you up to date.  My accountant is hopefully
more on top of things than the bank so the only purpose in the statement
is to make sure the bank hasn't screwed up, but I don't accuse them of
crying wolf because they want to keep me appraised of things.

If people are this morally opposed to receiving an e-mail every few months 
maybe the implementor of this idea should let folks "bury their head in 
the sand" and stay happy.

And presumably this would come from some fixed address used for solely 
this purpose, so who's really going to miss e-mail over this?

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: what to do with dead camels ?

[Christopher Hicks]

On Mon, 4 Aug 2003, Johan Vromans wrote:

> Maybe a periodic 'ping' to module maintainers (e.g., once every two or
> three months) and mark maintainers (and their modules) that miss a
> couple of pings.  Modules marked as such could be returned last by the
> search engines, and be clearly marked as being of 'undetermined' status.

That'd be awesome.

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: Binary File Modules

[Christopher Hicks]

On Thu, 19 Jun 2003, Fergal Daly wrote:

> At the moment your only module is the PE module and that deals with a
> binary format but that's not to say that future modules won't deal with
> ascii formats too. Well ok, you said you'd be focussing on binary
> formats but some ASCII formats are none too simple and could probably
> use an Info modules.

Maybe the framework and the PE module should be seperately named?

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: Pod::DocBook

[Christopher Hicks]

On Mon, 9 Jun 2003, Shlomi Fish wrote:
> > Last I saw him, he was muttering "I think not..." at a party.
> > Haven't seen him since.
> When was that exactly?

A Renee Descartes joke.  Randal is a very funny guy.  Remember "I think
therefore I am" well the corollary is "I think not therefore I am not"  
which leads to several versions of Descartes philosophically humorous
demise.  It's the single most popular philosophy joke in my experience.

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: UDPM name space finalization

[Christopher Hicks]

On 3 Jun 2003, Kevin C. Krinke wrote:
> ...and the beat goes on...

Would somebody give Kevin a cookie for his concerted effort to get this
audiences' difficult approval?  His persistance is admirable IMHO.

-- 


Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
-Damian Conway, Perl God

Re: Stupid Questions

[Christopher Hicks]

On Thu, 29 May 2003, Hugh S. Myers wrote:
> If I don't ask, who will?
> 1. How do I set up a CPAN bundle?
> Pointers, tips, etc. welcome...thanks!

http://www.cpan.org/misc/cpan-faq.html#How_make_bundle

-- 


Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
-Damian Conway, Perl God

Re: rfc: a generic solution for dual-life CPAN packages

[Christopher Hicks]

On Thu, 27 Mar 2003, Stas Bekman wrote:
> Please, can we stay focused in this thread on the generic problem that
> I'm trying to solve?

I think this problem relates to the CPAN.pm bug we've seen reoocur several 
times where it tries to upgrade perl.  This is one of the biggest 
complaints I've heard from sysadmins trying to use perl apps in the last 
few years.  It seems like there should be some way to define certain 
modules as "core" - meaning "don't install unless you're really sure".  
These "core" things are dangerous to install mindlessly and shouldn't be 
considered for installation by automatic tools.  Can a flag be added via 
PAUSE or something else?

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

Re: rfc: a generic solution for dual-life CPAN packages

[Christopher Hicks]

On Wed, 26 Mar 2003, Stas Bekman wrote:
> Once we have this logic in place, we no longer need to make a special
> case for the perl core, but let every package that has a dual (or a
> ternary) life define its master package.

Could you just sneak the package into the core?  So, you'd release the 
normal .tar.gz to CPAN for the module and include that tar in core.  Then 
the core Makefile at some point could recurse off and do the install on 
that embedded module.  CPAN wouldn't have to know it was there so it 
wouldn't create a conflict.

-- 


The death of democracy is not likely to be an assassination from ambush. It
will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

RE: New module; Exec-RSE?

[Christopher Hicks]

On Wed, 27 Nov 2002, Hugh S. Myers wrote:

> Clever of you to miss the point entirely. That being to put it in the
> GetOpt namespace---the rest is up to the author...

Clever of you to miss that I did get your point entirely.  :)  I agreed
with you which is why I made my example in the GetOpt space.  I read an
article recently talking about not using strange acronyms in module names
and that's why I commented.  I responded to your e-mail since I was trying
to build on what you had correctly pointed out!  Sorry for not making that 
clearer.

"RSE" just makes me think of some strange IBM acronym.  VERA gives us
"Removable Storage Elements" and "Research and Systems Engineering" as
previous uses for RSE.  Who could guess the difference between GetOpt::RSE
and GetOpt::JCL?

-- 


Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
-Damian Conway, Perl God

RE: New module; Exec-RSE?

[Christopher Hicks]

On Tue, 26 Nov 2002, Hugh S. Myers wrote:
> Getopt::RSE or some variant if you want to people to be able to find it
> easily...

RSE is pretty meaningless in terms of good naming practices.  Who would 
know what RSE is?  GetOpt::StdResource might make sense to more people.

-- 


Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
-Damian Conway, Perl God

Re: MakeMaker autoconversion of module linefeeds?

[Christopher Hicks]

On Fri, 15 Nov 2002, Michael G Schwern wrote:
> On Fri, Nov 15, 2002 at 04:19:38PM -0800, Gurusamy Sarathy wrote:
> > I'm not sure what it is we're trying to solve here--has there been
> > a specific complaint we're trying to address?  "If nothing is
> > broken, don't fix it" etc.
> 
> Yes, yours. :)
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-04/msg02168.html
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-04/msg02144.html

[applause.]

> Its an old one.  I happened to dig it up while researching what TO_UNIX
> is for in MakeMaker.  The problem has largely been solved exactly as you
> suggested back that, Perl's newline handling has been made smarter.  
> Just wondering if anyone is still having problems with this. If not,
> I'll leave it be.  I might even tear out OS/2's special case.

The only instance where I've personally seen trouble with Perl and
different line-endings is in scripts.  If a script's #! line ends with a
CRLF many (maybe all?) UNIX's will give you "command not found" garbage.
Despite the irritation that has caused me through the years, it doesn't
seems worth leaving magical kruft buried in MakeMaker to fix it.

-- 


Camels may be nasty beasts, but they're the
only way to get through the desert. -me

Re: RFC Text::UberText

[Christopher Hicks]

On Tue, 15 Oct 2002, Chris Josephes wrote:
> I'd prefer to see
>  
>  [uber.customer payment-reminder]
> 
> in a template than
> 
>  [uber.conditional if:(overdue > 100) -> ]
>Your past due balance is over $100.  Please contact us to make
>plans regarding remittance.
>  [uber.conditional else ]
>Just a friendly reminder that you currently carry a past due balance.
>  [<- uber.conditional endif ]
> 
> The best we can do is make recommendations on what makes a good template,
> and that means the programmer using either TT or UT needs to create better 
> extensions for the document writers.

Well I'd disagree with your recommendation in this case.  (A) Your second
example above is much closer to something that can be easily
internationalized.  (B) Your second example puts the control of the
wording of the text in the hands of a non-programmer.

My point B above is one of the big motivators that drives our use of TT2 
actually.  We have a client that has lots of forms that do quite similar 
things.  Using TT2 we can let folks that aren't perl whizzes tweak the 
fields and their layout seperately from whatever programming may be 
required.  Quite often a non-technical person has been able to respond to  
a customer request weeks before a programmer would have gotten to it.

> It's kind of wierd how all of these examples always fall back on invoices, 
> bills, or other business documents.

We're currently using TT2 to do web applications for insurance and medical
records management, but those are all business documents too.  My dreams
of using TT2 for 'fun' things like systems administration and MP3 herding
just don't seem to get much time.  :(  [sigh.]

-- 


The truth is rarely pure, and never simple.
-Oscar Wilde, writer (1854-1900)

Re: RFC Text::UberText

[Christopher Hicks]

On Tue, 15 Oct 2002, Terrence Brannon wrote:
> 1. developing a good language is very difficult.
> 2. why do we need a template *language*. What is it about templating 
> that requires a new *language*? Templating entails a few simple 
> operations that can be handled in any general purpose language - LISP, 
> Perl, Python, C, C++.
> 
> Terrence "I love speaking to a brick wall" Brannon

I'm one of those lost souls that developed my own templating system only
to find that it was more trouble to keep it working than not.  I've been a
Template Toolkit (TT2) user for two years now and I'm actually working on
real stuff instead of dorking around with making the 'perfect templating
system'.  I've developed rather complex pages using TT2 to the point that
some of them I've reverted back to generating internally in Perl since too
much logic was involved.  But beyond that fact that TT2 has allowed me to 
create some misplaced complexity it has held up extremely well.  It's 
nicely documented and looking inside the code hasn't been too daunting.  
I've had no trouble adding directives that were highly relevant to my 
application which has made the pages that actually get edited as simple 
as I can imagine them being.

Anyone want to start a mailing list for templating system authors 
anonymous?  My name is Chris and I wrote my own templating system.  
[sniffle.]  ;-)

-- 


The truth is rarely pure, and never simple.
-Oscar Wilde, writer (1854-1900)

Re: howto "mirror" subset of CPAN?

[Christopher Hicks]

On Mon, 10 Jun 2002, Scott R. Godin wrote:

> I too had a hard time believing how some of the internal versioning is
> done. crazy regex and substr reductions of long version strings
> instead of a simple package::VERSION = nn.nn.nn;
> *bemused headscratching*

I'm sure a good percentage of that is done so that people can use the
version number from cvs or (insert your favorite SCM here).

-- 


There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
- - C.A.R. Hoare