Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT

[kmx]

Hi,

is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry
Perl 5.18.x series ?

I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess
Rob is also subscribed to this list) and AFAIK it works.

Pros:

1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin
without any special hacking that was needed for 5.16.0

2/ PDL users are gonna like it

3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit
strawberry perl

4/ Couple of others asking me privately will appreciate it (they ask: why
32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?)

--
kmx

[sisy...@optusnet.com.au]

-----Original Message-----
From: kmx

> Hi,
>
> is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry
> Perl 5.18.x series ?
>
> I have done some testing with PDL guys approx a year ago on 5.16.0 (I
> guess
> Rob is also subscribed to this list) and AFAIK it works.

I've been testing it continually over the last year or so. Every module I
build (not just PDL), I've been building on USE_64_BIT_INT - for both 5.16.0
and current blead (5.17.x).
I haven't struck any problems at any time that were related to the 64int
architecture.

I can think of only one con:

ActivePerl binaries (ppm packages) will not be usable on the 64int
architecture Strawberry Perl - unless, of course, ActiveState also start
providing packages for the 64int architecture. (I've no idea what
ActiveState are planning to do in this regard.)
I doubt that many Strawberry users (if any) would be affected by this, and I
don't regard it as a stopper. (Will 32int Strawberry builds still be
available for anyone who wants one ?)
As regards the ppm packages that I provide, they'll be available for both
the 64int and 32int architectures.

> Pros:
>
> 1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin
> without any special hacking that was needed for 5.16.0
>
> 2/ PDL users are gonna like it
>
> 3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit
> strawberry perl
>
> 4/ Couple of others asking me privately will appreciate it (they ask: why
> 32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?)
>

One other thing to consider with 5.18 Strawberry is whether it should be
COW-enabled or not.
Until recently, the p5p plan was to make 5.18 COW-enabled, but that has now
been postponed to 5.20 (which will definitely be COW-enabled).
As the plan currently stands, 5.18 will build as COW-disabled by default -
but there's an option to build it COW-enabled (which p5p are encouraging
module authors to use - mainly to have them avoid rude shocks when 5.20 does
come along).

I guess Strawberry Perl would just go with the default option - though I
don't have any personal preference in either direction.

Cheers,
Rob

[kmx]

Hi,

is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry
Perl 5.18.x series ?

I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess
Rob is also subscribed to this list) and AFAIK it works.

Pros:

1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin
without any special hacking that was needed for 5.16.0

2/ PDL users are gonna like it

3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit
strawberry perl

4/ Couple of others asking me privately will appreciate it (they ask: why
32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?)

--
kmx

[kmx]

On 13.3.2013 23:14, sisy...@optusnet.com.au wrote:
> -----Original Message----- From: kmx
>
>> Hi,
>>
>> is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry
>> Perl 5.18.x series ?
>>
>> I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess
>> Rob is also subscribed to this list) and AFAIK it works.
>
> I've been testing it continually over the last year or so. Every module I
> build (not just PDL), I've been building on USE_64_BIT_INT - for both
> 5.16.0 and current blead (5.17.x).
> I haven't struck any problems at any time that were related to the 64int
> architecture.

Thanks for feedback.

> I can think of only one con:
>
> ActivePerl binaries (ppm packages) will not be usable on the 64int
> architecture Strawberry Perl - unless, of course, ActiveState also start
> providing packages for the 64int architecture. (I've no idea what
> ActiveState are planning to do in this regard.)
> I doubt that many Strawberry users (if any) would be affected by this,
> and I don't regard it as a stopper.

On the other hand ActiveState ppm repositories use newer ppm format than
ppm utility included in strawberry perl is able to handle. So it is not
even today easily possible to install ppm from ActiveState repo into
strawberry perl.

> (Will 32int Strawberry builds still be available for anyone who wants one ?)

No, my idea is just one and only one 32bit strawberry perl 5.18.x with 64int.

> As regards the ppm packages that I provide, they'll be available for both
> the 64int and 32int architectures.
>
>> Pros:
>>
>> 1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin
>> without any special hacking that was needed for 5.16.0
>>
>> 2/ PDL users are gonna like it
>>
>> 3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit
>> strawberry perl
>>
>> 4/ Couple of others asking me privately will appreciate it (they ask: why
>> 32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?)
>>
>
> One other thing to consider with 5.18 Strawberry is whether it should be
> COW-enabled or not.
> Until recently, the p5p plan was to make 5.18 COW-enabled, but that has
> now been postponed to 5.20 (which will definitely be COW-enabled).
> As the plan currently stands, 5.18 will build as COW-disabled by default
> - but there's an option to build it COW-enabled (which p5p are
> encouraging module authors to use - mainly to have them avoid rude shocks
> when 5.20 does come along).
>
> I guess Strawberry Perl would just go with the default option - though I
> don't have any personal preference in either direction.

