Re: Hoplites: Watch for each
On Mon, Nov 03, 2003 at 05:06:01PM +0100, Elizabeth Mattijsen wrote: At 14:06 + 11/3/03, Tim Bunce wrote: Its cheap to reset an iterator, just do keys %foo; before the Ceach loop. Just wondering, is keys() optimized for void context? Perlfunc only states: As a side effect, calling keys() resets the HASH⤁s internal iterator... If it is _not_ optimized for void context, I think it's easy to reset rather than cheap ;-) If keys() _is_ optimized for void context, a change in the perlfunc.pod seems to be in order. No idea. A change in the perlfunc.pod seems to be in order either way. Tim.
Re: Hoplites: Watch for each
On Tue, Nov 04, 2003 at 07:18:34AM +0530, Abhijit Menon-Sen [EMAIL PROTECTED] wrote:
At 2003-11-03 21:35:22 +, [EMAIL PROTECTED] wrote:
Just wondering, is keys() optimized for void context?
Yes. From doop.c:Perl_do_kv:
OP *
Perl_do_kv(pTHX)
{ ...
keys = hv;
(void)hv_iterinit(keys);/* always reset iterator regardless */
if (gimme == G_VOID)
RETURN;
But be aware that it is also optimized for scalar context only if the
hash isn't tied.
Re: Hoplites: Watch for each
On Sun, Nov 02, 2003 at 12:20:11AM -0600, Andy Lester wrote:
Anything that uses the Ceach operator is a prime candidate for
bugginess. Please keep an eye out for them as you do your testing.
Any function that contains Ceach oughta be heavily checked.
Ditto anything that uses Ckeys or Cvalues without a sort.
Elaborating: Code that uses Ceach, Ckeys or Cvalues may have
worked in the past because the order of elements would be the same
between runs. For instance, you have one hash, and then another hash
with the same keys, and the code relies on those keys being in the same
order between the hashes. This reliance might be explicit or
accidental. Now, with 5.8.1 randomizing hashes, that code may break.
Also, in .t files, it'd be a good thing to not rely on each/keys/values
when determining the order of tests, because subsequent test runs might
not be in the same order. For example:
my %tests = ( test1 = 'foo', test2 = 'bar', etc );
while ( my($key,$val) = each %tests ) {
# do a test
}
The order in which these tests are done will be different between runs
of the code...
A separate issue with Ceach is that code using it generally assumes
that the has itterator is at the start of the hash. If it's not
(because an Ceach loop somewhere terminated early, for example)
then some items of the hash will be skipped. A very hard to find bug.
Its cheap to reset an itterator, just do
keys %foo;
before the Ceach loop.
But rather than post emails with such guidelines, only for them to
be lost in the sands of time, wouldn't it be better to update the
web site?
Tim.
Re: Hoplites: Watch for each
But rather than post emails with such guidelines, only for them to be lost in the sands of time, wouldn't it be better to update the web site? Yeah, it would. I'd like to come up with a list of guidelines of things to watch for. Lately, I've been spending my free time on prove and Test::Harness. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: Hoplites: Watch for each
On Mon, Nov 03, 2003 at 02:06:01PM +, Tim Bunce wrote: A separate issue with Ceach is that code using it generally assumes that the has itterator is at the start of the hash. If it's not (because an Ceach loop somewhere terminated early, for example) then some items of the hash will be skipped. A very hard to find bug. Its cheap to reset an itterator, just do keys %foo; before the Ceach loop. Similarly, I had a nasty bug in Class::DBI for a while where a reference to the hash being iterated over was being passed off to another method inside that loop. When the method being called did anything with the hash it reset the loop ... Tony
Re: Hoplites: Watch for each
At 14:06 + 11/3/03, Tim Bunce wrote: Its cheap to reset an itterator, just do keys %foo; before the Ceach loop. Just wondering, is keys() optimized for void context? Perlfunc only states: As a side effect, calling keys() resets the HASH⤁s internal iterator... If it is _not_ optimized for void context, I think it's easy to reset rather than cheap ;-) If keys() _is_ optimized for void context, a change in the perlfunc.pod seems to be in order. Liz
Re: Hoplites: Watch for each
Elizabeth Mattijsen wrote: Just wondering, is keys() optimized for void context? Perlfunc only states: As a side effect, calling keys() resets the HASHâ¤_s internal iterator... Yes, it is. If keys() _is_ optimized for void context, a change in the perlfunc.pod seems to be in order. Thanks, applied as #21644 :) --8-- As a side effect, calling keys() resets the HASH's internal iterator, -see L/each. +see L/each. (In particular, calling keys() in void context resets +the iterator with no other overhead.) --8--
Re: Hoplites: Watch for each
At 17:51 +0100 11/3/03, Rafael Garcia-Suarez wrote: Elizabeth Mattijsen wrote: Just wondering, is keys() optimized for void context? Perlfunc only states: As a side effect, calling keys() resets the HASHâ¤_s internal iterator... Yes, it is. Ok, so it is indeed cheap! If keys() _is_ optimized for void context, a change in the perlfunc.pod seems to be in order. Thanks, applied as #21644 :) No, thank _you_! ;-) Liz
Re: Hoplites: Watch for each
On Mon, Nov 03, 2003 at 09:33:56AM -0600, Andy Lester wrote: But rather than post emails with such guidelines, only for them to be lost in the sands of time, wouldn't it be better to update the web site? Yeah, it would. I'd like to come up with a list of guidelines of things to watch for. Lately, I've been spending my free time on prove and Test::Harness. *cough*wiki*cough* ;) -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Stupid am I? Stupid like a fox!
Re: Hoplites: Watch for each
On Fri, Oct 31, 2003 at 05:01:32PM -0600, Andy Lester wrote: Anything that uses the Ceach operator is a prime candidate for bugginess. Please keep an eye out for them as you do your testing. Any function that contains Ceach oughta be heavily checked. Ditto anything that uses Ckeys or Cvalues without a sort. Ummm... why? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Re: Hoplites: Watch for each
Anything that uses the Ceach operator is a prime candidate for
bugginess. Please keep an eye out for them as you do your testing.
Any function that contains Ceach oughta be heavily checked.
Ditto anything that uses Ckeys or Cvalues without a sort.
Elaborating: Code that uses Ceach, Ckeys or Cvalues may have
worked in the past because the order of elements would be the same
between runs. For instance, you have one hash, and then another hash
with the same keys, and the code relies on those keys being in the same
order between the hashes. This reliance might be explicit or
accidental. Now, with 5.8.1 randomizing hashes, that code may break.
Also, in .t files, it'd be a good thing to not rely on each/keys/values
when determining the order of tests, because subsequent test runs might
not be in the same order. For example:
my %tests = ( test1 = 'foo', test2 = 'bar', etc );
while ( my($key,$val) = each %tests ) {
# do a test
}
The order in which these tests are done will be different between runs
of the code...
xoa
--
Andy Lester
[EMAIL PROTECTED], AIM:petdance
http://petdance.com/ http://use.perl.org/~petdance/
Hoplites: Watch for each
Anything that uses the Ceach operator is a prime candidate for bugginess. Please keep an eye out for them as you do your testing. Any function that contains Ceach oughta be heavily checked. Ditto anything that uses Ckeys or Cvalues without a sort. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
