Re: Module namespace for IEEE754 encoder/decoder

[John M. Gamble]

Hmm, I was going to bring up Math::Int128, but it allows arithmetic on 
128-bit integers, which might count towards your objection.


I'm not keen on using the Convert namespace which is overwhelmingly used 
for text conversion. I suppose you could break it down with 
Convert::Number:: modules.


Pondering some more: is the intent to put all of the conversion 
operations into one module? I am typing in ignorance, but would it make 
sense to separate the integer conversions from the floating point 
conversions? In which case you would have Convert::Integer:: 
and Convert::Float::.


 --john

On 2021-06-03 06:22, Timothe Litt wrote:

I'd be a bit careful about assuming floating point - will someone want
to pack/unpack BCD? Or PDP-10 Gfloat (well, OK that's a floating
format)?  Or...

I don't like Math:: - it implies that it does arithmetic (or calculus,
or statistics, or - more than a conversion).

And I'd rather not have a format name encoded in the module that the
user calls.

How about Number::Encode->new("name") & Number::Decode->new("name")?

Let "name" get to a subclass, so other formats can be supported just
by adding a module - e.g. "Number:Encode::BCD" could be require'd if
*->new('bcd') called.  Obviously, you'd implement IEEE754, Intel80,
and whatever else...

Define the API for the subclasses - encode(),decode(), perhaps some
info functions (e.g. a printable name, perhaps exponent and fraction
range/#bits, ...)

Then someone who wants Number::Decode::VAX_DFLOAT just calls
Number::Decode->new('vax_dfloat') - after writing it.

Some of these can get interesting if you want to decode and actually
do math - presumably you'll support Math::BigXxx / bignum? (binary128,
VAX H_Floating are, IIRC about 36 decimal digits)

And some program that reads archived data can have a description
language that is simply "name"  "format" "byte offset" "length", and
not worry about what module handles what format.  In fact, such a
program might appreciate the trivial modules Number::Encode::INTEGER32
(and perhaps the less obvious
Number::Encode::INTEGER32_ONESCOMPLEMENT)...

I suspect there are better names for the format, but the idea is to
export a simple wrapper so the next format can be added by anyone, and
the callers don't have to know too much.

FWIW.

On 03-Jun-21 06:23, Peter John Acklam wrote:


I also plan to implement the 80 bit "extended precision" format,
which
is not IEEE 754 compatible. Perhaps the best and simplest is
Number::Pack and Number::Unpack?

Peter

tor. 3. jun. 2021 kl. 11:43 skrev Peter John Acklam
:


Hi

I am working on two modules for encoding and decoding numbers as
per IEEE754. The pack() function can encode and decode the formats
binary32 (single precision) and binary64 (double precision). My
module can also handle binary128 (quad precision), binary16 (half
precision), bfloat16 (not an IEEE754 format, but it follows the
IEEE754 pattern), and a few other formats.

My question is about the namespace. Is Math::IEEE754::Encoder (and
...::Decoder) OK? Or is Number::IEEE754::Encoder better? Or any
other?

Here is an example showing how I use it:

my $encoder = Math::IEEE754::Encoder -> new("binary16");
my $bytes = $encoder -> (3.14159265358979);  # = "\x42\x48"

my $decoder = Math::IEEE754::Decoder -> new("binary16");
my $number = $decoder -> ($bytes);   # = 3.140625

The reason for returning an anonymous function rather than
implementing the function directly, is speed. There are some
constants involved, and I don't want to compute them for each
function call.

Cheers,
Peter John Acklam (PJACKLAM)

Re: Algorithm-SkipList

[John M. Gamble]

Thank you. I also recall you mentioning that you had a project that used 
skip lists that needed to use Perl 5.8. Is this still the case?


 --john

On 2021-02-25 02:31, Robert Rothenberg wrote:

I'm fine with it.

Note there's an unfinished development version on CPAN and a github
repo at https://github.com/robrwo/Algorithm-SkipList

Robert


On 25/02/2021 06:40, John M. Gamble wrote:
I was surprised to see Algorithm-SkipList marked as owned by ADOPTME 
in PAUSE, which is not the case in MetaCPAN, where it is owned by 
Robert Rothenburg (although it is marked for adoption, see 
<https://metacpan.org/release/Algorithm-SkipList>).


In any event, I'm marked as co-maintainer. What is the process for 
adoption, assuming that RRWO is amenable?


Thanks,
 --john

Algorithm-SkipList

[John M. Gamble]

I was surprised to see Algorithm-SkipList marked as owned by ADOPTME in 
PAUSE, which is not the case in MetaCPAN, where it is owned by Robert 
Rothenburg (although it is marked for adoption, see 
).


In any event, I'm marked as co-maintainer. What is the process for 
adoption, assuming that RRWO is amenable?


Thanks,
 --john

Re: Module name hierarchy...

[John M. Gamble]

On Fri, September 25, 2020 4:12 pm, David Cantrell wrote:
> On 25/09/2020 19:59, Dan Book wrote:
>> On Fri, Sep 25, 2020 at 2:20 PM BC > > wrote:
>>
>> Let's say I wanted to submit a module named:
>>
>>       Class::Error::Foobar
>>
>> Would this be considered bad form if my "Foobar" module is not
>> related
>> to the existing Class::Error module in any way?  In other words,
>> Foobar does not depend on, extend, nor reference the Class::Error
>> module other than perhaps a courtesy "See Also" mention.
>>
>> It is not necessarily bad form, but if there is an existing
>> "Class::Error" ecosystem you might consider asking the author first in
>> case they wanted to use that sub-namespace. That does not really seem to
>> be the case here.
>
> I'd say that you should ask no matter what, and should also consider
> using something like Foobar::Error instead. Partly to avoid trampling on
> someone else's namespace, but also because using C::E::Foobar might give
> your users some incorrect expectations if they are already using
> Class::Error elsewhere.
>
> --
> David Cantrell
>
>

I'm of two minds. If the top and second level is large enough then it's
possible that the "ecosystem" has escaped the menagerie and it not really
under the top-and-second namespace author's control. Likewise, if the
author is clearly limiting their module to one purpose, then I don't
believe this is an issue.

But that's making assumptions that I don't know are true about your case.
If neither one is true, then yes, contact the author.

Disclosure of bias on my part: I am the author of Math::Polynomial::Solve,
and the then-author of Math::Polynomial was clearly an example of the
second case.

 --john

RE: Mime-Base64 Pending PRs

[John M. Gamble]

Please don't do that.

It's not a major change request, true, but it's certainly not stupid. And
if it is deemed unimportant, then it can be rejected, and doesn't require
this level of editorializing, particularly since it only affects the test
files, not the module code.

The main question is whether github is how the author wishes to deal with
change requests, as there are open (and unresponded) issues dating from
2015.

 -john

On Sat, June 20, 2020 2:54 pm, Konovalov, Vadim wrote:
> The “Enable strict and warnings on all
> tests” is soo stupid
>
> It is no modernization, it is just plain stupod
>
> From: Nicolas R. 
> Sent: Thursday, June 18, 2020 2:03 AM
> To: gisle@it.uib.no
> Cc: module-authors@perl.org
> Subject: Mime-Base64 Pending PRs
>
>
> [EXTERNAL EMAIL]
> Hi Gisle, I've submitted a few extra Pull Requests to Mime-Base64 today
> and realized that I've some PRs opened since 2017 that have no feedbacks.
>
> https://github.com/gisle/mime-base64/pulls
>
> I was wondering if you need help for the maintenance of Mime-Base64.
> If so I would gladly take co-maint on the module and help releasing
> updates.
>
> Please let me know
>
> sincerely
> nicolas
>

Re: [RFC] File::TVShow::Parse

[John M. Gamble]

I'm already on record on not supporting anything older than 5.10.1*. But
the reason I mentioned the META.* files is because I would think (well,
hope) that that in itself should be enough to prevent older Perls from
even looking at the package**.

Therefore, if the package isn't ever downloaded by these older Perls, the
'use' statement can use the all-integer format without problem. In theory.

 -john

---
* In two or three years I'll be changing that to 5.16.1.

** People who deliberately override that restriction aren't part of this
conversation.

On Tue, April 16, 2019 2:59 pm, Dan Book wrote:
> It depends entirely what Perls you want to support. If you only want to
> support Perl 5.10 or newer, module versions in the dotted-decimal form are
> fine as long as you always declare them as strings and don't use
> underscores. If you want to support older than that, you have to jump
> through some hoops or risk users getting the wrong behavior.
>
> For the 'use X' statement itself for declaring a minimum perl version of a
> file, the '5.XXXYYY' format is still (always?) recommended, because it
> will
> make sure that running it on older Perls will result in a sensible error
> message.
>
> -Dan
>
> On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble  wrote:
>
>> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
>> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
>> >
>> >> As a side note, remember that the X.Y.Z form of versions (with more
>> than
>> >> one decimal point) is a sequence of integers ...
>> >
>> > Sadly it's worse than that.
>> >
>> > There exists popular software management software out there written by
>> > idiots who think that 3.0014 > 3.1, so that rule applies even when
>> > you're using numbers in the form X.Y with a single decimal point.
>> Those
>> > people did a lot of hard work to break numeric comparisons, one of the
>> > few things that computers are any good at.
>>
>> Are we at the point where there is no reason to not use X.Y.Z? I recall
>> (I
>> think) the historical reasons for using the 5.00y00z format, but given
>> that minimum Perl versions are now specified in META.* files, surely
>> there's no real reason to keep doing that anymore?
>>
>> I say this while looking at all my modules, which still use the fraction
>> format.
>>
>>  -john
>>
>

Re: [RFC] File::TVShow::Parse

[John M. Gamble]

On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
> On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
>
>> As a side note, remember that the X.Y.Z form of versions (with more than
>> one decimal point) is a sequence of integers ...
>
> Sadly it's worse than that.
>
> There exists popular software management software out there written by
> idiots who think that 3.0014 > 3.1, so that rule applies even when
> you're using numbers in the form X.Y with a single decimal point. Those
> people did a lot of hard work to break numeric comparisons, one of the
> few things that computers are any good at.

Are we at the point where there is no reason to not use X.Y.Z? I recall (I
think) the historical reasons for using the 5.00y00z format, but given
that minimum Perl versions are now specified in META.* files, surely
there's no real reason to keep doing that anymore?

I say this while looking at all my modules, which still use the fraction
format.

 -john

Re: [RFC] File::TVShow::Parse

[John M. Gamble]

I would tend toward Info myself. The existence of Video::Info is
irrelevant except for highlighting that Info is a valid choice. But I also
admit that's just me, and I tend to view Parse in a language context.

Don't bother trying to support Perl versions less that 5.10. Last I
checked the (admittedly unscientific) surveys, 5.10 was the lowest version
that had a sizeable usage percentage, and on a personal level, I just
don't want to support Perls with flawed security.

My current modules either have a minimum required versions of 5.10.1, or
5.16.1, depending on whether I might have to deal with Unicode. I've never
had a complaint (I don't write pragmas or system-oriented code, so it's
never been anything I've need to worry about).

 -john

On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:
> Hello Everyone,
>
> I am considering a module to supplement Video::Filename written by
> Behan Webster. I have tried reaching out to him in the past couple of
> weeks. Submitting a patch to provide support for show
> name..mm.dd.ext
>
>
> In the mean time I have been considering if a specific module for TV
> Shows only might also be worth while, of course with additional
> features and support.
>
> See attached podtotext file.
>
> I have a few questions.
>
> 1)
> Would it be better to go with Parse, Meta, or Info since we are
> attempting to get meta data from from the file naming. There is
> already a Video::Info which does the deep dive into the file contents
> from what I have read. I have not used the module itself.
>
> 2)
> Should I keep support for perl below version 5.10 as versions below
> this do not support named groups in regex. I have seen on PerlMonks
> that there are still questions being asked by people using perl
> versions less than 5.10
>
>
> Looking forward to hearing back.
>
> Best,
> Adam Spann
>

