From cottrell@wfu.edu Sun Apr  4 19:42:04 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] "break" bug fixed
Date: Sun, 04 Apr 2010 19:42:03 -0400
Message-ID: <Pine.A41.4.58.1004041929260.2920566@f1n11.sp2net.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0627017080727791913=="

--===============0627017080727791913==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


I'm embarrassed to say that there has been a bug in the "break"
command (for loops) since it was introduced, probably.

Up till now, the effect of "break" has been to invalidate the loop
continuation condition. The loop would not proceed to the next
iteration -- but it would, however, continue to the end of the
current iteration. The new behavior, which I'm sure is what users
would expect, is that the thread of execution of the current loop
breaks immediately after the "break" command.

Simple test case:

<script>
loop 100
  print "One"
  break
  print "Two"
endloop
</script>

Up till now you'd see "One" and "Two" printed once; now you see
just "One". I hope this hasn't caused anyone grief in writing
complex scripts.

Allin

--===============0627017080727791913==--