On 13.3.2013 23:14, sisyph...@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
