Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #32831 > unrolled thread

ANS Forth test programs

Back to article view | Back to comp.lang.forth

Contents

  ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-03 23:34 +0100
    Re: ANS Forth test programs mhx@iae.nl - 2014-08-03 22:33 -0700
      Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-04 08:47 +0100
        Re: ANS Forth test programs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-04 05:10 -0400
          Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-05 17:33 +0100
        Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-21 16:01 +0000
          Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 16:20 +0000
            Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-21 21:47 +0000
              Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:33 +0000
            Re: ANS Forth test programs albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-22 19:23 +0000
          Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-22 12:28 +0100
            Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-22 13:35 +0100
              Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-22 17:11 +0100
            Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:47 +0000
      Re: ANS Forth test programs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-04 14:26 +0200
        Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-05 17:35 +0100
          Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-05 20:06 -0700
            Re: ANS Forth test programs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-06 16:43 -0400
            Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-07 10:23 +0100
              Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-07 18:29 -0700
                Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-07 23:28 -0700
                  Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-08 04:25 -0500
                    Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-08 08:08 -0700
                      Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-08 10:49 -0500
                        Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 19:54 -0700
                      Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-08 16:27 +0000
                        Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-08 10:47 -0700
                          Re: ANS Forth test programs Coos Haak <chforth@hccnet.nl> - 2014-08-08 22:34 +0200
                            Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-08 21:06 -0700
                              Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 23:59 -0700
                                Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-09 01:35 -0700
                                  Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-09 04:41 -0500
                                    Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-09 17:53 -0700
                                      Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-10 03:25 -0500
                                        Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-10 03:19 -0700
                                  Re: ANS Forth test programs Mikael Nordman <oh2aun@gmail.com> - 2014-08-10 05:28 -0700
                                    Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-12 22:43 -0700
                                      Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-13 09:46 +0000
                                        Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-13 21:17 -0700
                                          Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-14 10:24 +0000
                                            Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-14 12:10 +0100
                                            Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-14 06:02 -0700
                                              Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-14 23:48 +0000
                                            Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-14 20:06 -0700
                                              Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-15 09:13 +0000
                                                Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-15 21:07 -0700
                                                  Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-16 02:22 -0500
                                                  Re: ANS Forth test programs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-16 04:43 -0400
                                                  Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-16 20:37 +0000
                              Re: ANS Forth test programs BruceMcF <agila61@netscape.net> - 2014-08-12 16:55 -0700
                                Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-12 22:47 -0700
                                  Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-13 10:43 +0100
                                  Re: ANS Forth test programs bruce.mcfarling@gmail.com - 2014-08-16 10:02 -0700
                          Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-09 11:09 +0000
                            Re: ANS Forth test programs Lars Brinkhoff <lars.spam@nocrew.org> - 2014-08-09 13:34 +0200
                              Re: ANS Forth test programs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-09 21:45 +0200
                    Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 13:39 -0700
                      Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-10 03:21 +0100
                  Re: ANS Forth test programs "Bill Leary" <Bill_Leary@msn.com> - 2014-08-08 10:34 -0400
                Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-08 10:18 +0100
                  Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 12:48 -0700
                    Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-08 21:46 +0100
                      Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 14:14 -0700
                        Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-08 23:06 +0100
                      Re: ANS Forth test programs Coos Haak <chforth@hccnet.nl> - 2014-08-09 00:40 +0200
                        Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 18:17 -0700
    Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-06 14:50 -0700
      Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-07 10:12 +0100
        Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-07 16:07 -0700
    Re: ANS Forth test programs francois.ganza@wanadoo.fr - 2014-08-08 13:40 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#32831 — ANS Forth test programs

I've just updated version 0.10 of the ANS Forth test program suite to 
the FLAG web-site http://soton.mpeforth.com/flag/anstests/index.html

The update includes more tests of the Core Extension word set mostly 
kindly contributed by James Bowman plus a few changes listed in the 
changes.txt file.

Using Windows 7 (32 bit) the only Forth system that passed all tests 
with no errors was Swiftforth. The maintainers of GForth, VFX Forth, 
iForth and Win32 Forth might like to try running the tests.

-- 
Gerry

[toc] | [next] | [standalone]

#32836

On Monday, August 4, 2014 12:34:27 AM UTC+2, Gerry wrote:
> I've just updated version 0.10 of the ANS Forth test program suite to
> the FLAG web-site http://soton.mpeforth.com/flag/anstests/index.html
> 
> Using Windows 7 (32 bit) the only Forth system that passed all tests 
> with no errors was Swiftforth. The maintainers of GForth, VFX Forth,
> iForth and Win32 Forth might like to try running the tests.

