Re: spamming cpan? was [Fwd: Perl-Freelancer needed]

[Sam Vilain]

David Golden wrote:
> Corion contacted them (see http://use.perl.org/~Corion/journal/31223
>  ):
>
> I got some spam by a German company (Online Microsystems) seeking
> a freelancer today. I gave them a call and educated them about
> jobs.perl.org , which they actually were
> really happy to learn about.
>
>
> Perhaps the CPAN home page "FAQ etc" section needs a link to
> jobs.perl.org ?

And while you're at it, how about a link to some kind of software
development management clue.  I really feel for the probably talented
but naïve programmer who doesn't realise this line from the spam is a
recipe for disaster:

> If you are interested in doing the job, please quote us a lump-sum for this 
> package.

Sam.

Re: Give up your modules!

[Sam Vilain]

Ken Williams wrote:
> That said, there ought to be a way for the community to move forward
> without having the original author be the bottleneck.  With open-source
> licenses, there's explicitly a way for someone else in the community to
> pick up the reins and release a "derivative" of the original code
> without seeking the permission of the original author: JFDI.  Change the
> namespace if you must.  People will cope, it's better than having no new
> release at all.

You do not even need to change the namespace; if people would like to
show that they are ready to take over a module, there is nothing to stop
them "proving themselves" by just uploading the it to CPAN.  They won't
get indexed (or, in turn, downloaded automatically by the CPAN shell),
but they will still be carried by the CPAN network, and show up on
search.cpan.org.

Then, all you need is a suitably convincing petition of users to have
the namespace handed over, or have the original author approve the
hand-over.

IOW "Show me the code" :)

With Perl 6, and once the core cpan network and installation modules
support this adequately, you even have a workaround; just tell your
users to write;

  use Crypt::Rijndael-(Any)-SCHNEIER;

There will be much more on this topic in the cpan6 announcement talk at
YAPC::Eu in Birmingham.

Sam.

Re: Test-time dependencies.

[Sam Vilain]

Johan Vromans wrote:
> Ken Williams <[EMAIL PROTECTED]> writes:
> 
>> My intention when I added 'build_requires' to Module::Build was not
>> to let people avoid downloading & building those dependencies, but
>> rather to indicate that there was no runtime dependency, ...
> 
> For this to function properly, the 'build_requires' modules (and their
> respecitve dependencies!) should all be downloaded and installed in a
> temporary location (e.g., blib) and not be installed permanently.

This is what Module::Install does when you use 'auto_include'.

What I've done for recent modules is to bundle Test::Depends by making
it the only build_requires line.  Then, from the test scripts I can just;

 use Test::Depends qw(Some::Module), Other::Module => [ @import_args ];

Of course it means that the test suite doesn't get run fully, but I
think the output makes that obvious enough.

Sam.

Re: CPAN6

[Sam Vilain]

Leon Brocard wrote:
> Of course not - but in the usual Perl way, if you don't like it, you
> can build your own cpan6!
> And release it to, errr, CPAN.
>
> But as with most Perl 6 projects, I have to ask: Why do we have to
> wait for Perl 6 before we get a better CPAN?
>   

We don't, we're building it using Moose :-).  You're waiting on good old
fashioned hubris.

> Or is this getting too meta and should I wait until your yapc talk
> instead... Leon
>   

Yes, come to the talk, it's 98% "meta" free and no added "Schema".

Sam.

Re: A Semi-Public Version Control Repository for Your CPAN Modules

[Sam Vilain]

Shlomi Fish wrote:
>> Another option is to just upload the distribution with your changes
>> using your own PAUSE ID to cpan.  It will not get indexed, but succeeds
>> in that users who don't know about or trust some external repository can
>> still access your changes via the CPAN network.
>> 
>
> I really don't want to do that, because it's not a real solution.  This 
> mailing 
> list, modules@perl.org and other forums are inundated with such requests for 
> gaining maintainership of authors who disappeared. Now Damian did not 
> disappear - he's still alive and kicking - he just doesn't have the time to 
> apply all patches or fix all bugs. 
>   

I'm not sure why you say it is not "real" - would you care to elaborate
the failings in this working solution that you see?  I've come across
authors who have thanked me for doing a release for them, and it means
that the *users* of the modules don't have to wait for the upstream
author to do a release if they want to get the modified version.

Sometimes it's just the simplest and most effective way to publish the
changes.

> Once a FOSS project becomes popular and the author becomes busy, then having 
> only one person able to commit changes to such a project, scales less and 
> less. That's what version control and multiple commiters (or alternatively or 
> complementarily distributed version control) is for. 
>
> I could release a module I have changed for with patch A, and then patch B, 
> and then patch C, etc. I've already done it with 
> http://www.shlomifish.org/open-source/bits-and-bobs/gringotts-patch/ which is 
> written in C. However, I'd rather take advantage of Audrey Tang's and Adam 
> Kennedy's lead and simply commit changes directly to their version control 
> system so they'll eventually be available upstream.
>   

A lot of what you say is true, but we should be extremely careful not to
enforce or specifically condone any particular style of development. 
Some prefer the wiki-style/open commit approach and hence use SVN as a
robust filesystem for this, others prefer that changes are reviewed
first and probably use a distributed system like bazaar, git, darcs,
etc, for a cleaner concept of branches.

Consider how this works with savannah.gnu.org.  If you have a patch to a
software package that implements a particular feature, you can just
upload it to the system.  It is then available for all users, not just
the maintainer.  Later, the maintainer can mark the patch as included in
a release, and the patch gets marked done.  Making it easy for these
changes to be available to a given user is just a matter of installation
tool sophistication.

However, if you just commit on an SVN trunk, your trunk becomes a
"ghetto" of features which may or may not work.  Some relish in delight
at the prospect of grokking these new ideas from people, and the success
of pugs is testament to the energy of people like Audrey who actively
engage in this process.  But if the maintainer doesn't do that for all
their modules all the time, the ghetto ends up needing much clean-up
before release, possibly involving a painful process of branching and
cherry picking, which is always painful with svn.

I think the point is that it is not valid to imply that a module author
is not fulfilling their moral duty because they do not embrace the wiki
model and want to adopt your changes.  There are plenty of options - set
up your own VCS, upload to CPAN independently, post a patch to the
module's users' mailing list, etc.

The reason I recommended uploading to CPAN, is because as CPAN to VCS
bridges emerge, your new version will fit in tidily as a separate
branch.  Assuming the author uses this bridge they can then just merge,
then "commit" back via the bridge to CPAN.

> Well cpan6 aside, I've thought about an idea for Park ( 
> http://www.shlomifish.org/park-lisp-fooware/park-lisp-informal-spec/ ) which 
> I have yet to put in writing in the slowly-progressing informal spec, but 
> it's doable for other languages too:
>
> What happens is that everyone can register a "vendor tag" in CPAN, which is 
> an 
> alphanumeric name. He can also make other people co-maintainers of this 
> vendor tag. Then new versions of modules of an existing author can be 
> released under a vendor tag that they belong to. And the user can specify to 
> install modules that belong to a certain vendor tag. 
> (e.g: "install --vendor=ShlomiFish Parse::RecDescent").
>   

