Re: Module name: WWW-ISBNReference

[Jim Cromie]

Robert Rothenberg wrote:
I am working on a module that can query isbnreference.org for 
information about a particular book.

isbnreference.org is an open-source ISBN lookup service.
As far as I know, there is no Perl module which uses 
isbnreference.org, although there are modules to support the Library 
of Congress Net::Z3950 protocol that isbnreference.org uses.


IIRC  WebService::* emerged by consensus as the new and improved TLN for 
this kind of thing.

Dave Rolsky is the 1st, with WebService::StreetMapLink

Re: META.yml keywords

[Jim Cromie]

Smylers wrote:
And I still reckon most humans are approximately appalling at picking
appropriate keywords anyway.  A system like you're proposing still
requires an individual module's author to think of the right keywords
and bother to do this, which is putting a single-point of failure in the
system.
 

This list already advises authors (those that ask) on appropriate names,
it could readily name the top 10 keywords also.  Those that dont ask cannot
be helped w/o undue complexity.
OTGH, its not impractical for the many regulars here to moderate/gatekeep
on what modules are publicized.  New uploads (ie new dists) result in a 
reply
to the user, and a post to module-authors, flagging a new dist for name 
approval.

KISS.  (moderation may not be sufficiently simple)

Re: Version Numbers

[Jim Cromie]

Elizabeth Mattijsen wrote:

I guess I can make it so that if you had in PERL5OPTS, it would only 
do its magic when called from Makefile.PL.  So I could make it 
implicit for the lazy ones amongst us.

Do we have a name for this beast?   Devel::Panacea doesn't seem right 
either...  ;-)

Devel::VersionCheck ?

Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]

[Jim Cromie]

Marco Marongiu wrote:

And, last, there is a proposal to rename it to Date::Calc::Iterator

Date::Iterator is not a subclass of Date::Calc: it *uses* it; and 
Date::Calc as a namespace for my module is just confusing: my modules 
Iterates over Dates, fullstop. The "Calc" part is confusing.


Derivation/sub-classing is not the only reason to choose a namespace.
Delegation/has-a relationships (for one) are also a good reason, and it 
sounds like your module
fits this case.

Namespaces are not about implementation (which is what derivation is doing),
theyre about interfaces.  And for humans, knowing where to find those 
modules.

  Mazda-RX-8 has a Wankel motor in it - does that make it
different enough to not be a Car ?  Of course not.   You drive it just 
like every other
car.  Is a minivan a car ? an SUV ?  YES.   Should they be under CAFE ?
(Corporate Average Fuel Economy - Congressional law)   *Absolutely*

so wrt finding  Date::Calc::Iterator,  how would one go about it ?   
search.cpan.org !
and what are your search criteria ?   *Date*,  *Iterator* 

I just searched Iterator, and hit several with it as the 3rd level name-

*File::Find::Iterator* 

*XML::LibXML::Iterator* 

*Test::Harness::Iterator* 


So sticking Calc in there's not gonna make it any less 'found',
It adds info wrt your dependency, and it keeps Date::* a little less 
cluttered.

Re: Geography Specific Namespace

[Jim Cromie]

Aran Deltac wrote:

Allright, well, Geography is a great namespace to start!  I think it 
would be a good idea to plan out the namespace a little.  I would like 
to propose coming up with a logical structure to the modules contained 
within Geography::.  This would really just be a list of directories 
and module names and how they relate if at all.  It would also 
describe justifications for choosing one name/structure over another.  
Then as module authors need geography functionality they can just 
write a module that fits in with the structure.

Of course plans never quite fit the bill in practice, so it would just 
be a guideline.

Comments, questions, moral support?
I'd love to do this if its considered ok by the local gods.
Aran

.

${"a plan is good"}++; # Its not often that we get a chance to migrate 
to a new, clean namespace.

I found this, which might be of some use.
http://www.opengis.org/resources/?page=faq#10
I look forward to learning about GIS thru your efforts :-)

Re: proposed name Data::Dumper::Functor

[Jim Cromie]

A. Pagaltzis wrote:

bandwidth. And the fact that the code you posted has compilation
errors turns a nuisance into an offense.
 

oops.  Please accept my apologies on that lack of $ in front of VERSION.
Its Ironic - the error was introduced while working towards a good 
distribution. 

