[0] http://testers.cpan.org/show/Games-AlphaBeta.html#Games-AlphaBeta-0.2.0
Any pointers?
Stig
The obvious thing that springs to mind is the possibility that you are
not specifying the correct minimum versions in the prerequisites but
having looked at the source of this module I can't convince myself
that this is the case.
Note: I think module numbers are compared as pure numbers. This means
that 0.2.0 and 0.2.3 are noor distinct.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
First, when I asked a similar question on PerlMonks, the consensus was
the CPANPLUS often handled dependencies incorrectly, and that warnings
about dependencies should be ignored:
http://www.perlmonks.org/index.pl?node_id=372922
The error messages for your module don't look like dependency
problems, though.
One useful thing is to see how the environments where it's failing are
different from yours. For example, a different version of Perl, a
different endianness if you're doing the sorts of things that depend
on that, etc. It's straightforward to install a different version of
Perl in a temporary location and see how your module works with it;
finding a machine of a different endianness might be a little
trickier.
Another useful thing is to see what it's dying from (often undefined
or empty variables, it looks like) and add assert-style checks for
that in various places in your program. That way if it dies at least
you'll know where. Something like:
defined($a) or die "\$a not defined";
inserted in appropriate places would tell you when a variable first
became undefined, for example.
-----ScottG.
I've been in contact with one of the testers that had a failure. He said
he now cannot reproduce it, but that the first time he tested it some
dependency problems were reported. The module depends on the latest
version of a different module I've written, and if that was not
installed I can well imagine that this error would occur.
> Note: I think module numbers are compared as pure numbers. This means
> that 0.2.0 and 0.2.3 are noor distinct.
I was of the impression that this would be fine, as long as the version
numbers where quoted (but maybe I've missinterpreted
http://search.cpan.org/~jpeacock/version-0.41/lib/version.pm#Quoted_Versions
?).
Stig
I think they might be. The module depends on the latest version of a
different module. If instead an earlier version of this module was used
this problem could well occur, I believe.
> on that, etc. It's straightforward to install a different version of
> Perl in a temporary location and see how your module works with it;
> finding a machine of a different endianness might be a little
> trickier.
I've talked to one of the testers where the tests failed, and he can not
reproduce it. I'm starting to suspect the module is actually ok.
Stig
> Brian McCauley <nob...@mail.com> wrote:
>
>>Note: I think module numbers are compared as pure numbers. This means
>>that 0.2.0 and 0.2.3 are not distinct.
>
> I was of the impression that this would be fine, as long as the version
> numbers where quoted (but maybe I've missinterpreted
> http://search.cpan.org/~jpeacock/version-0.41/lib/version.pm#Quoted_Versions
> ?).
You may or may not have interpreted the document correctly, but you are
not using the version module.
I'm of course aware of that :)
From the above:
"These are the newest form of versions, and correspond to Perl's own
version style beginning with 5.6.0. Starting with Perl 5.10.0, and
most likely Perl 6, this is likely to be the preferred form. This
method requires that the input parameter be quoted, although Perl's
after 5.9.0 can use bare numbers with multiple decimal places as a
special form of quoting."
I took this to mean that the style of quoted version numbers I've used
was okay in Perl 5.6.0 onwards (not only when using the version module).
I must admit that this is the only base I have for that though. Do you
think there is something wrong with my way of specifying the version
number?
Stig
Stig Brautaset wrote:
> Brian McCauley <nob...@mail.com> wrote:
>
>>>>Note: I think module numbers are compared as pure numbers. This means
>>>>that 0.2.0 and 0.2.3 are not distinct.
>>>
>>>I was of the impression that this would be fine, as long as the
>>>version numbers where quoted (but maybe I've missinterpreted
>>>http://search.cpan.org/~jpeacock/version-0.41/lib/version.pm#Quoted_Versions
>>>?).
>>
>>You may or may not have interpreted the document correctly, but you are
>>not using the version module.
>
>
> I'm of course aware of that :)
>
> From the above:
>
> "These are the newest form of versions, and correspond to Perl's own
> version style beginning with 5.6.0. Starting with Perl 5.10.0, and
> most likely Perl 6, this is likely to be the preferred form. This
> method requires that the input parameter be quoted, although Perl's
> after 5.9.0 can use bare numbers with multiple decimal places as a
> special form of quoting."
>
> I took this to mean that the style of quoted version numbers I've used
> was okay in Perl 5.6.0 onwards (not only when using the version module).
This is, I think not a valid inferrence. What it means is that the
version numbering of Perl itself starting with Perl 5.6 uses the new
format. It doesn't mean that all the version-related utilities (e.g.
ExtUtils::MakeMaker) that ship with Perl 5.6 will understand the new
version numbering for modules.
I think the ones that ship with 5.10 will.
It is possible that the ones that ship with 5.6 may magically support
the new numbering if you "use version" and explicily construct your
module version numbers as version objects (which overload the semantics
of < and >).
Okay, thank you for that insight. I will have a look about changing the
version numbers again then.
Stig