This is actually required for Perl 6, to be able to specify a vendor. 
eg, `use Parse::RecDescent-(Any)-cpan:SHLOMI'.  The vendor tag is just
your PAUSE ID, or perhaps a cpan6 archive URL.

It is expected that this functionality will eventually be retrofitted
into Perl 5 via CPAN6.pm.

> Naturally, it introduces some problems, and probably not a perfect solution 
> but worth thinking of. Note that I hope to see some of the non-Perl6-related 
> improvements to Perl6 back-ported to CPAN (or to CPAN 2.0 - ;-)).
>
> Another improvement 

Re: A Semi-Public Version Control Repository for Your CPAN Modules

[Sam Vilain]

Shlomi Fish wrote:
> Now, Adam Kennedy recently made an interesting step of making commit access 
> to 
> a Subversion repository with the source code for most of his modules to 
> anyone with a valid PAUSE login:
>
> http://use.perl.org/~Alias/journal/29327
>
> My suggestion is for you to do something similar. What do you think? Is there 
> any reason for you not to do so?
>   

Shlomi,

Another option is to just upload the distribution with your changes
using your own PAUSE ID to cpan.  It will not get indexed, but succeeds
in that users who don't know about or trust some external repository can
still access your changes via the CPAN network.

If you are in Europe in August, you might like to come to YAPC and see
the announcement of cpan6, this concern is included in the design
requirements and making small changes to other's code will be natural
and safe.

http://www.birmingham2006.com/cgi-bin/yapc.pl?act=talk-item&talkid=51

Sam.

Re: I think we can just scrap CPAN Ratings altogether

[Sam Vilain]

A. Pagaltzis wrote:

>* Adam Kennedy [2006-05-23 11:10:13]
>  
>
>>Data-Pageset (1.03) — 1 star:
>>
>>This is reciprocal karma for the author one-starring a
>>competing module and advertising his own. Bad form. (not a
>>commentary on how this works) 
>>
>>
>
>This sort of thing is lunacy. What’s the point of MODULE REVIEWS
>if they’re going to be turned into crusade vehicles?
>  
>

Can't we just move the site to cpanrantings.org? That's the spelling
I've always used :-)

Sam.

Re: New module: FLV file parsing

[Sam Vilain]

On Wed, 2005-11-30 at 09:06 -0800, Eric Wilhelm wrote:
> # from A. Pagaltzis
> # on Wednesday 30 November 2005 07:49 am:
> 
> >> Or File::FLV?  Or File::FLV::Parser?
> >
> >I don’t think File:: is right for this.
> 
> Right, because it's not a filehandle or otherwise IO/filesystem related.
> 
> Should we be using an FF::  namespace for File Formats?  I've got a few 
> modules that would like to live there too.

FWIW, I know of at least one module in the Parse:: namespace for a file
format - SVN Diff format.  And it is capable of writing, too.

Sam.

Re: Module abstract: Is its length still limited?

[Sam Vilain]

On Mon, 2005-11-07 at 21:08 -0500, Ricardo SIGNES wrote:
> * "Andreas J. Koenig" <[EMAIL PROTECTED]> [2005-11-07T17:29:50]
> > I will be very happy if you guys decide something and let me know.
> > I'll adjust the code for the forms on PAUSE then.
> 
> Here's my official vote:
> 
> (length $module_name + length $abstract + 3) should be under 80.
> 
> This means that the whole header and abstract will fit in one line.
> That's more than 44 characters for short module names.  Longer module
> names, which should be pretty descriptive, need shorter abstracts.
> 
> Wombat - a framework for building reusable fruit-counting applications
> Application::Framework::FruitCounting - for reusable produce applications
> 

My feeling is that this wouldn't really work when the module name gets
too long, for example when a namespace under which you are contributing
has chosen verbose terms.

For keeping your source code at 80 characters wide, it should be
perfectly legal to wrap that line in the source; it's not a verbatim
block so all Pod parsers SHOULD see it as a flowed paragraph.  Whether
or not this is true for all relevant parsers is another story.
Personally I'd call it a bug if they don't follow the POD rules, though.

I also feel that the total length of those two is somewhat irrelevant
for its intended use - for instance, if you are browsing modules on
search.cpan.org, the module names and abstracts are both flush left.
Tabular format works better like that.

I think the key question is more along the lines of, how much text do
you want to see while you are reading the abstract for a whole bunch of
modules?  What length is "about right"?

I suggested 60 because it's just a *little* bit longer, to allow for
better word choices here and there, but still too short for rambling.
Perhaps 80 is fine, too.

I had a read through the modules by the authors listed in the other
e-mail, AUTRIJUS, BDFOY, and DCONWAY, and I couldn't really see any
obviously "overly squeezed" abstracts.  Except perhaps QM for "Quantum
Mechanical".

Can anyone find any examples of abstracts that they think are inadequate
due to size restrictions?

Sam.

Re: Module abstract: Is its length still limited?

[Sam Vilain]

On Sun, 2005-11-06 at 07:51 +0100, Andreas J. Koenig wrote:
>   > So, the question I would now ask:  How rigidly should I enforce the 
>   > 44-character limit if I am guiding someone in the task of creating 
>   > proper Perl modules?
> As the module list is dead, we cannot really argue in favor of 44
> characters except with the one argument of tradition/best practice. I
> believe when 3815 authos have managed to describe their modules in 44
> characters, then it should be doable for some other 3815000 modules
> too.

Yes, let's keep it short.  But how about increasing the limit to 60 or
so?  Many a time I would've liked an extra word or two.

> There's an old business advice that you shouldn't start an enterprize
> if you cannot describe its mission in a single sentence. I think its
> true for modules too.

There are very few sentences that fit in 44 characters.  60 characters I
think still honours this principle.

Sam.

Re: Name advice: check license of dependencies

[Sam Vilain]

On Mon, 2005-10-31 at 11:20 -0500, Mark Stosberg wrote:
> > I don't like any of the names I've come up with so far.  It seems  
> > clear that it should be in the Module:: namespace, but beyond that  
> > I'm unsure.  Possibilities:
> >Module::GuessLicense
> >Module::License
> >Module::LicenseChain
> >Module::DistributionRights
>  From your description, this is much as about a module's dependencies as
> it as a about a specific module. So I'll suggest: 
>
> Module::Depends::LicenseReport
>
> Including "Report" signifies that the module has a "read-only" purpose. 

On the other hand, a license might be seen to implicitly imply
dependency on all of the things that it depends on (esp. if any are
GPL).

I think your point is very valid, and perhaps the logic for figuring a
module's dependencies recursively should be available independently from
the logic to show the license for an individual module.

So, perhaps

   Module::Depends

and

   Module::License
   Module::License::(Report|Chain|...)

Sam.

Re: Tests needing user parameters

[Sam Vilain]

On Wed, 2005-10-19 at 21:51 +0100, Jess Robinson wrote:
> Hey folks,
> 
> I'm writing a module which will need user account data for it's tests, and 
> I'm wondering if theres a standard way (or module) for doing this.. 
> 
> Else I'll guess I'll look for environment variables and otherwise not 
> test, any ideas?

Look at the Tangram test suite in 2.08_05; it asks for information about
where to find a database to connect for tests, saves the information to
a state file in t/.  It also correctly handles the situation where no
information is given, by altering the test manifest.

It doesn't use ExtUtils::MakeMaker::prompt, though arguably it should.

Sam.

Re: Module abstract: Is its length still limited?

[Sam Vilain]

On Sun, 2005-09-04 at 21:02 -0400, James E Keenan wrote:
> IIRC, there was once a 44-character limit to the length of a CPAN module 
> abstract:  the brief description which follows the module's name in the 
> NAME section of POD.
> 
> But when I uploaded a module a couple of hours ago, I noted that, at 
> least on search.cpan.org, an abstract much longer than 44 characters was 
> fully displayed.
> 
> Has this restriction been relaxed?  Did it ever exist?  I searched 
> perlmod, perlnewmod, perlmodstyle, etc., as well as googling this 
> group's archives, but came up with very little re module abstracts?
> 

This was probably for the sake of the text-only modules list, which has
since fallen out of maintenance.

Sam.

Re: Regexp code feature

[Sam Vilain]

Chris Dolan wrote:
What's the minimum version of Perl needed to reliably exploit the (?{  
code }) feature in regexps?
I'm working on a module that I call Net::IP::Match::Regexp which builds  
and runs regexps that contain simple code blocks.  It works great under  
5.8.1 on my Mac, but I haven't tested older Perl versions yet.

My code turns these IP ranges (randomly generated)
  109.27.190.54/28=> 1
  109.61.26.198/24=> 2
  180.203.154.195/28  => 3
  5.98.198.68/19  => 4
  68.238.145.35/29=> 5
into regexps look like this:
my $re =  
"^(?:0(?:10101100010110(?{'2'})|1(?:000100111011101001000100100(? 
{'3'})|10110100(?:01101110100011(?{'5'})|0100011010(? 
{'4'}|1011010011001011100110101100(?{'1'}))";

It's used in this context, pulling the code values out via $^R:


Perhaps it would be a good idea to make an extension to Net::CIDR::Lite
that uses this module to optimise matching IP addresses when given very
large numbers of ranges to check.

Sam.

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

[Sam Vilain]

Orton, Yves wrote:

Imo it would better to expose a different subroutine name for this.
sub GetOptions {
  GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?


If you consider the signature a part of the "subroutine name", then
simply making it take an arrayref as the first argument is enough
to distinguish it.

in Perl 6 you could say

  multi sub GetOptions(Array @ARGV, Pair [EMAIL PROTECTED]) { ... }

is a different subroutine to

  multi sub GetOptions(Pair [EMAIL PROTECTED]) { ... }

If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.

But that, of course, is a matter of style ;-)

Sam.

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

[Sam Vilain]

Johan Vromans wrote:

You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to every function that may use them? [1]
Global things are intended to be global, I'd say.


This is why code using CGI.pm is so hard to wrap, too.  Assumptions that
globals will always be globals.

Then you go and try and do anything vaguely re-entrant and it all falls
to pieces.

Sam.

Re: RFC: Getopt::Modern

[Sam Vilain]

Johan Vromans wrote:

I have several tools that take different syntax on the command line,
specific for the task. For example, subcommands:
   mycmd init db=$HOME/mydb
   mycmd load db=$HOME/mydb data1 
   mycmd load --trace db=$HOME/mydb data1 
   mycmd --trace load db=$HOME/mydb data1 


Yes; I've wanted to do this before, and commands like svn, svk, etc
are good examples of this... I've jumped through all sorts of hoops
before coördinating getting this right from the command line and
config files at once...

However I must admit I found Getopt::Long provided me with the API I
needed to do the command line parsing part easily and flexibly enough.

Sam.

Re: IO::ALL (Was: check for errors on close())

[Sam Vilain]

Smylers wrote:
I've only just begun to reap the benefits of it.
After how long of using it?  Does that mean that initially you found it
more hassle?
No, not at all.  I've just only found myself using it twice so far.
However, when I did I found it deliciously DWIMmy and extremely handy.
eg, in http://svn.kwiki.org/ingy/Perldoc/lib/Perldoc/MugReader.pm I use
it to accept a filehandle, string, filename, etc - whilst still being
able to treat them all as if they were files, as well as knowing that
now my module can accept URIs too!
Now, it seems that the built-in ways of doing these things are just
too awkward.
That strengthens my feeling that Ingy is on to something with his
shorter syntax, and that Perl 6 should benefit from many of his ideas.
So come on over to p6l!  :)
Or, actually it's probably better to join in the pugs crowd and
contribute an update to S29 based on IO::All and Path::Class.  Perhaps
there is even enough in Pugs to be able to start a basic implementation?
At least the non-OO interface, anyway.
Sam.

Re: IO::ALL (Was: check for errors on close())

[Sam Vilain]

Smylers wrote:
Sam (or any other IO::All users reading this), what's your experience of
IO::All?  How much effort has it saved you?  Does it make your code look
I've only just begun to reap the benefits of it.
Now, it seems that the built-in ways of doing these things are just
too awkward.  Just this morning I cursed as I had to change;
 my @mp3s = grep { -f } @ARGV, ($m3u?io($m3u):());
to:
 my @mp3s = grep { -f } @ARGV, ($m3u?(map{chomp;$_}`cat "$m3u"`):());
Because I didn't have internet available to grab IO::All.  Clearly,
there are two fairly opposite morals to read from that story.
mailing list: does the Spiffy thing make sense to you?  (I get the
feeling that there's something I'm missing, or that I'm not clever
enough to understand it.)
Spiffy doesn't do a lot; it just gives you accessors and does an extremely
simple and very safe-looking source filter to make modules virtually all
code and no infrastructure.
I think Spiffy is a perfectly acceptable choice for a lightweight accessor
package; it provides a nice set of features that solve a lot of long-
standing problems with writing Perl 5 code.
Like, inheriting functions (not just methods) to sub-classes.  Like
automatic use strict, which still gets me occasionally.
And I think I've just about listed all that Spiffy does, so don't worry
about it!  :)
Sam.

Re: check for errors on close()

[Sam Vilain]

Eric Wilhelm wrote:
Just spent way too much time trying to find a bug when it turns out that 
I just had a full disk.  
So, food for thought for today:  close() does not always return true.
  close(FILE) or die "file error: $!";
In the disk-full case, open() succeeds (if there are still inodes 
available), but close fails because the buffers cannot be flushed.
You don't already check the return value of every system call?
Too tedious?  Just use IO::All.
Sam.

Re: Parse::Lex abandoned?

[Sam Vilain]

Eric Wilhelm wrote:
Would anti-pollution laws help or hurt CPAN?
Well, we might go and do that.  We could go and seize control of what
we think is the worst problem, and make laws that restrict it.  We could
make targets about how much pollution we weren't going to make, and
when.
Then we could find that 400 years later we've got a global green age anyway
because the planet has a 1500 year weather variation and that the form
of pollution we chose to restrict was not actually part of the problem.
Maybe the process of polluting itself needed to be addressed.  And I'd say
in the context of coding that's a very contemplative / introspective thing.
Sam.

Re: Win32::TieRegistry or Perl problem (?)]

[Sam Vilain]

Ken Williams wrote:
On Mar 2, 2005, at 5:53 PM, Linda W wrote:
I'm not sure what perl does with invalid
character data in a variable when you try to manipulate
it by appending it to another value.

There's no such thing as invalid character data in Perl strings.  Perl 
strings can contain arbitrary binary data.
Sure, in the "C" locale.
Outside of that, all bets are off.  You could quite easily have arbitrary
binary data in a Perl scalar that isn't valid character data in UTF-8,
for instance.
Sam.

Re: Net::Ftp use proxy et al...

[Sam Vilain]

Linda W wrote:
Might it not be "useful" if Net::FTP could use an ftp_proxy, transparently,
if one was set in the environment?
Net::FTP couldn't provide its entire API if proxied; after all, the proxy
is pretty-printing the directories into HTML so they look nice in a browser.
Just ask the authors of NcFTP why they don't support HTTP proxies :).
Note that LWP::UserAgent can fetch FTP URLs transparently using whatever
environment proxies are defined, if any.  If you're using an FTP server as
if it were an HTTP server, it makes sense to use an HTTP interface.
Than again, maybe the author will disagree with me and add the feature,
who knows :).
Unlike most people in the linux world, I don't think the concept of
a single per-user/per system registry would be a bad thing if done
right -- all the little config files/rc files sitting around on volumes
with large allocation block sizes and wasting a large amount of
filespace...  If done "right", could make moving setups between systems
easier...
You'll hurt your head thinking about that for too long.  The technical
inefficiency really isn't the issue at all, and in fact if you're on a
real OS then it isn't even inefficient.
UNIX does have a registry.  It's called /etc and ~/.*, the problem is
that after 30+ years of text file config formats, we've decided we still
love text files but we don't like the differences in their format.  If
you want to ease the standardisation of these things then just use YAML
for your next config format, and be done with it.  If YAML were to become
best practice for a configuration file format, you could present them
with an API that looked like a registry anyway.  The idiosynchronacies
would still be there but the solutions should proliferate.
Such a change will take a long time to get right, I think most people
will agree that many of the benefits arising from a convention regarding
making configuration files homogenous in a way that is almost, but not
entirely, quite unlike a registry is probably worth it in the long run
- but it will be a slow, slow process.
Maybe if you write a nice generic cross-platform GUI YAML config editor
for YAML dotfiles that applications can provide custom extension dialogs
for, then you will have something control-panel like for conforming
applications.  The idea is that it's trivial for application authors to
supply the information used to build the GUIs, and possibly even plug
their own components in.
Actually, such an idea would naturally need to have alternate UI support,
a bit like Debconf I guess - but be warned, and people who call this
flamebait can be damned - Joey Hess' code is not to be taken as a good
example for style.  Seeing main loops like this;
   1 while $debconf->communicate();
Make me want to shoot the author on grounds of inapproprate public
displays of self-affection.  Besides, debconf is combined in unholy
matrimony with the system packager, and focuses on a different set of
goals.
And whatever you do, don't call it a registry, you'll hit a sore spot on
lots of people ;)
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Net::Ftp use proxy?

[Sam Vilain]

Linda W wrote:
When cpan goes to do a "get", it first says LWP not available,
then tries NET::Ftp (which failes because it is behind
a FW and needs to use ftp_proxy) and finally lynx.  Lynx works
(fortunately).
Should Net:Ftp be able to use my "ftp_proxy" set in the
environment?
Note that you need to set "ftp_firewall" if you have a true FTP
firewall, or more likely if you're setting something like
ftp_proxy=http://proxy:3128/, then you actually need to talk *HTTP*
to the proxy.  Net::FTP can't do that itself, but LWP should DTRT
once it's installed.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Tree::Meta

[Sam Vilain]

Eric Wilhelm wrote:
associative arrays.  This module uses tied associative arrays and some 
conventions to represent ordered trees where each node of the tree has 
both contents (deeper nodes) and properties (things about the node.)  
It's not exactly homogeneous (like an n-ary tree) because it uses a 
file/directory concept (a "directory" contains more nodes (a recursive 
version of the same data-structure), but a "file" only contains flat 
data (as arrays.))
Something like a Directed Acyclic Graph?  (see Tree::DAG_Node)
Mapping a DAG to native types using magic rather than objects for the
extra information is an interesting idea.
How about Tie::DAG?  or Tie::DAG::Meta/Tree::DAGMeta ...
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: What to name the baby? (module naming advice)

[Sam Vilain]

Rocco Caputo wrote:
I think it would be misleading to imply that this code only works with
IRC.
Even so, what you are doing is inherantly an IRC-ish thing to want to do.
Wouldn't you still refer to non-IRC but IRC-like chatrooms as IRC?  It's
a concept beyond the protocol IMHO.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Class::Validating - naming suggestions

[Sam Vilain]

module-authors@perl.org wrote:
Perhaps it should be named 
Params::Validate::Derivable
or something along those lines.
I agree, but given that being derivable is something really important
for being able to be called OOP, why not:
  Params::Validate::OO - Derivable parameter validation
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Module naming advice

[Sam Vilain]

David Wheeler wrote:
I agree that it should be lowercased; yes, there are modules on CPAN 
that look like pragmas (such as only). I personally would prefer, 
however, that the name tell me that it's doing something more than 
loading a class; "class" and "module" don't do that. 
However, this code reads very well:
 use module 'Foo::Bar' as 'Bar';
 use package 'Foo::Bar' as 'Bar';
And this does not read as well (at least, in English):
 use aka 'Foo::Bar' as 'Bar';
My suggestion;
 use aliasing to 'Bar', 'Foo::Bar';
With the upside that "aliasing" also clearly states what the module
does.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

cross-posted FAQ question [was: Win98 - DBD-Oracle install issue]

[Sam Vilain]

John Berry wrote:
I am trying to install DBD-Oracle-1.16 along with DBI-1.46
DBI was installed successfully, but got errors intalling the 
DBD-Oracle-1.16.
John,
Two things.
Firstly, you cross-posted this message to two mailing lists, one of
which has no interest in this problem.  This is bad netiquette.
Secondly, you have failed to check the mailing list archives to see if
this problem has come up before.  You are the third person to ask a
question like this in the dbi-users list this week.
Please, check the dbi-users mailing list archives, and try to be more
careful with the recipient lists on e-mails you send.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

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

[Sam Vilain]

Orton, Yves wrote:
DBD::Ingres does something similar. DBD::Oracle appears to be closer to
Sybase/MySQl:
"dbi:Oracle:host=myhost.com;sid=ORCL"
Normally you don't bother with connection parameters with Oracle at all:
  DBI->connect("dbi:Oracle:", "database", "password");
Instead, you configure which logical Oracle installation that you want
with an environment variable.  The information about where that database
actually lives is in a config file in the Oracle client installation.
So, if you actually override the environment variable by specifying the
SID in the program, you run the risk of confusing the poor SysAdmins who
look after it, as every other program honours this convention.
> Clearly any DBD driver that can connect to providers on a different
> host will have to in some way allow the user to specify which host
> that is.
Not necessarily.  There might be an ORB or some other name service
locator that finds those details out at run time given something that
isn't a host name.
I think that this information should be removed from most programs
altogether.  They should just have to specify a logical data source
(possibly including a schema version), then a module with a config file
maps that to a set of connection parameters.
ie, if we're going to go ahead and try to make some sense of how you
specify the parameters to the DBI connect call, why don't we go the
whole way and think about where that connection information is coming
from?
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Suite of modules to be released - the name game

[Sam Vilain]

John Siracusa wrote:
There are a few things that make this difficult.  The first is that any OO
"helper" module depends on the object base class and method maker.  The
second is that the object base class and method maker are very simple, and
hardly worth distributing separately.
If they are very simple, why not use an existing module?
What functionality do they add, why could it not be added to another
accessor module?  If it is because the others were too simple, could
they have been split to load extra functionality on demand?
You shouldn't answer these questions on this list btw.  But they should
help you decide whether to rip them out, or release them seperately.
> The third is that even the functional
helper classes are very simple, and usually only exist so that I have a
single point of access for some functionality within my suite.
I suggest that you release them under the namespace of your own for now.
However, over the next few years, you should actively try to move
portions over to more functional namespaces and incorporate the
functionality into other modules.  This is a particularly more serious
state of affairs for the database side of things; database libraries
have more traps and pitfalls than you may be aware of, and the bugs in
that space are usually the hardest to debug and have the worst impact!
You should definitely ask on the POOP-group list about which existing DB
library is most similar to your new approach.
When you add a single method to a prepackaged module, could it be that
the module could be enhanced with the feature?  Try sending a patch to
the author.
Is your assessment of whether it fits in with the module you are using
correct?  Check with the community, maybe they have an approach that
works in the way you want.
Are you replicating the API of another module, with a competing
implementation?  That module should be released as Foo::Lite (if it is
actually `Lite'r) or otherwise under the namespace of the original
module.
Once the great ideas and fresh approaches that you have discovered with
your efforts are incorporated into other modules, or had new modules
made from the ones that really are new and different, the originals can
be deprecated and "laid to rest".
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Which namespace for a build system?

[Sam Vilain]

A. Pagaltzis wrote:
The question I'd ask is, is there established Computer Science
terminology for the problem a dependency solver addresses? That
probably requires determining what kind of field the problem
falls into. I have a hunch that that would be AI.
How about a "Dependancy Algorithm" ?  :-)
http://search.cpan.org/dist/Algorithm-Dependency/
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: namespace for users and groups

[Sam Vilain]

David R. Baird wrote:
I think the treeness is quite important, because groups inherit the 
capabilities/permissions of their subgroups. So whenever you check if 
your own group is permitted to do something, you know that the tree-
like hierarchy of groups contained within your group is also being 
checked. 
 

"Group", by itself, infers no such treeness.  You may have chosen to 
model your groups and users by some close analogue of;

   
 +-+  +-+  ++
 | GrantableEntity |--|  Grant  |--| Entity |
 +++ 1  * +-+ *  1 ++
 /_\
  |
+---+   +-++
|   | * |  |
|* +-+ * * ++
+--|  Group  |-|  User  |
   +-+ ++

Unix Groups, for instance, do not bother with this, so "Group" doesn't 
mean "Heirarchy of Groups" in this case.

The problem with these such discussions is that such a wide variety of 
possible ACL structures are all used and called "ACLs" - though each can 
have a different arrangement of explicit or implied inheritance between 
security objects, and multiplicity of each relationship.  So, they have 
different properties, which is easy to see when they are expressed in 
UML, as above.

Some people even try to express one particular concrete form or describe 
a design-specific property, and call that structure the definition of 
the term.  In the end, as long as there is a virtual concept of 
controlling access, it can be called an ACL.  You could call Unix Groups 
an ACL mechanism, and it would not be incorrect.