the if ($0=~/Functor.pm/) is just an appendix (in the biological sense), 
useful
sometime ago in evolution, and (mostly) harmless now.

don't think the rather long IMPLEMENTATION section belongs in
your docs. Most of it should be obvious from the code, and the
rest should be squirreled away in a handful of short comments.
 

Of the 4 paragraphs in implementation, 3 are about the API, so should be 
said somewhere.
Ill agree that they should focus more on the interface - new() and Set() 
take %tagvals,
and will in next version.

thx for the pod feedback, which is btw why I sent it.  Ive just learned of
   http://lists.netthink.co.uk/listinfo/code-review-ladder
which is where Ill go next. after updates.
As to the name, per everyones feedback, Im leaning towards   
Data::Dumper::EasyOO.
I cant quite figure how to get Styled into the name, and since DD is all 
about output anyway,
Styled is either redundant (yes its output) or misleading (OO-Style? - 
no print-style)

thx again
jimc

proposed name Data::Dumper::Functor

[Jim Cromie]

ndency on DD attrs,
partly/mostly/completely solvable with existing DD methods

 format control not per-use (object only)
it may be possible to use 'defined wantarray' to implement.

 no global format control (will add import tags)

 auto-labelling may be overzealous.

 flexibility wrt capitalization of attr/methods
can issue warnings with different capitalization from usage

 not *entirely* data-agnostic,
pass '__SA__' to functor iff you want the underlying DD object

 Comments welcome.

=head1 ACKNOWLEDGMENTS

Gurusamy Sarathy for writing DD, I love it and use it *ALL* the time,
its often my microscope of choice.  I cant leave the above critique as
the only commentary.  

=head1 AUTHOR

Jim Cromie <[EMAIL PROTECTED]>

Copyright (c) 2003 Jim Cromie. All rights reserved.  This program is
free software; you can redistribute it and/or modify it under the same
terms as Perl itself.

I dont suppose Ill ever recover the development time via reduced
keystrokes, but CPAN has saved me so much already; heres a little
give-back.  Anyway, perl is fun, like an always-new toy.

=cut

##

package Data::Dumper::Functor;
use Data::Dumper;
use Carp 'carp';

sub AUTOLOAD {
my ($ddf, $arg) = @_;
(my $meth = $AUTOLOAD) =~ s/.*:://;
return if $meth eq 'DESTROY';
$ddf->Set($meth,$arg);
}

# 1 forces method test via symbol table
my $viasymtbl = 0;  # 1 doesnt work !

sub Set {
# sets internal state of private data dumper object
my ($ddf, %cfg) = @_;

my $ddo = $ddf->('__SA__') if ref $ddf eq __PACKAGE__;
#print "setting ddo: ", Dumper $ddo, \%cfg if %cfg;

for my $item (keys %cfg) {
#print "$item => $cfg{$item}\n";

if ($viasymtbl) {
my $meth = ucfirst $item;
unless (\&{"Data::Dumper::$meth"}) {
carp "illegal $item on DDobj\n"
.\&{"Data::Dumper::$meth"};
next;
}
$ddo->$meth($cfg{$item});
}
else { # direct ddo update
my $meth = ucfirst $item;
my $attr = lc $item;
unless (exists $ddo->{$attr}) {
carp "illegal method <$attr>";
next;
}
# 
eval { $ddo->$meth($cfg{$item}) };
carp "illegal method <$attr>" if $@;
}
}
}

sub new {
my ($cls, %cfg) = @_;

my $ddo = Data::Dumper->new([]); # bogus data
Set($ddo, %cfg);

my $code = sub { # closure on $ddo
my @args = @_;
$ddo->Reset unless $ddo->{ddf_noreset};

if (@args == 1) {
# special access for AUTOLOAD
return $ddo if $args[0] eq '__SA__';

# else Regular usage
$ddo->{todump} = [EMAIL PROTECTED];
return $ddo->Dump();
}
# else
if (not @args % 2) {
# possible labelled usage - check!

my %rev = reverse @args;
if (grep {ref $_} values %rev) {
# odd elements are refs. print as array
$ddo->{todump} = [EMAIL PROTECTED];
return $ddo->Dump();
}
my (@labels,@vals);
while (@args) {
push @labels, shift @args;
push @vals,   shift @args;
}
$ddo->{todump} = [EMAIL PROTECTED];
$ddo->{names}  = [EMAIL PROTECTED];
return $ddo->Dump();
}
else {
$ddo->{todump} = [EMAIL PROTECTED];
return $ddo->Dump();
}
};
#print $code;
return bless $code, $cls;
}