As for COW I am gonna follow perl core default behaviour.

--
kmx

[sisy...@optusnet.com.au]

-----Original Message-----
From: kmx

> > ActivePerl binaries (ppm packages) will not be usable on the 64int
> > architecture Strawberry Perl - unless, of course, ActiveState also start
> > providing packages for the 64int architecture. (I've no idea what
> > ActiveState are planning to do in this regard.)
> > I doubt that many Strawberry users (if any) would be affected by this,
> > and I don't regard it as a stopper.
>
> On the other hand ActiveState ppm repositories use newer ppm format than
> ppm utility included in strawberry perl is able to handle. So it is not
> even today easily possible to install ppm from ActiveState repo into

Oh yes ... I think I recently discovered that there's quite a few hoops to
jump through if you want to 'ppm install' from AS repo to Strawberry Perl.
(Although I build a few ppm packages, I rarely actually use ppm - and I keep
losing track of the capabilities of this utility.)

> > (Will 32int Strawberry builds still be available for anyone who wants
> > one ?)
>
> No, my idea is just one and only one 32bit strawberry perl 5.18.x with
> 64int.

Good - that keeps it nice and simple.

> > One other thing to consider with 5.18 Strawberry is whether it should be
> > COW-enabled or not.
> > Until recently, the p5p plan was to make 5.18 COW-enabled, but that has
> > now been postponed to 5.20 (which will definitely be COW-enabled).
> > As the plan currently stands, 5.18 will build as COW-disabled by
> > default - but there's an option to build it COW-enabled (which p5p are
> > encouraging module authors to use - mainly to have them avoid rude
> > shocks when 5.20 does come along).

>

> As for COW I am gonna follow perl core default behaviour.

I've no problems with that. I intend to have both COW-enabled and
COW-disabled builds of 5.18.0, but I'm aiming to build ppm packages for
COW-disabled only.

Cheers,
Rob

[kmx]

So, 32bit strawberry perl 5.18.x will be built with USE_64_BIT_INT

You can test 5.17.10 beta (32bit+USE_64_BIT_INT) from:
http://strawberryperl.com/beta/ (MSI+ZIP+Portable)

--
kmx

[Michiel Beijen]

Hi kmx,

Great! I'm using it right now to test some modules.

I got this error on Log::Log4perl 053Resurrect.t - and only on
Windows, not on my Debian perl 5.17.10. Could it have anything to do
with the build options for this StrawberryPerl?

Deep recursion on subroutine
"Log::Log4perl::Resurrector::resurrector_fh" at
C:\strawberry\cpan\build\Log-Log4perl-1.40-XYO4Rb\blib\lib/Log/Log4perl/Resurrector.pm
line 70.
Deep recursion on subroutine "File::Temp::tempfile" at
C:\strawberry\cpan\build\Log-Log4perl-1.40-XYO4Rb\blib\lib/Log/Log4perl/Resurrector.pm
line 28.t/053Resurrect.t .....
Dubious, test returned 253 (wstat 64768, 0xfd00)

--
Mike

[kmx]

You have to downgrade File::Temp to version 0.22 then it works nice with
strawberry 5.17.10

What File::Temp version do you have on your Debian box?

--
kmx

[Michiel Beijen]

On Thu, Apr 4, 2013 at 9:25 PM, kmx <k...@atlas.cz> wrote:
>> C:\strawberry\cpan\build\Log-Log4perl-1.40-XYO4Rb\blib\lib/Log/Log4perl/Resurrector.pm
>> line 28.t/053Resurrect.t .....
>> Dubious, test returned 253 (wstat 64768, 0xfd00)
>
> You have to downgrade File::Temp to version 0.22 then it works nice with
> strawberry 5.17.10

Thanks, this works indeed!

> What File::Temp version do you have on your Debian box?

On Debian I have 0.23, which does not seem to cause any trouble there.
Should I file a bug report for File::Temp?
--
Mike

[kmx]

It is either a bug in File::Temp or Log::Log4perl is using File::Temp in a
way that is not supported on all platforms.

But yes, probably start an RT for File::Temp

BTW: the same behaviour on strawberry perl 5.16.1

--
kmx