Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
-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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
-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
