You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While running (at least parts) of the Test Suite from block storage, @frenchie68 noticed a bug in the test related to the test word TL7 in the blocktest.fth tests. The attention to this test made us ask what the purpose of the test was and whether it was justified by the Forth 2012 Standard.
The intent of the test was to exercise the relationship between the standard words LOAD and UPDATE. It is common for LOAD to be implemented as a colon definition, built on other words like BLOCK, and so disturbing the buffer that would be flagged for update by a subsequent UPDATE. The test was written to demonstrate this effect. (Aside: The bug found by @frenchle68 related to the further disturbance caused by running the tests themselves from the block storage.)
The Forth standard (ANSI X3.215-1994 and Forth 2012 RC3) states:
§7.6.1.1790 LOAD
Save the current input-source specification. Store u in BLK
(thus making block u the input
source and setting the input buffer to encompass its
contents), set >IN to zero, and interpret.
When the parse area is exhausted, restore the prior input
source specification. Other stack
effects are due to the words LOADed.
An ambiguous condition exists if u is zero or is not a valid
block number.
§7.6.1.2400 UPDATE
Mark the current block buffer as modified. An ambiguous
condition exists if there is no
current block buffer.
UPDATE does not immediately cause I/O.
The definition of LOAD above is not explicit in saying that it changes the "current block buffer" applied in UPDATE (either during or after the LOAD). This is unlike the definitions of BLOCK (§7.6.1.0800) and BUFFER (§7.6.1.0820) are both explicit in stating "At the conclusion of the operation, the block buffer pointed to by a-addr is the current block buffer ...".
Therefore, @frenchie68 and I feel that the TL7 test not justified by the specification, and so should be deprecated.
@gerryjackson : Do you have any issues regarding deprecating tests? There might be arguments for leaving a "dummy" test that trivially passes rather than reducing the number or order of the tests which might be important to the test-suite users? On the other hand, if simpler is better, then removing the code related to TL7 might be the simplest change. If we can agree on how a test should be deprecated, I am happy to make the changes.
The text was updated successfully, but these errors were encountered:
While running (at least parts) of the Test Suite from block storage, @frenchie68 noticed a bug in the test related to the test word
TL7
in theblocktest.fth
tests. The attention to this test made us ask what the purpose of the test was and whether it was justified by the Forth 2012 Standard.The intent of the test was to exercise the relationship between the standard words
LOAD
andUPDATE
. It is common forLOAD
to be implemented as a colon definition, built on other words likeBLOCK
, and so disturbing the buffer that would be flagged for update by a subsequentUPDATE
. The test was written to demonstrate this effect. (Aside: The bug found by @frenchle68 related to the further disturbance caused by running the tests themselves from the block storage.)The Forth standard (ANSI X3.215-1994 and Forth 2012 RC3) states:
The definition of LOAD above is not explicit in saying that it changes the "current block buffer" applied in UPDATE (either during or after the LOAD). This is unlike the definitions of BLOCK (§7.6.1.0800) and BUFFER (§7.6.1.0820) are both explicit in stating "At the conclusion of the operation, the block buffer pointed to by a-addr is the current block buffer ...".
Therefore, @frenchie68 and I feel that the TL7 test not justified by the specification, and so should be deprecated.
@gerryjackson : Do you have any issues regarding deprecating tests? There might be arguments for leaving a "dummy" test that trivially passes rather than reducing the number or order of the tests which might be important to the test-suite users? On the other hand, if simpler is better, then removing the code related to TL7 might be the simplest change. If we can agree on how a test should be deprecated, I am happy to make the changes.
The text was updated successfully, but these errors were encountered: