Closed p5pRT closed 16 years ago
p5pRT
commented
20 years ago module->VERSION is reporting incorrect version numbers in blead perl. it works just fine in 5.8.3.
% perl-5.8.3 -le 'use LWP; print LWP->VERSION' 5.76 % perl-blead -le 'use LWP; print LWP->VERSION' 5.760.0
% perl-5.8.3 -le 'use CGI; print CGI->VERSION' 3.04 % perl-blead -le 'use CGI; print CGI->VERSION' 3.40.0
p5pRT
commented
20 years ago Stas Bekman wrote in perl.perl5.porters :
module->VERSION is reporting incorrect version numbers in blead perl. it works just fine in 5.8.3.
% perl-5.8.3 -le 'use LWP; print LWP->VERSION' 5.76 % perl-blead -le 'use LWP; print LWP->VERSION' 5.760.0
Technically this is correct. UNIVERSAL::VERSION now returns a version object\, which overloads stringification to return a normalized representation of the version (see util.c:Perl_vstringify()).
p5pRT
commented
20 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
20 years ago Rafael Garcia-Suarez wrote:
Stas Bekman wrote in perl.perl5.porters :
module->VERSION is reporting incorrect version numbers in blead perl. it works just fine in 5.8.3.
% perl-5.8.3 -le 'use LWP; print LWP->VERSION' 5.76 % perl-blead -le 'use LWP; print LWP->VERSION' 5.760.0
Technically this is correct. UNIVERSAL::VERSION now returns a version object\, which overloads stringification to return a normalized representation of the version (see util.c:Perl_vstringify()).
What he said! ;) What is it that you are trying to do that this is a problem? If it helps\, you can say this:
$ perl-blead -le 'use LWP; print LWP->VERSION->numify' 5.760000
instead.
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
p5pRT
commented
20 years ago John Peacock wrote:
Rafael Garcia-Suarez wrote:
Stas Bekman wrote in perl.perl5.porters :
module->VERSION is reporting incorrect version numbers in blead perl. it works just fine in 5.8.3.
% perl-5.8.3 -le 'use LWP; print LWP->VERSION' 5.76 % perl-blead -le 'use LWP; print LWP->VERSION' 5.760.0
Technically this is correct. UNIVERSAL::VERSION now returns a version object\, which overloads stringification to return a normalized representation of the version (see util.c:Perl_vstringify()).
What he said! ;) What is it that you are trying to do that this is a problem? If it helps\, you can say this:
$ perl\-blead \-le 'use LWP; print LWP\->VERSION\->numify' 5\.760000instead.
Well\, don't you find that broken? The doc entry for UNIVERSAL::VERSION in 5.8.3 and blead are exactly the same. Nowhere I can see it saying that the behavior has changed.
Besides this change will break any code that relies on the current 5.8.x behavior. Does it mean I can't use Foo->VERSION in any of my code that has to support older perls? I can't call numify on older perls.
Finally\, it's require feature error reporting is obviously wrong:
% perl-blead -le 'use CGI; print $CGI::VERSION' 3.04
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1.
it should be: CGI version 3.05 required--this is only version 3.04 at -e line 1. or similar. Perl itself doesn't call numify :(
This works:
% perl-blead -le 'use CGI; print CGI->VERSION(3.04)' 3.40.0
so it does accept a version number as a non-object\, but it won't do that for the output?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Stas Bekman said:
Well\, don't you find that broken?
No\, since I wrote the version object code. ;)
The doc entry for UNIVERSAL::VERSION in 5.8.3 and blead are exactly the same. Nowhere I can see it saying that the behavior has changed.
Then it appears that I haven't updated the docs yet.
Besides this change will break any code that relies on the current 5.8.x
Again I ask exactly what you are doing that gives you that impression?
Version objects overload both == and eq (and all the other comparison operators). The only difference is the stringified output\, which always displays the fully qualified version number.
Finally\, it's require feature error reporting is obviously wrong:
% perl-blead -le 'use CGI; print $CGI::VERSION' 3.04
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1.
it should be: CGI version 3.05 required--this is only version 3.04 at -e line 1. or similar.
As I said\, the stringified output is fully qualified. Is that the problem? Are you trying to match the error string?
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5748
p5pRT
commented
20 years ago On 23 Mar 2004\, at 22:55\, John Peacock wrote:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1.
That is going to confuse the hell out of the average user. They will go off to CPAN looking for version 3.50.0 and not find it\, because the lastest available is 3.05
it should be: CGI version 3.05 required--this is only version 3.04 at -e line 1. or similar.
As I said\, the stringified output is fully qualified. Is that the problem?
IMO\, yes.
Are you trying to match the error string?
Yes\, human matching with the version numbers they see on CPAN.
Graham.
p5pRT
commented
20 years ago On Tue\, 23 Mar 2004\, Graham Barr wrote:
On 23 Mar 2004\, at 22:55\, John Peacock wrote:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1.
That is going to confuse the hell out of the average user. They will go off to CPAN looking for version 3.50.0 and not find it\, because the lastest available is 3.05
How about we stringify as 3.050.000 instead? There is an implicit leading zero so we may as well make it explicit if that leads to less confusion (the error message as it stands is consistent with version numbers of perl itself since 5.6.0 aka 5.006.000)
-- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj
p5pRT
commented
20 years ago Tim Jenness wrote:
On Tue\, 23 Mar 2004\, Graham Barr wrote:
On 23 Mar 2004\, at 22:55\, John Peacock wrote:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1.
That is going to confuse the hell out of the average user. They will go off to CPAN looking for version 3.50.0 and not find it\, because the lastest available is 3.05
How about we stringify as 3.050.000 instead? There is an implicit leading zero so we may as well make it explicit if that leads to less confusion (the error message as it stands is consistent with version numbers of perl itself since 5.6.0 aka 5.006.000)
As Graham suggested\, most users won't make any sense of 5.006.000.
3.050.000 != 3.05\, when: use overload '!=' => \&human_brain
3.050 may do\, but it's still very confusing.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Stas Bekman wrote:
How about we stringify as 3.050.000 instead? There is an implicit leading zero so we may as well make it explicit if that leads to less confusion (the error message as it stands is consistent with version numbers of perl itself since 5.6.0 aka 5.006.000)
As Graham suggested\, most users won't make any sense of 5.006.000.
Please give me a chance to work on something; I was out of the office today so I am vastly behind on everything.
John
p.s. remember that 5.9.1 is a /dev/ release; we should expect stuff to break. This code has been in bleadperl for many months now\, yet this is the first that anyone has noticed/complained...
-- 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
p5pRT
commented
20 years ago John Peacock wrote:
Stas Bekman wrote:
How about we stringify as 3.050.000 instead? There is an implicit leading zero so we may as well make it explicit if that leads to less confusion (the error message as it stands is consistent with version numbers of perl itself since 5.6.0 aka 5.006.000)
As Graham suggested\, most users won't make any sense of 5.006.000.
Please give me a chance to work on something; I was out of the office today so I am vastly behind on everything.
Certainly\, take your time\, John. ;)
I think it's the best to spec things out before spending any time on writing code. If people are unhappy about the way things head\, why proceeding this way?
p.s. remember that 5.9.1 is a /dev/ release; we should expect stuff to break. This code has been in bleadperl for many months now\, yet this is the first that anyone has noticed/complained...
Simply because nobody has tried to use it or relies on code that uses it. How many people use 5.9.0-1? My guess is that it would be far less than 1% of perl users. So may be 'many months' is not the best indicator ;)
Here is my take on it:
The way things are now in blead\, I'm happy with:
eval { Foo->VERSION($min_version) }
to verify a certain version number to substitute:
if ($Foo::VERSION >= $min_version);
but you should consider the error message to be user friendly\, since it's most likely the user who is going to make sense of it. At least consider an output like this:
CGI version 3.05 (3.50.0) required--this is only version 3.04 (3.40.0) at -e line 1.
the good thing is that besides the first number is a familiar version number\, the number in parens teaches users about the internal presentation.
As for Foo->VERSION\, I think you want to at least document that it should not be used to print version numbers\, since it returns a special version object.
But still\, any code relying on 5.8.x behavior of Foo->VERSION will break. So I've an alternative suggestion: leave Foo->VERSION alone\, back compat to 5.8.x\, and provide a new method which will return the version object?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Graham Barr wrote:
On 23 Mar 2004\, at 22:55\, John Peacock wrote:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1.
That is going to confuse the hell out of the average user. They will go off to CPAN looking for version 3.50.0 and not find it\, because the lastest available is 3.05
Larry has stated (in a private communication) that Perl 6 will have multi-value versions; when do you suggest we introduce the user community to the concept? I'm not being argumentative\, just trying to elicit some suggestions for ways to make it easier to transition from the current state to the new one.
I checked and the version object patch which includes the replacement UNIVERSAL::VERSION since February of 2003:
Change 18682 by hv@hv-crypt.org on 2003/02/10 00:26:50
Subject​: \[PATCH\] version objects final\(?\) patch From​: John Peacock \<jpeacock@​rowman\.com> Date​: Sun\, 05 Jan 2003 21​:28​:41 \-0500 Message\-ID​: \<3E18E9D9\.2040908@​rowman\.com>Affected files ...
... //depot/perl/lib/version.pm#4 edit ... //depot/perl/lib/version.t#3 edit ... //depot/perl/universal.c#61 edit ... //depot/perl/util.c#376 edit
For those who missed the earlier [extensive] discussions\, the basic issue is this:
1) According to the 5.6.0 README's\, this is the way that decimal versions for Perl itself will be translated into the multi-value version:
5.005_03 => 5.5.30 5.006_001 => 5.6.1
This was originally intended to be done with v-strings\, but for many reasons this never worked the way it was intended to work.
2) Many authors in releasing modules to CPAN used only two significant digits after the decimal place\, so that by following rule #1\, the apparent translation is:
3.05 => 3.50.0
which is (I fully agree) confusing to they eye. I have a possible way to have a specific way of treating CPAN modules different than random versions in the wild (which will require setting a flag). Testing continues.
3) I resolved to create a version object which would permit consistent behavior no matter whether you said:
$VERSION = 1.023; or $VERSION = 1.23.0;
However\, rather than complaining that no one bothered to test bleadperl like this until now\, I have a solution to the immediate problem.
How about for the UNIVERSAL::VERSION warnings only\, the output is the numified version\, rather than the stringified version? Like this:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.05 required--this is only version 3.04 at -e line 1.
But this would also be true:
% perl-blead -le 'use CGI; print CGI->VERSION()' 3.40.0
I can do this easily; I need to make a small change to universal.c and adjust the tests in lib/version.t to correspond to the new output.
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
p5pRT
commented
20 years ago Stas Bekman wrote:
but you should consider the error message to be user friendly\, since it's most likely the user who is going to make sense of it. At least consider an output like this:
CGI version 3.05 (3.50.0) required--this is only version 3.04 (3.40.0) at -e line 1.
That is still going to break anything that was testing for a specific string to be thrown as the error\, but I like this a lot.
the good thing is that besides the first number is a familiar version number\, the number in parens teaches users about the internal presentation.
As for Foo->VERSION\, I think you want to at least document that it should not be used to print version numbers\, since it returns a special version object.
But I don't understand this; it /does/ print a version number just fine\, just not in the format you were expecting. If you use Foo->VERSION in any sort of comparison\, it will Just Work(TM); it is only when you try and print it out will it be somewhat confusing compared to 5.8.x behavior.
But still\, any code relying on 5.8.x behavior of Foo->VERSION will break. So I've an alternative suggestion: leave Foo->VERSION alone\, back compat to 5.8.x\, and provide a new method which will return the version object?
I'm still not seeing what behavior (outside of printing) you are talking about. Could you give me an example of code which uses Foo->VERSION that doesn't work the same as in 5.8.x (again ignoring throwing a different error than you were expecting)?
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
p5pRT
commented
20 years ago John Peacock via RT wrote:
Stas Bekman wrote:
but you should consider the error message to be user friendly\, since it's most likely the user who is going to make sense of it. At least consider an output like this:
CGI version 3.05 (3.50.0) required--this is only version 3.04 (3.40.0) at -e line 1.
That is still going to break anything that was testing for a specific string to be thrown as the error\, but I like this a lot.
That's good.
the good thing is that besides the first number is a familiar version number\, the number in parens teaches users about the internal presentation.
As for Foo->VERSION\, I think you want to at least document that it should not be used to print version numbers\, since it returns a special version object.
But I don't understand this; it /does/ print a version number just fine\,just not in the format you were expecting. If you use Foo->VERSION in any sort of comparison\, it will Just Work(TM); it is only when you try and print it out will it be somewhat confusing compared to 5.8.x behavior.
mod_perl has mp2bug\, similar to perlbug\, which besides the usual stuff also reports the version numbers for certain modules which may help us to diagnose users problems. I was using Foo->VERSION to add those version numbers to the report:
... my $ver = eval { require $path; delete $INC{$path}; $package->VERSION; }; ... print $report_fh $ver;
yesterday\, we had a bug report from a user trying to get mp2 pass the tests with 5.9.1 on his machine. And his report was very confusing\, since I was surprised to learn that he had CGI.pm version 3.40\, which I knew doesn't exist. So it took me some time and lost hair to realize what was the cause.
Now\, I can't use ->numify without making a special condition for 5.9.x. So I guess I should just use ${"$package\::VERSION"} instead.
Do you suggest\, that I shouldn't have used $package->VERSION; to print the version number if first place? In which case please document that ;)
But still\, any code relying on 5.8.x behavior of Foo->VERSION will break. So I've an alternative suggestion: leave Foo->VERSION alone\, back compat to 5.8.x\, and provide a new method which will return the version object?
I'm still not seeing what behavior (outside of printing) you are talking about. Could you give me an example of code which uses Foo->VERSION that doesn't work the same as in 5.8.x (again ignoring throwing a different error than you were expecting)?
I've presented such a case above.
Also I find the idiom:
perl -MFoo -le 'print Foo->VERSION'
to tell a (human readable) module version number\, to be very convenient and requiring no error-prone typing in the case where you have the module name in a variable:
${"$module\::VERSION"}
$module->VERSION reads much better.
So it'll be sad to see that functionality go away.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Stas Bekman wrote:
mod_perl has mp2bug\, similar to perlbug\, which besides the usual stuff also reports the version numbers for certain modules which may help us to diagnose users problems. I was using Foo->VERSION to add those version numbers to the report:
... my $ver = eval { require $path; delete $INC{$path}; $package->VERSION; }; ... print $report_fh $ver;
yesterday\, we had a bug report from a user trying to get mp2 pass the tests with 5.9.1 on his machine. And his report was very confusing\, since I was surprised to learn that he had CGI.pm version 3.40\, which I knew doesn't exist. So it took me some time and lost hair to realize what was the cause.
Sorry! You'll know better next time... \
Now\, I can't use ->numify without making a special condition for 5.9.x. So I guess I should just use ${"$package\::VERSION"} instead.
You have no idea how all-encompassing my plans are\, do you. ;~)
I actually have working code which automatically upgrades the package $VERSION
to a version object when the module is loaded... \
Do you suggest\, that I shouldn't have used $package->VERSION; to print the version number if first place? In which case please document that ;)
Rather I should document more clearly that the result of that will be different than what might be expected...
Also I find the idiom:
perl -MFoo -le 'print Foo->VERSION'
to tell a (human readable) module version number\, to be very convenient and requiring no error-prone typing in the case where you have the module name in a variable:
${"$module\::VERSION"}
$module->VERSION reads much better.
So it'll be sad to see that functionality go away.
I don't intend it to go away. But the whole basis of the module is to display the multipart version in some natural fashion; overloaded stringify seemed to be most appropriate. Perhaps for the duration of 5.9.x I should throw a mandatory warning explaining that this may not look like what you were expecting\, but it is\, nonetheless\, correct...
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
p5pRT
commented
20 years ago John Peacock wrote:
Now\, I can't use ->numify without making a special condition for 5.9.x. So I guess I should just use ${"$package\::VERSION"} instead.
You have no idea how all-encompassing my plans are\, do you. ;~)
I actually have working code which automatically upgrades the package $VERSION to a version object when the module is loaded... \
You must be kidding me\, don't you? if you don't\, just tell me one thing: how do I print the version number\, so that:
1) the user will make a sense of it and find it on CPAN (3.04\, not 3.40) 2) it'll work all the way to 5.005_03
and hopefully so that it will:
3) require no custom coding 4) ideally require no dependencies on non-core modules
Do you suggest\, that I shouldn't have used $package->VERSION; to print the version number if first place? In which case please document that ;)
Rather I should document more clearly that the result of that will be different than what might be expected...
Also I find the idiom:
perl -MFoo -le 'print Foo->VERSION'
to tell a (human readable) module version number\, to be very convenient and requiring no error-prone typing in the case where you have the module name in a variable:
${"$module\::VERSION"}
$module->VERSION reads much better.
So it'll be sad to see that functionality go away.
I don't intend it to go away. But the whole basis of the module is to display the multipart version in some natural fashion; overloaded stringify seemed to be most appropriate. Perhaps for the duration of 5.9.x I should throw a mandatory warning explaining that this may not look like what you were expecting\, but it is\, nonetheless\, correct...
IMHO\, you need to use an alternative method name for this purpose. In which case you keep the existing code working as before and users using the new method will have to require 5.9.1\, unless the new functionality will be split into a CPAN module.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Stas Bekman wrote:
You must be kidding me\, don't you? if you don't\, just tell me one thing: how do I print the version number\, so that:
1) the user will make a sense of it and find it on CPAN (3.04\, not 3.40) 2) it'll work all the way to 5.005_03
and hopefully so that it will:
3) require no custom coding 4) ideally require no dependencies on non-core modules
Try this:
--- /bleadperl/trunk/universal.c (revision 7876) +++ /bleadperl/trunk/universal.c (local) @@ -370\,11 +370\,12 @@
if ( vcmp( req\, sv ) > 0 ) Perl_croak(aTHX_ - "%s version %"SVf" required--this is only version %"SVf\, - HvNAME(pkg)\, req\, sv); + "%s version %"SVf" (%"SVf") required--" + "this is only version %"SVf" (%"SVf")"\, + HvNAME(pkg)\, vnumify(req)\,req\,vnumify(sv)\,sv); }
- ST(0) = sv; + ST(0) = vnumify(sv);
XSRETURN(1); }
I realized that I can treat
print FOO->VERSION;
differently from
print $FOO::VERSION;
and satisfy both of our needs. The former can return the compatible numified version (and you are happy)\, whereas the much less common latter can overload stringify and display the new format (and I am happy).
I need to adjust the lib/version.t file to work with this change (and add a new test). For some reason (probably lack of sleep) I am having fits with qr// this evening...
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
p5pRT
commented
20 years ago John Peacock via RT wrote:
Stas Bekman wrote:
You must be kidding me\, don't you? if you don't\, just tell me one thing: how do I print the version number\, so that:
1) the user will make a sense of it and find it on CPAN (3.04\, not 3.40) 2) it'll work all the way to 5.005_03
and hopefully so that it will:
3) require no custom coding 4) ideally require no dependencies on non-core modules
Try this:
--- /bleadperl/trunk/universal.c (revision 7876) +++ /bleadperl/trunk/universal.c (local) @@ -370\,11 +370\,12 @@
if \( vcmp\( req\, sv \) > 0 \) Perl\_croak\(aTHX\_- "%s version %"SVf" required--this is only version %"SVf\, - HvNAME(pkg)\, req\, sv); + "%s version %"SVf" (%"SVf") required--" + "this is only version %"SVf" (%"SVf")"\, + HvNAME(pkg)\, vnumify(req)\,req\,vnumify(sv)\,sv); }
- ST(0) = sv; + ST(0) = vnumify(sv);
XSRETURN\(1\);}
I realized that I can treat
print FOO\->VERSION;differently from
print $FOO​::VERSION;and satisfy both of our needs. The former can return the compatible numified version (and you are happy)\, whereas the much less common latter can overload stringify and display the new format (and I am happy).
+1 on the warning change.
I'm not sure about the second half. you will get people complaining why FOO->VERSION and $FOO::VERSION aren't doing the same in the "" context. I guess people will complain no matter what you do\, but as long as there is a solution that will work across all perls\, I'm happy with the second half as well.
I need to adjust the lib/version.t file to work with this change (and add a new test). For some reason (probably lack of sleep) I am having fits with qr// this evening...
You aren't alone in that hole. The following seem to apply to my case in the course of the last few days (weeks?):
Murphy's Law If anything can go wrong -- it will.
Murphy's First Corollary Left to themselves\, things tend to go from bad to worse.
Murphy's Second Corollary It is impossible to make anything foolproof because fools are so ingenious.
Quantized Revision of Murphy's Law Everything goes wrong all at once.
The Murphy Philosophy Smile... tomorrow will be worse.
I'm trying hard to follow the last rule.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago On 24 Mar 2004\, at 02:34\, John Peacock wrote:
Graham Barr wrote:
On 23 Mar 2004\, at 22:55\, John Peacock wrote:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1. That is going to confuse the hell out of the average user. They will go off to CPAN looking for version 3.50.0 and not find it\, because the lastest available is 3.05
Larry has stated (in a private communication) that Perl 6 will have multi-value versions; when do you suggest we introduce the user community to the concept? I'm not being argumentative\, just trying to elicit some suggestions for ways to make it easier to transition from the current state to the new one.
Getting people use to multi-value versions is not an issue. Most people are already using them for many other things. The issue is that the version that perl reports does not match the version that is available\, unless the person knows how to do the conversion between the two systems\, and most people will not.
When Perl6 arrives the modules on CPAN will have a multi-value version\, so it will not be an issue because they will match.
Graham.
p5pRT
commented
20 years ago -----BEGIN PGP SIGNED MESSAGE-----
Moin\,
John wrote:
Graham Barr wrote:
On 23 Mar 2004\, at 22:55\, John Peacock wrote:
% perl-blead -le 'use CGI; print CGI->VERSION(3.05)' CGI version 3.50.0 required--this is only version 3.40.0 at -e line 1. That is going to confuse the hell out of the average user. They will go off to CPAN looking for version 3.50.0 and not find it\, because the lastest available is 3.05
Larry has stated (in a private communication) that Perl 6 will have multi-value versions; when do you suggest we introduce the user community to the concept?
When they use Perl6? I see no point in making the already more than complicated Perl5 more complicated by pulling in things from Perl6.
I'm not being argumentative\, just trying to elicit some suggestions for ways to make it easier to transition from the current state to the new one.
In my mind the current state is already hell confusing\, and I would not want to transition any further before we check whether we go in the right direction.
Having said this:
1.05 \< 1.50
(I usually write v1.05 and mean the same\, e.g. a floating point number)
for me\, and has always been. (If not\, all my modules have no officially "wrong" version numbers).
So\, if I put in 1.05 I bloody expect it to give me 1.05 back again. I don't care how it represents it internally\, or what it does with that - and I certainly don't want to see the internal representation in an error message. If I request v1.06 and have v1.05 installed\, the error message should state that - and nt even mention the however-it-looks-this-week internal representation.
IHMO of course :)
Yes\, I read (I think) all the version discussions\, and you guys lost me several times over. As I said\, a simple thing done way too complicated...all I want to have is a number that counts up to distinguish newer modules from older ones..
1) According to the 5.6.0 README's\, this is the way that decimal versions for Perl itself will be translated into the multi-value version:
5\.005\_03 => 5\.5\.30 5\.006\_001 => 5\.6\.1
Why do we need to translate it in the first place? (If it is internal\, I don't want to see it)
This was originally intended to be done with v-strings\, but for many reasons this never worked the way it was intended to work.
Maybe because it was too complicated. I mean\, if even the guy implementing it and several top members of p5p can't agree what means what\, it probably is too complicated :)
2) Many authors in releasing modules to CPAN used only two significant digits after the decimal place\, so that by following rule #1\, the apparent translation is:
3\.05 => 3\.50\.0which is (I fully agree) confusing to they eye.
So keep it internal\, invisible and off my screen :)
I have a possible way to have a specific way of treating CPAN modules different than random versions in the wild (which will require setting a flag). Testing continues.
NOOOO! Noo! Not one more condition. Not "a equals b\, but not if a belongs to class CPAN\, it does not equal b\, unless b also belongs to class...." er you get the idea. vX.Y is always vX.Y. Remember: KISS :-)
Cheers\,
Tels
- -- Signed on Wed Mar 24 20:39:00 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"To be beautiful is enough! if a woman can do that well who should demand more from her? You don't want a rose to sing." -- Thackeray
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: When cryptography is outlawed\, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBQGHl/ncLPEOTuEwVAQGYFAf9ExmEJJ6bFqF7vX71HkMQL7M8Xb44qzO5 T3xqG6bOVnv2thpzvNK2l8AFjItmVc4QSH7W+Ir5NXetS1R9MkGYJzae/O+zwPF0 HpMuDHbXxk7hDSS0Foz5EGBoPL2SWY0pTIDAyUs+LvB1EdUfARgr/Z/SprLnVEIx qTHVRwK+6uigMlEqxtp/e6NLQPxsqLbXyyj7eZhJmZSOsP1cpoT/kreTtmWLW8v0 AVGYnt4Dzs29ZkPmYK7FXlB99DBRHHhdgj2D2hDj2aGIkLqvU0dtCK9R8JURpvng ziZxakWDu5c3dQw2oGw6NTIyBxRUywYEH7CwjZ7oPrA8fESqloSw7A== =iViX -----END PGP SIGNATURE-----
p5pRT
commented
20 years ago Tels wrote:
Having said this:
1\.05 \< 1\.50(I usually write v1.05 and mean the same\, e.g. a floating point number)
But many CPAN authors seem to want to say "the 50th version of 1.x"\, which would be more accurately be written as 1.050. You have a particular understanding of floating point comparisons (for obvious reasons ;)\, but many CPAN authors treat the stuff to the right of the decimal place as a two digit integer. For evidence of this\, consider the all too common behavior of alpha modules on CPAN looking like 1.50_03...
1) According to the 5.6.0 README's\, this is the way that decimal versions for Perl itself will be translated into the multi-value version:
5\.005\_03 => 5\.5\.30 5\.006\_001 => 5\.6\.1Why do we need to translate it in the first place? (If it is internal\, I don't want to see it)
Not my problem! Sarathy set that into stone when he released 5.6.0. See "Improved Perl version numbering system" in pod/perl56delta.pod. Both of these have to yield exactly the same meaning:
use 5.006_001; use 5.6.1;
which is only possible if the current translation scheme is followed.
This was originally intended to be done with v-strings\, but for many reasons this never worked the way it was intended to work.
Maybe because it was too complicated. I mean\, if even the guy implementing it and several top members of p5p can't agree what means what\, it probably is too complicated :)
No\, the problem was that v-strings were a one way translation during the tokenize-phase of compilation. It was impossible to distinguish a v-string from a conventional string (by design)\, which worked fine for arbitrary byte-strings but failed miserably for versions.
NOOOO! Noo! Not one more condition. Not "a equals b\, but not if a belongs to class CPAN\, it does not equal b\, unless b also belongs to class...." er you get the idea. vX.Y is always vX.Y. Remember: KISS :-)
It's actually not as bad as you think (iff # of decimal places == 2\, then parse as two digits\, else three)\, and it will be a user-selected option. I may abandon it entirely\, but please don't prejudge it before you see how it works.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5748
p5pRT
commented
20 years ago Stas Bekman wrote:
I guess people will complain no matter what you do\, but as long as there is a solution that will work across all perls\, I'm happy with the second half as well.
OK\, based on Stas's e-mails\, as well as an offline discussion I had with Martyn Pierce\, I have a proprosal for a way to deal with the concerns raised.
I realized that the only time I _have_ to return the normalized version form is when there are too many subterms to display otherwise. For example\,
$VERSION = 1.02; # stringify to 1.02 $VERSION = 1.2.3; # stringify to 1.2.3 $VERSION = 1.002003; # stringify to 1.2.3
I have a new release of the CPAN compatibility module\, and I can generate a diff against bleadperl. However\, I'd like to ask some volunteers to read the POD changes I made\, both to see if I missed anything as well as to see if they are clear\, before I push this release out to CPAN. The POD is a little big to foist on the whole list.
Can I get some volunteers? Stas? Martyn? Bueller?
TIA
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
p5pRT
commented
20 years ago John Peacock wrote:
Stas Bekman wrote:
I guess people will complain no matter what you do\, but as long as there is a solution that will work across all perls\, I'm happy with the second half as well.
OK\, based on Stas's e-mails\, as well as an offline discussion I had with Martyn Pierce\, I have a proprosal for a way to deal with the concerns raised.
I realized that the only time I _have_ to return the normalized version form is when there are too many subterms to display otherwise. For example\,
$VERSION = 1\.02; \# stringify to 1\.02 $VERSION = 1\.2\.3; \# stringify to 1\.2\.3 $VERSION = 1\.002003; \# stringify to 1\.2\.3
So real floating point versions will just stay as they are\, right?
What about this?
$VERSION = 1.02.3; # stringify to 1.2.3
or:
$VERSION = 1.02.3; # stringify to 1.02.3
I have a new release of the CPAN compatibility module\, and I can generate a diff against bleadperl. However\, I'd like to ask some volunteers to read the POD changes I made\, both to see if I missed anything as well as to see if they are clear\, before I push this release out to CPAN. The POD is a little big to foist on the whole list.
Can I get some volunteers? Stas? Martyn? Bueller?
Sure\, I can proof-read it\, for clarity (but remember that i'm not a native English speaker\, so it's the best that someone else will do that too).
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Stas Bekman wrote:
$VERSION = 1\.02\.3; \# stringify to 1\.2\.3
This one. The objects are stored internally as an array of integers\, so the leading zero is not significant. The only thing I am doing is comparing the length of the array and stringifying accordingly.
Sure\, I can proof-read it\, for clarity (but remember that i'm not a native English speaker\, so it's the best that someone else will do that too).
For you\, I was hoping you might have time to check function as much as POD. I have attached the entire module\, so you check the return values for any edge cases you may think of (that I missed).
Besides\, it is very useful to have non-native speakers look at it too\, since you may spot any tortured English more easily.
Thanks much
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
p5pRT
commented
20 years ago p5pRT
commented
20 years ago John Peacock wrote:
Stas Bekman wrote:
$VERSION = 1\.02\.3; \# stringify to 1\.2\.3This one. The objects are stored internally as an array of integers\, so the leading zero is not significant. The only thing I am doing is comparing the length of the array and stringifying accordingly.
Sure\, I can proof-read it\, for clarity (but remember that i'm not a native English speaker\, so it's the best that someone else will do that too).
For you\, I was hoping you might have time to check function as much as POD. I have attached the entire module\, so you check the return values for any edge cases you may think of (that I missed).
Besides\, it is very useful to have non-native speakers look at it too\, since you may spot any tortured English more easily.
Sorry\, I didn't read through the whole thing and haven't looked at the code\, I must finish a few more things tonight\, so here are the comments for the parts I've read:
=head1 SYNOPSIS
use version; $version = new version "12.2.1"; # must be quoted! ... Both of these methods will produce similar version objects\, in that the default stringification will yield the version normal form if required
$v = new version 1.002; # 1.002\, but compares like 1.2.0 $v = new version 1.002003; # 1.2.3 $v2 = new version "1.2.3"; # 1.2.3 $v3 = new version 1.2.3; # 1.2.3 for Perl > 5.8.0
but you said that "1.2.3" must be quoted in the SYNOPSIS section\, so may be you need to add 'for perl \< 5.8.0' there?
=head2 Numeric Versions
$v = new version 1.02; # 1.20 $v = new version 1.002; # 1.2
eh? I thought you said you are going to keep them unchanged\, i.e. 1.02 and 1.002.
proposal: use the triplet behavior *only* if there are more than 3 digits after the decimal period. i.e.:
$v = new version 1.2; # 1.2 $v = new version 1.02; # 1.02 $v = new version 1.002; # 1.002 $v = new version 1.0023; # 1.002.300 $v = new version 1.00203; # 1.002.030 $v = new version 1.002_03; # 1.002.030 See "Quoting" $v = new version 1.002003; # 1.002.003
And in any case your approach has a problem with someone who plans to have more than 999 non-major releases\, because you can't have this range:
1.0001 - 1.9999
as it will interpreted as:
1.0.1 - 1.999.900
I mean it'll work internally\, but externally it will show this ambiguous stringification:
$VERSION = version->new(1.9991); print $VERSION;
# 1.999.100
so you are inconsistent. Hopefully noone will have more than 999 versions before bumping up the major number.
I can see that one can DWIM with > 999\, using quoted versions\, but it doesn't seem to work. see below
=head2 Quoted Versions ...
$v = new version "1.2.3"; # 1.2.3 $v = new version "1.2.3"; # 1.2.3
these two examples are exactly the same. I'd also fix spacing\, you have too many spaces between version and the string.
next you say:
$v = new version "1.0003"; # 1.3
but that doesn't work:
perl-5.8.4-ithread -Mversion -le '$b = new version "1.0003"; print $b;' 1.0.300
either the code or the doc is wrong.
=head1 EXPORT
qv - quoted version initialization operator
you probably need to say that it's not exported by default\, but available on demand or similar. or replace the section name to "Exportable symbols"
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
p5pRT
commented
20 years ago Stas Bekman wrote:
$version = new version "12.2.1"; # must be quoted!
but you said that "1.2.3" must be quoted in the SYNOPSIS section\, so may be you need to add 'for perl \< 5.8.0' there?
Good catch. In reality\, for Perl >= 5.8.1\, initialization with a v-string acts as a form of quoting; I'll make that more clear.
---------------
=head2 Numeric Versions
$v = new version 1.02; # 1.20 $v = new version 1.002; # 1.2
eh? I thought you said you are going to keep them unchanged\, i.e. 1.02 and 1.002.
Yes\, the commented values are wrong.
proposal: use the triplet behavior *only* if there are more than 3 digits after the decimal period. i.e.:
And in any case your approach has a problem with someone who plans to have more than 999 non-major releases\, because you can't have this range:
1.0001 - 1.9999
as it will interpreted as:
1.0.1 - 1.999.900
I mean it'll work internally\, but externally it will show this ambiguous stringification:
$VERSION = version->new(1.9991); print $VERSION;
# 1.999.100
so you are inconsistent. Hopefully noone will have more than 999 versions before bumping up the major number.
I'll make sure that fact is highlighted in bright red ink in the POD\, then. ;~) I think this is a very reasonable limitation\, especially given that most modules (on CPAN anyways) use no more than 2 significant decimal places.
$v = new version "1.2.3"; # 1.2.3 $v = new version "1.2.3"; # 1.2.3
these two examples are exactly the same. I'd also fix spacing\, you have too many spaces between version and the string.
Cut and paste error. I think I am going to convert all examples to class->method notation in any case.
next you say:
$v = new version "1.0003"; # 1.3
but that doesn't work:
Fat finger syndrome here; there's too many zeros. Or else that is left over from an earlier codebase where I only split on explicit decimals (or underscores).
qv - quoted version initialization operator
you probably need to say that it's not exported by default\, but available on demand or similar. or replace the section name to "Exportable symbols"
... @EXPORT = qw(qv); ...
It _is_ exported by default; in fact it has to be\, in order to match the behavior in bleadperl.
Thanks for the proofreading! I'll make the changes before releasing to CPAN (probably over the weekend).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5748
p5pRT
commented
20 years ago jpeacock@rowman.com (John Peacock) wrote in message news:\1158\.208\.54\.112\.79\.1080082540\.squirrel@​squirrelmail\.rowman\.com...
Stas Bekman said:
Well\, don't you find that broken?
No\, since I wrote the version object code. ;)
The doc entry for UNIVERSAL::VERSION in 5.8.3 and blead are exactly the same. Nowhere I can see it saying that the behavior has changed.
Then it appears that I haven't updated the docs yet.
Besides this change will break any code that relies on the current 5.8.x
Again I ask exactly what you are doing that gives you that impression?
Just to flog the proverbial horse\, remember that this (seriously and egregiously\, IMHO) violates least surprise with module version checks\, in that\, for instance\, 0.96 > 0.95 but 0.96.1 \< 0.95.
I think I understand that Sarathy was trying to make version objects behave more purely like numbers within a "chuck" (for lack of a better term to describe what comes between a pair of '.' or '_'s\, but so doing broke their established version-like behavior. This wouldn't necessarily have been a problem were we starting from scratch\, but there's both a mindset and a large corpus of existing modules that run counter to it.
This'll go away eventually (Perl 6\, perhaps)\, but module users will continue to trip over it as long as there are modules on CPAN which follow the prior convention (i.e. haven't been updated to follow the new behavior).
-- Regards\, Charles Bailey \< bailey _at_ newman _dot_ upenn _dot_ edu > Newman Center at the University of Pennsylvania
p5pRT
commented
16 years ago p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#27847 (status was 'resolved')
Searchable as RT27847$