UML is an excellent language with which to express the exact nature of 
the ACL that your module implements.  _*The Art of Objects: 
Object-Oriented Design and Architecture_, by *Yun-Tung Lau 
<http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Yun-Tung%20Lau/102-5857950-6496945> 
(isbn://0201711613/) uses ACL design as one of its worked examples.  
Highly recommended.

--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: script local namespacing?

[Sam Vilain]

Eric Wilhelm wrote:
Just use ProgramName::
The assumption here is that you won't be distributing the modules on CPAN and 
that your program/project is going to have a unique name.
It's been suggested before on this list, and I agree with it.
 

What about the potential conflicts caused by takeovers and mergers?  
Maybe we should follow Java's lead

com::yourcompany::Perl::script::CLI::Util::ProgramName
Sam.
 "Would you like fries with your flamebait, Sir?"

The CPAN Guide [was Re: Future of the "Module List"]

[Sam Vilain]

Mark Stosberg wrote:
Maybe the convention could be:
Review::Text::Balanced::CPANUSERNAME
 

Good idea, but I think that is duplicated information.  CPAN already 
considers the uploaded user ID to be a part of the unique name of the 
module.  Two authors can upload a module with the same name; and that is 
fine; they will both be displayed uniquely when found on search.cpan.org.

Of course, when installing via CPAN.pm, the indexer will only 
automatically choose the versions of the modules written by the current 
maintainer (or some rule like that).  For reviews, this is not really a 
major consideration - except maybe for people compiling CPAN discset 
compilations.  OTOH, a link to http://search.cpan.org/dist/Some-Dist/ 
will go to whichever has the highest version number (see 
http://search.cpan.org/dist/Data-Lazy/ for an example).  Perfect.

Rather than trying to double the size of CPAN by making a review for 
each module, a review could cover a wide variety of different modules 
that cover a related problem space.  The reviews could be supplemented 
with examples and demonstrations exhibiting strengths and weaknesses of 
the modules that they review - for instance, benchmarking, memory tests, 
etc.  As new modules are written, the reviews could be extended 
(perhaps, but not necessarily by the same author as the original 
review).  You will get a similar situation to many of the modules in 
CPAN today, which have more than a handful of maintainers who have 
contributed.

There's nothing to say that individual module reviews shouldn't be 
written, and the convention of naming the review module the same as the 
single module it covers with a prefix is a good one.  This would almost 
certainly be linked to by the module which covers the generic problem space.

So, to make this distinction clear, maybe the
   Guide::*
namespace should cover "problem space" reviews, and serve as something 
of another index to CPAN - and

   Review::*
can be for more in-depth reviews of individual CPAN modules, to avoid 
potentional conflicts from using "Review::*" for both of these.  
Besides, I think Guide:: is more accurate here.

If no-one has any sound objections or beats me to the task, I will 
endeavour to complete Guide.pod, and Guide/Example.pod during my 
recreational Perl development time (not as abundant at present as it 
once was ;-)), and construct a skeleton of Guide:: distributions based 
on the old modules list.

But first, back to reinventing some more wheels ;-).
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Future of the "Module List"

[Sam Vilain]

I nominate the
 Review::*
Namespace for author-submitted module indexes and in-depth reviews, in 
POD format.  I think this has a number of advantages.  Let's use the 
infrastructure we already have, no?

The .pm versions of these modules could potentially contain lists (in 
YAML format of course) for use by the indexing systems, which would, 
after double checking, be used as a master data source for the 
auto-generated indexes and modules lists.

This probably needs to be prototyped a little, and a model review module 
(say that 5 times quickly) posted before reviews start coming in in earnest.

Sam.
Randy W. Sims wrote:
On 7/14/2004 5:51 PM, Tim Bunce wrote:
On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote:
On Wed, 14 Jul 2004, A. Pagaltzis wrote:

* Dave Rolsky <[EMAIL PROTECTED]> [2004-07-14 19:26]:
Some of them _are_ registered, but that document you're
referring to hasn't been regenerated since 2002/08/27!  I wish
the CPAN folks would just remove it if it won't be generated
regularly.

Does anyone else here think that the list should probably just be
done away with entirely?


The _file_ should go, yes. The concept of registering modules is 
different.


--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: not-so-plain documentation

[Sam Vilain]

A. Pagaltzis wrote:
* Eric Wilhelm <[EMAIL PROTECTED]> [2004-06-25 05:11]:
 

I've seen pod2usage() and this would work, but most of these
scripts have some defaults set for variables that can be
changed with the GetOptions flags and I'd like to show these
defaults at least in the help message.
   

You are looking for Pod::Constants.
 

Or even Scriptalicious...
http://search.cpan.org/dist/Scriptalicious/
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Module meta data

[Sam Vilain]

khemir nadim wrote:
Hi,
could someone, please, tell me how some modules get meta data like "module
is a devloper release" and the DLSIP definitions so I can get some of my
modules listed on search.cpan.org. All this information must be right in
front of me but it seems I have a temporary doc blindness.
I'm also curious about how many made the move to Module::Build.
 