From the page:
"As can be seen GForth failed one test."

I don't think it failed that one. The writer of the test *assumed* that
-1 (or the largest unsigned number) is so large that RESIZE would choke
on it.

-marcel

[toc] | [prev] | [next] | [standalone]

#32837

On 04/08/2014 06:33, mhx@iae.nl wrote:
> On Monday, August 4, 2014 12:34:27 AM UTC+2, Gerry wrote:
>> I've just updated version 0.10 of the ANS Forth test program suite to
>> the FLAG web-site http://soton.mpeforth.com/flag/anstests/index.html
>>
>> Using Windows 7 (32 bit) the only Forth system that passed all tests
>> with no errors was Swiftforth. The maintainers of GForth, VFX Forth,
>> iForth and Win32 Forth might like to try running the tests.
>
>  From the page:
> "As can be seen GForth failed one test."
>
> I don't think it failed that one. The writer of the test *assumed* that
> -1 (or the largest unsigned number) is so large that RESIZE would choke
> on it.
>

And the writer was well aware of that, see the assumptions at the start 
of that test file.

"\ Assumptions and dependencies:
\     - that 'addr -1 ALLOCATE' and 'addr -1 RESIZE' will return an error
..."

But so what, GForth did "choke on it"  as it returns (0 -524) for 
(a-addr2 ior) which indicates the operation failed, in which case 
according to the standard

14.6.1.2145 RESIZE (a-addr1 u -- a-addr2 ior)

"...

If the operation fails, a-addr2 equals a-addr1, the region of memory at 
a-addr1 is unaffected, and ior is the implementation-defined I/O result 
code"

As 0 <> a-addr1 it failed the test. It doesn't seem a particularly 
useful thing to do in this situation but that's what the standard says.

The test ought to also check that the region of memory is unaffected - 
thanks for bringing that to my attention, albeit indirectly.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#32839

On Mon, 04 Aug 2014 03:47:47 -0400, Gerry Jackson  
<gerry@jackson9000.fsnet.co.uk> wrote:

> And the writer was well aware of that, see the assumptions at the start  
> of that test file.
>
> "\ Assumptions and dependencies:
> \     - that 'addr -1 ALLOCATE' and 'addr -1 RESIZE' will return an error
> ..."
>

As a slight aside, if "addr -1 ALLOCATE" and "addr -1 RESIZE" don't
return an error, what should they do? 1) in general 2) to pass the test


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#32853

On 04/08/2014 10:10, Rod Pemberton wrote:
> On Mon, 04 Aug 2014 03:47:47 -0400, Gerry Jackson
> <gerry@jackson9000.fsnet.co.uk> wrote:
>
>> And the writer was well aware of that, see the assumptions at the
>> start of that test file.
>>
>> "\ Assumptions and dependencies:
>> \     - that 'addr -1 ALLOCATE' and 'addr -1 RESIZE' will return an error
>> ..."
>>
>
> As a slight aside, if "addr -1 ALLOCATE" and "addr -1 RESIZE" don't
> return an error, what should they do? 1) in general 2) to pass the test
>

If the system can't allocate/resize the space and doesn't return an 
error (lies) then the test will fail and presumably the failure will be 
investigated.

If it can allocate the space then the test assumption is wrong and so 
invalid - the test should be deleted for that system.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#32993

On Mon, 04 Aug 2014 08:47:47 +0100, Gerry Jackson
<gerry@jackson9000.fsnet.co.uk> wrote:

>On 04/08/2014 06:33, mhx@iae.nl wrote:
>
>And the writer was well aware of that, see the assumptions at the start 
>of that test file.
>
>"\ Assumptions and dependencies:
>\     - that 'addr -1 ALLOCATE' and 'addr -1 RESIZE' will return an error
>..."
>
>But so what, GForth did "choke on it"  as it returns (0 -524) for 
>(a-addr2 ior) which indicates the operation failed, in which case 
>according to the standard
>
>14.6.1.2145 RESIZE (a-addr1 u -- a-addr2 ior)
>
>"...
>
>If the operation fails, a-addr2 equals a-addr1, the region of memory at 
>a-addr1 is unaffected, and ior is the implementation-defined I/O result 
>code"
>
>As 0 <> a-addr1 it failed the test. It doesn't seem a particularly 
>useful thing to do in this situation but that's what the standard says.

