Skip Menu |

This queue is for tickets about the version CPAN distribution.

Report information
The Basics
Id: 102272
Status: resolved
Priority: 0/
Queue: version

People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.9912
Fixed in: (no value)



Subject: "original" field is saving numeric form, not string
$; perl -v | head -n2 This is perl 5, version 20, subversion 0 (v5.20.0) built for darwin-2level : [ether@bourbon git/Dist-Zilla-Plugin-OnlyCorePrereqs]$; perl -MData::Dumper -Mversion -wle'print Dumper($]); my $foo = $]; print Dumper($foo); print Dumper(version->parse($foo)); print Dumper(version->parse("$foo"))' $VAR1 = '5.020000'; $VAR1 = '5.020000'; $VAR1 = bless( { 'version' => [ 5, 20 ], 'original' => '5.02' }, 'version' ); $VAR1 = bless( { 'original' => '5.020000', 'version' => [ 5, 20, 0 ] }, 'version' ); The above code demonstrates that the numeric form of the supplied argument is being saved as "original", not the string form. For variables such as $] which are dualvar, this is an important distinction, and I believe it is more correct to save the stringified form, to avoid unintended loss of zero digits.
On Sat Feb 21 16:03:08 2015, ETHER wrote: Show quoted text
> The above code demonstrates that the numeric form of the supplied > argument is > being saved as "original", not the string form. For variables such as > $] > which are dualvar, this is an important distinction, and I believe it > is more > correct to save the stringified form, to avoid unintended loss of zero > digits.
Trailing zeros are not significant and not even preserved for bare decimals. I don't know that I want to special case one specific dualvar value; neither Perl 5.20.1 or 5.20.2 suffer from this problem. I'm taking a look at how I can do it. John
On Sat Feb 21 22:52:34 2015, JPEACOCK wrote: Show quoted text
> On Sat Feb 21 16:03:08 2015, ETHER wrote:
> > The above code demonstrates that the numeric form of the supplied > > argument is > > being saved as "original", not the string form. For variables such > > as > > $] > > which are dualvar, this is an important distinction, and I believe it > > is more > > correct to save the stringified form, to avoid unintended loss of > > zero > > digits.
I've tried to fix this by just swapping the order of SvPOK before SvNOK, but this breaks the non-period radix locale code. I don't know that we can just a priori assign higher value to contents of the PV slot over the NV slot, just because we have both POK and NOK set. For example, this is what $] looks like with a comma radix locale: SV = PVNV(0x2079a80) at 0x1b1aff8 REFCNT = 1 FLAGS = (NOK,POK,READONLY,pNOK,pPOK) IV = 0 NV = 5,018002 PV = 0x1b1f790 "5.018002"\0 CUR = 8 LEN = 16 And this is a floating point number initialized in a locale with comma as the radix and then printed (thus populating the PV slot): SV = PVNV(0x1f73aa0) at 0x1dbcfc8 REFCNT = 2 FLAGS = (PADMY,NOK,POK,pNOK,pPOK) IV = 0 NV = 1,23 PV = 0x1c71b00 "1,23"\0 CUR = 4 LEN = 40 If I do not parse the second one as an NV, it will not trigger the locale handling code, which is very specific to the NV handling. John
Subject: Re: [rt.cpan.org #102272] "original" field is saving numeric form, not string
Date: Sun, 15 Mar 2015 07:17:35 -0400
To: bug-version [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
If we s/,/./ the PV and stringify the NV in a period locale and they are the same, can we then use the modified PV safely to initialize the original form? David On Mar 15, 2015 12:09 AM, "John Peacock via RT" <bug-version@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=102272 > > > On Sat Feb 21 22:52:34 2015, JPEACOCK wrote:
> > On Sat Feb 21 16:03:08 2015, ETHER wrote:
> > > The above code demonstrates that the numeric form of the supplied > > > argument is > > > being saved as "original", not the string form. For variables such > > > as > > > $] > > > which are dualvar, this is an important distinction, and I believe it > > > is more > > > correct to save the stringified form, to avoid unintended loss of > > > zero > > > digits.
> > I've tried to fix this by just swapping the order of SvPOK before SvNOK, > but this breaks the non-period radix locale code. I don't know that we can > just a priori assign higher value to contents of the PV slot over the NV > slot, just because we have both POK and NOK set. For example, this is what > $] looks like with a comma radix locale: > > SV = PVNV(0x2079a80) at 0x1b1aff8 > REFCNT = 1 > FLAGS = (NOK,POK,READONLY,pNOK,pPOK) > IV = 0 > NV = 5,018002 > PV = 0x1b1f790 "5.018002"\0 > CUR = 8 > LEN = 16 > > And this is a floating point number initialized in a locale with comma as > the radix and then printed (thus populating the PV slot): > > SV = PVNV(0x1f73aa0) at 0x1dbcfc8 > REFCNT = 2 > FLAGS = (PADMY,NOK,POK,pNOK,pPOK) > IV = 0 > NV = 1,23 > PV = 0x1c71b00 "1,23"\0 > CUR = 4 > LEN = 40 > > If I do not parse the second one as an NV, it will not trigger the locale > handling code, which is very specific to the NV handling. > > John >
On Sun Mar 15 07:17:50 2015, DAGOLDEN wrote: Show quoted text
> If we s/,/./ the PV and stringify the NV in a period locale and they > are > the same, can we then use the modified PV safely to initialize the > original > form?
In a word: No http://www.statisticalconsultants.co.nz/blog/how-the-world-separates-its-decimals.html The red countries on that map use something other than comma or period as their radix point, so I can't just search/replace the comma. I'm trying to come up with something that ONLY handles the dualvar case specially. John
Resolved in 0.9913. NOTE: Perl releases of the form 5.x.0 prior to 5.19.0 will still have the problem due to underlying Perl core limitations; it isn't worth the time to work around those edge cases.
On 2016-01-01 19:14:03, JPEACOCK wrote: Show quoted text
> Resolved in 0.9913. NOTE: Perl releases of the form 5.x.0 prior to > 5.19.0 will still have the problem due to underlying Perl core > limitations; it isn't worth the time to work around those edge cases.
What limitations are these? Perhaps they would be worth the time of someone else, if they knew where to start.