package main;

if ($0 =~ /Functor\.pm$/) {

$foo = [qw/ hello there /];
$bar = {qw/ alpha 1 beta 2 zed 26 /};

$baseline = Data::Dumper->new([$foo], ['foo']);
print $baseline->Dump();

my $ddf = Data::Dumper::Functor->new;
print "new thingy: ", Dumper $ddf;

print "used on \$foo: ", $ddf->($foo);
print "used on \$bar: ", $ddf->($bar);

print "w label \$foo: ", $ddf->(foo=>$foo);
print "w label \$bar: ", $ddf->(bar=>$bar);

$ddf->Indent(1);
print "used on $foo: ", $ddf->($foo);

$ddf->Set(indent=>1,sortkeys=>1);
print "used on bar: ", $ddf->($bar);

$ddf->poop(1);

#print "used on $foo: ", $ddf->($foo);
}

1;

__END__

Re: I need a better name than File_Shred

[Jim Cromie]

A. Pagaltzis wrote:

* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 17:43]:
 

Its not 'particular' to C, except in reduce(), the last step,
which acts on the detected redundancies.  As I outlined, a Perl
version could move chunks into strings, then eval that in the
many places its needed.
   

Then maybe it should be split into two modules, one making use of
the other.
 

Heh - that creates 2 naming problems :-OJoking aside, that might 
solve the
problem of not fitting well in either domain - I just have to ponder 
that split,
and what names make sense for the 2 halves.

Me:

And because 'shred' is open-source, and part of the Linux vs
SCO drama, it serves as something of a touchstone - By
understanding the algorithm, you know its
advantages/disadvantages; fast but naive compared to parsing to
an ASN.
   

Good point. Algorithm::Shred?
 

Hmm - that might solve other problems, such as - What is a File::Shred ?
the wad of shreddings ? or the shredder that made them ?!
I'll look at some of the other Algorithm::* stuff to if the object 
models there have
a workable similarity.

FWIW - In  File_Shred::*, I have File_Shred::Shreddings, File_Shred::Chunk,
File_Shred::Ribbon, and File_Shred::Comparison.  Im not entirely happy 
with this
partitioning, but its a start.

Curiously, this shred and knit algorithm has some similarities with Gene 
Sequencing.
There, they chop up DNA such that the 2 sides of the helix fragments are 
ragged -
ie loose tails of 1 side of the helix dangle from both ends.  Then they 
put it in a bath
of nucleic acid, and those tails regrow; A-T, C-G.   Now the soup has 
fragments which
overlap with the fragments that were split off at either end.   Then 
they send the fragments
thru the sequencer, and knit the sequences together.

(BTW - this has inaccuracies - IANAB)

 

Its also applicable to any line-oriented text, not just
programs, hence the File::
   

Again, Algorithm::Shred sounds more like it.

The C-specific part would then be provided in another module
which would have to be named independently, probably leaving C as
the last part of the name so there is ::C, ::Perl etc.
 

Yes - Id say it fits, and Schuyler Erle seems to agree.
Now theres the question of the other half - is it warranted, and if so, 
whats appropriate.

Ill mull on that over the weekend.
thx.

Re: I need a better name than File_Shred

[Jim Cromie]

A. Pagaltzis wrote:

* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 09:35]:
 

My version has a different focus, namely to find duplicate code
chunks, write macros for them, and invoke those macros.  So
maybe a different name is appropriate.
   

So it is aimed at processing C sources? Then File:: is the wrong
TLNS for it, although off hand I'm at a loss about which one it
should be in. I'm not sure Parse::C:: is fitting here?
 

Its not 'particular' to C, except in reduce(), the last step, which acts 
on the detected redundancies.
As I outlined, a Perl version could move chunks into strings, then eval 
that in the many places
its needed.

Parse::* makes promises about its capabilities / sophistication which 
are untrue.

I also looked at generating functions for the chunks and calling those 
where needed, but
that was clearly harder ( taking addys of args in callers, doing derefs 
in fn body, skipping globals )
I havent entirely given that notion up though..