Actually, it's a lot worse than that, at least on a hosted system.
Since we do not and/or cannot know what happened on failure, we cannot
say anything about the contents of a-addr1 except to hope that the O/S
is generous.

MPE will update the five or six VFX Forths to match the standard for
v4.7, but in this case the rules of the standard are not desirable. 
Setting a-addr2 to some error code is much more useful IMHO. However,
the discussion as to the best tactics for error returns for the
memory and file access words will have to wait for the next standard
in 202x.

The other failure noted is a result of ancient history. I have already
suggested to Gerry that this test use POSTPONE.

Overall, this suite is becoming impressively comprehensive. Thanks,
Gerry.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#32994

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Mon, 04 Aug 2014 08:47:47 +0100, Gerry Jackson
><gerry@jackson9000.fsnet.co.uk> wrote:
>>14.6.1.2145 RESIZE (a-addr1 u -- a-addr2 ior)
>>
>>"...
>>
>>If the operation fails, a-addr2 equals a-addr1, the region of memory at 
>>a-addr1 is unaffected, and ior is the implementation-defined I/O result 
>>code"
>>
>>As 0 <> a-addr1 it failed the test. It doesn't seem a particularly 
>>useful thing to do in this situation but that's what the standard says.
>
>Actually, it's a lot worse than that, at least on a hosted system.
>Since we do not and/or cannot know what happened on failure, we cannot
>say anything about the contents of a-addr1 except to hope that the O/S
>is generous.

Well, if the host function you call is realloc() of a standard C
library, then you can say something about the contents of a-addr1:

The POSIX specification (which is aligned with ISO C for this
function) on realloc() says:

|If the space cannot be allocated, the object shall remain unchanged.

<http://pubs.opengroup.org/onlinepubs/009695399/functions/realloc.html>

So it's easy to implement RESIZE as specified on top of a standard
realloc().

>MPE will update the five or six VFX Forths to match the standard for
>v4.7, but in this case the rules of the standard are not desirable. 
>Setting a-addr2 to some error code is much more useful IMHO.

Why?  We have ior for the error code.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#32997

On Thu, 21 Aug 2014 16:20:51 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>>MPE will update the five or six VFX Forths to match the standard for
>>v4.7, but in this case the rules of the standard are not desirable. 
>>Setting a-addr2 to some error code is much more useful IMHO.
>
>Why?  We have ior for the error code.

On most processors we have to do
  ?DUP IF ... THEN
which is nasty bot in terms of stack effect an of code
generation, whereas
  IF ... THEN
is cleaner.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#33004

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Thu, 21 Aug 2014 16:20:51 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>MPE will update the five or six VFX Forths to match the standard for
>>>v4.7, but in this case the rules of the standard are not desirable. 
>>>Setting a-addr2 to some error code is much more useful IMHO.
>>
>>Why?  We have ior for the error code.
>
>On most processors we have to do
>  ?DUP IF ... THEN
>which is nasty bot in terms of stack effect an of code
>generation, whereas
>  IF ... THEN
>is cleaner.

Could you give a more complete example?  I still fail to see how an
error code for a-addr2 would help.  Also, how is that dependent on the
processor?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#33011

In article <2014Aug21.182051@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>stephenXXX@mpeforth.com (Stephen Pelc) writes:
<SNIP>
>
>>MPE will update the five or six VFX Forths to match the standard for
>>v4.7, but in this case the rules of the standard are not desirable.
>>Setting a-addr2 to some error code is much more useful IMHO.
>
>Why?  We have ior for the error code.

I too would opt for the address to be don't care in that case.

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#33002

On 21/08/2014 17:01, Stephen Pelc wrote:

[...]

>
> The other failure noted is a result of ancient history. I have already
> suggested to Gerry that this test use POSTPONE.

I remember and this refers to [COMPILE]. Yes in an application you would 
most likely replace [COMPILE] with POSTPONE but this is a test program 
testing [COMPILE] so it doesn't make sense to replace it with POSTPONE, 
which is tested elsewhere.

The tests concerned are:

T{ : [cif] [COMPILE] IF ; IMMEDIATE -> }T
T{ : [c3] [cif] 111 ELSE 222 THEN ; -> }T
T{ -1 [c3] -> 111 }T
T{  0 [c3] -> 222 }T

