Re: Smoke [5.8.6] 23484 FAIL(X) MSWin32 WinXP/.Net SP1 (x86/1 cpu)

2004-11-09 Thread Steve Hay
Nicholas Clark wrote: On Mon, Nov 08, 2004 at 01:02:00AM +, Steve Hay wrote: Automated smoke report for 5.8.6 patch 23484 TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu) onMSWin32 - WinXP/.Net SP1 using cl version 12.00.8804

RE: sharing hash-values

2004-11-09 Thread Orton, Yves
I needed this too some time ago and ended up writing http://search.cpan.org/dist/Array-RefElem/. Ive always wished this was part of Scalar/List Utils and thus/or alternatively in the core modules. It's a very useful module and the code bloat would be minimal as all it does pretty much is

\N{...} and bytes pragmas

2004-11-09 Thread Dintelmann, Peter
When using the \N{...} notation from the charnames pragma one can easily run into a bit of trouble when the bytes pragma is also in effect. $ perl -Mcharnames=:full -Mbytes -le 'print ord \N{WHITE SMILING FACE}' Character 0x263a with name 'WHITE SMILING FACE' is above 0xFF at -e line 1

Re: Smoke [5.9.2] 23450 FAIL(M) MSWin32 WinXP/.Net SP1 (x86/1 cpu)

2004-11-09 Thread Steve Hay
[EMAIL PROTECTED] wrote: As far as I know, there isn't a portable way to declare a local variable within a macro, but the existing definition for SvREFCNT_inc() is one way you could achieve it. I'm willing to give that a go, but SvREFCNT_inc() uses PL_Sv as the temporary variable for compilers

Re: sharing hash-values

2004-11-09 Thread Nicholas Clark
On Tue, Nov 09, 2004 at 11:52:04AM -, Orton, Yves wrote: I needed this too some time ago and ended up writing http://search.cpan.org/dist/Array-RefElem/. Ive always wished this was part of Scalar/List Utils and thus/or alternatively in the core modules. It's a very useful module and

Re: sharing hash-values

2004-11-09 Thread Rafael Garcia-Suarez
Nicholas Clark wrote: I'd actually like it if we had LVALUE reference assignment to do this. So I could say something like \$a[1] = \$c to alias $a[1] and $c to the same scalar in memory. Assuming that Perl 6 keeps the same dereferencing syntax as Perl 5, I've no idea if Larry would want

RE: sharing hash-values

2004-11-09 Thread Konovalov, Vadim
I'd actually like it if we had LVALUE reference assignment to do this. So I could say something like \$a[1] = \$c to alias $a[1] and $c to the same scalar in memory. This looks to me very perlish and excellent, and I like this idea very much. However there could be a kind of difficulty: I

Smoke [5.9.2] 23487 FAIL(c) bsd/os 4.1 (i386/1 cpu)

2004-11-09 Thread kane
Automated smoke report for 5.9.2 patch 23487 on bsd/os - 4.1 (i386/1 cpu) (fixit.xs4all.nl) using version Report by Test::Smoke v1.18.09 (perl 5.00503) [3 hours 3 minutes] O = OK F = Failure(s), extended report at the bottom X = test(s) failed under TEST but not under harness ? = still running

