[PATCH] Tweaks to Bleadperl Version Object Support
John Peacock
1) no longer pads to three decimal places when stringifying a version; numified
versions are still zero-padded
$ ./perl -l
$ver = new version v1.2.3;
print $ver;
print $ver->numify();
__END__
1.2.3
1.002003
2) PORTABLE warning if the perl-style version string is used (5.005_03)
$ ./perl -we '$ver = new version v1.2_03; print $ver'
perl-style version not portable at -e line 1.
1.2.30
3) Perl_croak() if a version contains more than a single underscore
$ ./perl -e '$ver = new version 1_23.1_24.1_25;'
Invalid version format (multiple underscores) at -e line 1.
4) stringify "beta" versions with underscore in place of last decimal
$ ./perl -e '$ver = new version v1.2_25; print $ver'
1.2_25
5) Replaces a line in universal.c:boot_core_UNIVERSAL with one that works so
that version objects' overload magic works again.
With reference to 5), is there an XS equivalent to pp_null, i.e. a sub (CV)
which just immediately returns? I need it to permanently fix the changes I made
to xsubpp to support the OVERLOAD keyword.
I am working on new tests as part of the patches to come.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
h...@crypt.org
:The attached patch does the following:
:
:1) no longer pads to three decimal places when stringifying a version; numified
:versions are still zero-padded
:3) Perl_croak() if a version contains more than a single underscore
:4) stringify "beta" versions with underscore in place of last decimal
:5) Replaces a line in universal.c:boot_core_UNIVERSAL with one that works so
Thanks, applied as #17819 so that we're all arguing from the same base.
Hugo
John Peacock
And attached are the tests to argue over...
Andreas J. Koenig
> And attached are the tests to argue over...
First of all I want to thank you for stubbornly pursuiting an
ungrateful task. I do that because I know I might sound ungrateful in
the following :-)
I do not like the betaness indictor of underscores for v-strings. I
found Benjamin's suggestion to follow Linux's and Perl's convention of
an odd second element of the version vector a good suggestion (i.e.
5.7.3 is beta as is 2.5.53). If we would follow that, we could make it
legal to use an unlimited amount of underscores (or no underscores)
for v-string versions. And we could also let 1.2.3_4 be equal to
1.2.34. Special cases hurt. If we can keep the special cases as
limited as possible, we would increase the attractiveness of the
version rules.
What I haven't understood at all is why
(new version v5.005_02)->numify == (new version "5.005_02")->numify
I'd expect that v5.005_02 is the same as v5.502.
And now I probably open a completely different can of worms: I just
discovered that
% /usr/local/perl-5.8.0@17821/bin/perl -le 'print v5.005_02->numify'
Can't call method "numify" without a package or object reference at -e line 1.
Somehow I always presumed that all v-strings are turned into objects
at the parser level. Am I missing something?
--
andreas
John Peacock
> First of all I want to thank you for stubbornly pursuiting an
> ungrateful task. I do that because I know I might sound ungrateful in
> the following :-)
Not to worry; I've had my ego surgically removed! Just ask Tels...
>
> I do not like the betaness indictor of underscores for v-strings. I
> found Benjamin's suggestion to follow Linux's and Perl's convention of
> an odd second element of the version vector a good suggestion (i.e.
> 5.7.3 is beta as is 2.5.53). If we would follow that, we could make it
> legal to use an unlimited amount of underscores (or no underscores)
> for v-string versions. And we could also let 1.2.3_4 be equal to
> 1.2.34. Special cases hurt. If we can keep the special cases as
> limited as possible, we would increase the attractiveness of the
> version rules.
I'm only trying to follow the convention currently ingrained in CPAN. I think
the "beta versions are odd subversion" is a much bigger special case. I want to
automatically cover all of the beta modules on CPAN without forcing the
wholesale re-release of modules.
And remember, whether you initialize a version as a number, v-string, or string,
it should be the same _version_:
$VERSION = 1.2;
$VERSION = v1.2;
$VERSION = "1.2";
are all the same.
>
> What I haven't understood at all is why
>
> (new version v5.005_02)->numify == (new version "5.005_02")->numify
>
> I'd expect that v5.005_02 is the same as v5.502.
new version v5.005_02
and
new version "5.005_02"
convert exactly the same. Here, lets look at it another way:
$ ./perl -Ilib -MDevel::Peek -e 'Dump 5.005_02'
SV = NV(0x8181d20) at 0x816ebc0
REFCNT = 1
FLAGS = (NOK,READONLY,pNOK)
NV = 5.00502
$ ./perl -Ilib -MDevel::Peek -e 'Dump v5.005_02'
SV = PVMG(0x81994e8) at 0x816ebc0
REFCNT = 1
FLAGS = (RMG,POK,READONLY,pPOK,UTF8)
IV = 0
NV = 0
PV = 0x81826c0 "\5\307\266"\0 [UTF8 "\x{5}\x{1f6}"]
CUR = 3
LEN = 6
MAGIC = 0x8184b88
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_v-string(V)
MG_LEN = 9
MG_PTR = 0x817f030 "v5.005_02"
You can see that the v-string is encoded as effectively 5.502, but the
scan_version code only looks at the MG_PTR and uses the original representation
to generate the version object.
>
> And now I probably open a completely different can of worms: I just
> discovered that
>
> % /usr/local/perl-5.8.0@17821/bin/perl -le 'print v5.005_02->numify'
> Can't call method "numify" without a package or object reference at -e line 1.
>
> Somehow I always presumed that all v-strings are turned into objects
> at the parser level. Am I missing something?
>
No, v-strings are magical but not overloaded objects. I had to maintain all
existing v-string code, so all I am doing is hanging some magic off of an
otherwise ordinary scalar. The only time anything peers at the magic is the
version code (to retrieve the original representation) or the 'ref \$vs' code
(which is still open for debate). I would like to find a way to retrieve the
original representation from pure Perl code.
The key to my code is that the version-ness overrides the v-string-ness (which
hardly anyone understands in any case). So the following lines are completely
identical:
$VERSION = "1.2.3";
$VERSION = v1.2.3;
$VERSION = 1.2.3;
Just, for the purpose of discussion, ignore the fact that version objects are
stored as v-strings and look at the behavior of version objects themselves. I
am just using v-strings internally for convenience sake; I could just as easily
have used an array of integers (either IV's or actual int's).
Andreas J. Koenig
> Andreas J. Koenig wrote:
>> I do not like the betaness indictor of underscores for v-strings. I
>> found Benjamin's suggestion to follow Linux's and Perl's convention of
>> an odd second element of the version vector a good suggestion (i.e.
>> 5.7.3 is beta as is 2.5.53). If we would follow that, we could make it
>> legal to use an unlimited amount of underscores (or no underscores)
>> for v-string versions. And we could also let 1.2.3_4 be equal to
>> 1.2.34. Special cases hurt. If we can keep the special cases as
>> limited as possible, we would increase the attractiveness of the
>> version rules.
> I'm only trying to follow the convention currently ingrained in CPAN.
I know, but as Benjamin pointed out, for v-string-like versions, the
convention has not yet been in use, so we can still decide upon it.
> I think the "beta versions are odd subversion" is a much bigger
> special case.
Maybe, but we must also see the price we pay. The underscore in floats
did not complicate things because they were already part of the
language as something that was ignored. Your implementation suddenly
changes the semantics of v-strings in a major way.
> I want to automatically cover all of the beta modules
> on CPAN without forcing the wholesale re-release of modules.
This should not be the highest guideline in the game. If it comes at a
high price, we need to weigh the alternatives against each other.
> And remember, whether you initialize a version as a number, v-string,
> or string, it should be the same _version_:
> $VERSION = 1.2;
> $VERSION = v1.2;
> $VERSION = "1.2";
> are all the same.
I is not possible, at least not when leading zeroes come into play.
And zeroes play an important role in today's modules version numbers.
Maybe we need to hear more voices about v1.023:
In 5.6.1 it was an error "Octal number in vector unsupported".
In 5.8.0 it is the same as 1.23.
What *should* it be? *I* liked the octal number interpretation with
error most.
[...]
>> And now I probably open a completely different can of worms: I just
>> discovered that
>> % /usr/local/perl-5.8.0@17821/bin/perl -le 'print v5.005_02->numify'
>> Can't call method "numify" without a package or object reference at -e line 1.
>> Somehow I always presumed that all v-strings are turned into objects
>> at the parser level. Am I missing something?
>>
> No, v-strings are magical but not overloaded objects. I had to
> maintain all existing v-string code, so all I am doing is hanging some
> magic off of an otherwise ordinary scalar.
OK, that's what I was missing and I guess that's fine with me. Thanks
for the explanation.
[...]
> Just, for the purpose of discussion, ignore the fact that version
> objects are stored as v-strings and look at the behavior of version
> objects themselves.
Sure, that's what I'm doing. We need to come to a conclusion before
5.10 what most people would expect from version objects independent of
implementation. But we should not depart from what we know about
integers, floats and v-strings too much. V-strings are a pesky thing
by themselves, let's try not to add a forth type that spreads more
confusion.
--
andreas
Chromatic
> +# Test stringify operator
> +print "# tests with stringify\n";
diag() will take care of escaping and prettifying these for you. In this case,
you're okay without it, but if you want to print anything much more
complicated, it's worth making the switch.
(Diagnostic output also goes to the correct filehandle registered with
Test::Builder.)
-- c
John Peacock
> Maybe we need to hear more voices about v1.023:
>
> In 5.6.1 it was an error "Octal number in vector unsupported".
>
> In 5.8.0 it is the same as 1.23.
>
> What *should* it be? *I* liked the octal number interpretation with
> error most.
That was my patch, too, so I am of course a little biased. ;~) I object to
dying in the middle of the parse due to a harmless leading zero. It's the
trailing zero's which will kill you... ;~)
>
> We need to come to a conclusion before
> 5.10 what most people would expect from version objects independent of
> implementation. But we should not depart from what we know about
> integers, floats and v-strings too much. V-strings are a pesky thing
> by themselves, let's try not to add a fourth type that spreads more
> confusion.
I know that _I_ was suprised when using a v-string as a version didn't do what I
expected, especially given the discussion in perl56delta.pod. It's really why I
got into this whole thing in the first place. _I_ want to do this:
$VERSION = qw$Revision: 1.2.3$[1];
and have it do something useful. Right now, it won't compare properly with
other things used as versions (i.e. use module 1.2). I think it should, and I
believe I have the way to do it.
There has been previous discussion about how $VERSION had to be a number because
of the mention in the Camel, but you'll notice I got this into 5.8:
> [ 13243] By: jhi on 2001/11/24 18:46:31
> Log: Subject: Re: [PATCH] Make Exporter::Heavy use Universal->VERSION()
> From: John Peacock <jpea...@rowman.com>
> Date: Sat, 24 Nov 2001 14:27:46 -0500
> Message-ID: <3BFFF4B...@rowman.com>
> Branch: perl
> ! lib/Exporter/Heavy.pm
which allows us to the room to change Universal->VERSION() and have most things
work out of the box.
What we on P5P know about v-string behavior should be taken with a big grain of
salt, since most Perl programmers don't know any better (which is why the
mistake above is common). I'm not the only one who thinks that the current
state of v-string behavior is confusing:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00063.html
(which is you, by the way ;~)
and in particular, this message and Jarkko's response:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00096.html
I am more than happy to change my code to take over the v1.2.3 side of v-strings
for versions and leave the 1.2.3 side alone, but that would cause problems for
the nasty people who use v13.10 for CR/LF. :~(
Benjamin Goldberg
[snip]
> +ok ( $version->numify() > v5.005_02, '$version->numify() > 5.005_02' );
Is that 'v' supposed to be there? ISTM that this is converting $version
into a scalar number, and then doing a numeric comparison with a string.
--
tr/`4/ /d, print "@{[map --$| ? ucfirst lc : lc, split]},\n" for
pack 'u', pack 'H*', 'ab5cf4021bafd28972030972b00a218eb9720000';
John Peacock
> John Peacock wrote:
> [snip]
>
>>+ok ( $version->numify() > v5.005_02, '$version->numify() > 5.005_02' );
>
>
> Is that 'v' supposed to be there? ISTM that this is converting $version
> into a scalar number, and then doing a numeric comparison with a string.
>
I was adapting a test file that I wrote for the Universal::Version proof of
concept on CPAN. I should have changed that to this:
+ok ( $version->numify() > 5.005020, '$version->numify() > 5.005020' )
but logically what I was testing was whether 5.6.0 > 5.005_02 (in the sense that
the next higher version was greater than the previous beta version).
Andreas J. Koenig
> Andreas J. Koenig wrote:
>> Maybe we need to hear more voices about v1.023:
>> In 5.6.1 it was an error "Octal number in vector unsupported".
>> In 5.8.0 it is the same as 1.23.
>> What *should* it be? *I* liked the octal number interpretation with
>> error most.
> That was my patch, too, so I am of course a little biased. ;~) I
> object to dying in the middle of the parse due to a harmless leading
> zero.
These leading zeroes are not so harmless. Leading zeroes on integers
always had a well defined meaning: they turned decimals into octals.
Not at all a harmless transformation. I'd like to have that change
reverted and leading zeroes within v-strings be disallowed again.
> I am more than happy to change my code to take over the v1.2.3 side of
> v-strings for versions and leave the 1.2.3 side alone, but that would
> cause problems for the nasty people who use v13.10 for CR/LF. :~(
Sorry, I don't understand that sentence.
--
andreas
John Peacock
> These leading zeroes are not so harmless. Leading zeroes on integers
> always had a well defined meaning: they turned decimals into octals.
> Not at all a harmless transformation. I'd like to have that change
> reverted and leading zeroes within v-strings be disallowed again.
But the original definition of v-strings as specified in perl56delta.pod states
that they are
a string composed of characters with the specified ordinals
which says nothing about integers. A bare number without any decimal points is
an integer; it is completely appropriate to take a leading 0 to signal that as
an octal encoded integer.
However, v-strings are not integers, even though in a very real sense they are
composed of a sequence of integral values. And, most importantly from my point
of view, enforcing this artificial limitation is 100% fatal to any code trying
to create version objects. The script has to be able specify a version in a
commonly understood format and not have Perl throw an illogical (from this
standpoint) error.
What I mean here is that
require 5.005_03;
has to be understood to mean the same thing as
require 5.5.30;
per the transformation rules specified in perl56delta. With my code it finally
does.
>
> > I am more than happy to change my code to take over the v1.2.3 side of
> > v-strings for versions and leave the 1.2.3 side alone, but that would
> > cause problems for the nasty people who use v13.10 for CR/LF. :~(
>
> Sorry, I don't understand that sentence.
>
In the thread I cited, Graham suggested that the v1.2.3 form of v-strings be
taken soley for use as versions, and the 1.2.3 form remain available for other
use as arbitrary bit strings. I can do that with little difficulty.
Andreas J. Koenig
> Andreas J. Koenig wrote:
>> These leading zeroes are not so harmless. Leading zeroes on integers
>> always had a well defined meaning: they turned decimals into octals.
>> Not at all a harmless transformation. I'd like to have that change
>> reverted and leading zeroes within v-strings be disallowed again.
> But the original definition of v-strings as specified in
> perl56delta.pod states that they are
> a string composed of characters with the specified ordinals
> which says nothing about integers.
Ah yes, sorry. I meant ordinal and wrote integer...language problem.
> A bare number without any decimal
> points is an integer; it is completely appropriate to take a leading 0
> to signal that as an octal encoded integer.
See, you're saying "octal". But in 5.8.0, the leading zero is ignored
unless the first ordinal is an octal:
15:40:19 k@k75:/usr/sources/perl/repoperls% /usr/local/perl-5.8.0-threads/bin/perl -le '
print 65.065.065.65;
print 065.065.065.65;
'
AAAA
53535365
This is ridiculous.
> However, v-strings are not integers, even though in a very real sense
> they are composed of a sequence of integral values. And, most
> importantly from my point of view, enforcing this artificial
> limitation is 100% fatal to any code trying to create version objects.
> The script has to be able specify a version in a commonly understood
> format and not have Perl throw an illogical (from this standpoint)
> error.
I really doubt that it is fatal for the whole version project. I
believe, we're close to a solution. You seem to not see where I'm
heading towards. Maybe I need to post longer sentences, I'm always
trying to keep it short.
> What I mean here is that
> require 5.005_03;
This is not a v-string. No problem with leading zeroes in floats.
> has to be understood to mean the same thing as
> require 5.5.30;
This has no leading zeroes. No dispute.
> per the transformation rules specified in perl56delta. With my code
> it finally does.
>> > I am more than happy to change my code to take over the v1.2.3
>> side of
>> > v-strings for versions and leave the 1.2.3 side alone, but that would
>> > cause problems for the nasty people who use v13.10 for CR/LF. :~(
>>
>> Sorry, I don't understand that sentence.
>>
> In the thread I cited, Graham suggested that the v1.2.3 form of
> v-strings be taken soley for use as versions, and the 1.2.3 form
> remain available for other use as arbitrary bit strings. I can do
> that with little difficulty.
I cannot find Graham's posting and I don't understand the implications
of that idea offhand, so cannot comment on that.
--
andreas
Ronald J Kimball
> >>>>> On Mon, 02 Sep 2002 09:15:49 -0400, John Peacock <jpea...@rowman.com> said:
>
> > A bare number without any decimal
> > points is an integer; it is completely appropriate to take a leading 0
> > to signal that as an octal encoded integer.
>
> See, you're saying "octal".
Yes, but he's also saying "a bare number without any decimal points".
> But in 5.8.0, the leading zero is ignored
> unless the first ordinal is an octal:
>
> 15:40:19 k@k75:/usr/sources/perl/repoperls% /usr/local/perl-5.8.0-threads/bin/perl -le '
> print 65.065.065.65;
> print 065.065.065.65;
> '
> AAAA
> 53535365
>
> This is ridiculous.
I wasn't aware of that misbehavior. That is pretty ridiculous.
> > However, v-strings are not integers, even though in a very real sense
> > they are composed of a sequence of integral values. And, most
> > importantly from my point of view, enforcing this artificial
> > limitation is 100% fatal to any code trying to create version objects.
> > The script has to be able specify a version in a commonly understood
> > format and not have Perl throw an illogical (from this standpoint)
> > error.
>
> I really doubt that it is fatal for the whole version project. I
> believe, we're close to a solution. You seem to not see where I'm
> heading towards. Maybe I need to post longer sentences, I'm always
> trying to keep it short.
>
> > What I mean here is that
>
> > require 5.005_03;
>
> This is not a v-string. No problem with leading zeroes in floats.
>
> > has to be understood to mean the same thing as
>
> > require 5.5.30;
>
> This has no leading zeroes. No dispute.
I agree with John. If the intent is to have a syntax for denoting
*versions*, it makes little sense to treat the components as octal numbers.
Why should I be prohibited from having a version like 1.5.08, for example?
(Similarly, I don't think I should be required to use odd versions as betas
and even versions as releases, as suggested elsewhere in the thread.)
> > per the transformation rules specified in perl56delta. With my code
> > it finally does.
>
>
> >> > I am more than happy to change my code to take over the v1.2.3
> >> side of
> >> > v-strings for versions and leave the 1.2.3 side alone, but that would
> >> > cause problems for the nasty people who use v13.10 for CR/LF. :~(
> >>
> >> Sorry, I don't understand that sentence.
> >>
>
> > In the thread I cited, Graham suggested that the v1.2.3 form of
> > v-strings be taken soley for use as versions, and the 1.2.3 form
> > remain available for other use as arbitrary bit strings. I can do
> > that with little difficulty.
>
> I cannot find Graham's posting and I don't understand the implications
> of that idea offhand, so cannot comment on that.
One obvious problem is that arbitrary bit strings will be restricted to
strings of at least three bytes.
Ronald
John Peacock
> On Mon, Sep 02, 2002 at 03:53:54PM +0200, Andreas J. Koenig wrote:
>
>>print 65.065.065.65;
>>print 065.065.065.65;
>>'
>>AAAA
>>53535365
>>
>>This is ridiculous.
>
>
> I wasn't aware of that misbehavior. That is pretty ridiculous.
>
That _is_ misleading, but has nothing to do with the present discussion. If you
walk through the toke.c routines (starting around line 7124), you will quickly
see that the tokenizer has chosen to treat that as
print "53"."53"."53"."65";
where I am leaving out the 065 (octal) => 53 (integer) conversion. Perl never
treats 065.065.065.65 as a single entity. Is this a bug?
However, in the former case, what would it buy us to restore the prohibition on
strictly internal leading zeros, since we are already in the v-string encoding
routines and the zeros are now harmless.
$ ./perl -e 'print ref(\65.065.065.65)'
VSTRING
The v-string code is triggered by the presence of the second decimal in an
otherwise well-formed float (or the leading bare v). It will then eat every
character that is /[\d_.]/ whether the 0 is leading or not.
>
> One obvious problem is that arbitrary bit strings will be restricted to
> strings of at least three bytes.
>
Yes, that was the major drawback and there was a report of code using shorter
sequences to denote control characters (like CR/LF).
Graham Barr
> > v-strings be taken soley for use as versions, and the 1.2.3 form
> > remain available for other use as arbitrary bit strings. I can do
> > that with little difficulty.
>
> I cannot find Graham's posting and I don't understand the implications
> of that idea offhand, so cannot comment on that.
And I cannot remember saying anything. Of course I could have been high
on paint fumes :)
Graham.
John Peacock
> And I cannot remember saying anything. Of course I could have been high
> on paint fumes :)
>
It was a while ago, but then I have been working on this for a while...
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00096.html
Graham Barr
> Graham Barr wrote:
> > And I cannot remember saying anything. Of course I could have been high
> > on paint fumes :)
> >
>
> It was a while ago, but then I have been working on this for a while...
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00096.html
Oh, that message. Was it really that long ago.
Graham.