That's valid use of [COMPILE] isn't it?

Surely there's a good case for removing [COMPILE] from Forth 200X, or at 
least declaring it obsolescent. According to D6.7 of the ANS Forth 
standard cases where [COMPILE] cannot be simply replaced by POSTPONE 
were rare (presumably non-existent for VFX Forth users) so we should be 
able to get rid of it. Any volunteers for an RfD?

>
> Overall, this suite is becoming impressively comprehensive. Thanks,
> Gerry.

Thanks to James Bowman for most of the recent additions. I've a locals 
test program that needs tidying up when I get time. I ought to add tests 
for Forth 200X words, many of which already exist in the RfDs, but it's 
time and test programs aren't the most interesting things to write!


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#33003

on 22/08/2014 12:28:04, Gerry Jackson wrote:

> 
> Surely there's a good case for removing [COMPILE] from Forth 200X, or
> at least declaring it obsolescent. According to D6.7 of the ANS Forth

D6.7? My copy dated 9th November, 2013 stops at D.5.

> standard cases where [COMPILE] cannot be simply replaced by POSTPONE
> were rare (presumably non-existent for VFX Forth users) so we should
> be able to get rid of it. Any volunteers for an RfD?
> 

I'd like to see it obsoleted. Meeting the requirements of the standard
are made difficult because of the requirement to work out if <name> has
"other than default compilation semantics". Not all systems can answer
that question.

[toc] | [prev] | [next] | [standalone]

#33009

On 22/08/2014 13:35, Alex McDonald wrote:
> on 22/08/2014 12:28:04, Gerry Jackson wrote:
>
>>
>> Surely there's a good case for removing [COMPILE] from Forth 200X, or
>> at least declaring it obsolescent. According to D6.7 of the ANS Forth
>
> D6.7? My copy dated 9th November, 2013 stops at D.5.

I think you're looking at the last Forth 200X draft whereas I was 
referring to the 1994 ANS document. Annex D from the 1994 doc has been 
omitted from the Forth 200X doc.


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#33005

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 21/08/2014 17:01, Stephen Pelc wrote:
>
>[...]
>
>>
>> The other failure noted is a result of ancient history. I have already
>> suggested to Gerry that this test use POSTPONE.
>
>I remember and this refers to [COMPILE]. Yes in an application you would 
>most likely replace [COMPILE] with POSTPONE but this is a test program 
>testing [COMPILE] so it doesn't make sense to replace it with POSTPONE, 
>which is tested elsewhere.
>
>The tests concerned are:
>
>T{ : [cif] [COMPILE] IF ; IMMEDIATE -> }T
>T{ : [c3] [cif] 111 ELSE 222 THEN ; -> }T
>T{ -1 [c3] -> 111 }T
>T{  0 [c3] -> 222 }T
>
>That's valid use of [COMPILE] isn't it?

It's standard-compliant, yes.

>Surely there's a good case for removing [COMPILE] from Forth 200X, or at 
>least declaring it obsolescent.

I certainly have not felt an need for [COMPILE] since Forth-94.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#32841

mhx@iae.nl wrote:

> On Monday, August 4, 2014 12:34:27 AM UTC+2, Gerry wrote:
>> I've just updated version 0.10 of the ANS Forth test program suite to
>> the FLAG web-site http://soton.mpeforth.com/flag/anstests/index.html
>> 
>> Using Windows 7 (32 bit) the only Forth system that passed all tests
>> with no errors was Swiftforth. The maintainers of GForth, VFX Forth,
>> iForth and Win32 Forth might like to try running the tests.
> 
> From the page:
> "As can be seen GForth failed one test."
> 
> I don't think it failed that one. The writer of the test *assumed* that
> -1 (or the largest unsigned number) is so large that RESIZE would choke
> on it.

The current development version doesn't fail that test, it returns addr2 
-524, not 0 -524.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#32854

On 04/08/2014 13:26, Bernd Paysan wrote:
> mhx@iae.nl wrote:
>
>> On Monday, August 4, 2014 12:34:27 AM UTC+2, Gerry wrote:
>>> I've just updated version 0.10 of the ANS Forth test program suite to
>>> the FLAG web-site http://soton.mpeforth.com/flag/anstests/index.html
>>>
>>> Using Windows 7 (32 bit) the only Forth system that passed all tests
>>> with no errors was Swiftforth. The maintainers of GForth, VFX Forth,
>>> iForth and Win32 Forth might like to try running the tests.
>>
>>  From the page:
>> "As can be seen GForth failed one test."
>>
>> I don't think it failed that one. The writer of the test *assumed* that
>> -1 (or the largest unsigned number) is so large that RESIZE would choke
>> on it.
>
> The current development version doesn't fail that test, it returns addr2
> -524, not 0 -524.
>

