Heads up on version patches
John Peacock
> At 12:01 PM 8/28/02 -0400, John Peacock wrote:
>
>> p.s. any hints on how I debug a segfault occurring inside a #define
>> macro???
>
>
> At the danger of repeating myself: use Valgrind?
>
> http://developer.kde.org/~sewardj/
Big gun; tiny little core dump. Actually, I can just run the code in gdb to see
a backtrace. The problem I cannot seem to wrap my head around is the code where
it is failing is a macro (in XSUB.h to be exact) so I cannot break before the
core and step through to see where everything goes south.
I suppose I will just have to pick one file and embed the code where the macro
is currently expanding and then I can test it that way. I was hoping that
someone would say something useful like "oh, just run it through the gcc
preprocessor and compile the intermediate file, like this []" where [] is a
detailed set of steps...
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
Elizabeth Mattijsen
>p.s. any hints on how I debug a segfault occurring inside a #define macro???
At the danger of repeating myself: use Valgrind?
http://developer.kde.org/~sewardj/
Liz
John Peacock
my earth-shattering (!) set of patches the completely change the way Perl treats
versions. I had a few minutes while waiting for some data to be imported, so I
thought I would document a few things:
I am currently assuming that the stringified output of a version object will
have 3 decimal places for all subversions. Thus,
$VERSION = new version "1.2_3"; # stored as \1\2\3 with beta flag
print $VERSION;
__END__
1.002.003beta
though of course the display of "beta" could change.
I have just thought of a way to effectively store a format for each version, but
just a single one, e.g.
$VERSION = new version "1.23.4"; # stored as \1\27\4
print $VERSION;
__END__
1.23.04
note that the minimum value becomes 2, so the last subversion has left padding.
In any case, does anyone think that this is worthwhile? It is still not going
to deal with the issue that a user can do this:
$VERSION = new version "1.0003.01"; # stored as \1\3\1
print $VERSION;
__END__
1.0003.0001
and I cannot do anything about it.
Alternatively, I could stash the original representation and simply return
_that_ as the stringified representation, though the internal representation
would still be used for testing. I still cannot do anything about this:
$VERSION = new version 1.03_01; # stored as \1\304\255
print $VERSION;
__END__
1.0301
since Perl has already eaten the underscore before I can get to it.
And another thing - I am being a little misleading above, since I have gotten
the $VERSION scalar magicalized, so you can just type:
$VERSION = v1.2.3; #version object \1\2\3
so this code I found in List::Scalar won't work any longer:
our $VERSION = "1.07_00";
our $XS_VERSION = $VERSION;
$VERSION = eval $VERSION;
since both $VERSION and $XS_VERSION are now version objects and in this case,
the eval will fail as long as I stringify that $VERSION as "1.007.000beta".
I have to reboot my machine now (I'm at work so I am infected with Win2K instead
of my nice stable Linux box at home ;~).
More later...
John
p.s. any hints on how I debug a segfault occurring inside a #define macro???
--
Andreas J. Koenig
I'm not sure if my expectations are consistent. They differ from yours
and so I'll try to find out where my expectations are coming from.
>>>>> On Wed, 28 Aug 2002 12:01:46 -0400, John Peacock <jpea...@rowman.com> said:
> I can see the light at the end of the tunnel (and I don't *hear* a
> train ;~) in my earth-shattering (!) set of patches the completely
> change the way Perl treats versions. I had a few minutes while
> waiting for some data to be imported, so I thought I would document a
> few things:
> I am currently assuming that the stringified output of a version
> object will have 3 decimal places for all subversions. Thus,
> $VERSION = new version "1.2_3"; # stored as \1\2\3 with beta flag
> print $VERSION;
> __END__
> 1.002.003beta
I'd expected 1.23
> though of course the display of "beta" could change.
> I have just thought of a way to effectively store a format for each
> version, but just a single one, e.g.
> $VERSION = new version "1.23.4"; # stored as \1\27\4
> print $VERSION;
> __END__
> 1.23.04
I'd expected 1.23.4
> note that the minimum value becomes 2, so the last subversion has left
> padding. In any case, does anyone think that this is worthwhile? It
> is still not going to deal with the issue that a user can do this:
> $VERSION = new version "1.0003.01"; # stored as \1\3\1
> print $VERSION;
> __END__
> 1.0003.0001
I'd expected 1.3.1
> and I cannot do anything about it.
> Alternatively, I could stash the original representation and simply
> return _that_ as the stringified representation, though the internal
> representation would still be used for testing. I still cannot do
> anything about this:
> $VERSION = new version 1.03_01; # stored as \1\304\255
> print $VERSION;
> __END__
> 1.0301
Good!
> since Perl has already eaten the underscore before I can get to it.
My expectations seem to come from the following basic ideas:
1. A version string is a sequence of integers. Integers never
stringify with leading zeros. If people specify an integer within a
version string with a leading zero, it is either ignored, as in
perl 5.8.0.
23.024.025 equals 23.24.25
(maybe it would have been more natural to say these are octals, but
that's definitely too late now)
2. If a version looks like a floating point, it is treated like a
floating point
23.024 equals 23.02400000
3. An underscore influences neither the stringification of a v-string
nor of a float:
123.124_125 stringifies as 123.124125
1_23.1_24.1_25 stringifies as 123.124.125
4. Where to put the underscore? It's an object, so let's ask it
$version->beta() # returns true if the parser saw an underscore
Doable?
--
andreas
John Peacock
> John,
>
> I'm not sure if my expectations are consistent. They differ from yours
> and so I'll try to find out where my expectations are coming from.
>
> > print $VERSION;
> > __END__
> > 1.002.003beta
>
> I'd expected 1.23
The reason that underscores are important for versions is that when a beta
version is release to CPAN, 1.2.0 < 1.2_3 < 1.3.0 and your way won't do that.
> My expectations seem to come from the following basic ideas:
>
> 1. A version string is a sequence of integers. Integers never
> stringify with leading zeros. If people specify an integer within a
> version string with a leading zero, it is either ignored, as in
> perl 5.8.0.
>
> 23.024.025 equals 23.24.25
>
> (maybe it would have been more natural to say these are octals, but
> that's definitely too late now)
Up until this next set of patches, I had to pad the digits (so that the various
UNIVERSAL::VERSION paths would *just work* at least most of the time). I just
realized that once I completely replace that maze of code with a simple sv_cmp()
of the encoded versions, I now longer need that. So, no leading zeros! Point
to Andreas!
>
> 2. If a version looks like a floating point, it is treated like a
> floating point
>
> 23.024 equals 23.02400000
modulo FP notation failures (you're always safer quoting the version). I'm
limited to how much I can get the tokenizer to do for me.
>
> 3. An underscore influences neither the stringification of a v-string
> nor of a float:
>
> 123.124_125 stringifies as 123.124125
>
> 1_23.1_24.1_25 stringifies as 123.124.125
see above. I would parse that as 1.23.1.24.1.25, so don't do that! ;~)
Remember that versions are not v-strings or numbers; we are creating a
completely new syntax so we can do what we want (within reason). I suppose we
could simply flag as error any version with more than one underscore... hmmm....
>
> 4. Where to put the underscore? It's an object, so let's ask it
>
> $version->beta() # returns true if the parser saw an underscore
>
> Doable?
>
That's certainly easy enough. But in order to have MakeMaker automatically
create the correct distribution name, preserving the information that this is a
beta version, it _must_ be visible in the default stringification. I can
replace the last period with an underscore, which should have the appropriate
effect and will have the added benefit of not freaking out when eval'd. I'll
try this tonight.
I want this to be completely natural:
$ cat mymodule.pm
...
modules mymodule;
$VERSION = v1.2_3;
# note the v-string will be \1\27 but the version will be \1\2\3 beta!
...
$ perl Makefile.PL
... blah blah ...
$ make tardist
... blah blah ...
$ ls *gz
mymodule-1.2_3.tar.gz
John
Tels
John Peacock <jpea...@rowman.com> wrote:
>I want this to be completely natural:
I dislike artificial versions, too :)
>$ cat mymodule.pm
> ...
> modules mymodule;
> $VERSION = v1.2_3;
> # note the v-string will be \1\27 but the version will be \1\2\3
^^^^^^^
You mean \1\23?
Cheers,
Tels
- --
"It's amzing what you can do with a little charm and a lot of blackmail."
- Nanny Ogg
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPW0rsncLPEOTuEwVAQFFKAf8Dz0pPRLxPF7Colffw01HwVCThS/tv0WS
6/pPgIbagxOfVbB1Wy6+S2AFSpFREdWohPgYI82ZAeSRi5a4oZ0H4TnD+FzmjEhv
D/4eW9UJx25y4WsVOhpGR+kt7RYd+TGVduQht8U0ErZvdXBK57Ctn3A21EtXGMmh
NQqC2hPs1GjrfpIK4D7ZG5EGHWgth7Z8XphIMpunQY4MeL0Z6AQsvkHAWYbrCi3B
ULOoIAYn8rPBupvjcYmtX8r76vVapYbPLNKGUfdB4c6cTd2lbkw+x6xPSHzQtvQ6
XmPzjdWMkDw/urY7TV48z4orECid1tQBb7S8VVE+QdNmRh1BOjaaRg==
=MysV
-----END PGP SIGNATURE-----
Tels
Moin,
On 28-Aug-02 Ronald J Kimball carved into stone:
> On Wed, Aug 28, 2002 at 09:59:52PM +0200, Tels wrote:
>>
>> John Peacock <jpea...@rowman.com> wrote:
>>
>> >$ cat mymodule.pm
>> > ...
>> > modules mymodule;
>> > $VERSION = v1.2_3;
>> > # note the v-string will be \1\27 but the version will be
>> > # \1\2\3
>> ^^^^^^^
>>
>> You mean \1\23?
> 23 decimal is 27 octal.
How confusing.. why is \27 suddenly denoting octal, and why is octal used
there, anyway? *puzzled*
Cheers,
Te"I need sleep. Or coffee. Or both."ls
- --
perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
synergistically repurpose dot-com e-business
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPW0t/HcLPEOTuEwVAQHnZwf+Md/U7y6nVPau0rNf1qr+75+3nwcOtyRO
S9Egw899QwvPZJ/WoGyqiwywWGqTtN2YcdSywHyj7K3vZoqVJ8ji3LgaMQXpp4RJ
sf+w3kjc3jzRYsBKe/zdZ523lyKWIIu0kc66/+9f1ku1mUL0XEbpeUzfLbETLwo6
ZmSmZw3lhE9Pts1uLMwfkxmlaObo0F2RqAWspwbwjHdqg6cml3dEdIyIW6Gh+56P
p6fAwBjphiC2KMfbQpcCQpCoyRh/At1S4Dm2q6/FM6zmLH5zkPmJ8JbiaoPmn+Ct
f/l2JUj9jlewlkjYisLnggpjTq2jAu/gY+5D1VbM0VYQtB1FEpNw+w==
=E/Vb
-----END PGP SIGNATURE-----
Ronald J Kimball
>
> John Peacock <jpea...@rowman.com> wrote:
>
> >$ cat mymodule.pm
> > ...
> > modules mymodule;
> > $VERSION = v1.2_3;
> ^^^^^^^
>
> You mean \1\23?
>
23 decimal is 27 octal.
Ronald
Ronald J Kimball
>
> On 28-Aug-02 Ronald J Kimball carved into stone:
> >>
> >> John Peacock <jpea...@rowman.com> wrote:
> >>
> >> >$ cat mymodule.pm
> >> > ...
> >> > modules mymodule;
> >> > $VERSION = v1.2_3;
> >> > # note the v-string will be \1\27 but the version will be
> >> ^^^^^^^
> >>
> >> You mean \1\23?
> > 23 decimal is 27 octal.
>
> there, anyway? *puzzled*
\27 has always denoted octal (the leading 0 is optional after a backslash).
Octal is used because Perl doesn't have a way to interpolate a character by
its decimal value.
Ronald
Dave Mitchell
> Big gun; tiny little core dump. Actually, I can just run the code in
> gdb to see a backtrace. The problem I cannot seem to wrap my head
> around is the code where it is failing is a macro (in XSUB.h to be
> exact) so I cannot break before the core and step through to see where
> everything goes south.
>
> I suppose I will just have to pick one file and embed the code where the
> macro is currently expanding and then I can test it that way. I was
> hoping that someone would say something useful like "oh, just run it
> through the gcc preprocessor and compile the intermediate file, like
> this []" where [] is a detailed set of steps...
The only way I know is to break at the line before the macro, then use
stepi (or nexti) to step through the individual machine instructions
and pray that you can kind of correlate them to the definitions in the
macro.
Dave.
--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.
Tels
Moin,
On 28-Aug-02 Ronald J Kimball carved into stone:
Oh, I see. You learn something new everyday.
But it is only used inside "" like:
perl -le 'print \27,"\n"'
SCALAR(0x8133a78)
perl -le 'print "\127","\n"'
W
I would have prefered \x, though. Octal is to confusing for me. :)
Cheers,
Tels
- --
perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
synergistically utilize low-risk niches
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPW0xU3cLPEOTuEwVAQEV3wf+LyfpmkA+1eAh4L6aRZT6SViXSyl1IqQB
PJxLS7cDHSCUzzD3CXxxfOaxIeWdAMd/VsY3LW5+IX563/IghGzaCDfFI16xsqNk
JLfVOApBu2/FD4kj0Rp5qNF5THo9IANA5PP41c9B6Zs8AuJX6NkMQVOrrcQ2ItDk
q3MVno+Qr4+FdrjYfChFJmkU7QCNYJwCexrgqel7WU9keSKFV6tbPgCuL0Ajo/sq
/059ex1uN3TPYDD/D957uICiPBtgH46EnXefJRHriaeAAEhhLoO1M+p9KXc/b8qN
qas6jOHoeOzDWXr8MXJL5ktvLBLTXzx03OLm+YmI/85OoB7zvDzjdw==
=5oZr
-----END PGP SIGNATURE-----
John Peacock
> The only way I know is to break at the line before the macro, then use
> stepi (or nexti) to step through the individual machine instructions
> and pray that you can kind of correlate them to the definitions in the
> macro.
>
Ooh, machine language! My favorite! Like I said, I'll just replace the macro
with the actual code temporarily, so I have something to look at.
I have learned more about Perl internals in the last year stepping in the
debugger than any other way (except Simon Cozens' "Perl Internals")! Try
stepping through yylex() sometime to figure out the tokenizer; learning when to
's' and when to 'n' is an exercise left to the reader...
Elizabeth Mattijsen
>I would have prefered \x, though. Octal is to confusing for me. :)
***sound and vision becomes blurry***
I started my career on a 60-bit Control Data Cyber mainframe. Characters
were 6 bits then, with a prefix character for shift. When characters are 6
bits, octal makes sense.
Then came 4-bit micro-processors, then 8-bit, then 16-bit... etc. Hex made
a lot more sense then.
Actually, internally the Cyber was using 64 bits, but the last 4 bits were
used internally for internal consistency checks and error conditions, so
you couldn't get at them.
*** end of flashback, vision is clear again ***
Liz
Philip Newton
(Tels) wrote:
> On 28-Aug-02 Ronald J Kimball carved into stone:
> > \27 has always denoted octal (the leading 0 is optional after a
> > backslash). Octal is used because Perl doesn't have a way to interpolate
> > a character by its decimal value.
>
> Oh, I see. You learn something new everyday.
>
> But it is only used inside "" like:
>
> perl -le 'print \27,"\n"'
> SCALAR(0x8133a78)
> perl -le 'print "\127","\n"'
> W
Correct. This comes from C, which also uses "\123" and "\xab" type
literals, but only inside double-quoted strings.
(Just like you can't use \xab outside a double-quoted string in Perl,
either. Or \b10111011.)
Cheers,
Philip
Benjamin Goldberg
>
> Andreas J. Koenig wrote:
> > John,
> >
> > I'm not sure if my expectations are consistent. They differ from
> > yours and so I'll try to find out where my expectations are coming
> > from.
> >
> > > $VERSION = new version "1.2_3";
> > > # stored as \1\2\3 with beta flag
> > > print $VERSION;
> > > __END__
> > > 1.002.003beta
> >
> > I'd expected 1.23
>
> The reason that underscores are important for versions is that when a
> beta version is release to CPAN, 1.2.0 < 1.2_3 < 1.3.0 and your way
> won't do that.
How often do people use underscore with more than one decimal point?
Consider:
our $VERSION = "1.07_00";
our $XS_VERSION = $VERSION;
$VERSION = eval $VERSION;
This puts 1.0700 into $VERSION.
So, numerically, 1.2 < 1.23 < 1.3 ... if people want to have versions
with underscores, they shouldn't be mixing it with version with two or
more periods. (If there are two or more periods, then beta-ness should
be indicated by the second numeric part being odd (eg, 5.6 is non-beta,
5.7 is beta, 5.8 is non-beta, 5.9 is beta, 5.10 will be non-beta, etc)).
[snip]
> > 3. An underscore influences neither the stringification of a
> > v-string nor of a float:
> >
> > 123.124_125 stringifies as 123.124125
> >
> > 1_23.1_24.1_25 stringifies as 123.124.125
>
> see above. I would parse that as 1.23.1.24.1.25, so don't do that!
> ;~)
>
> Remember that versions are not v-strings or numbers; we are creating a
> completely new syntax so we can do what we want (within reason). I
> suppose we could simply flag as error any version with more than one
> underscore... hmmm....
I would say, "An underscore has no effect on the encoded form of the
version object; however, if there are two or more "."s and one or more
underscores, or if there are two or more underscores, a warning will be
emitted."
As to stringification ... I would make version objects *die* on
stringification through, and only allow them to be stringified
explicitly through method calls:
my $version = new version "1.07_00";
print $version; # dies!
print $version->numifiy;
# prints 1.07 or 1.07_00
print $version->unicode;
# prints "\1\7" or "\1\106" or "\1\x{2BC}"
# or "\1\7\0" or "\1\106\0"
print $version->vstring;
# prints "v1.7" or "v1.07" or "v1.70" or "v1.700"
# or "v1.7.0" or "v1.07_00"
Ignoring beta-ness from underscores, calling <=> on the results of
calling ->numify on two vstring objects should be the same as comparing
the two vstring objects directly.
Ignoring beta-ness from underscores, calling cmp on the results of
calling ->unicode on two vstring objects should be the same as comparing
the two vstring objects directly.
The vstring method should be defined such that when it's resultant
string is eval()ed, it will produce an object which will compare as
being equal to the original version object. And it should look pretty,
too.
--
tr/`4/ /d, print "@{[map --$| ? ucfirst lc : lc, split]},\n" for
pack 'u', pack 'H*', 'ab5cf4021bafd28972030972b00a218eb9720000';
Michael G Schwern
> (If there are two or more periods, then beta-ness should
> be indicated by the second numeric part being odd (eg, 5.6 is non-beta,
> 5.7 is beta, 5.8 is non-beta, 5.9 is beta, 5.10 will be non-beta, etc)).
Just because perl does it this way doesn't mean everyone else has to.
> As to stringification ... I would make version objects *die* on
> stringification through, and only allow them to be stringified
> explicitly through method calls:
Why?
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
I do have a cause though. It is obscenity. I'm for it.
-- Tom Lehrer "Smut"
Benjamin Goldberg
>
> On Thu, Aug 29, 2002 at 04:15:01AM -0400, Benjamin Goldberg wrote:
> > (If there are two or more periods, then beta-ness should
> > be indicated by the second numeric part being odd (eg, 5.6 is
> > non-beta, 5.7 is beta, 5.8 is non-beta, 5.9 is beta, 5.10 will be
> > non-beta, etc)).
>
> Just because perl does it this way doesn't mean everyone else has to.
>
> > As to stringification ... I would make version objects *die* on
> > stringification through, and only allow them to be stringified
> > explicitly through method calls:
>
> Why?
Because there's (at least) 3 different ways to stringify/numify version
objects, and therefor a less than 1/3 chance that the particular one
that's the default will be correct for your own purposes.
John Peacock
> Because there's (at least) 3 different ways to stringify/numify version
> objects, and therefor a less than 1/3 chance that the particular one
> that's the default will be correct for your own purposes.
>
Not after I'm done. All version objects go through a single function,
scan_version() and hence all version objects are processed the same way. And
once we decide which way to output the object, there will be a single output as
well (well, one stringify and one numify). I suspect once completed, there will
actually be no reason for anyone to use $obj->numify, since all comparisons will
be performed on the underlying normalized representation.
John Peacock
> How often do people use underscore with more than one decimal point?
>
> Consider:
> our $VERSION = "1.07_00";
$VERSION is now a version objects
> our $XS_VERSION = $VERSION;
as is $XS_VERSION
> $VERSION = eval $VERSION;
> This puts 1.0700 into $VERSION.
Except that you missed my earlier posting. $VERSION is already converted to be
a version objects _before_ the eval and in fact the eval is undoing that magic
(and hence cannot be used). I believe it was Graham who first suggested this as
a way to get an underscore into the $VERSION/$XS_VERSION pair, but it is no
longer required now that version objects are available.
> As to stringification ... I would make version objects *die* on
> stringification through, and only allow them to be stringified
> explicitly through method calls:
I disagree in very strong terms. The biggest problem with v-strings was that
you never knew when you needed "%vd" since there was no way to know whether the
string had been processed or not. Hence, it was largely impossible to use them
as versions.
The basic reason behind my slogging through the code for the last 10 months was
to make something Just Work(tm) for versions. You should be able to just set
your $VERSION using whatever you want (modulo quoting issues) including
v-strings, and yet still be able to just
print $VERSION;
and get a sensible result. Having to explicitly use method calls defeats the
whole purpose of the version object.
Graham Barr
> John,
>
> I'm not sure if my expectations are consistent. They differ from yours
> and so I'll try to find out where my expectations are coming from.
My expectations are exactly the same as Andreas.
Graham.
> > $VERSION = new version "1.2_3"; # stored as \1\2\3 with beta flag
> > print $VERSION;
> > __END__
> > 1.002.003beta
>
> I'd expected 1.23
> > $VERSION = new version "1.23.4"; # stored as \1\27\4
> > print $VERSION;
> > __END__
> > 1.23.04
>
> I'd expected 1.23.4
> > $VERSION = new version "1.0003.01"; # stored as \1\3\1
> > print $VERSION;
> > __END__
> > 1.0003.0001
>
> I'd expected 1.3.1
> > $VERSION = new version 1.03_01; # stored as \1\304\255
Tim Bunce
> On Wed, Aug 28, 2002 at 07:05:04PM +0200, Andreas J. Koenig wrote:
> > John,
> >
> > I'm not sure if my expectations are consistent. They differ from yours
> > and so I'll try to find out where my expectations are coming from.
>
> My expectations are exactly the same as Andreas.
Same here.
(The fact such issues are still being discussed is rather scary.)
Tim.