From: do-not-use@swldwa.uk   
      
   On 18/09/2024 09:44, Ruvim wrote:   
   > On 2024-09-17 22:58, Anthony Howe wrote:   
   >> On 2024-09-17 07:59, Ruvim wrote:   
   >>> On 2024-09-17 15:20, minforth wrote:   
   >>>> I would like to see an "officially recognized" standard reference   
   >>>> system, speed and number of xt's per word are of no importance.   
   >>>>   
   >>>> Are you planning to make one?   
   >>>   
   >>> I think, having the single standard reference implementation is a big   
   >>> step back in Forth standardization process. Because implementation   
   >>> details of the particular implementation will be used as requirements.   
   >>   
   >> I think it should be recognised in some capacity, given Forth's   
   >> origins, but whether there should be a reference implementation   
   >> probably not.   
   >>   
   >>   
   >>> I think, the standard conformance test suite is enough.   
   >>   
   >> One would think so, but the test suite is:   
   >>   
   >> * incomplete   
   >> * as published in draft 19-1 has typos and possible errors   
   >> * test cases often test multiple words at once that have not be tested   
   >> separately   
   >> * assumes the entire draft with all the optional sets are present,   
   >> rather than separate the word sets into separate unit tests   
   >   
   > There is another testsuite:   
   > https://github.com/gerryjackson/forth2012-test-suite   
      
   Just to put the record straight, The Forth Test suite in the Forth 200X   
   standard draft 19.1 incorporates most of my test suite with the addition   
   of, for example, tests for new words such as FIND-NAME and FIND-NAME-IN.   
      
   >   
   >   
   > I have an idea for a testsuite that:   
   >    — is a ready-to-use program;   
   >    — does not use words from optional word sets (for that, all the   
   > source files are transpiled into a single file that can be passed to   
   > stdin);   
   >    — does not change the host Forth system (for example, does not add   
   > the missed standard words);   
   >    — has an external program that parses output of the testsuite from   
   > the host's Forth system stdout and generates a report in text/xml/xhtml   
   > form;   
   >    — includes into the report general information such as implemented   
   > words and word sets, implementation options (that can be inferred by a   
   > standard program), the behavior of some words in edge cases, etc., along   
   > with the lists of passed and failed tests;   
   >    — has a configuration for a number of known systems (that is extended   
   > by the community);   
   >   
   Some of these, particularly the reporting has been suggested before but,   
   as you pointed out elsewhere everybody is an unpaid volunteer and nobody   
   has found the time or motivation to undertake such extensions. Are you   
   volunteering? I've just requested that the Forth 200X committee find   
   someone else to take over my test suite - so feel free to volunteer.   
      
   One thing not included in the Test Suite in the standard, as far as I   
   can see,  and not mentioned in your wish list is that the Hayes tester   
   assumes so much of the system is working before the tests actually start   
   - how do you test the tester? I thought about this and developed a   
   preliminary test based on the assumption that for automated testing at   
   least the interpreter must work. So it starts by using SOURCE TYPE (   
   comments ) and CR to output messages and include a commentary of how the   
   tests progress. If the displays are correct it tests >IN manipulation   
   and uses it as an interpretive IF to actually detect errors. Then it   
   goes on to do a basic test of the words used in the Hayes tester and so   
   on. This is included in the link above.   
      
   --   
   Gerry   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)