[31925] in Perl-Users-Digest
Perl-Users Digest, Issue: 3188 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 25 11:09:26 2010
Date: Mon, 25 Oct 2010 08:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 25 Oct 2010 Volume: 11 Number: 3188
Today's topics:
Re: map an array but first item different? <justin.1010@purestblue.com>
problem packaging Net::TFTP for fedora 13 amd64 <j.asenjo@asenjo.nl.invalid>
Re: problem packaging Net::TFTP for fedora 13 amd64 <hjp-usenet2@hjp.at>
Re: problem packaging Net::TFTP for fedora 13 amd64 <j.asenjo@asenjo.nl.invalid>
Re: problem packaging Net::TFTP for fedora 13 amd64 <ben@morrow.me.uk>
version numbers (was: problem packaging Net::TFTP for f <hjp-usenet2@hjp.at>
Re: version numbers (was: problem packaging Net::TFTP f <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 25 Oct 2010 14:15:46 +0100
From: Justin C <justin.1010@purestblue.com>
Subject: Re: map an array but first item different?
Message-Id: <2hcgp7-inj.ln1@zem.masonsmusic.co.uk>
On 2010-10-22, John W. Krahn <jwkrahn@example.com> wrote:
> Justin C wrote:
>> I'm using CGI.pm to generate a table, and within that table I'm using
>> map to put the contents of an arrayref into cells within each table row:
>>
>> print table(
>> { get_formatting_string($formatting) },
>> Tr({-class=>'holding'},
>> [
>> th([@{$col_heads}]),
>> map { td($_) } @{$data},
>> ],
>> ),
>> );
>>
>> Here's what Data::Dumper says about $data:
>> $VAR1 = [ '2010-10-01', 'First consignment of two. Order split due to size.', 'John Smith' ];
>> $VAR2 = [ '2010-10-21', 'Sent email requesting payment. If no joy by follow-up date then set a deadline.', 'Justin' ];
>>
>> The problem I'm having is that when the second column has a lot of text
>> it causes the first column to shrink and wrap and this looks terrible. I
>> can fix this with td({-nowrap=>'nowrap}, $_) if doing things manually,
>> but I'd still like map to handle this for me because I'm using the same
>> sub to print tables with different numbers of columns.
>>
>> How can I set a parameter for the first item while still letting map
>> handle this? ... or how else could I do this?
>
> print table(
> { get_formatting_string($formatting) },
> Tr({-class=>'holding'},
> [
> th([@{$col_heads}]),
> td( { -nowrap => 'nowrap' }, $data->[ 0 ] ),
> map { td( $_ ) } @{ $data }[ 1 .. $#$data ],
> ],
> ),
>);
Ah! There's always MTOWTDI! Thank you for the suggestion. I'd never
considered that map could would on anything other than the whole array.
Justin.
------------------------------
Date: Sun, 24 Oct 2010 15:21:36 +0200
From: "Natxo" <j.asenjo@asenjo.nl.invalid>
Subject: problem packaging Net::TFTP for fedora 13 amd64
Message-Id: <56dff$4cc432e0$4df90e69$1793@news.chello.nl>
hi,
Fedora 13 does not have the Net::TFTP module in their repositories, so I
am using cpanspec to try to build a rpm module. I follow the
instructions on http://fedoraproject.org/wiki/Perl/cpanspec
I then run this:
$ cpanspec -v Net::TFTP --packager 'Natxo Asenjo <user@example.org>'
--srpm
Updating
/home/user/.cpan/sources/modules/02packages.details.txt.gz...
Fetching /home/user/.cpan/sources/modules/02packages.details.txt.gz
from http://www.cpan.org/modules/02packages.details.txt.gz...
Fetching Net-TFTP-0.18.tar.gz from
http://www.cpan.org/authors/id/G/GB/GBARR/Net-TFTP-0.18.tar.gz...
Trying to fetch description from Net-TFTP-0.18/TFTP.pm...
Writing perl-Net-TFTP.spec...
Building source rpm from perl-Net-TFTP.spec
Wrote: /home/user/perl/build/perl-Net-TFTP-0.18-1.fc13.src.rpm
So I get a source rpm file. When I try to rebuild it:
$ rpmbuild --rebuild perl-Net-TFTP-0.18-1.fc13.src.rpm
Installing perl-Net-TFTP-0.18-1.fc13.src.rpm
error: Failed build dependencies:
perl(Test::More) >= 0.8701 is needed by
perl-Net-TFTP-0.18-1.fc13.noarch
But the Test::More version is bigger than that:
$ perl -MTest::More\ 9999
Test::More version 9999 required--this is only version 0.94.
BEGIN failed--compilation aborted.
Any idea why?
TIA,
--
Groeten,
Natxo Asenjo
------------------------------
Date: Sun, 24 Oct 2010 20:14:13 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: problem packaging Net::TFTP for fedora 13 amd64
Message-Id: <slrnic8trl.crv.hjp-usenet2@hrunkner.hjp.at>
On 2010-10-24 13:21, Natxo <j.asenjo@asenjo.nl.invalid> wrote:
> Fedora 13 does not have the Net::TFTP module in their repositories, so I
> am using cpanspec to try to build a rpm module. I follow the
> instructions on http://fedoraproject.org/wiki/Perl/cpanspec
[...]
> $ rpmbuild --rebuild perl-Net-TFTP-0.18-1.fc13.src.rpm
> Installing perl-Net-TFTP-0.18-1.fc13.src.rpm
> error: Failed build dependencies:
> perl(Test::More) >= 0.8701 is needed by
> perl-Net-TFTP-0.18-1.fc13.noarch
>
> But the Test::More version is bigger than that:
>
> $ perl -MTest::More\ 9999
> Test::More version 9999 required--this is only version 0.94.
> BEGIN failed--compilation aborted.
>
> Any idea why?
The versioning schemes of RPM and Perl are incompatible. Perl version
numbers are simple floating point numbers, so 0.94 > 0.8701. But RPM
version numbers consist of segments which are compared indvidually from
left to right. Since 0 = 0 and 94 < 8701, 0.94 is less than 0.8701.
This means that when packaging Perl modules as RPMs, one may have to
adjust the number of digits in version numbers. If there was a version
0.8701 and the new version is 0.94, it must be written as 0.9400 to be
larger than the old version. Or you could change the dependency in the
.spec file from 0.8701 to 0.87.01 so that it is less than 0.94.
In any case you have to inspect the version numbers of the RPM packages
not the Perl modules, to see what scheme is used by Fedora.
hp
------------------------------
Date: Sun, 24 Oct 2010 20:57:24 +0200
From: "J.I. Asenjo" <j.asenjo@asenjo.nl.invalid>
Subject: Re: problem packaging Net::TFTP for fedora 13 amd64
Message-Id: <10eca$4cc48194$4df90e69$29032@news.chello.nl>
On 2010-10-24, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> This means that when packaging Perl modules as RPMs, one may have to
> adjust the number of digits in version numbers. If there was a version
> 0.8701 and the new version is 0.94, it must be written as 0.9400 to be
> larger than the old version. Or you could change the dependency in the
> .spec file from 0.8701 to 0.87.01 so that it is less than 0.94.
ok, I changed that in the spec file and it works. Thanks for the
pointer.
> In any case you have to inspect the version numbers of the RPM packages
> not the Perl modules, to see what scheme is used by Fedora.
Yes, that will be the correct way for future packages. I need to read up
on rpm packaging now.
Thanks again.
--
Groeten,
Natxo Asenjo
------------------------------
Date: Sun, 24 Oct 2010 22:31:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: problem packaging Net::TFTP for fedora 13 amd64
Message-Id: <m6lep7-u0p2.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>
> The versioning schemes of RPM and Perl are incompatible. Perl version
> numbers are simple floating point numbers,
Ahahahahaha. Would that it were so.
Presumably you haven't come across the 'delights' of version.pm yet?
Ben
------------------------------
Date: Mon, 25 Oct 2010 10:27:22 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: version numbers (was: problem packaging Net::TFTP for fedora 13 amd64)
Message-Id: <slrnicafra.hqh.hjp-usenet2@hrunkner.hjp.at>
On 2010-10-24 21:31, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>>
>> The versioning schemes of RPM and Perl are incompatible. Perl version
>> numbers are simple floating point numbers,
>
> Ahahahahaha. Would that it were so.
I left out v-strings, since I think they weren't relevant to the OP's
question.
In the case of Test::More (and many other modules on CPAN), v-strings
also don't capture the intent of the author. If you have two version
numbers like "0.8701" and "0.94", I think it is clear that the author
intended that to mean "version 0, subversion 87, subsubversion 1" and
"version 0, subversion 94", respectively. But 0.8701 is equivalent to
v0.870.100 and 0.94 is equivalent to v.940.0. Fortunately, for
comparison purposes, it doesn't make any difference.
BTW, there's an error in perldoc version. It says (at least until
5.12.1):
$v1 = version->parse("v0.95.0");
$bool = $v1 < 0.96; # FALSE since 0.96 is v0.960.0
The comment should read "TRUE since 0.96 is v0.960.0", but of course
that isn't surprising. A better example would be
$v1 = version->parse("v0.97.0");
$bool = $v1 < 0.96; # TRUE since 0.96 is v0.960.0
> Presumably you haven't come across the 'delights' of version.pm yet?
I know about v-strings, the _ convention for alpha versions on CPAN,
etc. But so far it hasn't caused me any trouble.
hp
------------------------------
Date: Mon, 25 Oct 2010 11:42:02 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: version numbers (was: problem packaging Net::TFTP for fedora 13 amd64)
Message-Id: <qg3gp7-nsu.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-10-24 21:31, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> >>
> >> The versioning schemes of RPM and Perl are incompatible. Perl version
> >> numbers are simple floating point numbers,
> >
> > Ahahahahaha. Would that it were so.
>
> I left out v-strings, since I think they weren't relevant to the OP's
> question.
>
> In the case of Test::More (and many other modules on CPAN), v-strings
> also don't capture the intent of the author. If you have two version
> numbers like "0.8701" and "0.94", I think it is clear that the author
> intended that to mean "version 0, subversion 87, subsubversion 1" and
> "version 0, subversion 94", respectively.
Yes, especially since the latter is usually written "0.87_01".
> But 0.8701 is equivalent to
> v0.870.100 and 0.94 is equivalent to v.940.0. Fortunately, for
> comparison purposes, it doesn't make any difference.
Well, only according to version.pm (and, since version.pm is core since
5.10, UNIVERSAL->VERSION). In 5.8 vstrings were just that, strings, and
weren't convertable to numbers at all.
> BTW, there's an error in perldoc version. It says (at least until
> 5.12.1):
>
> $v1 = version->parse("v0.95.0");
> $bool = $v1 < 0.96; # FALSE since 0.96 is v0.960.0
>
> The comment should read "TRUE since 0.96 is v0.960.0", but of course
> that isn't surprising. A better example would be
>
> $v1 = version->parse("v0.97.0");
> $bool = $v1 < 0.96; # TRUE since 0.96 is v0.960.0
Yup, and this is just one of the cases where version.pm ends up doing
*incorrect* comparisons. If a module says
our $VERSION = version->new("v0.97.7");
and I ask for
use Module 0.96;
I would expect that to succeed, but of course it doesn't.
> > Presumably you haven't come across the 'delights' of version.pm yet?
>
> I know about v-strings, the _ convention for alpha versions on CPAN,
> etc. But so far it hasn't caused me any trouble.
vstrings (in their 5.6 form) don't exist any more. Instead we have
version objects, which do a whole lot of highly complicated stuff to
ensure they can... not compare versions quite right. In particular,
designing the system so that '0.1234' is '0.123.4' when most CPAN
modules use it to mean '0.12.34' was rather stupid. I also have yet to
find a way to get a $VERSION that stringifies as something with a _ in,
*and* compares correctly to the versions either side without a _,
without resorting to
our $XS_VERSION = our $VERSION = "0.12_01";
$VERSION = eval $VERSION;
and relying on EUMM sticking to its documented hacks.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3188
***************************************