For developer releases, include an underscore in the version number.
Eg
$VERSION = "2.07_04";
The version will be indexed and displayed on CPAN as the head release,
but will not automatically trash systems via CPAN.pm.
Kudos to whoever put this feature into CPAN btw.
For the meta information, upgrade to a new ExtUtils::ModuleMaker.
I've used Module::Build in a few modules that I've released.  It's
smashing, once you've got shell aliases for "perl Build test verbose=1",
etc (`make test' was SO much quicker to type ;-)).  It introduces
another dependancy, but IMHO it's well worth it for dropping the
dependancy on a local Makefile guru.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Application framework namespaces

[Sam Vilain]

Lincoln A. Baxter wrote:
Does it make sense to create a new generic TLNS into which one might
hope to eventually see all such Frameworks migrated, or, should we just
go for our own new TLNS?
 

Sorry if I'm flogging a dead horse, but IMHO just pick a name, and make 
sure that you include a good introduction that weighs up the pros and 
cons of your module / system / framework versus all the others that you 
reviewed on your main POD file.  Having L style links in 
the intro will assist a person looking at the module to zip around the 
differing modules to perform a particular task.

It was said before, but I'll repeat it - seperating out the logical 
components of the framework into seperate distributions (and perhaps 
releasing a Bundle:: to get the lot) would be well worthwhile.

--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: PerlHack - Adding new flag into a SV

[Sam Vilain]

No, weakrefs cast backref magic onto their target to avoid this 
problem.  When the reference count drops to zero the magic ensures that 
the weakref is set to undef.

See Perl_sv_rvweaken() in sv.c for more.

Sam.

Orton, Yves wrote:

> From: "Orton, Yves" <[EMAIL PROTECTED]>
> > > I thought you are just automagicaly weaken()ing the referenced
> > > stored in the tied hash??? Something like package
> Hash::NoRef; use
> > > Scalar::Util qw(weaken); require Tie::Hash; @ISA = (Tie::StdHash);
> > > sub STORE {   $_[0]{$_[1]} = $_[2];  
> weaken($_[0]{$_[1]}) if (ref
> > > $_[2]);
> > > }
> > > 'And that\'s it!';
> > > Am I missing something?
> >
> > Itll segfault under many circumstances.
> >
> > yves
>
> Then you should report an error in Scalar::Util.
>
> Do you have an example script that segfaults?

Maybe you were thinking I meant a problem with your code. I meant a 
problem with the entire approach. IMO weak refs are not the greatest 
solution to the problems that they are usually used for. Often there 
are much better approaches that don't involve risking segfaults.

Anyway, :-)
Yves



--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: New module: Scriptalicious

[Sam Vilain]

Thanks all for your feedback.  I have added a "SEE ALSO" section that 
includes the feedback from this list and released version 1.01.  It now 
also accepts a program version to be passed in the normal way (ie, in 
$main::VERSION).

--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

New module: Scriptalicious

[Sam Vilain]

lly to the
  script.

  abort "won't go to sea in a storm"
  Prints a short program usage message (extracted from the POD 
synop-
  sis) and exits with an error code.

  moan "weather is miserable"
  Prints a warning to standard error.  It is preceded with the text
  "warning:".  The program does not exit.
  barf "hit an iceberg"
  Prints a warning to standard error.  It is preceded with the text
  "warning:".  The program does not exit.
  run("command", "arg1", "arg2")
  Runs a command or closure, barf's with a relevant error 
message if
  there is a problem.  Program output is suppressed unless 
running in
  verbose mode.

  run_err("command", "arg2", "arg1")
  Same as run, but returns the error code rather than assuming that
  the command will successfully complete.  Again, output it sup-
  pressed.
      capture("command", "1gra", "2gra")
  runs a command, capturing its output, barfs if there is a 
problem.
  Returns the output of the command as a list.

  capture_err("command", "foo")
  Works as capture, but the first returned item is the error 
code of
  the command ($?) rather than the first line of its output.

  Usage:

 my ($rc, @output) = capture_err("somecommand", @args);

AUTHOR
  Sam Vilain, [EMAIL PROTECTED]
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: defining 'constants' at run time

[Sam Vilain]

On Fri, 05 Mar 2004 00:05, Simon Cozens wrote;

  > However, if the programmer doesn't bother to explain what that
  > reason is, it's natural to assume that he's just being weird.

Q: What's the difference between an object methodologist and a
   terrorist?

A: You can negotiate with the terrorist. 

:)
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  Only presidents, editors and people with tapeworms have the right to
  use the editorial "we"
MARK TWAIN

Re: defining 'constants' at run time

[Sam Vilain]

On Thu, 04 Mar 2004 21:55, Orton, Yves wrote;

  > Well, people who spend a lot of time on the message boards helping
  > out get a lot of questions like:
  >    "How can I replace every letter 'o' not preceded by 'f' and not
  > followed by an 's' without using index, subtr, or a regex."
  > The useless answers are typically things like 
  >   "Very very carefully" 
  >   "With a piece of camembert and a two foot length of string" 
  > The useful answers are typically like 
  > "Why on earth do you want to do such a silly thing. USE THE
  > FRIGGIN REGEX ALREADY." 

To the programmer who has some real reason not to use the regex
engine, that you don't know about, none of the above are useful.
On the other hand,

 sub doit {pack("C*",(map{($a!=102)&&($_!=115)&&($b==111)&&($b=118);
 ($q,$a,$b)=($a,$b,$_);$q}unpack("C*",$_[0])),$a,$b)}

would either be entirely what they're after, or speak aloud as an
adequate answer to why s/([^f])o([^s])/${1}v${2}/g is usually better.

To broad-handedly cast aside the the bearer of a question's approach
as flawed is incredibly closed minded.  Pretending that you know best
for their situation is at worst arrogant and at best naive.

Remember - harmony, melody, chords[1].  We are each perfecting a
symphony in our own direction.
(see also http://www.perl.com/pub/a/2000/10/23/soto2000.html)
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  With the exception of capitalism, there is nothing so revolting as
  revolution
GEORGE BERNARD SHAW

Re: Reshaping the modules list: a starting point, help remove the bias.

[Sam Vilain]

On Wed, 25 Feb 2004 02:32, Leon Brocard wrote;

  > I only skimmed the discussion before. What problem are you trying
  > to solve?

Locating and selecting a module to perform a particular task can be
time consuming, and daunting for the novice.  Authors often don't find
what they want, and end up re-inventing wheels unnecessarily, when
they could be (and I would guess would rather be) re-inventing
suspension coils and inventing low speed differentials.

Perhaps you're personally happy with search.cpan.org, but a little
extra directory and indexing information can't hurt for those who
can't discern the coding prowess of the author at a single glance at
an API, and who don't hang out with Perl geeks for 90% of their waking
hours.

The relevant review information may be out there on use.perl.org,
perlmonks.org, etc, you might say, but if they are all in one place
they are more likely to be kept current.

It might make CPAN look a bit "tidier" as well :-).
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Sarcasm is not the lowest form of wit.  Sarcasm is the sour cream of
wit.  Puns are the lowest for of wit, for which someone should be
drawn and quoted.
  - Fred Allen (adaptation)

Re: Reshaping the modules list: a starting point, help remove the bias.

[Sam Vilain]

Ah, there's also no math or statistics sections there.  Please,
someone in the field beat me to it :)
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Beauty is only skin deep, but Ugly goes straight to the bone.

Reshaping the modules list: a starting point, help remove the bias.

[Sam Vilain]

Hi all,

I've performed an initial re-work of the modules list.  Please look
over the sections of the list that you are most in touch with and
provide feedback.

This is a brainstorming phase only; please provide suggestions and not
*just* negative criticism (both is OK, but please be constructive).
Preferably in the form of the section as a YAML compliant data
structure, as the below is.  I'll be going through the chunks and
modifications that people suggest and collating it into a single list
and republishing as time permits.

Hopefully it's fairly obvious what I've done with the different
sections of the old list.  There are fewer top level categories, but
more sub-categories - and the possibility of sub-sub-categories.  Some
sections I'm not so in touch with, or wasn't feeling particularly
inspired about at the time, that I've left alone.

After this stage, I'll try and fit the modules from the existing lists
and the Phalanx project into it one by one, and see how I get on.

Core Perl language modules and extensions:

   - internal packages
   - language mutations
   - Perl 6-like features

Code development and documentation tools:

   - Editor extensions
   - Test suite systems
   - POD processing
   - POD for more than just API docs
   - Control Flow Utilities (callbacks and exceptions etc)

Pure data and structures:

   - Pure algorithm implementations (c.f. C++ STL)
   - Class generator frameworks
   - Parameter parsing modules
   - Data Schema modules - tree-based (eg XMLSchema)
   - Data Schema modules - general (eg YAML::Schema)
   - Code modelers and CASE tool plug-ins

String and Text Processing:

   - Parsing modules
   - Indexing modules
   - Searching modules
   - Natural Language Text Processing
   - Internationalisation and Localisation

Databases, marshalling and persistence:

   - persistent hashes
   - structured data marshalling
   - SQL abstraction frameworks
   - Object Databases
   - Object/Relational mappers & hybrids
   - Prevayler-style storage (antidatabases)

Networking - raw communication, including IPC:

   - Shared memory solutions
   - Pipes 
   - Sockets
   - Datagrams
   - Object Request Broker mechanisms

Networking - protocol implementations:

   - RFC based
   - other standards based

Networking - accessing services:

   - Mail and Usenet News
   - XML services
   - YAML-RPC services

Networking - providing services:

   - Server and Daemon Utilities
   - Web Services Frameworks:
  - Apache:
 - Apache PerlHandler modules
 - Apache PerlInitHandler modules
 - Apache PerlAuthenHandler modules
 - Apache PerlAuthzHandler modules
 - Apache PerlAccessHandler modules
 - Apache PerlTypeHandler modules
 - Apache PerlTransHandler modules (May also include a
   PerlHandler)
 - Apache PerlFixupHandler modules
 - Apache PerlLogHandler modules
 - Apache PerlChildInitHandler modules
 - Apache Server Configuration
 - Apache Database modules
 - Interfaces and integration with Apache C structures and
   modules
 - HTTP Method handler
  - OpenFrame
  - etc, submissions welcome :)
   - Web Services Components:
  - Lots of the Apache sections from above could be moved here
   - Authentication, Security and Encryption:
  - Authentication Systems
  - Encryption algorithm implementations
  - Security interfaces

Networking - administering services:

   - Watchdog and Monitoring tools
   - Development and Debug tools
   - Miscellaneous Apache modules

User Interfaces:

   - Command line interfaces
   - Configuration files
   - Interactive character and terminal based UIs
   - Tk toolkit
   - Gtk toolkit
   - WxWindows toolkit
   - other graphical toolkits

Imaging, Images, Multimedia:

   - Sound manipulation
   - Image Conversion
   - Raster Image Manipulation
   - Vector Image Manipulation
   - Drawing and Graphing utilities

Interfaces to and emulations of other languages:

   - The XS C interface
   - XS alternatives
   - C, C++
   - Java
   - JavaScript / JScript / ECMAScript 
   - ...

Platform interface:

   - File Names
   - File Handle, Directory Handle and Input/Output Stream Utilities
   - File Systems interfaces
   - File Locking
   - File Archiving
   - File Compression
   - File Conversion
   - Hardware Support:
  - Generic device APIs, eg modems
  - Specific Hardware/Device drivers

Multiprocessing:

   - Time-slicing oriented
   - Threading oriented
   - Fork() oriented

Operating System Support:

   - UNIX system platform specific modules
   - UNIX variants
   - Win32 (MicroSoft Windows) platform specific modules
   - VMS/OpenVMS platform specific modules
   - mainframe platforms
   - Embedded / hand-held platforms

Interface Modules to Commercial Software:

   - ?

Misfits and Oddballs:


-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(in

Reshaping the modules list: the current situation

[Sam Vilain]

2) Perl Core Modules, Perl Language Extensions and Documentation Tools
   
   (CORE, DynaLoader, etc)

   * Perl Pragmatic Modules (constant, integer, strict et al)
   * [C] Experimental pragmatic modules live in the ex:: namespace
   * Perl Language Extensions (everything from Safe to
 Attribute::Handlers to Inline to Exporter::Import)
   * The Perl Compiler (B, O, B::Graph, etc)
   * Source Code Filters
   * Thread support
   * Module Support
   * Documentation Tools

3) Development Support

4) Operating System Interfaces, Hardware Drivers

   * Platform Specific Modules
   * Portable Digital Assistants
   * Hardware related modules

5) Networking, Device Control (modems) and InterProcess Communication

6) Data Types and Data Type Utilities

   * Data Type Marshaling (converting to/from strings) and Persistent
 Storage

7) Database Interfaces

   * DBIx -- Extensions to the DBI
   * Tied Hash File Interfaces

8) User Interfaces

   * Major Character User Interface Modules
   * Tk X Windows User Interface Modules
   * Modules in the realm of Tk but with a separate namespace
   * Other Major X Windows User Interface Modules
   * Abstract Graphical User Interfaces modules

9) Interfaces to or Emulations of Other Programming Languages

10) File Names, File Systems and File Locking (see also File Handles)

11) String Processing, Language Text Processing, Parsing and Searching

* Language text related modules
* Other Text:: modules (these should be under String:: but
  pre-date it)
* Stemming algorithms
* Natural Languages
* Specific Natural Languages

12) Option, Argument, Parameter and Configuration File Processing

13) Internationalization and Locale

14) Authentication, Security and Encryption

15) World Wide Web, HTML, HTTP, CGI, MIME

* Apache PerlHandler modules
* Apache PerlInitHandler modules
* Apache PerlAuthenHandler modules
* Apache PerlAuthzHandler modules
* Apache PerlAccessHandler modules
* Apache PerlTypeHandler modules
* Apache PerlTransHandler modules (May also include a PerlHandler)
* Apache PerlFixupHandler modules
* Apache PerlLogHandler modules
* Apache PerlChildInitHandler modules
* Apache Server Configuration
* Apache Database modules
* Interfaces and integration with Apache C structures and modules
* HTTP Method handler
* Watchdog and Monitoring tools
* Development and Debug tools
* Miscellaneous Apache modules

16) Server and Daemon Utilities
17) Archiving, Compression and Conversion
18) Images, Pixmap and Bitmap Manipulation, Drawing and Graphing
19) Mail and Usenet News
20) Control Flow Utilities (callbacks and exceptions etc)
21) File Handle, Directory Handle and Input/Output Stream Utilities
22) Microsoft Windows Modules
23) Miscellaneous Modules
24) Interface Modules to Commercial Software
25) Bundles



-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

A pipe gives a wise man time to think and a fool something to stick in
his mouth.
 - anon.

Curators of modules, changing namespaces, APIs vs Distributions

[Sam Vilain]

I was only talking about curators of the information about the
modules, not curators of CPAN.  That sounds like far too nasty a job,
and as has been said, it has already been hashed and rehashed ad
nauseum.

We also can't go enforcing rules about namespace - the (non-CPAN.pm
indexed, search.perl.org) namespace is already pretty much raped.  All
you can do as an author is boycott badly named modules / re-release
them under a more correct name :).  The indexing should follow the
community, not define it.

Also, some people seem to have in their minds no distinction between a
distribution name, and the name of the module.  They are independant.

For instance, the Compress-Deflate distribution could install
Compress::Deflate, which provides raw entry points to the commonly
described algorithm, Compress::Gzip, which provides Perlish wrapper to
Compress::Deflate and the Gzip header format, and Compress::Zlib::PP,
which emulates the Zlib interface for legacy code... indeed, in the
future it might also install a compatibility stub at %Compress::Zlib::
that the installation of the "real" Compress-Zlib distribution
replaces.  I said could, not "the forthcoming release of
Compress::ZlibPP ought to".  It's just an example.

In summary;

   - the Distribution refers to the _implementation_ and may be
 completely different from the delivered modules (eg, libwww)

   - the name-space chosen for the installed modules refer to the
 *API*

   - unfortunately, currently it is not possible for more than one
 module deliver the same API - except by carefully arranging @INC

Once you have changed the API of a module significantly, you should
really be releasing the new API in a different name space.  As there
is a current lack of a clear, *widespread* notation for requiring an
API version, this is a sensible strong suggestion to module authors,
especially for modules that are expected to be in heavy use.  [unless
you already used the API version API in your module's Synopis' API,
then you have the freedom]

This practice is followed for long-standing and core modules, of
course.  Just ask Tim if he'd consider enhancing the DBI API and
releasing it as a backwards-incompatible DBI 2.0.

I think I've just re-defined my mapping exercise to mapping APIs and
not distributions.  But as an AP, it's the I that you're interested in
anyway - and AP's are the primary target market of this information.
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  The rich will do anything for the poor but get off their backs.
KARL MARX

Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]

[Sam Vilain]

On Tue, 17 Feb 2004 02:53, A. Pagaltzis wrote;

  > > (At least the Perl-XML folks got it right, props to Grant
  > > McLean!).
  > You don't put yourself in a particular spot on Google, you just
  > get there by being linked from lots of places. You have zero
  > control over whether and where you appear in the results for a
  > query.

That's not entirely true.  It is by design that pages - especially
off-site pages that contain text content on a relevant subject, and
linking to an article will increase the ranking of the target article
in Google.  AIUI, this was Google's flagship feature in the early
days.  No doubt the others have since followed suit to varying
degrees.

In face, the "better" search engine optimiser companies out there work
(as well as doing easy things like making meta information
appropriate) by producing a series of "micro-sites" that have a page
or two of relevant information, then link to the target site, and to
each other.

So, editorial content may have the desired effect of raising search
engine rankings; especially the more they are linked to as a "primary"
source of this information.
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

No man can prove upon awakening that he is the man who he thinks went
to bed the night before, or that anything that he recollects is
anything other than a convincing dream.
 -- Richard Buckminster Fuller

Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]

[Sam Vilain]

On Mon, 16 Feb 2004 14:24, Dave Rolsky wrote;

  > I like what you're proposing, but I think the best way to do this
  > is to simply start it, and then try to get the CPAN folks to buy
  > into it once it's established as being useful.

I couldn't agree more, but I didn't really want to start without
bouncing the idea around first.  

  > Or instead of cpan.org, maybe it could be a *.perl.org site.
  > There's a lower barrier to entry here, I think.

The prototype, sure, astute suggestion.  I see this a bit like a CPAN
mapping project, and if it is successful it will be considered auch a
useful part of the archive that they would be distributed together :)

Anyway, enough said on the idea ...
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  Not what I have, but what I do is my kingdom.
THOMAS CARLYLE

Re: pure perl Zlib

[Sam Vilain]

On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote;

  > Autrijus suggested Compress::Zlib::PurePerl, which I think is
  > reasonable.

...but it doesn't use Zlib!  :)   Compress::Gzip?
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

If cars had followed the same developmental path as computers, a Rolls
Royce would cost $100, get a million miles per gallon, and explode
once a year, killing everyone inside.

Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]

[Sam Vilain]

 So, content should be written that pays attention and refers the
 programmer to communities that have chosen to thrash out a
 particular path, as well as noting the upstarts that are trying
 something new.

  e) No personal attacks,

  f) Try to distinguish between commenting on APIs and
 implementations; but please, do compare both where useful :)

  g) Keep as much bibiolgraphy information as possible.  Link to as
 many relevant articles, and opinion articles as you can, within
 reason.  Especially take note of large OSS projects or other
 modules on CPAN that use the works as a base, for "prime
 examples".

  > The text file is out of date. The underlying database isn't:
 [...]
  > Please work with the PAUSE system, and Andreas and myself, to
  > enhance what already exists (which includes a UI for module
  > authors to pick which category they want the module in).

I'd be honoured to.  I think that the plan you propose would be an
excellent step forward, and whether or not the editorial plan gains
acceptance then it has merit.

Unfortunately right now I have to move house :-) but I should be able
to dedicate at some time this week to research and kick-start this
recategorisation effort.
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  The most incomprehensible thing about the world is that it is
comprehensible.
ALBERT EINSTEIN

OK, so we've decided that the right modules are too hard to find.

[Sam Vilain]

  ___ 
 / _ \
| | | |_  _   
| |_| ||\ | ||___ 
 \___/ | \| |___ |___ upon a time, the Perl 5 modules list was an
excellent resource for those seeking to do anything non-core with
Perl.  However, it has not kept pace adequately with the needs of the
community.

I propose, what we do about this situation is :

  - expand the modules list into a new section of the www.cpan.org
site, by;

  - deciding if the current categories are good enough 'in this day
and age'; using the current list as a starting point, go through
each category and decide whether it is a useful grouping any more.

This will ideally also involve individuals with experience with
other languages trawling over the appropriate CPAN equivalents, ie
PEAR, RAA, etc, and providing nice, *brief*, informative reports
on their structure.

We will then hopefully have a half-decent list of categories.
This process should be quick, perhaps reporting back its progress
to the list every few days until there is a general consensus.

  - encourage curators to step forward, or groups of curators, for
each category; possibly even create mailing lists for people with
a general interest in the technology in that category; to field
questions about naming for new modules to fit into each category.
These curators must have the power to update the contents of the
relevant portions of the www.cpan.org site.

The idea would be to have each category something like the
http://poop.sourceforge.net/ site - but on a standard template to
lend it more credibility.  Ideally with space for user feedback.

I would hesitate to seed the listing of actual modules on the current
long Perl 5 modules list.  Factors such as the usage that the module
has seen, whether long standing bugs were ever fixed, whether a better
module has come along since and gained widespread acceptance, etc need
to be taken into consideration.  Many popular modules are missing from
the list altogether.

The Phalanx project have a good list too, if much shorter.  Such
modules would likely feature as "recommended" in the relevant
sections.

If anyone who knows of any similar re-categorisation efforts (is there
anything useful on PerlMonks perhaps?), now is the time to bring them
forward.
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  Once ... in the wilds of Afghanistan, I lost my corkscrew, and we
  were forced to live on nothing but food and water for days.
W C FIELDS

Re: Testing output to STDOUT and STDERR

[Sam Vilain]

On Tue, 10 Feb 2004 00:57, Orton, Yves wrote;

  > Its worth noting that this approach wont actually grab everything
  > on the tied filehandles.  There are enough ways to bypass the tie
  > that you have to do a lot more than that to get the majority, and
  > even then there is stuff that will still bypass it.

Yes, that is worth noting; but I'd consider all code that bypasses the
tie to be bugs or an inappropriate test case :-).

I'm just a little curious about the ways that this could happen; see
if you can add to this list.

  a) something grabs the file handle number via fileno(STDOUT) - or
 has a hardcoded `1' for STDOUT - and prints to that directly
 using stdio (now, wouldn't that have to be XS code?)

  b) something uses syswrite(STDOUT)

  c) something written via system("") prints to STDOUT

  d) something has already DUP'ed the file handle (ie open FOO,
 ">&STDOUT") and prints to it normally

  > Its very annoying actually that there isnt a reliable and clean
  > way to intercept STDOUT/STDERR properly. (IMO)