I think the fact that it compares "shreds" is to be ignored as an
implementation detail for the name at least.
Indeed its an implementation thing, but 'Shred' is unlikely to be 
confused with anything else,
except perhaps 'rm -rf *', which most people wouldnt look on CPAN for ;-)

And because 'shred' is open-source, and part of the Linux vs SCO drama,
it serves as something of a touchstone - By understanding the algorithm,
you know its advantages/disadvantages; fast but naive compared to parsing
to an ASN.
Its also applicable to any line-oriented text, not just programs, hence 
the File::
While it wont find re-wrapped text (cuz line boundaries have shifted), 
it will
(once ive nailed the N-file crosscheck) find duplication between *.pm 
and readme.
Aside: this suggests that an interactive capability to skip chunk 
reduction would be good.

The fact that it generates macros is important of course.. so is
the fact that it does so for common code, though. That should
probably be in the name somewhere.
Parse::C::CommonToMacros? Awkward and not truly descriptive I
think..
 

btw - Macro in the name could imply to some that it can write 
parametrized macros.
It cant - cuz the md5 fingerprinting foundation doesnt work that way.
For macroizing, the best it can do is 90%, leaving plenty for the hacker 
to do.
That said, Ive already seen similarities in the generated macros which 
look parametrizable.

Hmm..

 

thx for your comments.

PS - I havent posted code or pod, it doesnt seem to be the 
module-authors way..
I can do so (public or private ) if anyone cares to see it at this point.

I need a better name than File_Shred

[Jim Cromie]

Hi folks,

Ive written a module which implements Eric Raymonds 'shred'
program, which is pretty well described here.
http://www.arstechnica.com/archive/news/1063140308.html

File::Shred is my working name

My version has a different focus, namely to find duplicate code chunks,
write macros for them, and invoke those macros.  So maybe a different name
is appropriate.
File::Macrofy
File::Macroize::C
a Perl version would create a string-eval equivalent:
my $MACRO_NNN = q{  }
   eval $MACRO_NNN;
given its basis in MD5, it cannot find even trivial differences in 2 chunks,

FWIW - Ive applied it to bleadperl source code, and am getting what look 
like reasonable
results, though I havent tried compiling yet.  (I will b4 the .01 release)
Ok, I did, it breaks, have to avoid chunks with unbalanced #ifdefs..

anyway,

[EMAIL PROTECTED] bleadperl]$ ls *.c.new |wc
35  35 415
[EMAIL PROTECTED] bleadperl]$ more *.c.macros |wc
  29879814   68087
[EMAIL PROTECTED] bleadperl]$ grep MACRO *.c.macros |wc
   2821128   14004
[EMAIL PROTECTED] bleadperl]$ grep MACRO *.c.new |wc
   428 856   15234

Re: Geography Specific Namespace

[Jim Cromie]

Terrence Brannon wrote:


>
> Hold that thought - IMO the Geo:: namespace is already a mess; it
> contains both Geometry and Geography stuff,
> and multiple Geo::Weather*, and Geo::Stormtracker
> all of which (in retrospect) could have been Geo::Weather::


I dont think I would call that a mess. Geo is a good abbreviation for 
Geometry and Geography. Maybe a bit of a melting pot, but not a mess :)
OK, Ill concede its a bit over-dramatic, but it is an unfortunate 
historical fact that cant be easily
corrected.  Id hate to see the same mistake occur in every TLD.

Next thing you know, we'll have Astro::Zodiac, Astro::Oracle, 
Astro::NancyReagan
invading the Astro namespace, which so-far contains only Astronomy 
stuff  ;-)


Ya, I always thought it weird what kind of stuff is strewn all over 
Geo::.  Its really should be like schooling - you have different 
departments, Math, History, Geography, Archaeology, Biology, etc.  
So, that would mean geometry would be a subset of math, and would be 
Math::Geo:;, not plain old Geo::.  Oh well.

Perhaps a whole new namespace for geography stuff.  How about...

GIS::*  (Bad idea, GIS is a subset of digitized geography)
Geography::*
Spatial::*


I think most naiive people (e.g. me!) would look under Geo or 
Geography for this type of thing, so put it there.

while Geography:: doesnt yet exist, it seems appropriate that it would.
It might even result in a long-term migration.
Aran, assuming that you have some non-trivial knowledge, can you 
elaborate on what GIS is, what youd expect to find in Geography::GIS, 
and what youre looking to create in relation to it ?

