$Win32::VERSION problem

I just tried building libwin32-0.26 using an installed copy
of the 
current bleadperl, and got this error:

Win32 version 0.270 (v0.270.0) required--this is only
version 0.260 
(v0.260.0) at c:perllib/File/Copy.pm line 273.
BEGIN failed--compilation aborted.
NMAKE : fatal error U1077: 'C:perlbinperl.exe' : return
code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:Program FilesMicrosoft
Visual 
StudioVC98BinN
MAKE.EXE"' : return code '0x2'
Stop.

I can't quite get my head round what's gone wrong. Current
bleadperl 
says $Win32::VERSION is 0.27 and libwin32-0.26 says 0.26,
but current 
maintperl says 0.2601 and doesn't experience the same
problem!

Is it something to do with having just moved
win32/ext/Win32API/File to 
ext/Win32API/File ? That's the main thing in this area that
is currently 
different between blead and maint.

-- 


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files
transmitted with it are confidential and intended for the
addressee(s) only. If you have received this message in
error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or
alteration of this message is strictly forbidden. Note that
any views or opinions presented in this email are solely
those of the author and do not necessarily represent those
of Radan Computational Ltd. The recipient(s) of this message
should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused
by any virus transmitted by this email.

Steve Hay wrote:
> I just tried building libwin32-0.26 using an installed
copy of the
> current bleadperl, and got this error:
>
> Win32 version 0.270 (v0.270.0) required--this is only
version 0.260
> (v0.260.0) at c:perllib/File/Copy.pm line 273.
> BEGIN failed--compilation aborted.
> NMAKE : fatal error U1077: 'C:perlbinperl.exe' :
return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:Program
FilesMicrosoft Visual
> StudioVC98BinN
> MAKE.EXE"' : return code '0x2'
> Stop.
>
> I can't quite get my head round what's gone wrong.
Current bleadperl
> says $Win32::VERSION is 0.27 and libwin32-0.26 says
0.26, but current
> maintperl says 0.2601 and doesn't experience the same
problem!
>
> Is it something to do with having just moved
win32/ext/Win32API/File to
> ext/Win32API/File ? That's the main thing in this area
that is currently
> different between blead and maint.