Other than fork and IPC, which bites and doesn't play well with the
test suites... try forking in the middle of a Test::Builder run.
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Activity is the politician's substitute for achievement.
 - anon.

Re: Class::HPLOO - Need advice in attributes and object persistence for OODB.

[Sam Vilain]

Pixie and Tangram implement Prevalyer-style persistence without the
deficiency you speak of.

I strongly recommend that you take a good, long, hard look at Pixie.
Figure out if you really need to have the logic that drives your
object's getters, setters, etc bound to your persistence mechanism.

Otherwise, if you do want to keep them bound, there are some very well
established systems for modelling such systems - Alzabo would be well
worth a look.

This wheel has been re-invented far too many times already.

Sam.

On Mon, 09 Feb 2004 21:23, Graciliano M. P. wrote;

  > I have just released Class::HPLOO 0.11, with support for attributes
  > definitions.
  > 
  > I have inserted the attribute support to build an automatically object
  > persistence system for OODB through Class::HPLOO.
  > 
  > First, some example of the new syntax for attributes:
  > 
  > use Class::HPLOO ;
  > 
  > class User {
  > 
  >   attr( str name , int age , &my_word_type user , &my_word_type pass , 
array
  > links ) ;
  > 
  >   ## my personalized type:
  >   sub my_word_type ($value) {
  > $value =~ s/\W//gs ;
  > $value = lc($value) ;
  > return $value ;
  >   }
  > 
  >   ## initializer for the object:
  >   sub User ( $name , $age , $user , $pass , @links ) {
  > ## through set method:
  > $this->set_name($name) ;
  > $this->set_links(@links) ;
  > 
  > ## through tied key:
  > $this->{age} = $age ;
  > $this->{user} = $user ;
  > $this->{pass} = $pass ;
  >   }
  > 
  >   ## some method:
  >   sub dump_user {
  > print "USER: $this->{user}\n" ;
  > print "  name: $this->{name}\n" ;
  > print "   age: $this->{age}\n" ;
  > print " links: ". join(" ", $this->get_links) ."\n" ;
  > print "\n" ;
  >   }
  > 
  > }
  > 
  > ## USAGE:
  > package main ;
  > 
  >   my $user = new User( 'Joe' , '30' , 'JOE' , 1234 , 'www.perl.com' ,
  > 'www.cpan.org' ) ;
  >   $user->dump_user ;
  > 
  >   exit;
  > 
  > 
  > The idea of the attributes, is to give a type to them and the setter 
and
  > getter methods. Soo, with a method to access or set the attributes we 
can
  > know when they are changed or not, soo will be possible to define if an
  > object is "dirty" or "clean", needed to make the persistent proxy 
system.
  > 
  > The DB communication will be made through HDB (a module that I haven't
  > released yet, for now it's just for our internal use in our projects, 
but
  > will be there for the public). With HDB we don't use SQL, or don't need 
to
  > use, to work with the DB, we just use commands and syntax based in Perl 
it
  > self. Soo, we can work with any type of DB without need to care with 
the
  > nuances of each SQL or behavior of each DB type. Soo, the persistence 
system
  > will work in any DB, from SQLIte to MySQL and Oracle.
  > 
  > But the seconde idea, is to make an easy and simple way to create a
  > persistence class. For example, in Java the easier framework for 
persistence
  > is the "Prevayler" system (not made by SUN), where we just declare the 
clas
  > with that:
  > 
  > public class User implements Serializable {
  >   ...
  > }
  > 
  > And bingo, the persistence system is done. But "Prevayler" use a log
  > persistence system, soo it doesn't use DB, just a log with all the 
commands
  > send to an object. Soo, when the system is reloaded, the objects are 
rebuild
  > with all the commands in the log.
  > 
  > But for a true persistent system, that works in different processes,
  > different machines and for big systems, it really need to be made with 
a
  > true DB.
  > 
  > But how to to make this simple and easy in Perl?
  > 
  > I'm talking about the declaration and syntax definition for that. Since 
how
  > to build what happens behind the framework is just the easy part, 
specially
  > with the resources that I have here.
  > 
  > For example, in Perl we don't have the "implements" resource for 
classes.
  > But with just an "extends" system it won't work too, since the 
persistence
  > system need to change the setter and getter methods, also inserting
  > "mask/layer" classes (proxy) when an object has some association with 
other
  > object.
  > 
  > But the biggest problem in the definition, is how to just define simple 
like
  > in the "Prevayler" example, and also define the DB connection?
  > 
  > Soo, before start to work on that, I'm just asking for some opinion 
from the
  > authors about the persistence system and the new attribute definition.
  > 
  > Thanks in advance.
  > 
  > Regards,
  > Graciliano M. P.
  > 
  > 
  > 
  > 
  > 

-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  I never loved another person the way I loved myself.
MAE WEST

Re: Testing output to STDOUT and STDERR

[Sam Vilain]

On Mon, 09 Feb 2004 14:00, Andy Lester wrote;

  > > While writing tests for some of my code, I was faced with the issue
  > > of capturing what the code sends to STDOUT and STDERR. As I have not
  > > found a module to make it easy, I wrote a trivial code to do it. It
  > > is used like this:
  > I'm not sure what you're actually trying to test.  If you're testing
  > test modules, look at Test::Builder::Tester.

No, something that ties STDOUT so that code can print to it, and you
can test that the right thing was printed; I've had to do this before,
and ended up not going through the CPAN ropes for this module:

{
package Capture;

sub new {
my $class = shift;
my $self = { stdout => "" };
bless $self, $class;
return $self;
}

sub capture_print {
my $self = shift;
$self->{so} = tie(*STDOUT, __PACKAGE__, \$self->{stdout})
or die "failed to tie STDOUT; $!";
}

sub release_stdout {
my $self = shift;
delete $self->{so};
untie(*STDOUT);
return $self->{stdout};
}

sub TIEHANDLE {
my $class = shift;
my $ref = shift;
return bless({ stdout => $ref }, $class);
}

sub PRINT {
my $self = shift;
${$self->{stdout}} .= join('', map { defined $_?$_:""} @_); 
}

sub PRINTF {
my ($self) = shift;
print STDERR "OUCH @_\n";
my ($fmt) = shift;
${$self->{stdout}} .= sprintf($fmt, @_)
if (@_);
}

sub glob {
return \*STDOUT;
}
}

Though, I must say that I prefer his API.  The above was really just a
quick hack based on what I'd extracted out of the ePerl code base.

I'd call it something like IO::Capture if I were to CPAN it.
IO::Seize isn't quite right, but "seize" is definitely a good Perlish
name for the function.

Note that php has a built-in function to do just this.
-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

  Time is an illusion perpetrated by the manufacturers of space.
GRAFFITI

Re: "would you$please shut the door?"

[Sam Vilain]

On Wed, 14 Jan 2004 12:03, A. Pagaltzis wrote;

  > Of course there are also cases where you'd want more text than
  > just the please to dis-/appear depending on its presence, but they
  > we're zeroing in to something close to a fullblown templating
  > system, and we wouldn't want another one of those on CPAN.. :-)

No, especially when Locale::Maketext is so very well suited to this
task...
-- 
Sam Vilain, [EMAIL PROTECTED]

  Give a small boy a hammer and he will find that everything he
encounters needs pounding.
ABRAHAM KAPLAN

Re: "would you$please shut the door?"

[Sam Vilain]

On Tue, 13 Jan 2004 18:25, david nicol wrote;

  > Is this an appropriate post to module-authors or would it
  > be better taken to fun-with-perl? It's a module announcement...
  > Acme::please is for randomly inserting " please" into
  > your output via a tied scalar.  The string and printing percentage
  > are both configurable (see the documentation.)

Surely this should be in Lang::Courtesy::Random::En?
-- 
Sam Vilain, [EMAIL PROTECTED]

Sarcasm is not the lowest form of wit.  Sarcasm is the sour cream of
wit.  Puns are the lowest form of wit, for which someone should be
drawn and quoted.
  - Fred Allen (adaptation)

Re: namespace for module

[Sam Vilain]

On Wed, 03 Dec 2003 16:21, A. Pagaltzis wrote;

  > Probably DBIx::SchematicXML::(Import|Export|Diff) or something
  > like that.

Yuck.  How about XML::Map::DB or XML::Map::SQL.

The original name confuses me slightly - "XML Object" seems to me to
be a fundamental mismatch of concepts, like giving a flat purple to
the time.

Do you mean an XML `Tree', `Fragment' or `Element' perhaps ?

Out of interest, could you pass your module a DOM compliant XML
Document, eg from Xerces/Sablotron/etc to work with ?
-- 
Sam Vilain, [EMAIL PROTECTED]

  If you are out to describe the truth, leave elegance to the tailor. 
ALBERT EINSTEIN

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

[Sam Vilain]

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?!


-- 
Sam Vilain, [EMAIL PROTECTED]

  If you cant learn to do it well, learn to enjoy doing it badly.
ASHLEIGH BRILLIANT

Re: Another sticky module naming issue

[Sam Vilain]

On Mon, 15 Sep 2003 17:25, Jenda Krynicky wrote;

  > Like http://search.cpan.org/search?query=Data::Lazy&mode=module 
  > right? :-)

Yes, exactly.

  > The only thing in Defer.pm that I do not have in Data::Lazy is the 
  > attribute syntax. Maybe it'd be better to add that to my module 
  > instead of uploading a brand new module :-)

Does your module untie the original object when it is read the first
time, where it could?  This avoids the tie overhead on every
subsequent access.

Do you provide any interface other than tie?  For instance, I have an
`overload' interface that passes method calls and accesses onto the
lazy object, so you can do stuff like this:

my $dbh = defer { DBI->connect(@dsn) };

Changing the `defer' to `do' to have it execute immediately is one
nice feature of this syntax.

  > Patches welcome, otherwise I'll have a look at Defer.pm when I get 
  > some free time and steal the attribute stuff from there ... that is 
  > if Sam doesn't mind ;-)

Not at all, please go ahead.
-- 
Sam Vilain, [EMAIL PROTECTED]

It is unwise to be too sure of one's own wisdom. It is healthy to be
reminded that the strongest might weaken and the wisest might err.
 -- Mahatma Gandhi

Re: Another sticky module naming issue

[Sam Vilain]

> Isn't this the same as Markov's Object::Realize::Later ?

No, but that module certainly helps solve a similar set of problems;
it uses a formal object that populates itself in a defined manner,
instead of a tied scalar `tripping an alarm' that calls the sub to get
itself realized.

Very interesting, this more complex/complete solution may end up
avoiding some of the caveats of my approach.  Thanks for the pointer.

> To my understanding it's a lot more like Simon Cozens's
> Tie::Discovery, only with single scalars rather than hash
> entries.

Yes, this is exactly right.  I'll check out Simon's work to see if I
can fit the scalar version in gracefully.  richardc++

> Mmm. The perl community seems to be bad at finding suitably
> descriptive names for things, given the seeming inability of
> later programmers to find them, and save re-inventing wheels.

No kidding.  Perhaps the low volume of mail on this list is related.

> This seems on first inspection to be a form of Memoize, but
> providing access via variables (presumably tied, and therefore
> less efficient) than via functions.  Memoize is part of the Perl
> core as of 5.8.0 .

No, memoize remembers the result from a function call with a set of
indexed arguments and caches them.  This module _replaces_ a scalar
(eg, a reference to an object) with the result of a sub (eg, the
object) when it is accessed.  Chalk and cheese, I'm afraid.  The
efficiency issue is also a moot point, because after FETCH is called
once, the tied variable collapses into a regular scalar.

Besides, according to qq«package foo;
sub TIESCALAR { my $class = shift; bless { foo => shift }, $class; }
sub FETCH { return $_[0]->{foo}; }
package main;
use Benchmark;
my $thingy; my $obj = tie $thingy, "foo", "bar";
timethese(1_000, { "tie" => sub { ($thingy eq "bar") for (1..1000) },
      "method" => sub { ($obj->FETCH eq "bar") for 1..1000 },
});», it's not dreadfully slower than a method call.
-- 
Sam Vilain, [EMAIL PROTECTED]

  Try to be the best of what you are, even if what you are is no good.
ASHLEIGH BRILLIANT

Another sticky module naming issue

[Sam Vilain]

Hi all,

Any ideas for a better name for this module?

NAME
   Defer - Defer execution of code until it is accessed

SYNOPSIS
 use Defer;

 # Attribute::Handlers interface
 my Defer $dbh : Defer = sub { DBI->connect(...) };

 # traditional tie interface
 tie $dbh, Defer => \$dbh, sub { DBI->connect(...) };

 # inline interface - this uses overload
 my $structure = { this => "that",
   Foo => defer { do_this() }, };

 # the first time $dbh is accessed, the sub will be called and the
 # value replaced.


DESCRIPTION
   This module implements `magic variables' that are only
   calculated when they are accessed.  This can be extremely
   useful for defering things like connecting to a database,
   or performing computationally expensive operations.

   So, the code that you are passing the variables does not
   *need* to know (but, unfortunately, *can* find out, lead­
   ing to other problems, see below) that the data isn't
   immediately available; the closure that you pass is called
   when you access it for the first time, and the result
   placed in the most efficient place for future reference.

   This concept is used by the Tangram internals to perform
   on-demand loading of data from the database, for instance.

Available at http://vilain.net/pm/Defer-0.01.tar.gz
-- 
Sam Vilain, [EMAIL PROTECTED]

Sometimes I think we're alone. Sometimes I think we're not. In either
case, the thought is staggering.
 -- R. Buckminster Fuller

Re: More on authors that don't respond

[Sam Vilain]

Perhaps you missed
<http://www.stonehenge.com/merlyn/LinuxMag/col30.html>, putting an
iterator behind a tied hash, giving you "each" as a single
iteration, or "keys" to get them all.
Yet Another Way. :)

OK, well if you're using a hash to iterate, then it's perhaps a
different type of iterator.  In Maptastic there is a map_each(&@)
method, which sets @_ to (each %hash) in the block.  This would work
with your tied hash approach, as the input would be ->isa("HASH").

However, I suppose that using the scalar form of `each', returning
just the key, would be the appropriate thing to use for map variants
that expect singular items.

So we've got:

Blessed objects:
$_->__next__(Object::Iterate)
$_->get_next(SPOPS-style)
$_->next(Tangram::Cursor, File::Iterator,
   Data::Iterator::EasyObj, etc)
Unblessed:
$_->()  (MJD-style, his hybrid blessed closures can be
 expected to ->can() one of the above)
scalar(each %$_)

Hmm, for completion, what about arrays?

I can see two possible semantics for arrays as iterators;

   shift @$_while (@$_)

   $_->[$i++]   while (exists $_->[$i]);

I think the latter is better, though it doesn't work with sparse
arrays.  Caveat emptor?
-- 
Sam Vilain, [EMAIL PROTECTED]

  Things are more like they are now than they ever were before.
DWIGHT D EISENHOWER

Re: More on authors that don't respond

[Sam Vilain]

>Further to the earlier discussion, I thought some might find this
>auto-response I got from mailing one CPAN author funny:
>-
>I am preparing to or have deployed with my National Guard unit for
> federal active duty.  I may not be able to access or read my email
Funny in an amusing way?  Or funny as bad?

Funny as in, now it's not about dead camels, rather hibernating
camels, an aspect the conversation did not really focus on.
Fortunately as he's looked after this responsibility it's not funny as
in bad.  There's also the distinctly unfunny side of it, and my
thoughts go out to Brian in that regard.

I now co-own everything in BDFOY's CPAN land, and his home page has a
"CPAN power of attorney" pointing at me or Randal.  What did you need
help with?

It's about Object::Iterate; I have a module to be released that will
supply some extra forms of map (eg, Tye McQueen's mapcar), and wanted
to produce iterative versions of them too.  Therefore, it would be
good to form a standardised set of semantics for iterators.

I quite liked MJD's semantics for using a CODE ref as an iterator; it
certainly makes the code simple.  OTOH, I appreciate that it's not OO
clean, so the Object::Iterate approach might be considered better by
some.  This calls for hybrid semantics IMHO.

The question is, what should those semantics be, and should/how can
Object::Iterate form a convenient `adapter' for the differing
conventions?