Re: Proposed Name Space Geo::Data::*

[Jim Cromie]

Aran Deltac wrote:

I propose to release the beginning of a large repository of geographic 
data made available on a high-level through perl objects.  Currently 
the data I have organized and modularized is local to the United 
States. The data is ZCTA (Census Zip Code Tabulation Area, essentialy 
Zip Codes), States, Counties, Places (Cities and others), Airports 
(including baloonports and others), and Airport  Runways.  I intend to 
include other parts of the world as time permits.

The intent of this data is for general purpose geographic comparison - 
not graphical mapping!  


Since youve bothered to make this point explicitly, perhaps the 
namespace could also say so.
IOW - what (related) namespace would carry the maps/mapping that youre 
not doing ?
Geo::Mapping ?  Geo::Maps ?  Geo::Data::Mapping ? 

Theres already a Geo::GPS::Data,  Do you have a suitable/corresponding 
2LD that would work ?
theres already a Geo::PostalCode - you might contact TJMATHER and 
inquire whether
Geo::PostalCode::CensusData is fitting - if not, Geo::ZipCode::CensusData.
CensusData is probably too specific, but Data needs somesort of 
qualifier, a 2LD, or a prefix.

Naming the (not yet existing ?) namespaces that could share your 
environment is playing nice,
youre inviting them to join your game.  For instance, what if someone 
were trying to add
modules to support Route-Planning, Navigation ?

Hold that thought - IMO the Geo:: namespace is already a mess; 
it contains both Geometry and Geography stuff,
and multiple Geo::Weather*, and Geo::Stormtracker
all of which (in retrospect) could have been Geo::Weather::

obviously this is just carping, but it begs the question :

Is there sufficient justification for someone to write an 
Acme::Module::Rename ?
   collect advice on good Module-names
   collect techniques to support migration
 ie:  perl -pi.bak  tricks,  and simple script to use them.
 old-name-closer.pl
   rewrites the existing package to new one.  
   writes the last version of the old-namespace module,  
which wraps the new namespace one.
   maybe this is just POD of best practices..

I imagine theres quite a bit out there - perhaps its worth collecting ?

If anyone responds to this point, a new subject is probably warranted   :-O



Every data type has
I want to hear people either cry or laugh hysterically before I 
actually show some code (I need to pod and do some organizing on it 
too).  So, anyone find this intriguing?

Also, are these namespaces ok?

Aran

.

Re: module to access w3c validator

[Jim Cromie]

Struan Donald wrote:

So, does WWW::Validator::W3CMarkup::Detailed seem like a good name for
this?
 

as you noted earlier, Detailed insnt quite right..

How about:
  Analysis, Critique, ErrorSet,
   Details (this suffix is more noun, less adjective)
   or Feedback  ( just a punt, probably worse than detailed )
Thanks

Struan

.

 


WRT Fergals later point:

you wouldn't be doing your clients any
favours by making their production servers depend on a webservice that has
no specified interface and no promises about availability.
This is a good arg for doing it both ways (ie at least consider them,
and dont preclude them by mis-designing), making the SW-install
request (thereby covering your bases - so when W3C shuts them off
for pounding their server - You Told Them So).
OT - Chris, does your email address get you black-holed a lot ?
with the amount of porn-spam these days, and not-quite-there 
filter-tools (mozilla anyway)
Ive had to de-junk legit email periodically.

new candidate CPAN module: Log::Log4perl::AutoCategorize

[Jim Cromie]

Folks,

Attached is a tarball for Log::Log4perl::AutoCategorize-0.008, a module 
Ive been
developing for eventual CPAN-ification at 0.01 (20 steps left).

Ive received encouraging words about this code & namespace from Mike 
Schilli,
the 'owner' of Log::Log4perl, so I think the namespace issue is pretty 
much sorted,
but ICBW.

I have a few doc items and better integration with Log::Log4perl 
initialization to address,
but I wanted to put it out to a wider audience to see if anything else 
got uncovered.

POINT of INTEREST.  It uses optimizer.pm

If youre so inclined, please;

make, make test.
squelch the B::Generator function redefined warnings.  (I couldnt, in 
several tries)
run perftests/timeit.sh, send me results.


Log-Log4perl-AutoCategorize-0.008.tgz
Description: Unix tar archive