There is a bigger difference than that.  As of last
December
(
http://nntp.perl.org/group/perl.perl5.porters/119038),
the CORE
routines moved from win32/win32.c into Win32.xs.  Jan's evil
plan
(
http://nntp.perl.org/group/perl.perl5.porters/119009)
addresses
the problem you are seeing in (as yet undone) step 5.

On Mon, 26 Feb 2007, Yitzchak Scott-Thoennes wrote:
> Steve Hay wrote:
> > I just tried building libwin32-0.26 using an
installed copy of the
> > current bleadperl, and got this error:
> >
> > Win32 version 0.270 (v0.270.0) required--this is
only version 0.260
> > (v0.260.0) at c:perllib/File/Copy.pm line 273.

Hmm, this ugly error message looks a bit misleading, it
really should
look like this:

| Win32 version 0.27 required--this is only version 0.26 at
c:perllib/File/Copy.pm line 273.

I normally try to stay out of the version number silliness,
but this
does look like a step backwards to me. I have no idea if
this can (or
should) be fixed in bleadperl or not (Perl 5.8 does give the
correct
error message).

> > BEGIN failed--compilation aborted.
> > NMAKE : fatal error U1077: 'C:perlbinperl.exe'
: return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:Program
FilesMicrosoft Visual
> > StudioVC98BinN
> > MAKE.EXE"' : return code '0x2'
> > Stop.
> >
> > I can't quite get my head round what's gone wrong.
Current bleadperl
> > says $Win32::VERSION is 0.27 and libwin32-0.26
says 0.26, but current
> > maintperl says 0.2601 and doesn't experience the
same problem!
> >
> > Is it something to do with having just moved
win32/ext/Win32API/File to
> > ext/Win32API/File ? That's the main thing in this
area that is currently
> > different between blead and maint.
> 
> There is a bigger difference than that.  As of last
December
> (
http://nntp.perl.org/group/perl.perl5.porters/119038),
the CORE
> routines moved from win32/win32.c into Win32.xs.

Yes, and the forwarder() function (now in
ext/Win32CORE/Win32CORE.c requires
Win32 version 0.27 or later:

static void
forward(pTHX_ const char *function)
{
    dXSARGS;
    Perl_load_module(aTHX_ PERL_LOADMOD_NOIMPORT,
newSVpvn("Win32",5), newSVnv(0.27));
    SPAGAIN;
    PUSHMARK(SP-items);
    call_pv(function, GIMME_V);
}

Therefore you will not be able to use old versions of the
Win32 module
with bleadperl anymore.

> Jan's evil plan (
http://nntp.perl.org/group/perl.perl5.porters/119009)
> addresses the problem you are seeing in (as yet undone)
step 5.

I'll try to get some time to do this early March (next
week). I thought
there is no urgency in releasing Win32 0.27 separately as
the latest
version is already in the core, but I didn't realize that
you also
cannot install libwin32 anymore on blead.

Cheers,
-Jan

Jan Dubois wrote:
> On Mon, 26 Feb 2007, Yitzchak Scott-Thoennes wrote:
>> Steve Hay wrote:
>>> I just tried building libwin32-0.26 using an
installed copy of the
>>> current bleadperl, and got this error:
>>>
>>> Win32 version 0.270 (v0.270.0) required--this
is only version 0.260
>>> (v0.260.0) at c:perllib/File/Copy.pm line
273.
> 
> Hmm, this ugly error message looks a bit misleading, it
really should
> look like this:
> 
> | Win32 version 0.27 required--this is only version
0.26 at c:perllib/File/Copy.pm line 273.
> 
> I normally try to stay out of the version number
silliness, but this
> does look like a step backwards to me. I have no idea
if this can (or
> should) be fixed in bleadperl or not (Perl 5.8 does
give the correct
> error message).

That *is* the correct error message [for bleadperl]:

	0.27 == 0.270 == v0.270.0

The presence of version objects in bleadperl mean that the
error message 
needs to show both the floating-point and extended versions
in the same 
message.  If you 'use version' under 5.8.x, you'll get that
same error 
message...

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

On Mon, 26 Feb 2007, John Peacock wrote:
> Jan Dubois wrote:
>>>>
>>>> Win32 version 0.270 (v0.270.0)
required--this is only version 0.260
>>>> (v0.260.0) at c:perllib/File/Copy.pm line
273.
>>
>> Hmm, this ugly error message looks a bit
misleading, it really should
>> look like this:
> > | Win32 version 0.27 required--this is only
version 0.26 at c:perllib/File/Copy.pm line 273.
> >
> > I normally try to stay out of the version number
silliness, but this
> > does look like a step backwards to me. I have no
idea if this can (or
> > should) be fixed in bleadperl or not (Perl 5.8
does give the correct
> > error message).
> 
> That *is* the correct error message [for bleadperl]:
> 
> 	0.27 == 0.270 == v0.270.0
> 
> The presence of version objects in bleadperl mean that
the error message
> needs to show both the floating-point and extended
versions in the same
> message.  If you 'use version' under 5.8.x, you'll get
that same error
> message...

This is a reason why I don't want to 'use version'. I'm
using plain
numbers as the version, and therefore shouldn't have to
worry about all
this other stuff.  I hope you at least realize that the new
error message
is much more confusing for the novice user who couldn't care
less
about version objects.

Anyways, I don't want to get involved in this, and will live
with whatever
the pumpking decides to do...

Cheers,
-Jan

Jan Dubois wrote:
> This is a reason why I don't want to 'use version'. I'm
using plain
> numbers as the version, and therefore shouldn't have to
worry about all
> this other stuff.  I hope you at least realize that the
new error message
> is much more confusing for the novice user who couldn't
care less
> about version objects.

As long as you use exclusively numeric versions, you
shouldn't notice 
any difference with 'use version' at all (apart from the
[improved] 
error message).  Personally, I don't think that the error
message is all 
that confusing, but if that is the feeling of the group, I
could make 
the output dependent on whether the module $VERSION was
numeric or 
extended.

In other words, the error message that Steve (Hay) would
have seen would 
have been this instead:

	Win32 version 0.270 required--this is only version 0.260

(the trailing zero is due to the version being normalized on
three 
decimal multiples).  Iff the module $VERSION was using an
extended 
version, the error would be:

	XXX version v0.270.0 required--this is only version
v0.260.0

The only tricky part is that there is an equality
relationship between 
extended and floating point versions, so someone /could/ mix
them in a 
'use' line successfully (though I could forbid mixing that
usage if we 
wanted to).

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

On Mon, 26 Feb 2007, John Peacock wrote:
> Jan Dubois wrote:
> > This is a reason why I don't want to 'use
version'. I'm using plain
> > numbers as the version, and therefore shouldn't
have to worry about all
> > this other stuff.  I hope you at least realize
that the new error message
> > is much more confusing for the novice user who
couldn't care less
> > about version objects.
> 
> As long as you use exclusively numeric versions, you
shouldn't notice
> any difference with 'use version' at all (apart from
the [improved]
> error message).  Personally, I don't think that the
error message is all
> that confusing, but if that is the feeling of the
group, I could make
> the output dependent on whether the module $VERSION was
numeric or
> extended.

I think this is exactly backwards.  This should depend on
the type of
VERSION used in "use Module VERSION". 
perlfunc.pod says:

| VERSION may be either a numeric argument such as 5.006,
which will be
| compared to C<$]>, or a literal of the form v5.6.1,
which will be
| compared to C<$^V> (aka $PERL_VERSION.
[...]
| If the VERSION argument is present between Module and
LIST, then the
| C<use> will call the VERSION method in class Module
with the given
| version as an argument. The default VERSION method,
inherited from the
| UNIVERSAL class, croaks if the given version is larger
than the value
| of the variable C<$Module::VERSION>.

If VERSION is a number, as specified by the *user* (not the
module
author), then the error message should use this requested
version
number, and not some re-interpretation of it.

I think readability of error messages should be optimized
for
(potentially novice) users, and not for the module author,
who will
generally be more knowledgeable about this stuff already.

Of course if the module uses extended version numbers (not
just a
string, but a version that cannot be represented as a
float), then the
error message will have to be more complex.

> In other words, the error message that Steve (Hay)
would have seen would
> have been this instead:
> 
> 	Win32 version 0.270 required--this is only version
0.260
> 
> (the trailing zero is due to the version being
normalized on three
> decimal multiples).

I also do disagree with the normalization to three decimal
multiples. It
serves no purpose for normal numbers and should only be done
for
extended version numbers.

Cheers,
-Jan 

Jan Dubois wrote:
> I think this is exactly backwards.  This should depend
on the type of
> VERSION used in "use Module VERSION". 
perlfunc.pod says:
> 
> | VERSION may be either a numeric argument such as
5.006, which will be
> | compared to C<$]>, or a literal of the form
v5.6.1, which will be
> | compared to C<$^V> (aka $PERL_VERSION.
> [...]
> | If the VERSION argument is present between Module and
LIST, then the
> | C<use> will call the VERSION method in class
Module with the given
> | version as an argument. The default VERSION method,
inherited from the
> | UNIVERSAL class, croaks if the given version is
larger than the value
> | of the variable C<$Module::VERSION>.
> 
> If VERSION is a number, as specified by the *user* (not
the module
> author), then the error message should use this
requested version
> number, and not some re-interpretation of it.

That's a very good argument, I must say.  I haven't gone and
modified 
all of the other POD that talks about $VERSION's, but in
this case, I 
don't need to do so.  I can just make UNIVERSAL::VERSION
correspond to 
this behavior with a stroke of my magic pen... 

I'd like to get more feedback before I do so, since I would
be changing 
an established API (sort of, since I consider everything
before v5.10.0 
ships to be preparatory).  Anyone else want to weigh in
here?  I also 
what to hear from people who don't like
$version->is_alpha() denote a 
version with an embedded underscore (usually used for
development 
releases to CPAN).

> Of course if the module uses extended version numbers
(not just a
> string, but a version that cannot be represented as a
float), then the
> error message will have to be more complex.

Currently, the only way to use non-numbers with $VERSION is
through the 
use of my own version::AlphaBeta (which AFAIK, no one is
using on CPAN 
certainly).  In that case, the ruling module would be 
version::AlphaBeta, which restricts what you can enter on
the 'use' line 
to what it recognizes anyways.

> I also do disagree with the normalization to three
decimal multiples. It
> serves no purpose for normal numbers and should only be
done for
> extended version numbers.

0.27 is mathematically equivalent to 0.270 (or any number of
trailing 
zeros).  While I can preserve the original notation for
output purposes 
(which is incidently what the Module::Build::Version
subclass does), it 
would make for more complicated code in the base version
class.  Does 
this bother you so much that it is worth complicating
things? 
Internally, it would still be stored as three-digit
subversions (since 
this is how the extended and floating point map to each
other).

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

On Mon, 26 Feb 2007, John Peacock wrote:
> .27 is mathematically equivalent to 0.270 (or any
number of trailing
> zeros). While I can preserve the original notation for
output purposes
> (which is incidently what the Module::Build::Version
subclass does),
> it would make for more complicated code in the base
version class.
> Does this bother you so much that it is worth
complicating things?

It does not bother *me* personally, but I've seen enough
people being
confused by error messages that I know it is best to be as
literal as
possible.

I'm not bothered if the code is more complicated because it
will only
be executed when there is an error.  The only concern I
would have
is if this makes the code too hard to maintain.

Cheers,
-Jan

On Mon, Feb 26, 2007 at 09:13:03AM -0800, Jan Dubois wrote:

> Yes, and the forwarder() function (now in
ext/Win32CORE/Win32CORE.c requires
> Win32 version 0.27 or later:

> Therefore you will not be able to use old versions of
the Win32 module
> with bleadperl anymore.

Um.

I was working on the assumption that all the
movement/rearrangement of the
win32 directory, win32/ext and the Win32 modules was
appropriate to replicate
in maint.

But "not be able to use" doesn't seem a good thing
for maint.

Nicholas Clark

Jan Dubois wrote:
> I'm not bothered if the code is more complicated
because it will only
> be executed when there is an error.  The only concern I
would have
> is if this makes the code too hard to maintain.

I don't know that yet.  It is very easy to do this in the
pure Perl 
module (<POOF> it is already done,  minus new tests to
confirm that it 
works the way I expect it to).  I have to look at how hard
it will be to 
do the equivalent in C/XS code (which is what gets put into
in bleadperl).

I appreciate the feedback, even it it does mean more work
for me.   I 
want version objects to be as transparent to the user as
possible, while 
still taming the beast that is $VERSION handling going back
to at least 
5.005_04...

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

On Mon, 26 Feb 2007, Nicholas Clark wrote:
> On Mon, Feb 26, 2007 at 09:13:03AM -0800, Jan Dubois
wrote:
> > Yes, and the forwarder() function (now in
ext/Win32CORE/Win32CORE.c
> > requires Win32 version 0.27 or later: Therefore
you will not be able
> > to use old versions of the Win32 module with
bleadperl anymore.
>
> Um.
>
> I was working on the assumption that all the
movement/rearrangement of
> the win32 directory, win32/ext and the Win32 modules
was appropriate
> to replicate in maint.
>
> But "not be able to use" doesn't seem a good
thing for maint.

It is indeed a bit worrisome, and I have to admit that I
didn't even
realize this problem before today.

But assuming I re-release an otherwise unchanged libwin32
without the
Win32 module to CPAN would that be good enough? Or do we
imply that you
can install any older CPAN version of a core module on the
latest
maintenance release and it will still work?

Of course this would be nice, but it is not always possible.
 E.g. you
cannot install Scalar-List-Utils 1.07 into Perl 5.8.8
without breaking
overload::strVal (because of the missing refaddr()), even
though
1.07 was bundled with 5.8.0 and overload.pm didn't care back
then.

Cheers,
-Jan

On Tue, Feb 27, 2007 at 12:24:49AM -0800, Yitzchak
Scott-Thoennes wrote:
> Nicholas Clark wrote:
> > On Mon, Feb 26, 2007 at 09:13:03AM -0800, Jan
Dubois wrote:
> >
> >> Yes, and the forwarder() function (now in
ext/Win32CORE/Win32CORE.c
> >> requires
> >> Win32 version 0.27 or later:
> >
> >> Therefore you will not be able to use old
versions of the Win32 module
> >> with bleadperl anymore.
> >
> > Um.
> >
> > I was working on the assumption that all the
movement/rearrangement of the
> > win32 directory, win32/ext and the Win32 modules
was appropriate to
> > replicate
> > in maint.
> >
> > But "not be able to use" doesn't seem a
good thing for maint.
> 
> It should be fine, assuming a new CPAN libwin32 and
standalone Win32
> get released before 5.8.9.  If it were a non-core
module that the
> "not be able to use" applied to, I can see
reason to keep it out of
> maint, but the core Win32 *is* 0.27, and there's no
reason the core
> should need to work with an older Win32.  The
installing-libwin32-
> downgrading-Win32 thing is just an artifact of the
planned changes
> not being quite complete.
> 
> Does this make sense?

Yes, except excuse my ignorance on one thing:

If you upgrade to 5.8.9, can existing installed modules stop
working?
(I'm not entirely sure which parts of what is being
discussed is in the Win32
module in the core, and which parts are installed from
CPAN)

Nicholas Clark

On Tue, 27 Feb 2007, Nicholas Clark wrote:
> On Tue, Feb 27, 2007 at 12:24:49AM -0800, Yitzchak
Scott-
> Thoennes wrote:
>> It should be fine, assuming a new CPAN libwin32 and
standalone Win32
>> get released before 5.8.9. If it were a non-core
module that the "not
>> be able to use" applied to, I can see reason
to keep it out of maint,
>> but the core Win32 *is* 0.27, and there's no reason
the core should
>> need to work with an older Win32. The
installing-libwin32-
>> downgrading-Win32 thing is just an artifact of the
planned changes
>> not being quite complete.
>>
>> Does this make sense?
>
> Yes, except excuse my ignorance on one thing:
>
> If you upgrade to 5.8.9, can existing installed modules
stop working?
> (I'm not entirely sure which parts of what is being
discussed is in
> the Win32 module in the core, and which parts are
installed from CPAN)

The core version of the Win32 module is comprehensive; there
are no parts
that can be loaded from CPAN that are not yet in the core
version.

The problem is that libwin32 contains *both* an older
version of a core
module (Win32) and the latest version of other modules
(Win32:).
Since you cannot downgrade the core module, you could not
install the
other modules.

The only way I can see existing modules to stop working is
if you have
an installation where you have the current (or older)
libwin32 installed
in a directory that you put into INC in front of the core
directory,
effectively disabling the core version of the Win32 module.

The analogous situation with Scalar::Utils and overload
would be when
the user installed Scalar-List-Utils 1.07 into a tree at the
front
of INC.  overload::strVal would break because the core
version of
Scalar::Utils would be disabled by this.

One thing we could do, at least for maint, is duplicate the
old code
from win32/win32.c in Win32CORE and remove the version check
for Win32.

I can make a patch for this later this week, but I don't
think it
should end up in blead (except maybe for testing), because
this would
be essentially dead bloat.

Cheers,
-Jan

On Tue, Feb 27, 2007 at 08:22:33AM -0800, Jan Dubois wrote:
> One thing we could do, at least for maint, is duplicate
the old code
> from win32/win32.c in Win32CORE and remove the version
check for Win32.
>
> I can make a patch for this later this week, but I
don't think it
> should end up in blead (except maybe for testing),
because this would
> be essentially dead bloat.

I'd rather not have this even in maint - there really
doesn't seem to
any reason to do it.  Is there anything I can do to help get
new
libwin32 and Win32 distributions out?