In that case, provided errors haven't been introduced, GForth joins 
Swiftforth as the only systems passing all tests.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#32855

On Tuesday, August 5, 2014 9:35:39 AM UTC-7, Gerry wrote:
> In that case, provided errors haven't been introduced, GForth joins 
> Swiftforth as the only systems passing all tests.

When I wrote my novice package, I found bugs in every Forth system that I tested it on (I haven't tried VFX yet, but will try it for the next novice package release) --- the whole novice package is just a big collection of work-arounds for bugs in the Forth systems and bad design in ANS-Forth itself. 

For example, you can't tick semicolon in Gforth. Anton Ertl explained this away with a lot of hand-waving --- he said that I had no reason to expect all words to have xt values, and that some of them don't. WTF??? But the upshot is that I'm a bad Forth programmer because wrote the novice package and got it to work, but those who don't write any code at all get to be big experts.

This reminds me of a poster I once saw describing the 10 steps that a software project goes through. Step #1 was: "Wild enthusiasm and eagerness to get started." It goes downhill from there. Steps #8, #9 and #10 are: "A search for the guilty," "A persecution of the innocent," and "Fame and glory for the non-participants." I don't have the poster anymore --- I don't remember what all of the other steps were --- but ANS-Forth seems to have settled into these latter steps.

Anyway, I don't put any stock in these test 
suites. I don't think ANS-Forth is a good choice for professional programming because the programmer is going to run into bugs and get bogged down. What is the point of a test suite when the ANS-Forth document repeatedly says that something may be this or may be that? Is the test suite going to test both forks? They're contradictory!!! A program can't be both this and that --- and there are multiple forks like this --- so, thanks to exponential growth, there is the possibility of quite a lot of compliant ANS-Forth systems all of which contradict each other.

[toc] | [prev] | [next] | [standalone]

#32864

On Tue, 05 Aug 2014 23:06:39 -0400, <hughaguilar96@yahoo.com> wrote:

> When I wrote my novice package, I found bugs in every
> Forth system that I tested it on (I haven't tried VFX
> yet, but will try it for the next novice package release)
> --- the whole novice package is just a big collection of
> work-arounds for bugs in the Forth systems and bad design
> in ANS-Forth itself.

LOL!  That's truly funny.  Sigh, I'll probably have to
explain why ...

You're always talking about how great your novice package
is, but today, you just admitted that you coded up a bunch
of crap.  Of course, you're blaming all that crap on the
faults of other systems, but that doesn't change the fact
you just admitted to coding a bunch of crap.

Sometimes, I wonder if you find humor in posting stupid stuff
just to see if anyone here is smart enough to recognize it.

> Anyway, I don't put any stock in these test suites.

What?!?  Dude, sometimes you're so irrational it's unreal.

The test suites you just riled against are the only thing
that is helping to eliminate your two complaints:

1) "work-arounds for bugs in the Forth systems"
2) "bad design in ANS-Forth itself"

The test suites find the bugs in Forth systems and reveal
the bad-design of ANS-Forth.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#32872

