FAQ
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

Search Discussions

  • Kmx at Mar 13, 2013 at 6:24 pm
    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
  • Sisyphus1 at Mar 13, 2013 at 10:15 pm
    -----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 at Mar 14, 2013 at 7:42 am

    On 13.3.2013 23:14, sisyphus1@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
  • Sisyphus1 at Mar 14, 2013 at 8:47 am
    -----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 at Apr 3, 2013 at 8:26 pm
    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 at Apr 4, 2013 at 2:47 pm
    Hi kmx,
    On Wed, Apr 3, 2013 at 10:25 PM, kmx wrote:
    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)
    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 at Apr 4, 2013 at 7:25 pm

    On 4.4.2013 16:46, Michiel Beijen wrote:
    Hi kmx,
    On Wed, Apr 3, 2013 at 10:25 PM, kmx wrote:
    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)
    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)
    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 at Apr 4, 2013 at 7:47 pm

    On Thu, Apr 4, 2013 at 9:25 PM, kmx 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 at Apr 5, 2013 at 1:06 am

    On 4.4.2013 21:46, Michiel Beijen wrote:
    On Thu, Apr 4, 2013 at 9:25 PM, kmx 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?
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupwin32-vanilla @
categoriesperl
postedMar 13, '13 at 12:29p
activeApr 5, '13 at 1:06a
posts10
users4
websitestrawberryperl.com

People

Translate

site design / logo © 2019 Grokbase