These are the conventions I've seen used:

->__next__(Object::Iterate)
->()  (MJD-style)
->get_next(SPOPS-style)
->next(Tangram::Cursor, File::Iterator,
   Data::Iterator::EasyObj, etc)

Also, there are some stickier points; such as - is it reasonable to
assume that if an iterator returns `undef' that it's finished?  Should
there be a similar set of conventions for resetting or un-getting
items from the iterator?
-- 
Sam Vilain, [EMAIL PROTECTED]

Real software engineers don't program in assembler.  They become
queasy at the very thought.

More on authors that don't respond

[Sam Vilain]

No, I'm not trying to flog a dead horse.

Further to the earlier discussion, I thought some might find this
auto-response I got from mailing one CPAN author funny:

-
I am preparing to or have deployed with my National Guard unit for federal
active duty.  I may not be able to access or read my email for extended
periods of time, and even then may be limited by time or security measures.
I cannot answer any questions about this deployment, the nature of our
mission, or a projected return date.  "Loose lips sink ship" ;)

Mail may not be saved depending on how long I have not read mail and
how much disk space I am using.

If you care to write to me, my physical address for mail delivery is

 ...

That mail will be periodically forwarded to me, or handled appropriately. 
Note that military censors will read anything that you write, and they
will take anything you say seriously. Don't make the FBI visit you.

-- 
Sam Vilain, [EMAIL PROTECTED]

  'Martyrdom' is the only way a person can become famous without
ability
GEORGE BERNARD SHAW

Re: what to do with dead camels ?

[Sam Vilain]

> It turns out that in June there were 4000+ hits on modules in the
could you please teach me how do you look such statistic?
Is it available for public?

Andy, why don't you talk with acme about getting such information
added to the CPANTS metrics... clearly it is something that authors
want to know.
-- 
Sam Vilain, [EMAIL PROTECTED]

  The rich will do anything for the poor but get off their backs.
KARL MARX

Re: Naming Advice - Devel::DebugPrint

[Sam Vilain]

"Barbie" <[EMAIL PROTECTED]> wrote:

> I have been busy tidying up and documenting my first module for CPAN and
> after a email from another author, noted that my first choice of name might
> be a bit confusing, so I thought 'Devel::DebugPrint' might be better.
   [...]
> Is Devel::DebugPrint an appropriate name or do I need a rethink?

Can it fit into the Log::Dispatch architecture perhaps?

To me a debug message is very much the same as a critical alert but
with less severity, perhaps so little that it gets snipped off at
compile time.

Just a thought.  If you restrict the scope to what you have described
I think the name is pretty appropriate.
--
   Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E  GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13

  Please dont ask me what the score is, Im not even sure what the game
is.
ASHLEIGH BRILLIANT

Re: name of perl in MakeMaker

[Sam Vilain]

Stephen Zander <[EMAIL PROTECTED]> wrote:

> Sam> Hi all, How do you return the name of perl in your module's
> Sam> Makefile.PL?
> If you're generating rules for the Makfile that will be produced,
> don't try to hardcode perl at all.  Rather use the PERL Makefile
> variable that MakeMaker has already gone to great pains to get right
> for you.

OK, I've tried this - the following code is an example of how to get
MakeMaker's variables in a Makefile.PL:

<<<<<<<<
use ExtUtils::MakeMaker;

# If this function is not called manually on older versions of
# ExtUtils::MakeMaker, it goes tits up.
ExtUtils::MakeMaker::full_setup();

my $mm = MM->new({
'NAME'  => 'Pod::Constants',
...
});

open TEMPFILE, "t/tempfile" or die $!;
print TEMPFILE, $mm->{FULLPERL},"\n";
close TEMPFILE;

$mm->flush();
<<<<<<<<

In the test script, you have to open "t/tempfile" to get the contents.

It's a hack, but it works.  Tested with 5.00503 and 5.6.1.

I fall back to the $Config{perlpath} and $^X variables in the event of a
failure with this method.

There should be an easier way.

Cheers,
--
   Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E  GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13

Hi, I'm a .signature virus!  Copy me into your ~/.signature, please!

name of perl in MakeMaker

[Sam Vilain]

Hi all,

How do you return the name of perl in your module's Makefile.PL?

I have a module (Pod::Constants) that needs to invoke perl as a part of
its test script.  If your perl is not called perl, but say perl5.00503,
then the test fails.

Is there an easy way around this?

Cheers,
--
   Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E  GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13

Hi, I'm a .signature virus!  Copy me into your ~/.signature, please!

Re: repost: RFC: CPAN::Grab

[Sam Vilain]

"Kurt D. Starsinic" <[EMAIL PROTECTED]> wrote:

> Just to be clear, one of the most use features of a .dpkg
> is the _versioned_ dependencies.  You can't build them
> automatically.  If you leave them out of make them up, then
> what you've got is no better than `make tardist'.  Which is
> pretty good.

You can specify package dependancies with MakeMaker, including version
numbers of required packages.  Surely that is enough information to build
up necessary depends: relationships?
--
   Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E  GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13

Re: repost: RFC: CPAN::Grab

[Sam Vilain]

Which reminds me.  Is anyone working on a CPAN debian package archive?

I remember Schwern making a joke about it after Ingy's plea for PPM help
at YAPC last year.  Did anything ever eventuate?

At the moment, many packages are being built by the debian project, but
it's far from ideal as they tend to be a version or two behind, and only
covering a very small proportion of CPAN.

Sam.

"Rhet Turnbull" <[EMAIL PROTECTED]> wrote:

> Sounds very useful. It's something I've wished for on more than one 
> occasion.  Regards,
> 
> --Rhet
> 
> 
> Original Message Follows
> From: Stas Bekman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: repost: RFC: CPAN::Grab
> Date: Wed, 06 Mar 2002 11:26:36 +0800
> 
> I've posted this about 6 months ago, but got no feedback. I guess I'll
> just go ahead and release the module.
> 
>  Original Message 
> Subject: RFC: CPAN::Grab
> Date: Thu, 6 Sep 2001 17:28:02 +0800 (SGT)
> From: Stas Bekman <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> CC: "Andreas J. Koenig" <[EMAIL PROTECTED]>
> 
> I've attached a new module (very small) called CPAN::Grab.
> 
> Andreas, any chance we can integrate it with CPAN dist?
> 
> Here is the doc, the questions are at the end.
> 
> NAME
>CPAN::Grab - Grab a bundle or a number of modules from CPAN and
>package them into one buildable tar.

Re: [ANNOUNCE] Module::Info 0.11

[Sam Vilain]

Hi there,

I may be beating a dead horse here, but you can easily extract stuff out
of the POD at runtime with Pod::Constants;

our $number;
use Pod::Constants
'THE MAGIC NUMBER' => sub { ($number) = m/(\d+)/ };

=head2 THE MAGIC NUMBER

There is a magic number, that number is 42.  

=cut

As you can see, the sub passed to Pod::Constant's import() function is a
closure that is passed all of the POD until the next command in $_.  You
can also give a reference to a hash, array or scalar, and slightly
different behaviour occurs.

I've found that using this I can avoid a fair amount of code duplication
and distill key coding concepts into a minimal number of places through my
work.

It's a long shot from elisp's method of tying of documentation and code
into the same data structure, but I never really liked that anyway.

On Sun, 3 Feb 2002 10:58:00 -0500
"Jay Lawrence" <[EMAIL PROTECTED]> wrote:

> Hi Michael,
> 
> I just had a quick look at your module - looks cool! I'll give this a
whirl> sometime soon.
> 
> On a tangential note - something I've been bringing up here 'n there is
the> notion that it would be really interesting if classes would supply
this and> more class/module-related info. In other words - runtime
documentation.> Method to return list of properties or methods in a class.
Method to return> detailed information about a property. We do this and we
can make the> creation of much more interesting run-time environments
easier.> 
> Really its just a case if a module wishes to offer run-time
documentation> they would have a few well known methods/functions. The
issue is deciding> and making those functions well known. :) I've
mentioned this briefly on the> POOP list and I see that P2EE might be
related (but they've got bigger> things on the - go I fear). I've thought
about maybe tying this to the> module's POD by looking to to a POD filter
thus saving duplication of> effort - but maybe introducting some influence
on how methods, etc. are> documented in POD.
> 
> Is ths something that you or others think about or ponder?
> 
> Regards,
> Jay
> 
> - Original Message -
> From: "Michael G Schwern" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Saturday, February 02, 2002 5:15 PM
> Subject: [ANNOUNCE] Module::Info 0.11
> 
> 
> > http://www.pobox.com/~schwern/src/Module-Info-0.11.tar.gz
> >
> > Didn't get quite as far as I'd hoped, but I got the hard part's done.
> >
> > The interesting bit is you can now find every function and method call
> > in a program (I just realized I'm not handling function calls with
> > symbolic refs quite right, will fix), the line its on, etc see
> > subroutines_called().
> >
> > superclasses() is actually a really dirty cheat and I have to spruce
> > it up some.
> >
> > Some users were reporting silent failures in the last few versions.
> > I've made failures much more noisy so we'll see if that can be worked
> > out.
> >
> >
> > 0.11  Sat Feb  2 16:54:23 EST 2002
> > * Fixed B::Utils->kids
> > * Added subroutines_called()
> > * Added superclasses()
> > * Added dynamic_method_calls()
> > - Documented that it isn't just for modules.
> > - name() can now be used to set
> > - failures inside B::Module::Info now report their errors instead
of> >   failing silently
> > * Added a THANKS section.
> >
> > 0.10  Wed Dec 12 05:40:14 EST 2001
> > * Windows filenames would cause subroutines() and modules_used()
to> >   choke. (Thanks to Alessandro Forghieri for the patch)
> >
> >
> > --
> >
> > Michael G. Schwern   <[EMAIL PROTECTED]>   
http://www.pobox.com/~schwern/> > Perl Quality Assurance
<[EMAIL PROTECTED]>Kwalitee Is Job One> > Let me check my notes.
> > http://www.sluggy.com
> >
> 
> 
>