[perl #32380] numeric.c assumes that NV_DIG+2 will be enough digits for all precision possible in NV

2004-11-09 Thread via RT
# New Ticket Created by Allen Smith # Please include the string: [perl #32380] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32380 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of

RE: sharing hash-values

2004-11-09 Thread Orton, Yves
However there could be a kind of difficulty: I saw many people on perlmonks.org rely on fact that stringified reference to scalar (or SV) being consistent, so they write $hash{$ref} = \$ref; And this could be easily broken by such kind aliasing. Well, IMO this is a bad habit that I

[PATCH perl-current] Re: [perl #32380] numeric.c assumes that NV_DIG+2 will be enough digits for all precision possible in NV

2004-11-09 Thread Ed Allen Smith
Well, for some reason RT does not seem to have forwarded to p5p the information about the patch and test program (which includes sample problematic output) I attached to the bug report. They are both included below. If further comments on them are necessary, please check the RT comments first.

Re: sharing hash-values

2004-11-09 Thread Fergal Daly
On Tue, Nov 09, 2004 at 03:07:52PM -, Orton, Yves wrote: However there could be a kind of difficulty: I saw many people on perlmonks.org rely on fact that stringified reference to scalar (or SV) being consistent, so they write $hash{$ref} = \$ref; And this could be easily broken by

Re: sharing hash-values

2004-11-09 Thread Yuval Kogman
On Tue, Nov 09, 2004 at 15:07:52 -, Orton, Yves wrote: However there could be a kind of difficulty: I saw many people on perlmonks.org rely on fact that stringified reference to scalar (or SV) being consistent, so they write $hash{$ref} = \$ref; And this could be easily broken by

[PATCH perl-current] Re: [perl #32380] numeric.c assumes that NV_DIG+2 will be enough digits for all precision possible in NV

2004-11-09 Thread Allen Smith via RT
Well, for some reason RT does not seem to have forwarded to p5p the information about the patch and test program (which includes sample problematic output) I attached to the bug report. They are both included below. If further comments on them are necessary, please check the RT comments first.

Re: [perl #2383] Undefining signals

2004-11-09 Thread Ben Morrow
Quoth Nick Ing-Simmons [EMAIL PROTECTED]: I _think_ I prefer that solution too if setting $SIG{FOO}=undef blocks the signal That has a perlish-feel. That was the intention, yes. It is the if possible, and then set it to SIG_IGN (in that order) bit that bothers me. If you _can_

RE: sharing hash-values

2004-11-09 Thread Orton, Yves
There's one gotcha with this. If the thing in $ref gets garbage collected, the address can be reused, so you actually have to do $hash{refaddr $ref} = [do{$r=$ref;weaken($r)}, ...]; and then check that -[0] is still valid. Wrap it up in a class and it's not too bad. Of course this

Re: [perl #2383] Undefining signals

2004-11-09 Thread Andy Dougherty
On Tue, 9 Nov 2004, Ben Morrow wrote: Quoth Nick Ing-Simmons [EMAIL PROTECTED]: The other snag is what happens to $SIG{NEVERMENTIONED} ? In current sources a sig which is never mentioned is 'undef' (in some sense) and so is DEFAULT. I would not want an unmentioned INT to be blocked.

[PATCH] fix IO::File to support binmode

2004-11-09 Thread Jos I. Boumans
Hi, So, in a rather annoying set of circumstances i noticed Archive::Tar's binary file tests failing on windows, for no apparent reason... after some debugging i found that my call to IO::File's 'binmode' didn't actually work.. when called directly like this: $fh-binmode; it dies with a 'no

[perl #32383] DProf breaks List::Util::shuffle

2004-11-09 Thread via RT
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #32383] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32383 This is a bug report for perl from [EMAIL PROTECTED], generated with the

Re: [PATCH] fix IO::File to support binmode

2004-11-09 Thread H.Merijn Brand
On Tue 09 Nov 2004 16:59, Jos I. Boumans [EMAIL PROTECTED] wrote: Hi, So, in a rather annoying set of circumstances i noticed Archive::Tar's binary file tests failing on windows, for no apparent reason... after some debugging i found that my call to IO::File's 'binmode' didn't actually

Re: sharing hash-values

2004-11-09 Thread Tels
-BEGIN PGP SIGNED MESSAGE- Moin, On Monday 08 November 2004 22:25, Gisle Aas wrote: Tels [EMAIL PROTECTED] writes: Or would I need to use XS for that? I needed this too some time ago and ended up writing http://search.cpan.org/dist/Array-RefElem/. Wow, 173 (vs. roughly 220) bytes

Re: [PATCH] fix IO::File to support binmode

2004-11-09 Thread Jos I. Boumans
On Nov 9, 2004, at 7:24 PM, H.Merijn Brand wrote: 1. In general CORE modules do not have no_plan T::M headers. I've changed that to match the actual number of tests Didn't know that, my apologies -- the number of tests depends on the OS, hence the no plan... but i see you've already adapted

[PATCH] Re: [perl #32272] Not OK: perl v5.8.5 +MAINT23414 on cygwin-thread-multi-64int 1.5.12s(0.11642) (UNINSTALLED)

2004-11-09 Thread Yitzchak Scott-Thoennes
On Mon, Nov 01, 2004 at 07:50:30PM -, Yitzchak Scott-Thoennes wrote: t/io/tell.FAILED at test 28 The io/tell doesn't concern me; it's a questionable test, and goes away with PERLIO=perlio (or -Uusefaststdio). Here's a patch to skip it. It isn't actually

RE: [perl #32346] wperl prompt me a dos window

2004-11-09 Thread Jan Dubois
I'm actually using winXP SP1. To manage my network, I use mrtg since a long time. This soft use perl every 5 minutes to refresh informations. So, until yesterday, wperl was working great (with activeperl 5.6) but i've got a problem yeasterday and i have had to reinstall my os. Since,