I got an error:
Dist E/EB/EBUSBOOM/Net-ICal-0.11.tar.gz, current version undef has been
uploaded by EBUSBOOM. Please contact EBUSBOOM or choose a different
namespace.
I pulled down Net-ICal -- and there is nothing named Types\* in the
distribution.
So why would it conflict?
Seems the index claims it is present, but you can't install it because
it isn't
in the distribution.
On 2013-11-13 07:14, Linda A. Walsh wrote:
I got an error:
Dist E/EB/EBUSBOOM/Net-ICal-0.11.tar.gz, current version undef has
been uploaded by EBUSBOOM. Please contact EBUSBOOM or choose a
On Wed, Nov 13, 2013 at 07:14:44AM -0800, Linda A. Walsh wrote:
I got an error:
Dist E/EB/EBUSBOOM/Net-ICal-0.11.tar.gz, current version undef has been
uploaded by EBUSBOOM. Please contact EBUSBOOM or choose a different
namespace.
I pulled down Net-ICal -- and there is nothing named
On Wed, Nov 13, 2013 at 07:20:17AM -0800, Linda W wrote:
Seems the index claims it is present, but you can't install it because
it isn't in the distribution.
I don't believe you. The reason I don't believe you is that I just tried
it:
$ cpan -t Types
it downloads the correct distribution,
On Wed, Nov 13, 2013 at 07:43:25AM -0800, Linda W wrote:
On 2013-11-13 07:30, David Cantrell wrote:
Ah-- NetIcal1.11 doesn't have it.. but if I try
No I didn't.
Types by itself, it downloads Netical 1.15
The indexing system is broken, IMO...
If it is, it's broken at your end. I wonder what
On Wed, Nov 13, 2013 at 4:43 PM, Linda W perl-didd...@tlinx.org wrote:
On 2013-11-13 07:30, David Cantrell wrote:
Ah-- NetIcal1.11 doesn't have it.. but if I try
Types by itself, it downloads Netical 1.15
The indexing system is broken, IMO...
I see Types:
cp lib/Net/ICal/Parser.pm
On 11/13/2013 04:43 PM, Linda W wrote:
The indexing system is broken, IMO...
no, version 0.11 of Net::ICal is broken.
http://cpansearch.perl.org/src/EBUSBOOM/Net-ICal-0.11/lib/Net/ICal/Types.pm
it says package Types instead of package Net::ICal::Types.
again, an accident. no one reserved
On 2013-11-13 08:28, Aldo Calpini wrote:
This is what I turned in for the justification.
more Types.txt
ease of use;
With a few exceptions, the functions exported are the names of the basic
types. They either take a parameter or not.
If there is a parameter, it tests it as a ref to
On 2013-11-13 07:55, David Cantrell wrote:
I wouldn't. I don't see the need for such a module.
Oh *good* sigmonster!
Why are you being deliberately antagonist.
I was told such behavior wasn't welcome here.
Was I told incorrectly?
On Wed, Nov 13, 2013 at 08:58:41AM -0800, Linda A. Walsh wrote:
It's not meant to be fancy -- just simple and convenient.
Simple and convenient for you perhaps, but that doesn't merit an upload to
the CPAN where code is expected to be usable by all.
At this point I feel obliged to point to
On 2013-11-13 10:13, Karen Etheridge wrote:
On Wed, Nov 13, 2013 at 08:58:41AM -0800, Linda A. Walsh wrote:
It's not meant to be fancy -- just simple and convenient.
Simple and convenient for you perhaps, but that doesn't merit an upload to the
CPAN where code is expected to be
* Linda A. Walsh perl-didd...@tlinx.org [2013-11-13 16:20]:
Unclear as to problem: Tried to register 'Types', but says can't due
to unrelated module.
And that didn’t make you stop and wonder, if you thought that this other
author should not have claimed that namespace, that maybe the same could
On 2013-11-13 16:46, David Mertens wrote:
Linda -
I think that you got feedback that you did not even ask for: a clear
response from the module-authors community to not name your module
Types. Might I suggest Types::LAW. Obviously, LAW are your initials,
but it also lets you brag about
If my understanding is correct and these are only for built-in types,
how about Types::BuiltIn or Types::Perl (cf Types::Numbers and
Types::CLike)?
While I'm at it, I think P is OK as an export, but I think even
IO::P would have been a more descriptive module name and perhaps more
likely to
I second Brian's opinion. I would offer also Types::Core as a potential
name for the module.
As for the ref checking, what if I pass a plain scalar? In that case, I
seem to recall that ref($plain_scalar) will be undef, in which case
comparing it to a string with the eq operator will issue a
* Linda A. Walsh perl-didd...@tlinx.org [2013-11-14 04:25]:
Which would at least have looked better as:
elseif(SCALAR $refx || REF $refx)...
elsif (HASH $refx)...
https://metacpan.org/pod/Params::Util --- Use that.
There you go. Thread solved.
sub ARRAY (;$) {my $p = $_[0]; my
On 2013-11-13 20:38, David Mertens wrote:
I second Brian's opinion. I would offer also Types::Core as a
potential name for the module.
As for the ref checking, what if I pass a plain scalar? In that case,
I seem to recall that ref($plain_scalar) will be undef, in which case
comparing it to a
17 matches
Mail list logo