Re: Naming and Feedback for a module, Druid

[John M. Gamble]

Hmm, I see you uploaded it already. Druid does seem like an acceptable
top-level name (analogous to Amazon Web Service top-level AWS), but I wish
you had qualified it (e.g., Druid-Query, for example), so as to not give
the impression of end-all and be-all.

The only other comment I have is that unless there's a pressing reason for
it, I'd bump up the MIN_PERL_VERSION to 5.010001, to avoid some security
issues. But that's me.

 -john

On Sat, November 25, 2017 11:27 am, Gaurav Kohli wrote:
> Hey,
>
> I started working on a module, Druid( https://github.com/gauravkohli/Druid
> )  couple of months back which is a client to connect to Druid data store
> (
> http://druid.io/)
>
> Currently it provide access to three basic query patterns on Druid, but
> eventually it would even provide access to operational functionality on
> Druid as well.
>
> I was planning to upload it to CPAN and before that, I wanted if someone
> could have a look and give some feedback on the naming of the module and
> also on the current state of the module.
>
> Cheers,
> Gaurav
>
> --
>
> "I'm a great believer in luck, and I find the harder I work, the more I
> have of it."-Thomas Jefferson
>

Re: Boolean As a Top Level Name

[John M. Gamble]

Ah, no, sorry, I clearly didn't explain this well. A Boolean truth table
is not a matrix, and does not evaluate a Boolean expression (if anything,
it's the reverse. It takes the evaluations and re-creates the expression.
This gets complicated as the number of variables grows).

Technically it's math, but I suspect people would be more likely to use
the keyword 'boolean', or perhaps 'digital logic', when looking for
something like this.

(For supporting evidence, the Wikipedia article on the Quine-McCluskey
algorithm nowhere uses 'math' in the current version of the article.)

Thanks,
 -john


On Fri, September 9, 2016 2:50 pm, Karen Etheridge wrote:
> I think I'd look for such a module in the Math:: namespace.
>
> I also found these modules which may be similar:  Math::BooleanEval,
> Math::MatrixBool.
>
> On Fri, Sep 9, 2016 at 12:33 PM, John M. Gamble <jgam...@ripco.com> wrote:
>
>> A while back I was granted co-maintenance of Algorithm::QuineMcCluskey.
>> It
>> handles one Boolean expression at a time, and I decided that it would be
>> good to create a package that could manipulate a Boolean truth table.
>>
>> So Boolean::TruthTable is nearly ready to go (I have documentation to
>> complete).
>>
>> But, to handle the columns in the table, I created a base class.
>> Algorithm::QuineMcCluskey would become a child of this class (because
>> after all this is done, I'm going to explore other algorithms).
>>
>> Naming this class is a little trickier. It's not an algorithm, so I
>> don't
>> think using the Algorithm top level is appropriate. I'm settling on
>> Boolean::Minimizer (which is what the algorithms do).
>>
>> Now the potential problem is that Boolean isn't used much as a top-level
>> name. I can only find 'boolean', the pragma for using true and false
>> values, and Boolean-String, which has a 0.01 release and hasn't been
>> updated since.
>>
>> So are there any objections to my using Boolean as a top level name in
>> earnest?
>>
>>  -john
>>
>>
>

Boolean As a Top Level Name

[John M. Gamble]

A while back I was granted co-maintenance of Algorithm::QuineMcCluskey. It
handles one Boolean expression at a time, and I decided that it would be
good to create a package that could manipulate a Boolean truth table.

So Boolean::TruthTable is nearly ready to go (I have documentation to
complete).

But, to handle the columns in the table, I created a base class.
Algorithm::QuineMcCluskey would become a child of this class (because
after all this is done, I'm going to explore other algorithms).

Naming this class is a little trickier. It's not an algorithm, so I don't
think using the Algorithm top level is appropriate. I'm settling on
Boolean::Minimizer (which is what the algorithms do).

Now the potential problem is that Boolean isn't used much as a top-level
name. I can only find 'boolean', the pragma for using true and false
values, and Boolean-String, which has a 0.01 release and hasn't been
updated since.

So are there any objections to my using Boolean as a top level name in
earnest?

 -john

Re: Is META.yml Necessary Anymore?

[John M Gamble]

On 10/26/2015 1:42 AM, Damyan Ivanov wrote:

-=| Dominique Dumont, 25.10.2015 17:03:09 +0100 |=-

Le dimanche 25 octobre 2015 16:49:03, vous avez écrit :

As far as I can tell, dh-make-perl is already using CPAN::Meta, and
preferring META.json over META.yml as it should
(DhMakePerl::Command::Packaging::process_meta), I don't think there' a
problem there.

Oh well... Looks like I was misled by dh-make-perl man page which explicitly
mentions META.yml.

Then, I see no problem to obsolete META.yml if META.json is kept, but I'd like
to check this with Debian perl team (cc'ed)

So, Debian Perl colleagues,  what do you think ? Would META.yml removal cause
a problem for our workflow ?

It should not. If it does, then the workflow (including dh-make-perl)
needs to be fixed.


Or at the very least the man page needs to mention META.json.

-john

Re: Is META.yml Necessary Anymore?

[John M. Gamble]

Thank you very much for looking this up. I don't plan to require version
5.14 until 2017 or later, so I guess I'm stuck with META.yml for a while.

Thanks again,
 -john

On Fri, October 9, 2015 1:50 am, Aristotle Pagaltzis wrote:
> Hi John,
>
> * John M Gamble <jgam...@ripco.com> [2015-10-06 20:25]:
>> What with META.json being generated (and presumably used) in our CPAN
>> uploads, is it necessary to include META.yml anymore? A brief search
>> didn't really tell me anything.
>>
>> If it makes a difference, the minimum version of Perl that I require
>> for my modules is currently 5.10.1.
>
> if I’m looking at this right, Perl 5.13.10 is the earliest Perl version
> where the toolchain supports META.json out of the box.
>
> Specifically, 5.13.9 was the first perl to ship JSON::PP in core, but
> its CPAN.pm and Parse::CPAN::Meta lack META.json support. They were
> added in Parse::CPAN::Meta 1.41_01 and CPAN.pm 1.94_65, both of which
> were included in 5.13.10 (or rather, Parse::CPAN::Meta was upgraded to
> 1.44).
>
> In practice that means Perl 5.14.0 is the first Perl that can install
> dists with a JSON-only META out of the box.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>
>

Is META.yml Necessary Anymore?

[John M Gamble]

What with META.json being generated (and presumably used) in our CPAN 
uploads, is it necessary to include META.yml anymore? A brief search 
didn't really tell me anything.


If it makes a difference, the minimum version of Perl that I require for 
my modules is currently 5.10.1.


-john

Re: Naming help needed for evil @INC hackery

[John M Gamble]

My first thought was to question whether INC needed to be a whole level 
in the
name, but... upon consideration, yes, because it's the main point of the 
module.

Plus, there's precedence in Devel-INC-Sorted.

So my next thought is the third-level name. I'd drop the "My" and the 
"First"
and just call it Devel-INC-Subrefs. Justification for dropping "My" 
being, well,
whose else modules would you be wrapping; and justification for dropping 
"First"
is that I could very well see an option for putting them in other 
positions as a

possibility (e.g., after=>"Games::*"), so why limit yourself?

-john

On 10/6/2015 10:29 AM, David Cantrell wrote:
One of my modules is Sub::WrapPackages. It has a feature where you can 
invoke it once and it will both wrap itself around code that's already 
been loaded, but will also lurk in the background and do Things to 
code that is loaded in the future. It does this by dropping sub-refs 
in @INC. It also subverts 'use lib' so that if you 'use lib' after it 
has dropped its magic into @INC, it silently moves its sub-refs to the 
front of @INC.


The code for this is quite simple and right at the end of 
Sub::WrapPackages:
https://metacpan.org/source/DCANTRELL/Sub-WrapPackages-2.0/lib/Sub/WrapPackages.pm#L337 



I now find that I need this functionality in another module, so I'm 
going to rip it out and upload it to the CPAN as a seperate 
distribution that will let you register sub-refs to do this with. But 
what to call that?


Devel::INC::MySubrefsFirst?

I think that sucks, but I can't think of anything better that is still 
reasonably short. Anyone got any better suggestions?

Re: Need information about updating the modules on PAUSE and editing the information on CPAN Search.

[John M Gamble]

Looking in your Makefile.PL (which you should also do, as it it a 
fruitful area of study), you can see the line


VERSION_FROM = 'lib/Games/JackThief.pm',

This tells you where the version information is coming from (other 
options are also possible).


Go into your module JackThief.pm, and increase the version number. 
You'll find VERSION also referenced in your documentation, which you'll 
need to fix.


While you are at it, you may want to increase the perl version number 
too. Version 5.6 has not been supported for a very long time, and is not 
supported by the build/make tools either.


Others may disagree, but I've lately increased the MIN_PERL_VERSION line 
in Makefile.PL to 5.010001 (that is, version 5.10.1) in my own modules 
(although one of them will be staying at 5.008003 for a while due to a 
single machine out there that I need to keep happy). You will also find 
a use 5.006; line in your code; you should change that too to either 
5.8.3 or 5.10.1.


Good luck,
-john


On 6/28/2015 4:40 AM, KAPIL RATHORE wrote:

Hello Authors,.

Today i have posted my very first module on PAUSE. 
Games-JackThief-0.01.tar.gz - is working very fine for latest perl 
version.

But failing for older versions as reported by CPAN Testers.
I have fixed the issue, but didn't know how to post the version0.02 on PAUSE.
Does uploading on the following file
Games-JackThief-*0.02*.tar.gz  will update the package on server automatically ?

And i found that the description about the functions are not good on cpan 
search,
please let me know how can i update the documentation there ?


Thanks
Kapil Rathore

Re: Exclude tests from regular tests

[John M Gamble]

On 6/29/2015 7:01 AM, David Cantrell wrote:

On Thu, Jun 25, 2015 at 12:25:28PM -0500, John M Gamble wrote:


The problem I have with that is that since the author tests are there
for their usefulness, it
makes sense to keep them in the distribution for the next author (be it
a hand-off or a fork).

Sure, keep the author tests separate from the tests meant for the CPAN
testers. But let the
people interested in your code see how you're testing it.

I keep stuff for maintainers in my git repositories and tend not to
include it in the distribution.

My git repositories are mirrors of my CPAN uploads; as such they have 
everything.


I've experienced enough single points of failures that I like to keep 
things safe(r).


-john

Re: Exclude tests from regular tests

[John M Gamble]

On 6/20/2015 5:52 AM, K. Wittrock wrote:

Just to supplement Karen's response:

Am 18.06.2015 um 18:58 schrieb Vincent Lequertier:


Since I'm fairly new to the task of maintening modules, and that I'm
unable to find any doc about it, is moving a test file from /t to /xt
make the test secondary? Any advice?


I add the following lines to MANIFEST.SKIP to prevent xt/ from 
reaching the tarball:


# Avoid author tests dir.
^xt/



The problem I have with that is that since the author tests are there 
for their usefulness, it
makes sense to keep them in the distribution for the next author (be it 
a hand-off or a fork).


Sure, keep the author tests separate from the tests meant for the CPAN 
testers. But let the

people interested in your code see how you're testing it.

-john

Re: Curating old dists on CPAN

[John M Gamble]

On 4/30/2015 5:10 PM, Neil Bowers wrote:
I think we should either remove very old dists from CPAN, or update 
them to follow modern conventions (so they have a META.yml or 
META.json, for example). I had email with the author of CGI::Response 
(last released in 1995) for example, and he agreed that it should be 
removed from CPAN.


I had a look at all the dists that were last released in 1995 and 
wrote up my thoughts on them:


http://neilb.org/2015/04/30/curating-old-releases.html

Where people think dists shouldn’t be removed, I’m happy to try adopt 
them to release minimal updates, where I’m able to.


I’m interested to hear what others think.

Neil



This brought back some frustrated memories. I tried to take over 
Math::Brent, for the purpose of upgrading the package and fixing an 
error. I managed to locate John Williams, who was fine with it -- but 
who then couldn't grant me co-maintenance because PAUSE didn't have him 
as the owner (I checked, and all of his modules at that time were 
co-owned by another user, although only one had been worked on).


At that point he didn't feel like proceeding further, and I didn't feel 
like making an issue of it, especially if the other user was going to 
make the fixes anyway.


It's now two years later. The other user doesn't seem to have ownership 
anymore, but Math::Brent is still has an outstanding bug.


I'm still interested in being a co-maintainer. For that matter, I'd be 
interested in co-maintaining Math::Fortran and Math::Derivative, 
although I would probably retire the Math::Fortran name for something 
like Math::Util.


-john

Re: Module name advice?

[John M Gamble]

On 7/25/2014 8:48 AM, Maggie X wrote:

Thanks for looping me in, David! I don''t see Paul's email here though :)

Looks like a nice contribution. Is it going to involve PDL?


Best,
Maggie


Addresses (including mailing list) added to the mail.

 -john






On Thu, Jul 24, 2014 at 9:14 AM, David Mertens 
dcmertens.p...@gmail.com mailto:dcmertens.p...@gmail.com wrote:


Hey Paul,

Maggie Xiong, the author of PDL::Stats
http://sourceforge.net/projects/pdl-stats/, may have an interest
in this work, and may also have a recommendation for a name. I've
CC'd her to help with any ensuing conversation. :-)

David


On Wed, Jul 23, 2014 at 3:12 PM, John M Gamble jgam...@ripco.com
mailto:jgam...@ripco.com wrote:

On 7/22/2014 11:55 PM, Paul Bennett wrote:

I'm in the process of writing a Perl module that provides
a practical
implementation of the statistics language described at
http://ashishagarwal.org/2011/10/04/pdf-type-theory/ which
would
compile programs in that language to Perl objects that provide
-pdf($n), -cdf($n), and -rand() methods (providing the
probability
density at $n, the cumulative probability for $n, and a
random number
generated by a given script in that language, respectively).

Right now, I'm pondering the name
Statistics::Language::BAVC (the
initials of the authors of the paper).

If anyone's got any better ideas, now's your chance to
speak up.


I've just skimmed the paper. Even though they don't have a
name for their own technique, it seems risky to just name it
out of the blue.

Have you tried contacting the authors and asking if they've
come up with a term?

I agree that Statistics::Language is probably the prefix to
use for your module.

 -john




-- 
 Debugging is twice as hard as writing the code in the first place.

  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan

Re: Module name advice?

[John M Gamble]

On 7/22/2014 11:55 PM, Paul Bennett wrote:

I'm in the process of writing a Perl module that provides a practical
implementation of the statistics language described at
http://ashishagarwal.org/2011/10/04/pdf-type-theory/ which would
compile programs in that language to Perl objects that provide
-pdf($n), -cdf($n), and -rand() methods (providing the probability
density at $n, the cumulative probability for $n, and a random number
generated by a given script in that language, respectively).

Right now, I'm pondering the name Statistics::Language::BAVC (the
initials of the authors of the paper).

If anyone's got any better ideas, now's your chance to speak up.


I've just skimmed the paper. Even though they don't have a name for 
their own technique, it seems risky to just name it out of the blue.


Have you tried contacting the authors and asking if they've come up with 
a term?


I agree that Statistics::Language is probably the prefix to use for your 
module.


 -john

Re: Problem naming a module

[John M. Gamble]

On Mon, November 25, 2013 5:27 am, Aristotle Pagaltzis wrote:
 Hi Philippe,

 there are two issues causing a problem with naming for this module:

 1. very specific form of input required/expected (hash of weights)
 2. tightly bound to a DSL as its API

 If you want to be descriptive then you simply cannot give a module like
 this a terribly generic name. To cover (2), you need ::Rules. To cover
 (1), you basically need to name all aspects: takes a hash, specifically
 one where the values are weights, and reduces it to a single value. So
 I ended up with

 Hash::Reduce::Weighted::Rules

 It’s a mouthful but seems necessary to accurately summarize the module.
 None of the names that omit any of these components felt satisfactory:
 whichever one you take out, the shorter name seems to describe a very
 different module.


I can't disagree much, but I find that returning to my suggestion of
GroupBy works well with:

Hash::GroupBy::Weighted

since GroupBy implies Rules. For what it's worth.

 -john

Re: Jperl is bad name -;

[John M. Gamble]

On Tue, October 29, 2013 1:26 pm, David Cantrell wrote:
 On Tue, Oct 29, 2013 at 06:58:54PM +0100, Jean-Damien Durand wrote:

 I have been adviced by daxim@cpan that Jperl (c.f. [1]) is a bad name,
 and it is! May I ask for suggestions;

 The project is a JavaScript engine written in perl.
 ...
 Should the name mention explicitely the implementation, or could it be
 stand-alone but /not/ Jperl -;

 Rhino is a Javascript engine written in Java. The name doesn't mention
 either Javascript or the language it's written in. Likewise
 Spidermonkey, a Javascript engine written in C/C++.

 So there's good precedent for just calling it $animal.

 I like pilot whales and puffins, so I recommend naming it after one of
 those.


I suppose Luwak might be a reasonable choice
(https://en.wikipedia.org/wiki/Kopi_Luwak)...

Or Puffin. Puffin is good.

 -john

Re: SentiWordNet module

[John M. Gamble]

On Tue, August 27, 2013 2:08 am, Ashish Mukherjee wrote:
 Hi,

 I am exploring use of the SentiWordNet lexicon for a particular use case.
 Though WordNet does have perl interfaces, SWN doesn't seem to. I would
 like
 to validate this with the group.

 Also, if it is indeed true that there is no such module, I would think of
 making a CPAN contribution. Would WordNet::Sentiment or
 WordNet::SentiWordNet be appropriate names for the module?

 Regards,
 Ashish


Text::SentiWordNet perhaps? I had to do a search, and the first site that
I found (http://sentiwordnet.isti.cnr.it/) gave me the impression that
it's all about the text.

 -john

Re: need name for module that benchmarks hash algos, smoke ab/use

[John M. Gamble]

(Sorry for the duplicate message, bulk 88, I keep forgetting that reply
doesn't go to the list.)

Are the hash algorithms only available via the module? It sounds like this
should be split in two, e.g., Algorithm::Hash::HashNameABC, and perhaps
Hash::Util::Benchmark.

I know I demoted Benchmark from top level, but it seemed a more natural
fit to me.

Are the hash algorithms supposed to be stand-alone, or will it be possible
to use them as plug-ins for perl's built-in hashing? (I followed the
hashing discussion on perl5-porters with interest.)

 -john

On Sun, August 4, 2013 1:18 am, bulk 88 wrote:
 I need a module name for a module, that exists only to benchmark its built
 in hash algorithms, on different smoke machines, and then read the build
 logs to see how how fast the hash algos were. So far I am  calling it
 Benckmark::CoreHashes. Is that a good name?  Or is
 Benchmark::Perl::Corehashes a batter name?.

Re: Proposal For A Module To Generate Regular Expressions

[John M. Gamble]

On Sun, August 4, 2013 12:30 pm, Shawn H Corey wrote:
 On Sun, 4 Aug 2013 18:03:51 +0200
 Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote:

 This would be better in the Regexp top level namespace instead of
 occupying its own:

 I chose the short name so it would be remembered. Long names aren't.


People who use your module will remember it because its name is in their
code, not because it is short. People who haven't used your module won't
remember its name, be it long or short. Making the name searchable is more
important than guessing what a programmer might find memorable.

A good Name description (I'm amazed, by the way, at the number of people
who totally screw this up -- do they not want anyone to use their code?)
and a clear Synopsis are far more likely to get me to install and try out
a module.

 -john

Re: pod stuff... pod using variables?

[John M. Gamble]

On Sat, March 16, 2013 7:43 am, Linda W wrote:


 Different Q:

 Is there easy way to have the version number in the pod be taken from
 it's
 definition in the code rather than having it be static text that needs to
 be updated?  Seems an odd thing not to be 'automatic'...

 Thanks!


There was a discussion on this back in January/February
(http://www.nntp.perl.org/group/perl.module-authors/2013/01/msg9894.html).

The upshot was a few people deciding to work on it. No one has announced
working code yet though.

 -john

Re: stop shipping MYMETA to CPAN

[John M. Gamble]

I can say in my case I added them manually. There didn't seem to be a
reason not to at the time, and I was just being conscientious.

You know what might be the simplest way to prevent this from happening?
Put a comment line inside the MYMETA files, clearly saying Do not add
this file to your MANIFEST, with maybe another sentence saying why. I did
look inside the file before adding it.

 -john


On Fri, March 1, 2013 2:48 am, Eric Wilhelm wrote:
 # from Gabor Szabo on Thursday 28 February 2013:
/me is releasing new version of Test::Strict to fix this issue and
going over the
other modules as well.

 Hi Gabor,

 How did they get into your MANIFEST in this case?  Is there a tool which
 is tending to do this, or are people adding them manually?

 Thanks,
 Eric
 --
 ---
 http://scratchcomputing.com
 ---

Re: Make sure all the modules have the same version number in a distribution

[John M. Gamble]

On Wed, January 9, 2013 9:03 pm, David Christensen wrote:

 There seems to be two competing points of view regarding version
 numbering for software source code files:

 1.  Per-file -- a unique version number for each file that increments
 when that file changes.  RCS and CVS use this approach.  They also
 provide keywords that can be embedded in files for accessing version
 control system meta-data.  For example, I use CVS and embedded it's
 $Revision$ keyword in my Perl files with the following incantation to
 set the Perl $VERSION variable:

 our $VERSION  = sprintf %d.%03d, q$Revision: 1.32 $ =~ /(\d+)/g;

 http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_12.html#SEC99

 2.  Per-set -- unique version number for a set of files that increments
 when any one of them changes (and is the same for all the files in the
 set).  I believe Subversion and Git use this approach (and Mercurial?).


Yeah, after dithering about it for a few days, I went with the philosophy
that the package has the version, not the individual modules. For the
simple reason that the package as a whole is what's being developed, from
the documentation to the scripts to the README file to, of course, the
actual modules themselves.

Hmm. I use the 'dist_version' key in my Build.PL file. Maybe I can take
Gabor's idea and update my $VERSION values automatically using Build.PL as
the starting point. This would maintain the holistic approach, and give
me a single file to update instead of worrying about every file with a
version number (which for me would be the README file and any *.pm files
under the lib directory).


 Perhaps Gabor should consider using the second type of version control
 system that allows a Perl incantation similar to the first.


Except that PAUSE (which is the primary driver of the $VERSION use) wouldn't
be able to make use of it. As far as I can tell, it loads the .pm files to
find the $VERSION number, and doesn't look at META.json at all.

 -john

Re: license information and link to source code repository from your CPAN distribution

[John M. Gamble]

On Tue, January 8, 2013 5:15 am, Gabor Szabo wrote:
 Hi,

 those of you who read blogs.perl.org probably already saw my posts,
 but I guess there are many others
 on this list who are not reading that site.

 Recently I checked and only 50% of the CPAN distributions have a link
 to a public version control system:
 http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html

 17% don't have the license information in their META file:
 http://blogs.perl.org/users/gabor_szabo/2012/12/174-of-cpan-uploads-have-no-license-in-the-meta-files.html

 It would be nice if you could help improving the situation for your
 modules.


I think the finger should be pointed at h2xs, at least as it stands now. A
programmer new to CPAN won't know about the META information, and h2xs
just isn't oriented that way.

I can pass on the other META info (the module might be uploaded to CPAN
before the author even decides on a version control repository, for
example), but at a minimum h2xs should have been asking about license
information.

(I was going to compare and contrast with module-starter, which I have
used and recommend normally, but I just encountered this unpleasant
surprise:

C:\Users\jgamble\prjmodule-starter --module=Bogus::Example
The getpwuid function is unimplemented at
C:/Perl64/site/lib/Module/Starter/Simple.pm line 97.

So I'm blocked there for a moment.)

 -john

Re: license information and link to source code repository from your CPAN distribution

[John M. Gamble]

On Tue, January 8, 2013 10:43 am, David Cantrell wrote:
 On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote:

 I think the finger should be pointed at h2xs, at least as it stands now.
 A
 programmer new to CPAN won't know about the META information, and h2xs
 just isn't oriented that way.

 I think the finger should be pointed at perlnewmod.pod, which
 erroneously suggests using h2xs even for non-XS modules.  It should just
 tell people to use module-starter.

 And even if it doesn't work on Windows because of the getpwuid thing,
 it's still better than using h2xs.


Well, I'm hoping this is a temporary problem. I've used module-starter
successfully a couple of years ago. I'm submitting a bug report now.

 -john

Re: license information and link to source code repository from your CPAN distribution

[John M. Gamble]

On Tue, January 8, 2013 12:14 pm, Olaf Alders wrote:

 On 2013-01-08, at 1:03 PM, David Nicol wrote:


...



 On the other hand, a comprehensive CPAN by git as an additional CPAN
 feature would have a measure of awesome to it, as an alternate
 distribution and synchronization method.

I don't know what that means. What would this hypothetically entail?


 Well, there is GitPAN, but it needs a lot of love
 https://github.com/gitpan

Just to nip a possible misunderstanding in the bud, as far as I can tell
the purpose of gitpan was to help CPAN authors who were not on github get
on github, by starting their own accounts and forking their modules from
gitpan (which I did, by the way. Thank you, Schwern).

It was not intended as a constantly synchronized central repository of all
of CPAN.

So if you need a leg up on getting your modules over to a version control
system, gitpan is a very useful starting point.

 -john

Re: CPAN testers: failure installing dependencies

[John M. Gamble]

On Mon, November 5, 2012 1:54 am, Shmuel Fomberg wrote:
 Hi All.

 Can anyone tell me, when a cpan smoker / tester is trying to test a module
 but fails to install a dependency, what happens?

 Who should I convince to make such a failure similar to test fail?
 Or maybe mark it as failure to all the modules that depend on the failed
 module?

 I seek to do it because lately modules feel free to have deep
 dependencies,
 a lot of modules have some small test failure percentage, and these add up
 rather quickly.

 It is annoying to try and installed some new-shiny module, just to see
 some
 dep^3 fails testing, and then to start investigating.

 Thanks,
 Shmuel.


Sorry for the duplicate message Shmuel, I forgot to hit Reply All.

I'd count it as a bug, and file a report that way.

For example, if their module depended on Math::Complex, and they failed to
set up the dependency in (say) their Build.PL, I'd file a bug report
saying that they needed to add the line
'Math::Complex'= '1.36', # Bugfix of Im().
to their requires hash.

 -john

Re: About Math::Cephes module.

[John M. Gamble]

Don't know if this is the problem, but I note that there are two version
0.47 packages on CPAN, one posted 05 Jan 2009, the other posted 13 Mar
2012.

This may have had an effect on the indexer.

 -john

On Fri, October 12, 2012 3:42 am, Shlomi Fish wrote:
 Hi all,

 On Tue, 9 Oct 2012 09:20:25 +0200
 Shlomi Fish shlo...@shlomifish.org wrote:

 Hi aero,

 thanks for your report.

 On Tue, 9 Oct 2012 14:43:18 +0900
 aero chahk...@gmail.com wrote:

  Hi,
 
  I tried to install Math::Cephes module both on Window and Linux.
 
  On windows, cpan can't find the module.
  cpan Math::Cephes
  CPAN: CPAN::SQLite loaded ok (v0.202)
  Database was generated on Tue, 09 Oct 2012 02:55:37 GMT
  Warning: Cannot install Math::Cephes, don't know what it is.
  Try the command
 
  i /Math::Cephes/
 
  to find objects with matching identifiers.
  CPAN: Time::HiRes loaded ok (v1.9725)
 
  so, after I designated Full path name like the following .I managed
  to install the module.
 
  cpan S/SH/SHLOMIF/Math-Cephes-0.48.tar.gz
 

 I can confirm that cpan Math::Cephes or cpanp -i Math::Cephes
 from the Linux command-line are still finding the old
 Math-Cephes-0.47, while I have already published Math-Cephes-0.48:

 https://metacpan.org/release/Math-Cephes

 Dear CPAN admins, can you please fix the underlying problem that
 prevents the recently uploaded Math::Cephes from being indexed, so I
 can upload a new version which will be properly indexed?


 Any news? Can anyone tend to this problem? I have not heard from you back.

 Regards,

   Shlomi Fish

 --
 -
 Shlomi Fish   http://www.shlomifish.org/
 Freecell Solver - http://fc-solve.shlomifish.org/

 Duplicate effort in FOSS is inevitable. Live with it.

 Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: Suppressing excess indexing

[John M. Gamble]

On Thu, September 20, 2012 9:45 am, Johan Vromans wrote:
 David Cantrell da...@cantrell.org.uk writes:

 I would say that it's actually *useful* to index them all.  That way
 your dist will show up if people search for 'FLAC' (to pick just one
 example), which is probably a Good Thing.

 That would be the purpose of keywords. Not indexes by package name.

Are keywords being used yet? I've seen no evidence of it on either CPAN or
MetaCPAN.

 -john

Re: RFC: the Author:: namespace

[John M. Gamble]

On Sat, September 8, 2012 12:08 pm, Leon Timmermans wrote:
 On Sat, Sep 8, 2012 at 6:59 PM, sawyer x xsawy...@gmail.com wrote:
 No, I can't. Acme:: is people sharing jokes, which in most cases aren't
 supposed to be useful, they're JOKES. Author::PAUSEID,
 Task::BeLike::PAUSEID and Dist::Zilla::PluginBundle::PAUSEID are by
 people
 *not* sharing *anything* with *anyone* except using CPAN as their
 private
 repository. So, yes, there's a major difference.

 Dist::Zilla author bundles are useful if anyone wants to contribute to
 your project.

 Obviously CPAN is a place to upload modules so others can view, share
 and
 use them.

 By your claim, I can use CPAN to upload my last YAPC trip pictures (and
 hell, replace Flickr), because I've never seen any description of what
 CPAN
 is. So, no, there isn't a given description, but I think it's pretty
 obvious to both of us and anyone on this list and on CPAN. Using generic
 excuses as there's no sign on what goes in the pool, so I can pee in
 it
 don't help us much here.

 Not saying it's a good idea, but it has been done before, and not by
 the least of us:
 http://backpan.perl.org/authors/id/M/ME/MERLYN/index.html


That example doesn't actually support that statement. It's an index file
in an HTML directory, and all of the links in it reference outside of
CPAN. There are no personal single-use modules, random code, or YAPC trip
pictures. I don't know if it's proper, but CPAN is clearly set up to use
it (one clicks on MERLYN in the CPAN line of
http://search.cpan.org/~merlyn/). So this really has nothing to do with
the subject at hand.

 -john

Re: sudo in Const::Fast

[John M. Gamble]

Hmm. Looking at the INSTALL file, there's this:

## Installation with cpanm

If you have cpanm, you only need one line:

% cpanm Const::Fast

If you are installing into a system-wide directory, you may need to pass the
-S flag to cpanm, which uses sudo to install the module:

% cpanm -S Const::Fast


But you're not using cpanm, and I'm not seeing anything beyond the delete
or rewrite of BUILD_REQUIRES and CONFIGURE_REQUIRES hashes in the
Makefile.PL depending on the version of ExtUtils. Strange.

 -john

On Wed, July 18, 2012 5:46 pm, Shawn H Corey wrote:
 On 12-07-18 06:44 PM, Matthew Musgrove wrote:
 I'm sure Leon will pipe in soon but in the mean time, what version did
 you install and how? The only use of sudo I see in Const-Fast-0.011 is
 in the INSTALL text file.

 $ cpan Const::Fast
 CPAN: Storable loaded ok (v2.35)
 Reading '/home/shawn/.local/share/.cpan/Metadata'
Database was generated on Wed, 18 Jul 2012 12:13:34 GMT
 Running install for module 'Const::Fast'
 Running make for L/LE/LEONT/Const-Fast-0.011.tar.gz
 CPAN: Digest::SHA loaded ok (v5.71)
 CPAN: Compress::Zlib loaded ok (v2.052)
 Checksum for
 /home/shawn/.local/share/.cpan/sources/authors/id/L/LE/LEONT/Const-Fast-0.011.tar.gz
 ok
 CPAN: File::Temp loaded ok (v0.22)
 CPAN: Parse::CPAN::Meta loaded ok (v1.4404)
 CPAN: CPAN::Meta loaded ok (v2.120921)
 CPAN: Module::CoreList loaded ok (v2.68)

CPAN.pm: Building L/LE/LEONT/Const-Fast-0.011.tar.gz

 Checking if your kit is complete...
 Looks good
 Writing Makefile for Const::Fast
 Writing MYMETA.yml and MYMETA.json
 cp lib/Const/Fast.pm blib/lib/Const/Fast.pm
 Manifying blib/man3/Const::Fast.3
LEONT/Const-Fast-0.011.tar.gz
/usr/bin/make -- OK
 CPAN: YAML loaded ok (v0.84)
 Running make test
 PERL_DL_NONLAZY=1 /home/shawn/perl5/perlbrew/perls/perl-5.16.0/bin/perl
 -MExtUtils::Command::MM -e test_harness(0, 'blib/lib',
 'blib/arch') t/*.t
 t/00-compile.t  ok
 t/10-basics.t . ok
 t/release-kwalitee.t .. skipped: these tests are for release
 candidate testing
 t/release-pod-coverage.t .. skipped: these tests are for release
 candidate testing
 t/release-pod-syntax.t  skipped: these tests are for release
 candidate testing
 All tests successful.
 Files=5, Tests=26,  1 wallclock secs ( 0.05 usr  0.02 sys +  0.20 cusr
 0.02 csys =  0.29 CPU)
 Result: PASS
LEONT/Const-Fast-0.011.tar.gz
/usr/bin/make test -- OK
 Running make install
 [sudo] password for shawn:


 --
 Just my 0.0002 million dollars worth,
Shawn

 Programming is as much about organization and communication
 as it is about coding.

   _Perl links_
 official site   : http://www.perl.org/
 beginners' help : http://learn.perl.org/faq/beginners.html
 advance help: http://perlmonks.org/
 documentation   : http://perldoc.perl.org/
 news: http://perlsphere.net/
 repository  : http://www.cpan.org/
 blog: http://blogs.perl.org/
 regional groups : http://www.pm.org/

Re: XML-LibXML's 2.* Versioning Scheme: Please Advise.

[John M. Gamble]

I'm curious -- I know PAUSE checks the $VERSION in the package (I ran into
a thought that was inherited problem once), but isn't it using the the
version key in the META.json or META.yml files for its indexing? So while
getting the version information right in $VERSION is important, wouldn't
getting it right in Build.PL or dist.ini (or whatever tool you use) be
equally important?

 -john

On Thu, May 31, 2012 9:07 am, Fields, Christopher J wrote:
 Pretty much came about this independently for bioperl, but maybe it's a
 bit like convergent evolution :)

 bioperl uses the 1.x.y versioning and it has been a real pain to deal will
 over the years.  We've discussed this over the years, and since we're
 breaking bioperl up into smaller releases we'll be switching over to a 2.x
 release, pretty much the as the below.

 my 2c

 chris

 On May 31, 2012, at 8:57 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:

 This will be part of my talk at YAPC.

 I recommend you use 2.xxx, where xxx is always zero-padded.

our $VERSION = '2.001'; # 2nd version of revision 2
our $VERSION = '2.420'; # 421st version of revision 2

 It has the following properties:

 * It is fully compatible with the advice in
* perlmodstyle
* version.pm
* strict version rules
  http://p3rl.org/perl5120delta#Version-number-formats
* http://www.dagolden.com/index.php/369/ ¹
* Perl::Critic::Policy::ValuesAndExpressions::ProhibitVersionStrings
* Perl::Critic::Policy::ValuesAndExpressions::RequireNumericVersion
 * It completely prevents:
* trailing zeros from disappearing because it's a quoted string
* the confusion about 1.10  1.9 (Perl says that's true, other
  system say the opposite) because there are always exactly 3 digits
  after the decimal mark, so any(numeric,lexicographical,naturalsort)
  comparison has the same result
* the confusion about 5.10.1 == 5.010001 (and the variant mentioned
  by Aldo) since there is only a single representation because there
  are only enough decimal places (namely 3) for one portion of semver
  (or Perl's notion thereof)
* the confusion around v-strings which after all those years still
  are such an usual and (on average) poorly understood data type
* that ugly v-prefix in the distro package name
 * It is fully compatible with downstream packaging toolchains (RPM
  specfile macros and the like).
 * It is incompatible with semver. Not a big loss, for the reasons
  already mentioned by David.

 ¹ Avoid underscore version numbers and you don't need that ugly `eval`.
 Simply use the `TRIAL` feature for trial releases instead.
 https://pause.perl.org/pause/query?ACTION=pause_04about#convention

Re: DBIx::Pg::CallFunction

[John M. Gamble]

On Tue, May 29, 2012 4:42 am, Shlomi Fish wrote:
 Hi Joel,

 On Tue, 29 May 2012 14:48:27 +0700
 Joel Jacobson j...@trustly.com wrote:

 Hi!

 I'm about to submit a module to CPAN and would like some feedback on the
 proposed module name, and any other feedback on the code or interface.

 http://prepan.org/module/429En4oFbi
 https://github.com/joelonsql/dbix-pg-callfunction

 This module will be used at a financial institute processing millions of
 transactions,
 so I urge you to try to help me find any eventual bugs before putting it
 in
 production.


 OK, here's what I ran into:

 1. Regarding the choice of licence, see:
 http://www.shlomifish.org/philosophy/computers/open-source/foss-licences-wars/#which-licence-same-as-perl
 (including the links) and
 http://perlbuzz.com/2010/06/artistic-license-20-makes-dual-license-boilerplate-unnecessary.html

 (Yes, I know that most people still do not follow this advice, but I'm
 still going to try.)


It's kind of pointless to twit the end-users about this when it's the end
result of an automated process. Complain on MetaCPAN to the maintainers of
the module-making tools.

[skipping the style complaints]


 3. bin/example.pl should really be under eg/ or examples/ or whatever.


Yes. Absolutely agree.

[more style complaints skipped]


 6. my $validate_name_regex = qr/^[a-zA-Z_]+[a-zA-Z0-9_]*$/; == you can
 omit the first + in this case.


Yup. I'm guessing this is the result of an editing session that didn't
completely clear away the redundant code.

 7. «$_ =~ $validate_name_regex || croak invalid format of argument name:
 $_ for @arg_names;»

 I was wondering where $_ comes to play until I saw the trailing for
 (past the 80 columns). I suggest converting it into a foreach loop with a
 lexical variable:

 foreach my $name (@arg_names)
 {
   if ($name !~ $validate_name_regex)
   {
   croak...
   }
 }

 8. You may wish to cache the prepared SQL statements in call() based on
 the $name somewhere for making the execution faster (instead of preparing
 a statement each time the function is called. (Though DBI may already do
 this for you).


YES! I don't know how frequently the functions get called, but if it's in
a tight loop it's something that should be addressed.

 9. $proretset - what does this variable mean? I cannot parse the meaning
 of its identifer.

Return set, obviously. Don't know what the pro stands for, but who
cares? It's another style complaint.


 Otherwise, looks fine.

 Regards,

   Shlomi Fish


 -john

Re: DBIx::Pg::CallFunction

[John M. Gamble]

On Tue, May 29, 2012 7:46 am, Matthew Musgrove wrote:
 Joel,
 Perhaps you could explain how DBIx::Pg::CallFunction differs from
 DBIx::ProcedureCall and why someone would choose one over the other?

 http://search.cpan.org/dist/DBIx-ProcedureCall/ProcedureCall.pm

 Matt


Could it be that one is calling built-in functions, while the other is
calling stored procedures? It's hard to tell from the documentation
though. Joel, could you expand on that please?

 -john

Re: Looking for Sean Cannon (DODGER)

[John M. Gamble]

Just to follow up: I sent e-mail to those who might have known Sean
Cannon, and he seems to have vanished in their circle too. That doesn't
make this conclusive, but I think it's more than reasonable to assign
co-maintainance to whomever wants to apply patches.

 --john

On Mon, December 12, 2011 1:55 am, Shlomi Fish wrote:
 Hi Neil,

 On Mon, 12 Dec 2011 00:41:54 +
 Neil Bowers n...@bowers.com wrote:

 Hi,

 Does anyone know how I can contact Sean Cannon? His PAUSE id is DOGER,
 and he has several dists on CPAN, including Geo::Coder::HostIP, which
 I've fixed a few bugs in.


 well, the web site whatever3d referred to in
 https://metacpan.org/author/DODGER
 is down and his email appears to point at http://www.aquest.com/ whose
 owner
 appears to have passed away. There also appears to be many Sean Cannons:
 http://www.linkedin.com/pub/dir/Sean/Cannon .

 As a result, I think it's safe for you to try and get co-maint on the
 package.
 There's also this:

 http://wayback.archive.org/web/*/http://www.whatever3d.com/

 Regards,

   Shlomi Fish

 Neil




 --
 -
 Shlomi Fish   http://www.shlomifish.org/
 Interview with Ben Collins-Sussman - http://shlom.in/sussman

 My opinions may seem crazy but they all make sense. Insane sense, but
 sense
 nonetheless.

 Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: Looking for Sean Cannon (DODGER)

[John M. Gamble]

On Mon, December 12, 2011 1:55 am, Shlomi Fish wrote:
 Hi Neil,

 On Mon, 12 Dec 2011 00:41:54 +
 Neil Bowers n...@bowers.com wrote:

 Hi,

 Does anyone know how I can contact Sean Cannon? His PAUSE id is DOGER,
 and he has several dists on CPAN, including Geo::Coder::HostIP, which
 I've fixed a few bugs in.


 well, the web site whatever3d referred to in
 https://metacpan.org/author/DODGER
 is down and his email appears to point at http://www.aquest.com/ whose
 owner
 appears to have passed away. There also appears to be many Sean Cannons:
 http://www.linkedin.com/pub/dir/Sean/Cannon .

That was unexpected. Yes, Dan Lawrence (of aquest.com) passed away last
year. He was a friend of mine since college, and a prolific coder, though
not in perl. I don't know Sean Cannon, but the domain he used for e-mail
(dodger.org) is apparently available to be taken over. So it does look
like he at least has dropped off-web.

 -john


 As a result, I think it's safe for you to try and get co-maint on the
 package.
 There's also this:

 http://wayback.archive.org/web/*/http://www.whatever3d.com/

 Regards,

   Shlomi Fish

Re: The module authors pledge

[John M. Gamble]

On 11/10/2011 9:33 PM, David Nicol wrote:
I think this is not necessary at all.  I think you have pretty much 
described the current standards for granting takeover. I think the 
barrier to making local forks is already very low and there is no 
reason to switch the whole thing to Git.




Yeah, that was my impression as well. I've observed take-overs here, and 
they pretty much are exactly the same procedure -- Hey, is John 
Doe-Smith still working on his modules? No? The can you grant 
co-maintenance to Jane Roe-Jones? (Granted with more-back-and-forth 
than that, but it still isn't new.)


Really, the only thing that could help with the current situation is a 
direct contact number, and I don't see that happening.


(For what it's worth, having gone through a similar situation when my 
mother passed away recently, I'm setting up a list of accounts to be 
mailed if I get hit by a bus for my brother and sister, but that's about 
the only change I'm making right now.)



I think CPAN is fine as it is.



Oh, I can think of some changes. But they're not relevant to the 
discussion here.


-john

Re: Naming a module that injects new code into a file's source at compile time

[John M. Gamble]

On 11/1/2011 11:03 AM, Eric Strom wrote:

I am working on a module and set of tools for injecting source into
another file at compile time.  It currently does this by using
Filter::Util::Call to hook into the compilation process, inject the
new code before the next line that perl will compile, and then remove
itself handing control back to the compiler.

I have tentatively named this module `eval.pm`

use eval 'my $x = 1';

use eval some_sub(...);

since `use` implies compile time and it is injecting the source into
the currently compiling `eval`.

but I am considering any of the following names:

eval (my preference)
insert
inject
inline
compile
here

Since all of these names are single word/lowercase names, I wanted to
put the name up for the Perl community to comment on.

While not a pragmatic module in and of itself, the primary usage is to
insert declarations and other code elements that are otherwise
impossible to import (package declarations, my/our lexical
declarations, ...).  So due to this behavior, a lowercase name seems
appropriate.

The overall goal of the module is to allow people to write a macro function:

 sub my_0 {map my \$$_ = 0, @_}

And then be able to write:

 use eval my_0 qw(x y z);

And have the compiler see `my $x = 0; my $y = 0; my $z = 0;`

These macro functions can of course be of any complexity, but their
scope is limited to the supplied arguments, and not to the source file
at large, as would be the case with a normal source filter.

I have a fully written module with a decent test suite ready to upload
once the name is finalized.

This question was first posted to modu...@perl.org, and Steffen
Mueller pointed me here.  This was the first posting:

 http://www.nntp.perl.org/group/perl.modules/2011/10/msg78203.html

Thanks for your time,

Eric Strom
a...@cpan.org
https://metacpan.org/author/ASG


Huh. I was going to suggest inline, somewhat facetiously, but it turns 
out there already is an Inline::Perl module (it doesn't do quite what 
you've described, but on the other hand it might do something of what 
you want).


How about include... no, there's already an include module.

I don't like compile, as that implies something different from what 
you're doing.


Just from an English language point of view, here works since it forms 
a decent two-word sentence (use here or even require here).


Absent other suggestions, here seems to be the best choice remaining 
on your list. I'm not thrilled with eval.


-john

Re: PDF in Marpa::XS distribution?

[John M. Gamble]

On Sun, July 17, 2011 11:43 am, Jeffrey Kegler wrote:
 I'd like feedback on a question.  My feeling is that internals
 documentation
 is important, that disk is relatively cheap, and that I should include the
 PDF file that contains Marpa's internal documentation with the CPAN
 distribution.  But I'd like to know if others agree.

[ snip paragraph on 3M size]


 The sources of the PDF are already in the Marpa::XS distribution, but Cweb
 and TeX are required to build the PDF.  Cweb and Tex can be complicated to
 install -- it's a lot to ask of someone taking a first look at the code.
 Even if you already have Tex, it can save a lot of trouble if the PDF is
 already built.


Slightly off-topic question: can the Cweb-TeX combination produce the
document in EPUB format? I ask only because a document of that type would
be very useful for an eBook reader (Nook/Kobo/Kindle), and it would make
more sense for for those of us with one of these devices... which would
give you even more reason to *not* have these end files stored in the
tarball.

A second, more useful (in my opinion) format would mean that much more
space taken up, and give you more reason to have a site other than CPAN
for your documentation.

 -john

Re: Making sure your module works on other OS-es as well

[John M. Gamble]

On 7/3/2011 6:40 AM, Barbie wrote:

On Sun, Jul 03, 2011 at 07:42:42PM +0900, Shmuel Fomberg wrote:


The point is that CPAN deprecation should lag behind Perl
deprecation policy.

It does. Testers do upgrade over time. The oldest perl currently tested
is 5.6.2, up until about 18 months ago we were still getting test
reports for 5.5.x.

While perl versions are still relavent in the wild, then I'm happy to
see reports for them.

Authors do not need to support older versions, and often the reports
verify that distributions are no longer supported for a particular
version of perl. As David stated, it's all just data.

Cheers,
Barbie.


Just to be clear: If I have a perl requirement of, say, 5.10 in my 
META.yml, the

smokers will skip testing with all versions of 5.6 and 5.8?

What if the distribution is old and without a META.yml, but there's a 
require 5.6;

line in the module? What happens then?

(My modules are currently 5.6 friendly, although I've been considering 
bumping

that up to 5.10.)

-john

CPAN In The Comics

[John M. Gamble]

Rhymes With Orange has a perlish flavor today:

http://www.rhymeswithorange.com/2011/03/March-23-2011/

For those of you with worse eyesight than mine, the modules listed are:
Algorithm::Checkdigits
SMS::Send
HTTP::OAI

Congratulations Mathias Weidner, Adam Kennedy, and Tim Brody.

-john

Re: Recommended builder?

[John M. Gamble]

David Golden wrote:

On Sat, Dec 4, 2010 at 4:35 AM, Octavian Rasnita orasn...@gmail.com wrote:
  

Is there a module you recommend for creating CPAN packages?

Module::Build, Module::Install, ExtUtils::MakeMaker, Dist::Zilla, another one?

Is one of them more compatible with CPAN, CPANPLUS, App::cpanminus, or better 
maintained, prefered for the future?



All of the module builders you list are compatible with all the CPAN
clients you list.

None of them are best but they offer different tradeoffs.  Here is my take:
  

[cutting to the chase...]

Module::Build -- this is the 'pure perl' alternative.  It is very easy
to customize compared to EU::MM but you can't rely on users having a
new enough Module::Build for any given feature unless you target Perl
5.10.1 (which added the ability for CPAN/CPANPLUS to bootstrap tools
you need *before* running Build.PL)
  
What features do you mean? I shifted over to Module::Build when I was 
still using Perl 5.6.
My packages are not complicated (single .pm file; pure perl; the 
create_makefile_pl

set to 'traditional' for non-Build users), so maybe there's something else?

[more cutting...]

Dist::Zilla also can create a new boilerplate distribution, similar
to Module::Starter or h2xs.  The other three do not.

I have switched to Dist::Zilla and many other prolific CPAN authors
have as well.  (It was written by RJBS, the most prolific CPAN author
of all, so he has some perspective on what's the easiest thing for
managing CPAN distributions).  If you are interested in learning
Dist::Zilla, the online tutorial is the way to go:
http://dzil.org/tutorial/start.html

If you don't want a complete solution, the question is how much
customization do you need (to the test process, distribution packaging
process, etc.)?  If the answer is a lot, then I would recommend
M::B.  If the answer is very little, then I would recommend M::I.
  


Huh. I would never have considered Module::Build complicated (but then 
again, I don't have
complicated modules). On the other hand, thanks for pointing out the 
Dist::Zilla tutorial, that's

going to be very helpful.


Avoid direct EU::MM entirely.
  

Yep.


I hope that helps.  (I hope users of other tools find my descriptions
relatively objective.  My apologies for any excessive bias.)

Regards,
David

  


   -john

Re: Why are you releasing modules to CPAN?

[John M. Gamble]

Gabor Szabo wrote:

When I teach Perl people keep asking me why do all these
people spend their free time on writing modules and
uploading them to CPAN?

  


I suspect part of it is like any other creative endeavor: to share with 
one's
audience. And the audience here is very positive. Booing is rare 
(although not
unheard of).  What's more common are the helpful e-mails and suggestions 
that

make the code and my own satisfaction with my work better.

Beyond that, there are additional, different, motivations per module. My 
first

module was simply part of my learning perl experience, an experience that
included registering to CPAN for the first time. Another module was a
thank-you to another person who sent me his mathematics paper to study (I
implemented his mechanism in code). Both modules turned out to get 
unexpected

interest, and I've communicated with some interesting people as a result.

   -john

Re: naming advice required

[John M. Gamble]

Aristotle Pagaltzis wrote:

* Ryan Voots simcop2...@yahoo.com [2009-11-09 15:20]:
  

I Thought the typical convention was to try to find some other
root namespace to put things in rather than making yet another
one?



No one browses CPAN by namespace any more, so it hardly matters.
  


Ahem.  Just because it's deliberately made difficult to do so doesn't 
mean that no one does it.


In particular the Math and Algorithm namespaces are something I browse 
through often, and I

doubt that I'm the only one.


Whereas I find the trend toward cutesy names problematic. Because
ultimately what matters is that things be findable by sticking
the obvious keywords into search.cpan.org. Github::Fork::Parent
is quite acceptable by that criterion.

Regards,
  


   -john

Re: a lot of controversy about Module::Build

[John M. Gamble]

Bill Ward wrote:
On Wed, Apr 8, 2009 at 1:05 PM, Hans Dieter Pearcey 
hdp.perl.module-auth...@weftsoar.net 
mailto:hdp.perl.module-auth...@weftsoar.net wrote:


On Wed, Apr 08, 2009 at 10:55:44PM +0300, Burak Gürsoy wrote:
 I think M::B has a clean and understandable interface while
EU::MM is
 archaic (yes I know I didn't say something new).

Any current argument about Perl installation tools is, as far as I
can tell,
primarily a battle between Module::Build and Module::Install, with
EUMM on a
stretcher by the sidelines.  Pitting M::B against EUMM makes your
argument
neither fair nor compelling.


For the average simple module that's just a pm file or two, EUMM is 
the least painful solution.  It comes with every version of Perl that 
a user might possibly have, and it works the same in each of those 
Perl versions.  It may be clunky and lack many desirable fetures, but 
it works just fine in most cases.
Erm... not in my experience.  For a simple pure-perl package, M::B 
turned out to be simpler to use when setting up a new package.  Since I 
don't use either CPAN or CPANPLUS, those details were a non-issue, and I 
let M::B create the Makefile.PL also.  Much less hassle.  It's why my 
new package was made with M::B, and why I transfered my other packages 
to M::B.


Note that I am at the lowest level of perl programmer here: pure perl, 
minimal use of dependencies, straightforward documentation.


   -john

Re: Integrating license related things of CPAN

[John M. Gamble]

Eric Wilhelm wrote:

# from Ricardo SIGNES
# on Sunday 26 October 2008:

  

It would be nice to have a license pragma.

  use license Perl;
  

What would this do?



Skip calls to any code which didn't conform to that license ;-)

  


Oh good.  Nothing that could possibly go wrong then.

   -john

Re: Removing or Archiving outdated and unsupported modules on CPAN; proposal

[John M. Gamble]

Jonathan Rockway wrote:

* On Wed, Apr 02 2008, Linda W wrote:
  

I'd like to see the practice of domain-name squatting...er, I mean
module-name squatting squished.  Let people develop on devel.cpan.org and
when the owner feels their software ready to be released (V1.0) for
general use -- it can be moved to the main base.  While I know that releasing
a spec or a plan as a name reservation has been common practice, I run
across too many modules, that years after their posting date, seem to be nothing
more than place holders for vaporware.



This is annoying, but who cares?  The placeholder modules are few and
far between.

Actually, I don't know that.  Do we have any real numbers?


  If you want to fix the module, send the author a patch.
  


I agree that the author should be contacted, but remember that she is 
talking about
placeholder modules that don't have any code.  It is probably better to 
apply for ownership in
much the same way that the apparently abandoned working modules are.  
Write to the list,
apply for co-ownership if the author does not reply (and bear in mind 
that sometimes authors
do not reply for weeks, so that you may have spent a lot of time for 
nothing).



Or pick a new name and upload your own version.


  

[What CPAN Is paragraphs snipped]


If I was a paranoid person -- one of the best ways to kill CPAN would
be to have every MS employee (just a random example, but came to mind when
I thought of vaporware) sign up under email and submit plans and
bits of partial code to clog up the CPAN namespace and make searching through
it like searching for the proverbial needle in the haystack.



If I was a paranoid person, I wouldn't go outside my house because
someone on the street could buy a gun and shoot my entire family for no
reason.  Anyone can buy them, and they kill you instantly!  Fear!

Thankfully, most people are too lazy to be malicious.  Attacking the
CPAN would be rather boring.  Attacking the CPAN wouldn't gain anyone
anything important.  People don't do boring things that don't benefit
them.  (Plus, there are ways of dealing with outright malice.  Don't
worry, there are people that keep things like viruses and spam out of
the CPAN.)

The best way to kill the CPAN would be to add a bunch of restrictions on
what can be uploaded.  Another good way would be to delete modules that
have bugs in RT.  


As an example, WWW::Mechanize has a ton of bugs in RT.  It is one of the
best modules on the CPAN, though.  Basically, it has a lot of users.
Whenever they misread the manual, they post a bug report.  The author of
the module tries to go through these and reply, but it's a big time
drain.  So it's easier to just let the bugs stay open.  There is only so
much time in a day; would you rather authors spend their time following
your bureaucratic procedures, or adding new features to the modules?  I
would prefer the latter.

  

2) Allow modules with long-standing bugs or that don't build under the
current perl be marked for possible archiving.



Your long-standing bug may be someone else's feature.  Who cares about
archiving?  What would anyone gain from that?
  


Let's be realistic.  A long-standing bug is probably a bug.  But yes, 
archiving would not help.



Also, who cares about the current version?  There are tons of people
still using 5.005 and 5.6.  There are many, many more people using 5.8
than 5.10.

  


Um, I certainly care.  But on the other hand, it is not a difficult 
thing to check either.


[tagging suggestions and responses snipped.]

  

Not an area I want to address with this -- If it is obsolete
or broken for years, I don't care if it is rated 10 stars, it still
shouldn't clutter up the working CPAN library.  It's not hard if someone
wants to 'game' the system.  If someone is 'gaming' the system, this isn't
meant to deal with that.  It's only meant to slowly expire older, non-working
modules and archive them for historical reference.



The core of your argument confuses me.  You want to archive things.
What is the difference between archiving something and not archiving it?
You want two search sites, one for non-archived modules and one for
archived modules.  No offense, but that sounds like a waste of effort.

  


Not that hard to understand.  It's the equivalent of BACKPAN, with the 
added feature that only
non-working modules would go there (presumably to be replaced by working 
modules in CPAN).
But as before, it is not necessary:  apply for module co-ownership if 
you have code to fix the module

with and the author is non-responsive.


Does this sound like a reasonable, concrete and automatable
proposal?



No, it sounds like an incoherent rant from somebody that knows nothing
about the CPAN.
  


Okay, that was uncalled for.  It wasn't incoherent, and it wasn't a 
rant, and trying to be dismissive
like that doesn't help even if the thesis was wrong.  I agree that the 
problems listed mostly 

Re: (Create a new ?) namespace for applications on CPAN

[John M. Gamble]

On Thu, 17 May 2007, Andy Lester wrote:



On May 17, 2007, at 12:06 PM, Andreas J. Koenig wrote:


One of the oldest ideas for namespace decisions was that when a family
of modules constitutes something you can perceive as a framework, then
any top level namespace is ok. It makes no sense when everybody just
grabs a toplevel namespace with a cute name but when you come with a
bag of modules, you deserve one.


The whole idea of levels of namespace has pretty much been outdated anyway. 
Why is Nike::Foo any better or worse than App::Nike::Foo?


Nobody actually uses this hierarchy.  There's not some outline.  We don't 
traverse a strict tree.




Erm... yes we do.

Yeah, there's no tree-browsing capability on CPAN.  I wish there was.
Right now I have to make do by entering things like Math:: in the CPAN 
search box.  It's clunky, but it is all I've got, since the ridiculous 
and useless modlist seems to be treated as an alternative to tree-like 
searching.


Does it matter that WWW::Mechanize isn't LWP::Mechanize?  Shouldn't similar 
things be named in the same TLNS?


Why isn't RT::* App::RT::*?  Or WWW::RT::*?



Because there's no official tree structure.  Straw man argument, we 
already know that.  That doesn't mean that we don't try to give at least a 
semblance of order.  That there are multiple trees doesn't changed the 
fact that there are trees.


-john

Preserving Supplementary Documentation, Take 2

[John M. Gamble]

It appears that I got shot down at PAUSE:

Is this a separate distribution from Math::Polynomial::Solve? (It
shouldn't be.) Even if not, why not put the documentation as POD in
Math::Polynomial::Solve?

I pointed the respondent to the conversation at

http://www.nntp.perl.org/group/perl.module-authors/4558, which includes
both the reason why not, and the suggestions to solve this.  I got
no response.  I'm presuming silence does not equal consent, so I
have to find a different solution.

The other suggestion was to upload to a subdirectory of my CPAN directory.
I'll probably wind up doing this if no one has any other suggestion.  Does
this sound reasonable?

Thanks,
   -john

He who dies with the most code to maintain wins!
   Michael G Schwern perl5-porters, Wed, 6 Dec 2000

Documentation-only Module

[John M. Gamble]

After some consultation, I've decided to take David Golden's suggestion
and create a package that will hold the PDF article on cubics.  I also plan
to use his suggestion on a name: Math::Polynomial::Solve::Doc.

That leaves a question of the layout of the package.  I probably don't need
to lay out an extended directory structure, since there isn't an 
installation

process.  But would you expect a META.yml file?  How about a Build.PL file?

If you would expect a META.yml file, what lines would you expect in it?
Name and version, of course.  Anything else?

As an aside, it looks like the license (brought up by Chris Dolan) will be a
Creative Commons, since the other licensing schemes are more oriented
towards source code.  This is not in the list of valid licenses as known by
Module::Build::Base.  Should I just choose unknown for the META.yml file,
if the file is needed?

As a further aside, when I looked for the license list many of the sites 
found by
Google say that one should [s]ee Module::Build 
http://search.cpan.org/author/KWILLIAMS/Module-Build/ for the list of 
valid options

(the site http://module-build.sourceforge.net/META-spec.html is one such
example).  Module::Build doesn't list the valid licenses.  One has to search
Module::Build::Base, and even then it's not documented - I had to search
the code.

Thank you for your help.

   -john


Deathbot 9000 would rather avoid Internet drama.
   Questionable Content #642
   http://www.questionablecontent.net/view.php?comic=642

Re: Preserving Supplementary Documentation for Modules

[John M. Gamble]

A. Pagaltzis wrote:

* John M. Gamble [EMAIL PROTECTED] [2006-05-12 14:55]:
  

I have a pdf file, written by Dr. Nickalls, on solving cubic
equations that was the basis for the creation of
Math::Polynomial::Solve.



Was this created from a TeX source, and if so, is that available?
Or if not, could it be reproduced as a TeX source without too
much work? You could use POD with `=begin latex` sections in
combination with Pod::LaTeX.

  


Good point.  He contributes to CTAN, and so I'm sure that the source 
could be made
available under the right conditions (see Chris Dolan's comments on 
licenses).


Thanks,
   -john

Re: Preserving Supplementary Documentation for Modules

[John M. Gamble]

Chris Dolan wrote:


I agree with David in terms of size, but license may be a bigger 
problem.  Unless the author of the PDF explicitly gave you permission 
to release under the same terms as Perl itself (or whatever license 
you have chosen for your code) you may need to follow the advice above 
and bundle it as a separate upload with a different license.  In that 
case, you might consider making it a real Bundle so installing 
Math-Polynomial-Solve-Docs automatically installs 
Math-Polynomial-Solve too.


Thanks, I didn't think of that.  I'll ask him about his views on the 
matter of licenses.  I don't know that I want to make a whole module 
package for the sake of installing a single optional document though.  
It's probably a good idea for a different project I'm working on though.


   -john

Re: Preserving Supplementary Documentation for Modules

[John M. Gamble]

David Golden wrote:

John M. Gamble wrote:

CPAN, of course, is eternal, but putting the pdf in a module that is
only a tenth its size would be an undue burden on downloaders, not to
mention the lack of a clear policy on this.


How big is the PDF?  If it could be optimized down to the 100K range 
or less, I wouldn't really think twice about undue burden.
It's 97K, which of course isn't bad as these things go (although as a 
dial-up user at home, I tend to be more conscious of these things than 
most people).  Still, if it affects the size of a PPM, I'd be annoyed at 
getting more than I asked for.





So. Is there, or could there be, a separate spot on CPAN for
supplemental documentation like PDF files and graphics files? Has
this ever been discussed before?


My immediate thought it to just bundle it in another distribution, 
e.g. Math-Polynomial-Solve-Docs.  Give that a regular distribution 
skeleton with a Pod file that describes what it is and where it is in 
the distribution.  I think that if you create a pdf/ directory and 
put the file in there, it will get picked up as part of other files 
by search.cpan.org.  Then just reference 
Math::Polynomial::Solve::Docs in your main Pod file.


If you want to get really fancy, you could also configure a CPAN 
install tool to install the PDF in the perl library path for local 
browsing. (See the Module::Build::Cookbook for some examples).


This is a good idea, with the caveat that I am just starting out with 
Module::Build (the new upload of M-P-S will make use of it) and am a 
little wobbly on the wheels yet.


   -john

Preserving Supplementary Documentation for Modules

[John M. Gamble]

I have a pdf file, written by Dr. Nickalls, on solving cubic equations
that was the basis for the creation of Math::Polynomial::Solve. I’m
updating the module now, and I’d like to make the pdf file more readily
available (I have Dr. Nickalls’s permission to do so). It exists at
other web sites, but we have no idea how stable that is. I could just
put it in my home web site, but that would only last for as long as I
avoid getting hit by a bus.

CPAN, of course, is eternal, but putting the pdf in a module that is
only a tenth its size would be an undue burden on downloaders, not to
mention the lack of a clear policy on this.

So. Is there, or could there be, a separate spot on CPAN for
supplemental documentation like PDF files and graphics files? Has
this ever been discussed before?

Thanks,

-john

Searching and Browing (was: Re: New module: FLV file parsing)

[John M. Gamble]

Austin Schutz wrote:


On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote:
 

So, I already published it as FLV::Info, but this discussion has  
convinced me that FileFormat::FLV is the best option.  I may use that  
name for v0.02.  My only hesitation is that nobody else seems to be  
using that top-level namespace at this time.


The FF:: namespace is a terrible idea, in my opinion.  I expect that  
it will be meaningless to the majority of module searchers.  The  
argument that search makes names irrelevant is just silly.
   



..because?

Ok, I want to do something with my flash file. I search for
'flash file'...  Oh look, there's a flash file parser. Do I care what it's
called? No. I concur that the module name is effectively meaningless, but I
don't see that it makes any difference to the searcher.
 



Two bad assumptions here: 1) the searcher always knows what words to
search for, and 2) searching is an acceptable substitute for browsing.

In this case of course, 'flash' is pretty obvious and searching for it
should give one everything on CPAN, but in other cases this might not be
true. For example, I had a little trouble with the RSS and Atom
distinction, and had I been even more ignorant, I might have missed some
useful modules.

Taking the other side of the coin, browsing is much more useful when the
module has a name that can catch the eye. Right now we only have two
'browsing' modes in CPAN, the Recent Arrivals list, and the
all-but-useless Module List Chapter. I'd like to see true browsing,
arranged in a tree structure (e.g., a list of top level names that one
could click on, which would bring up a list of the
TopLevelName::NextLevelNames, and so on). Granted that I'm using a
non-existent feature [1] to demonstrate a point, but just how useful would
an FF top level name be in this situation?



It's marginally helpful to have a useful name when including it
in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but
beyond that, what tangible and practical difference does it make?

 



Choosing meaningful variable names in your code is considered good
programming practice. Why wouldn't it be an equally good practice for
naming modules?


   -john

[1] In theory, this means that I just volunteered to work on this.
Given that, does this idea interest anyone?