On 06/08/2014 04:06, hughaguilar96@yahoo.com wrote:
> On Tuesday, August 5, 2014 9:35:39 AM UTC-7, Gerry wrote:
>> In that case, provided errors haven't been introduced, GForth joins
>> Swiftforth as the only systems passing all tests.
>
> When I wrote my novice package, I found bugs in every Forth system that I tested it on (I haven't tried VFX yet, but will try it for the next novice package release) --- the whole novice package is just a big collection of work-arounds for bugs in the Forth systems and bad design in ANS-Forth itself..
>
> For example, you can't tick semicolon in Gforth. Anton Ertl explained this away with a lot of hand-waving --- he said that I had no reason to expect all words to have xt values, and that some of them don't. WTF??? But the upshot is that I'm a bad Forth programmer because wrote the novice package and got it to work, but those who don't write any code at all get to be big experts.
>
> This reminds me of a poster I once saw describing the 10 steps that a software project goes through. Step #1 was: "Wild enthusiasm and eagerness to get started." It goes downhill from there. Steps #8, #9 and #10 are: "A search for the guilty," "A persecution of the innocent," and "Fame and glory for the non-participants." I don't have the poster anymore --- I don't remember what all of the other steps were --- but ANS-Forth seems to have settled into these latter steps.
>
> Anyway, I don't put any stock in these test
> suites.

Well if you'd tried them you *may* have known what to avoid for 
particular systems and saved yourself time. They are very quick to run.

I don't think ANS-Forth is a good choice for professional programming 
because the programmer is going to run into bugs and get bogged down. 
What is the point of a test suite when the ANS-Forth document repeatedly 
says that something may be this or may be that? Is the test suite going 
to test both forks?
They're contradictory!!! A program can't be both this and that --- and 
there are multiple forks like this

Can you give an example of such forks and where a chain of them lead to 
exponential growth, and then perhaps I can explain what the tests do. 
Don't list 2's complement or sign+magnitude because the tests assume 2's 
complement as that's what most, if not all, modern processors use. Also, 
for floating point, whether it shares the data stack or is separate as 
these tests don't test FP. Anyway Forth 200X is going towards a separate 
stack.

--- so, thanks to exponential growth, there is the possibility of quite 
a lot of compliant ANS-Forth systems all of which contradict each other.
>


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#32875

On Thursday, August 7, 2014 2:23:45 AM UTC-7, Gerry wrote:
> On 06/08/2014 04:06, hughaguilar96@yahoo.com wrote:
> > Anyway, I don't put any stock in these test
> > suites.
> 
> Well if you'd tried them you *may* have known what to avoid for 
> particular systems and saved yourself time. They are very quick to run.

Why should I need anything other than the ANS-Forth document to learn ANS-Forth?

> What is the point of a test suite when the ANS-Forth document repeatedly 
> says that something may be this or may be that? Is the test suite going 
> to test both forks?
> They're contradictory!!! A program can't be both this and that --- and 
> there are multiple forks like this

> Can you give an example of such forks and where a chain of them lead to 
> exponential growth, and then perhaps I can explain what the tests do. 

Off the top of my head, here are a few:
1.) Locals may have their own stack or may use the return stack.
2.) Control-flow data may have its own stack or may use the data stack.
3.) Exception frame data may have its own stack, or may use the return stack.
4.) Code and data may be intermixed, or may be separate.
5.) Names may be case-sensitive or may be case-insensitive.
6.) Words may have an xt or may not have an xt at all (in which case FIND aborts).
7.) FIND may return the same xt value for a word whether used when compiling or not compiling, or may return different xt values.
8.) File names may be one format, or may be another format, depending upon the OS underneath.
9.) Various console I/O words may corrupt the ># buffer or they may not.
10.) ALIGN and ALIGNED may align, or they may not do anything.
11.) A cell may be 16-bit, 24-bit, 32-bit, 64-bit, etc..

Assuming that each of the above has 2 possibilities, that would be 2^11=2048 versions of ANS-Forth --- but several of the above have multiple possibilities, so we actually have tens of thousands of versions of ANS-Forth, and any program that assumes one particular version will not run on any other version.

To write portable ANS-Forth code (as I did in the novice package), it is necessary to assume the worst-case scenario every time. For example, I assume that the control-flow data is on the parameter stack, so in my :NAME definers I hold my working data in local variables rather than on the parameter stack. For the most part, assuming the worst-case scenario just means assuming SwiftForth --- but not always --- an example of Gforth being the worst-case scenario is that it doesn't have an xt for the semicolon, which is why I have late-binding in my MACRO: word.

All in all, the ANS-Forth standard doesn't nail anything down --- it is all up in the air like a juggler's pins: "may be this or may be that" --- I think that the chair of the ANS-Forth committee didn't know that the purpose of a standard is to standardize. It is like in the Rush song Freewill: "If you choose not to decide, you still have made a choice." Elizabeth Rather's choice was to torpedo the entire Forth language, just so that SwiftForth could be called the standard of the Forth community. 

Although everybody desperately wanted a standard, and thought that this was long overdue, we would have been better off if ANS-Forth had never come out at all and the Forthers had just continued to do their own thing --- ANS-Forth was less than zero --- a standard that made sense would have eventually coalesced on its own.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web