Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16411 > unrolled thread
| Started by | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| First post | 2012-10-17 16:56 -0500 |
| Last post | 2012-10-22 04:20 -0400 |
| Articles | 20 on this page of 89 — 23 participants |
Back to article view | Back to comp.lang.forth
FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-17 16:56 -0500
Re: FORTH Trouble--Please Show Me all2001@spambog.com (Wolfgang Allinger) - 2012-10-17 19:11 -0300
Re: FORTH Trouble--Please Show Me Mark Wills <forthfreak@gmail.com> - 2012-10-18 01:15 -0700
Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-18 05:25 -0500
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 00:14 +0200
Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-17 18:45 -0400
Re: FORTH Trouble--Please Show Me Anonymous <nobody@remailer.paranoici.org> - 2012-10-18 08:49 +0000
Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-18 15:58 -0400
Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-18 21:53 +0000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:39 -0700
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-19 23:22 -0700
Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-21 13:40 -0500
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-19 21:00 -1000
Re: FORTH Trouble--Please Show Me "A. K." <akk@nospam.org> - 2012-10-20 09:18 +0200
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 08:40 -1000
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 12:22 +0200
Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-21 08:46 -0400
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 21:08 +0200
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-18 12:29 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-17 20:24 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-19 19:46 -0400
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:46 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-20 21:03 -0400
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 15:40 -1000
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-20 18:52 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 16:27 -1000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-20 20:56 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:40 -0400
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 12:51 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 23:50 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 17:11 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl - 2012-10-22 00:19 -0700
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 00:41 -0700
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 09:31 -0500
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 08:13 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 21:40 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 13:14 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 10:41 -1000
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 23:21 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 14:27 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 14:16 -1000
Re: FORTH Trouble--Please Show Me Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-23 21:42 +0100
Re: FORTH Trouble--Please Show Me vandys@vsta.org - 2012-10-22 00:24 +0000
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:12 -0400
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 01:40 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:39 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:30 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 22:27 -0400
Re: FORTH Trouble--Please Show Me David Thompson <dave.thompson2@verizon.net> - 2012-11-04 22:18 -0500
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 15:35 +0100
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 12:22 -0700
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 12:51 -0700
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 23:40 -0700
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 12:50 +0000
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-24 09:13 -0700
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 12:31 +0000
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-26 09:58 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-21 16:24 -0700
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 02:51 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 19:55 -0500
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 03:02 +0200
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:50 -0400
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 01:03 -0700
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:12 +0000
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:08 +0000
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 18:06 +0200
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 22:14 +0200
Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-23 00:50 +0000
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-23 03:43 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-23 03:14 -0500
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 19:54 -0700
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-22 22:59 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 09:23 -0700
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 10:33 +0000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:05 -0700
Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-24 14:56 -0400
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 11:50 +0000
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 14:39 +0000
Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 15:59 +0000
Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-24 14:33 +0000
Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 14:19 +0000
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:56 -0400
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-21 22:12 -1000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:51 -0700
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 05:29 -0500
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:35 -0400
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-21 15:44 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 18:43 -0500
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:20 -0400
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2012-10-17 16:56 -0500 |
| Subject | FORTH Trouble--Please Show Me |
| Message-ID | <k5n9i1$b3a$1@dont-email.me> |
I am using FPC in the command window under Vista Home Premium. Okay, I'm *not* a wonderful FORTH programmer. I know that. But I think the following code should *not* break the interpreter... but it *does*!!! I load the code and it compiles without complaint. I do a "CLEAR-G%" and *no* complaint. Then I type in a "CLEAR-Q%"... and the FPC interpreter crashes on me. Some complaint about a bad instruction. I'm sure there are better and more efficient ways to do all the things I'm trying to do. I just want to know *why* this code is broken. (When I learn better... I will do better.) Here is the code in question: ( this is a sample program ) : cell-matrix create ( width height "name" ) over , * 2* allot does> ( x y -- addr ) dup 2+ >r @ * + 2* r> + ; : VECTOR CREATE 2* ALLOT DOES> SWAP 2* + ; 9 9 cell-matrix G% 9 9 cell-matrix Q% 7 VECTOR D% : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; : CLEAR-G% 10 0 DO 10 0 DO 0 I J G% ! LOOP LOOP ; : set-quad 316 4 5 G% ! 316 5 4 G% ! 1 3 2 Q% ! 2 6 4 Q% ! 2 3 8 Q% ! 2 5 1 Q% ! 3 7 2 Q% ! 3 2 7 Q% ! 3 6 2 Q% ! 3 2 6 Q% ! 3 1 7 Q% ! 3 7 1 Q% ! ; ( -------------------------------------------------- ) -- acer at aquaporin4 dot com
[toc] | [next] | [standalone]
| From | all2001@spambog.com (Wolfgang Allinger) |
|---|---|
| Date | 2012-10-17 19:11 -0300 |
| Message-ID | <CJ0SP7TEQoB@allinger-307049.user.uni-berlin> |
| In reply to | #16411 |
On 17 Oct 12 at group /comp/lang/forth in article k5n9i1$b3a$1@dont-email.me <numerist@aquaporin4.com> (Charles Richmond) wrote: >I am using FPC in the command window under Vista Home Premium. > >Okay, I'm *not* a wonderful FORTH programmer. I know that. But I >think the following code should *not* break the interpreter... but it >*does*!!! I load the code and it compiles without complaint. I do a >"CLEAR-G%" and *no* complaint. Then I type in a "CLEAR-Q%"... and the >FPC interpreter crashes on me. Some complaint about a bad instruction. > >I'm sure there are better and more efficient ways to do all the things >I'm trying to do. I just want to know *why* this code is broken. > >(When I learn better... I will do better.) > >Here is the code in question: > > >( this is a sample program ) > >: cell-matrix > create ( width height "name" ) over , * 2* allot > does> ( x y -- addr ) dup 2+ >r @ * + 2* r> + ; > >: VECTOR CREATE 2* ALLOT DOES> SWAP 2* + ; > >9 9 cell-matrix G% > >9 9 cell-matrix Q% [...] >: CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; >: CLEAR-G% 10 0 DO 10 0 DO 0 I J G% ! LOOP LOOP ; You declare 9x9=81 cells matrix, but scrubs 10x10 entries. CLEAR-O% clears some space of Q% too. I forgot, where FPC stores the array, but I think they were in the code area, so you overwrite some code of Q% ... make 9 0 do... or 10 10 cell-matrix.... Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit)
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-10-18 01:15 -0700 |
| Message-ID | <7c26c1a0-c61d-42c0-8710-bde1f6b156d6@b12g2000vbg.googlegroups.com> |
| In reply to | #16413 |
On Oct 17, 11:11 pm, all2...@spambog.com (Wolfgang Allinger) wrote: > On 17 Oct 12 at group /comp/lang/forth in article k5n9i1$b3...@dont-email.me > <numer...@aquaporin4.com> (Charles Richmond) wrote: > > > > > > > > >I am using FPC in the command window under Vista Home Premium. > > >Okay, I'm *not* a wonderful FORTH programmer. I know that. But I > >think the following code should *not* break the interpreter... but it > >*does*!!! I load the code and it compiles without complaint. I do a > >"CLEAR-G%" and *no* complaint. Then I type in a "CLEAR-Q%"... and the > >FPC interpreter crashes on me. Some complaint about a bad instruction. > > >I'm sure there are better and more efficient ways to do all the things > >I'm trying to do. I just want to know *why* this code is broken. > > >(When I learn better... I will do better.) > > >Here is the code in question: > > >( this is a sample program ) > > >: cell-matrix > > create ( width height "name" ) over , * 2* allot > > does> ( x y -- addr ) dup 2+ >r @ * + 2* r> + ; > > >: VECTOR CREATE 2* ALLOT DOES> SWAP 2* + ; > > >9 9 cell-matrix G% > > >9 9 cell-matrix Q% > [...] > >: CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; > >: CLEAR-G% 10 0 DO 10 0 DO 0 I J G% ! LOOP LOOP ; > > You declare 9x9=81 cells matrix, but scrubs 10x10 entries. > > CLEAR-O% clears some space of Q% too. I forgot, where FPC stores the > array, but I think they were in the code area, so you overwrite some > code of Q% ... > > make 9 0 do... or 10 10 cell-matrix.... > > Saludos (an alle Vernünftigen, Rest sh. sig) > Wolfgang > > -- > Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! > Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf > ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p > (lt. alter usenet Weisheit)- Hide quoted text - > > - Show quoted text - Indeed. It looks like the array is spilling over compiled code. That will break the linked dictionary and therefore the interpreter will fail to find words in the dictionary.
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2012-10-18 05:25 -0500 |
| Message-ID | <k5oles$3o8$1@dont-email.me> |
| In reply to | #16425 |
"Mark Wills" <forthfreak@gmail.com> wrote in message news:7c26c1a0-c61d-42c0-8710-bde1f6b156d6@b12g2000vbg.googlegroups.com... On Oct 17, 11:11 pm, all2...@spambog.com (Wolfgang Allinger) wrote: >> On 17 Oct 12 at group /comp/lang/forth in article >> k5n9i1$b3...@dont-email.me >> <numer...@aquaporin4.com> (Charles Richmond) wrote: >> >> >I am using FPC in the command window under Vista Home Premium. >> >> >Okay, I'm *not* a wonderful FORTH programmer. I know that. But I >> >think the following code should *not* break the interpreter... but it >> >*does*!!! I load the code and it compiles without complaint. I do a >> >"CLEAR-G%" and *no* complaint. Then I type in a "CLEAR-Q%"... and the >> >FPC interpreter crashes on me. Some complaint about a bad instruction. >> >> >I'm sure there are better and more efficient ways to do all the things >> >I'm trying to do. I just want to know *why* this code is broken. >> >> >(When I learn better... I will do better.) >> >> >Here is the code in question: >> >> >( this is a sample program ) >> >> >: cell-matrix >> > create ( width height "name" ) over , * 2* allot >> > does> ( x y -- addr ) dup 2+ >r @ * + 2* r> + ; >> >> >: VECTOR CREATE 2* ALLOT DOES> SWAP 2* + ; >> >> >9 9 cell-matrix G% >> >> >9 9 cell-matrix Q% >> [...] >> >: CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; >> >: CLEAR-G% 10 0 DO 10 0 DO 0 I J G% ! LOOP LOOP ; >> >> You declare 9x9=81 cells matrix, but scrubs 10x10 entries. >> >> CLEAR-O% clears some space of Q% too. I forgot, where FPC stores the >> array, but I think they were in the code area, so you overwrite some >> code of Q% ... >> > >make 9 0 do... or 10 10 cell-matrix.... > > >Saludos (an alle Vernünftigen, Rest sh. sig) > >Wolfgang > > >Indeed. It looks like the array is spilling over compiled code. That >will break the linked dictionary and therefore the interpreter will >fail to find words in the dictionary. Thanks for the help!!! Yes, last night when I was about to sleep... it came to me that I had overrun the arrays when I tried to clear them. Duh!!! I'll go away now... and slink back into my dungeon. :-) -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-18 00:14 +0200 |
| Message-ID | <57890317938435@frunobulax.edu> |
| In reply to | #16411 |
"Charles Richmond" <numerist@aquaporin4.com> writes Re: FORTH Trouble--Please Show Me [..] > Okay, I'm *not* a wonderful FORTH programmer. I know that. But I think the > following code should *not* break the interpreter... but it *does*!!! [..] > 9 9 cell-matrix G% [..] This is a 9 x 9 array. > : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; [..] And here you store 100 numbers in it. The interpreter has every right to break. I know what will happen next. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Spam@ControlQ.com |
|---|---|
| Date | 2012-10-17 18:45 -0400 |
| Message-ID | <alpine.BSF.2.00.1210171845140.25704@yoko.controlq.com> |
| In reply to | #16415 |
On Thu, 18 Oct 2012, Marcel Hendrix wrote: > This is a 9 x 9 array. > >> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; > [..] > > And here you store 100 numbers in it. > The interpreter has every right to break. > > I know what will happen next. > > -marcel > > Marcel, Perhaps you should recalibrate "The interpreter has every right to break." Don't you really mean that interpreters should support bad application code, and give meaningful error messages?? Cheers, Rob Sciuk
[toc] | [prev] | [next] | [standalone]
| From | Anonymous <nobody@remailer.paranoici.org> |
|---|---|
| Date | 2012-10-18 08:49 +0000 |
| Message-ID | <8a1b9cb790ec6b5150e22d15b4a38385@remailer.paranoici.org> |
| In reply to | #16416 |
Spam@ControlQ.com wrote: > > On Thu, 18 Oct 2012, Marcel Hendrix wrote: > > > This is a 9 x 9 array. > > > >> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; > > [..] > > > > And here you store 100 numbers in it. > > The interpreter has every right to break. > > > > I know what will happen next. > > > > -marcel > > > > > > Marcel, > > Perhaps you should recalibrate "The interpreter has every right to break." > > Don't you really mean that interpreters should support bad application > code, and give meaningful error messages?? > > Cheers, > Rob Sciuk I'm not Marcel, but I'll take this one: No, the interpreter can't do that (well it *could* on some systems but not all) any more than C can prevent you from running off the end of a string or array. If you write bad code and overlay storage, most applications are going to crash.
[toc] | [prev] | [next] | [standalone]
| From | Spam@ControlQ.com |
|---|---|
| Date | 2012-10-18 15:58 -0400 |
| Message-ID | <alpine.BSF.2.00.1210181553240.32192@yoko.controlq.com> |
| In reply to | #16427 |
On Thu, 18 Oct 2012, Anonymous wrote: > Date: Thu, 18 Oct 2012 08:49:46 +0000 (UTC) > From: Anonymous <nobody@remailer.paranoici.org> > Newsgroups: comp.lang.forth > Subject: Re: FORTH Trouble--Please Show Me > > Spam@ControlQ.com wrote: > >> >> On Thu, 18 Oct 2012, Marcel Hendrix wrote: >> >>> This is a 9 x 9 array. >>> >>>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; >>> [..] >>> >>> And here you store 100 numbers in it. >>> The interpreter has every right to break. >>> >>> I know what will happen next. >>> >>> -marcel >>> >>> >> >> Marcel, >> >> Perhaps you should recalibrate "The interpreter has every right to break." >> >> Don't you really mean that interpreters should support bad application >> code, and give meaningful error messages?? >> >> Cheers, >> Rob Sciuk > > I'm not Marcel, but I'll take this one: > > No, the interpreter can't do that (well it *could* on some systems but not > all) any more than C can prevent you from running off the end of a string or > array. If you write bad code and overlay storage, most applications are > going to crash. Admittedly, run time bounds checking has a price, but if this were under the control of a global setting, one might use a "safe" mode to debug new code, and a "fast" mode to run production code. I'm not proposing global bounds checking, but low hanging fruit like stack overflow/underflow should and could be handled this way, and perhaps dictionary and heap management should be simple to check. Indeed, forth encourages system exploration in an interactive environment, so this cannot be too restrictive ... IMHO. Rob.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-10-18 21:53 +0000 |
| Message-ID | <50807a5b$0$3146$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #16459 |
In article <alpine.BSF.2.00.1210181553240.32192@yoko.controlq.com>, <Spam@ControlQ.com> wrote: <SNIP> >Admittedly, run time bounds checking has a price, but if this were under >the control of a global setting, one might use a "safe" mode to debug new >code, and a "fast" mode to run production code. > >I'm not proposing global bounds checking, but low hanging fruit like stack >overflow/underflow should and could be handled this way, and perhaps >dictionary and heap management should be simple to check. Indeed, forth >encourages system exploration in an interactive environment, so this >cannot be too restrictive ... You missed an important point here. If you can get your arrays right with bound checking, you certainly can get them right without. If you make a mistake in the bounds checking, you're back to square one. So it makes sense for novices to use a novice package to be saved from this. The logic behind the Novice Package of Aguilar is flawless. > >IMHO. > >Rob. > Groetjes Albert
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-19 18:39 -0700 |
| Message-ID | <0df4f181-de4d-4943-8cdb-3a434cdb2a59@v11g2000pbs.googlegroups.com> |
| In reply to | #16459 |
On Oct 18, 12:58 pm, S...@ControlQ.com wrote: > On Thu, 18 Oct 2012, Anonymous wrote: > > Date: Thu, 18 Oct 2012 08:49:46 +0000 (UTC) > > From: Anonymous <nob...@remailer.paranoici.org> > > Newsgroups: comp.lang.forth > > Subject: Re: FORTH Trouble--Please Show Me > > > S...@ControlQ.com wrote: > > >> On Thu, 18 Oct 2012, Marcel Hendrix wrote: > > >>> This is a 9 x 9 array. > > >>>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; > >>> [..] > > >>> And here you store 100 numbers in it. > >>> The interpreter has every right to break. > > >>> I know what will happen next. > > >>> -marcel > > >> Marcel, > > >> Perhaps you should recalibrate "The interpreter has every right to break." > > >> Don't you really mean that interpreters should support bad application > >> code, and give meaningful error messages?? > > >> Cheers, > >> Rob Sciuk > > > I'm not Marcel, but I'll take this one: > > > No, the interpreter can't do that (well it *could* on some systems but not > > all) any more than C can prevent you from running off the end of a string or > > array. If you write bad code and overlay storage, most applications are > > going to crash. > > Admittedly, run time bounds checking has a price, but if this were under > the control of a global setting, one might use a "safe" mode to debug new > code, and a "fast" mode to run production code. > > I'm not proposing global bounds checking, but low hanging fruit like stack > overflow/underflow should and could be handled this way, and perhaps > dictionary and heap management should be simple to check. Indeed, forth > encourages system exploration in an interactive environment, so this > cannot be too restrictive ... > > IMHO. > > Rob. > > My arrays do have a compiler directive that can be set to turn on bounds checking or turn it off for better speed. This is "low-hanging fruit" --- it is easy to implement, and it helps catch bugs. Mark's suggestion of rewriting @ and ! is also good. Sometimes some data is getting corrupted and you have no idea what is corrupting it --- you can generally be pretty sure that it is a ! or C! or CMOVE however, so you can rewrite these to find your bug for you. C programmers would do this with ICE, but that is way more complicated than I care for --- I never really use symbolic debuggers, although I did write one for my 65c02 cross-compiler a long time ago when I was still a novice. I remember in MS-DOS days that soft-ICE was The technology for the 80286, but that was then --- nobody does that anymore. It is not just novices who make dumb mistakes such as forgetting that an array is 9x9 and accessing it as if it were 10x10, everybody does that. I did the exact same thing when I wrote my alien-alphabet program earlier. I solved the problem quickly enough though. This kind of mishap is typical of programming. This is why I'm unimpressed by people who talk a lot about programming theory but who never write any programs --- most of them have bumped into these problems and didn't solve them, or they took forever solving them and became frustrated --- so they stop writing programs and just focus on talking up their own expertise on forums like this. Well, I have sobering news for these self-proclaimed experts --- programming is mostly about debugging, and if you can't do this then you aren't a programmer.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-10-19 23:22 -0700 |
| Message-ID | <26f34eff-686d-4c37-8f81-3cfbd6d2aacf@b12g2000vbg.googlegroups.com> |
| In reply to | #16509 |
On Oct 20, 2:39 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: 80286, but that was then --- nobody does that anymore. > > This is why I'm unimpressed by > people who talk a lot about programming theory but who never write any > programs --- most of them have bumped into these problems and didn't > solve them, or they took forever solving them and became frustrated > --- so they stop writing programs and just focus on talking up their > own expertise on forums like this. Well, I have sobering news for > these self-proclaimed experts --- programming is mostly about > debugging, and if you can't do this then you aren't a programmer. Exactly. Or those bloody annoying articles that one reads all over the web talking about how finding bugs is really hard, and constantly developing new 'stuff' (languages) to "solve" the "problem". "Yeah we found that language X was too difficult to debug, so we made language Y" <a year later> "Yeah we found that language Y was too difficult to debug, so we made language Z" Of course, Z is no better than Y or X. But it doesn't suffer from the "not invented here" syndrome, so it is "better". You know what? STFU. Man up. Study your code, and fix it. Oh, and comment your code properly. Give yourself and others a chance!
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2012-10-21 13:40 -0500 |
| Message-ID | <k61fi9$bpq$1@dont-email.me> |
| In reply to | #16509 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:0df4f181-de4d-4943-8cdb-3a434cdb2a59@v11g2000pbs.googlegroups.com... On Oct 18, 12:58 pm, S...@ControlQ.com wrote: > >It is not just novices who make dumb mistakes such as forgetting that >an array is 9x9 and accessing it as if it were 10x10, everybody does >that. I did the exact same thing when I wrote my alien-alphabet >program earlier. I solved the problem quickly enough though. This kind >of mishap is typical of programming. This is why I'm unimpressed by >people who talk a lot about programming theory but who never write any >programs --- most of them have bumped into these problems and didn't >solve them, or they took forever solving them and became frustrated >--- so they stop writing programs and just focus on talking up their >own expertise on forums like this. Well, I have sobering news for >these self-proclaimed experts --- programming is mostly about >debugging, and if you can't do this then you aren't a programmer. It's the infamous off-by-one error. With loops, that off-by-one gets *multiplied*! :-) "To err is human; it takes a computer to really foul things up." -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-19 21:00 -1000 |
| Message-ID | <4aGdnR49buK50R_NnZ2dnUVZ_sKdnZ2d@supernews.com> |
| In reply to | #16459 |
On 10/18/12 9:58 AM, Spam@ControlQ.com wrote: > On Thu, 18 Oct 2012, Anonymous wrote: > >> Date: Thu, 18 Oct 2012 08:49:46 +0000 (UTC) >> From: Anonymous <nobody@remailer.paranoici.org> >> Newsgroups: comp.lang.forth >> Subject: Re: FORTH Trouble--Please Show Me >> >> Spam@ControlQ.com wrote: >> >>> >>> On Thu, 18 Oct 2012, Marcel Hendrix wrote: >>> >>>> This is a 9 x 9 array. >>>> >>>>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; >>>> [..] >>>> >>>> And here you store 100 numbers in it. >>>> The interpreter has every right to break. >>>> >>>> I know what will happen next. >>>> >>>> -marcel >>>> >>>> >>> >>> Marcel, >>> >>> Perhaps you should recalibrate "The interpreter has every right to >>> break." >>> >>> Don't you really mean that interpreters should support bad application >>> code, and give meaningful error messages?? >>> >>> Cheers, >>> Rob Sciuk >> >> I'm not Marcel, but I'll take this one: >> >> No, the interpreter can't do that (well it *could* on some systems but >> not >> all) any more than C can prevent you from running off the end of a >> string or >> array. If you write bad code and overlay storage, most applications are >> going to crash. > > Admittedly, run time bounds checking has a price, but if this were under > the control of a global setting, one might use a "safe" mode to debug > new code, and a "fast" mode to run production code. > > I'm not proposing global bounds checking, but low hanging fruit like > stack overflow/underflow should and could be handled this way, and > perhaps dictionary and heap management should be simple to check. > Indeed, forth encourages system exploration in an interactive > environment, so this cannot be too restrictive ... This whole thing is a great lesson in good programming strategy. It is poor strategy to use as many literal values as Charles has. If you define a SIZE constant for your array and use it, it's easy to avoid overruns. If you use the CELL-words instead of 2* etc. for conversions, your code will be easier to port to a 32-bit environment. The basic commandment (not specific to Forth) is "avoid 'magic' numbers" meaning literals that should really be a named and reused value. And I see no reason why the interpreter should have figured this out. The program crashed. That's a great diagnostic. Crashed programs are (in human interface terms) far more useful in getting you to pay attention to coding strategy than error messages, which are much too easy to ignore. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "A. K." <akk@nospam.org> |
|---|---|
| Date | 2012-10-20 09:18 +0200 |
| Message-ID | <5082503d$0$6642$9b4e6d93@newsspool2.arcor-online.net> |
| In reply to | #16513 |
On 20.10.2012 09:00, Elizabeth D. Rather wrote: > And I see no reason why the interpreter should have figured this out. > The program crashed. That's a great diagnostic. Crashed programs are (in > human interface terms) far more useful in getting you to pay attention > to coding strategy than error messages, which are much too easy to ignore. > Okay for the development process, but not okay for productive systems. You can't leave a system in an undefined state following a crash. An exception handling process and outputting diagnostic information is nearly always a must.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-20 08:40 -1000 |
| Message-ID | <paSdnWIi0ruDbR_NnZ2dnUVZ_tKdnZ2d@supernews.com> |
| In reply to | #16514 |
On 10/19/12 9:18 PM, A. K. wrote: > On 20.10.2012 09:00, Elizabeth D. Rather wrote: >> And I see no reason why the interpreter should have figured this out. >> The program crashed. That's a great diagnostic. Crashed programs are (in >> human interface terms) far more useful in getting you to pay attention >> to coding strategy than error messages, which are much too easy to >> ignore. >> > > Okay for the development process, but not okay for productive systems. > > You can't leave a system in an undefined state following a crash. > An exception handling process and outputting diagnostic information is > nearly always a must. > The primary causes of exceptions in a production system, assuming that system was thoroughly tested before deployment, are inappropriate or invalid input caused by user error or faulty equipment. Checking input is always an imperative, and appropriate response to erroneous input should be an element in the system's design. Input should be checked at the point at which it enters the system, so that redundant internal checks can be safely avoided. Charles' problem was a program bug. Program bugs that cause the system to crash, as this one, are easily detected and repaired, and can be avoided by good programming practice such as I was recommending. Program bugs that don't cause crashes need to be eradicated through pre-deployment testing. Cheers, elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-21 12:22 +0200 |
| Message-ID | <04139114938435@frunobulax.edu> |
| In reply to | #16459 |
Spam@ControlQ.com writes Re: FORTH Trouble--Please Show Me > On Thu, 18 Oct 2012, Anonymous wrote: [..] >>> Perhaps you should recalibrate "The interpreter has every right to break." >>> >>> Don't you really mean that interpreters should support bad application >>> code, and give meaningful error messages?? [..] > Admittedly, run time bounds checking has a price, but if this were under > the control of a global setting, one might use a "safe" mode to debug new > code, and a "fast" mode to run production code. The Forth language specification does not define arrays. How do you let the interpreter do automatic bounds checking then? In my experience bounds checks for ordinary variables is not needed when one uses (F)(D)X)(Z)VALUEs instead (i.e the type can be a problem more than the index). Programmers that have trouble with out-of-bounds accesses are advised to write their array code including checks. "Safe" array definers are one of the most published (and least used) code snippets in Forth. > I'm not proposing global bounds checking, but low hanging fruit like stack > overflow/underflow should and could be handled this way, and perhaps > dictionary and heap management should be simple to check. Indeed, forth > encourages system exploration in an interactive environment, so this > cannot be too restrictive ... > IMHO. If you check out a few modern Forths, you will notice that they already do all of what you propose above (and more)? A long time ago I proposed that Forthers post all the silly mistakes they make when writing something new (or debugging/using something old). Unfortunately there were no reactions. Most bugs that I make myself are related to specifications (unclear, or incomplete, or too difficult/timeconsuming to get right for the first version). There is also a large number of problems related to interfacing with other programs or the OS (e.g. a file that is written by A that must be opened by B but the OS/A takes its time to really write it). A very large number of bugs (and very murky code) is related to trying to make a program run on both Windows and Linux, or to support interfaces to more than one external program (e.g. both LTSpice and NGSpice, or both sockets and pipes, or FORTRAN and C-style interfacing). It seems to be generally better to write the program in a very modular way for one situation and then port it to the other ones. However, at some point you do the port, and maintainance/upgrading doesn't work that way. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-10-21 08:46 -0400 |
| Message-ID | <5083eeb9$0$283$14726298@news.sunsite.dk> |
| In reply to | #16536 |
On 10/21/12 6:22 AM, Marcel Hendrix wrote: > Programmers that have trouble with out-of-bounds accesses are advised to > write their array code including checks. The original poster had no idea that was his problem. Chicken and egg? > "Safe" array definers are > one of the most published (and least used) code snippets in Forth. Interesting statement given the original post. But you're right, he didn't use it (and likely wishes he had). -Doug
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-18 21:08 +0200 |
| Message-ID | <60951417938435@frunobulax.edu> |
| In reply to | #16416 |
Spam@ControlQ.com writes Re: FORTH Trouble--Please Show Me
> On Thu, 18 Oct 2012, Marcel Hendrix wrote:
>> This is a 9 x 9 array.
>>
>>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ;
>> [..]
>>
>> And here you store 100 numbers in it.
>> The interpreter has every right to break.
>>
[..]
> Perhaps you should recalibrate "The interpreter has every right to break."
I should have said "Under no conditions the interpreter should try to cover
up obvious mistakes -- I want to know about them as soon as possible."
> Don't you really mean that interpreters should support bad application
> code, and give meaningful error messages??
You can make high-level Forth do anything you want. However, the code
as written is extremely low-level:
: cell-matrix
create ( width height "name" ) over , * cells allot
does> ( x y -- addr ) dup cell+ >r @ * + cells r> + ;
This is not the code of a beginner. It can not be designed by a programmer
who has no notion of how memory is layed out, and also shows mastering
of the stack. In such a case and for such a user the Forth interpreter
should do EXACTLY what it is told. Any problems with this code should be
caught 1 second after it is written, during the first interactive tests
with DUMP etc.
Alternatively I could say that this is not application code. The word will
be hidden deep into something else and the top-level code will take care of
catching any (range or datatype) errors. As it is not application code, it
is not bad, and needs no safety-net.
Meaningful (that's not the same for everybody) error messages would be nice.
FORTH> 99 0 !
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = $0000000001131203
RAX = $01142E30 RBX = $00000000
RCX = $00000000 RDX = $00000041
RSI = $01045C00 RDI = $0140079A
RBP = $01025F88 RSP = $094AF820
R8 = $00000000 R9 = $010124B8
R10 = $00FD5BD0 R11 = $0501FC00
R12 = $00FD84E0 R13 = $01047000
R14 = $01036000 R15 = $01010000
Hardware exception in ``!''+$0000000B
**** RETURN STACK DUMP ****
But the hardware does not / cannot protect when we store to an address
in user memory -- there are no "good" or "bad" addresses there, we are
entitled and even encouraged (by the language) to access them all and
do anything we want with them.
I guess that what you mean is that the code is allowed to crash,
but there must be a host of diagnostics when that happens. I agree.
It would be nice to have a monitor that can protect an arbitrary block
of memory and shows the source code of any word that tries to store or
fetch there. (I can do this by starting the Forth interpreter within
Visual studio, get the adresses I need by poking around, exit to the
debugger, set breakpoints and monitors, re-enter Forth and run my code
at full speed, waiting until the debugger finds something. Piece of
cake but used maybe once every 10 years.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-10-18 12:29 -0700 |
| Message-ID | <642391e8-fd33-4a6f-a599-b0684227571d@ib4g2000vbb.googlegroups.com> |
| In reply to | #16448 |
On Oct 18, 8:08 pm, m...@iae.nl (Marcel Hendrix) wrote: > S...@ControlQ.com writes Re: FORTH Trouble--Please Show Me > > > > > On Thu, 18 Oct 2012, Marcel Hendrix wrote: > >> This is a 9 x 9 array. > > >>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ; > >> [..] > > >> And here you store 100 numbers in it. > >> The interpreter has every right to break. > > [..] > > Perhaps you should recalibrate "The interpreter has every right to break." > > I should have said "Under no conditions the interpreter should try to cover > up obvious mistakes -- I want to know about them as soon as possible." > > > Don't you really mean that interpreters should support bad application > > code, and give meaningful error messages?? > > You can make high-level Forth do anything you want. However, the code > as written is extremely low-level: > > : cell-matrix > create ( width height "name" ) over , * cells allot > does> ( x y -- addr ) dup cell+ >r @ * + cells r> + ; > > This is not the code of a beginner. It can not be designed by a programmer > who has no notion of how memory is layed out, and also shows mastering > of the stack. In such a case and for such a user the Forth interpreter > should do EXACTLY what it is told. Any problems with this code should be > caught 1 second after it is written, during the first interactive tests > with DUMP etc. > > Alternatively I could say that this is not application code. The word will > be hidden deep into something else and the top-level code will take care of > catching any (range or datatype) errors. As it is not application code, it > is not bad, and needs no safety-net. > > Meaningful (that's not the same for everybody) error messages would be nice. > > FORTH> 99 0 ! > Caught exception 0xc0000005 > ACCESS VIOLATION > instruction pointer = $0000000001131203 > RAX = $01142E30 RBX = $00000000 > RCX = $00000000 RDX = $00000041 > RSI = $01045C00 RDI = $0140079A > RBP = $01025F88 RSP = $094AF820 > R8 = $00000000 R9 = $010124B8 > R10 = $00FD5BD0 R11 = $0501FC00 > R12 = $00FD84E0 R13 = $01047000 > R14 = $01036000 R15 = $01010000 > Hardware exception in ``!''+$0000000B > **** RETURN STACK DUMP **** > > But the hardware does not / cannot protect when we store to an address > in user memory -- there are no "good" or "bad" addresses there, we are > entitled and even encouraged (by the language) to access them all and > do anything we want with them. > > I guess that what you mean is that the code is allowed to crash, > but there must be a host of diagnostics when that happens. I agree. > > It would be nice to have a monitor that can protect an arbitrary block > of memory and shows the source code of any word that tries to store or > fetch there. (I can do this by starting the Forth interpreter within > Visual studio, get the adresses I need by poking around, exit to the > debugger, set breakpoints and monitors, re-enter Forth and run my code > at full speed, waiting until the debugger finds something. Piece of > cake but used maybe once every 10 years. > > -marcel In Forth one can simply re-define @ and ! have them trap/abort if they access a memory area that is unexpected. Nice!
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-17 20:24 -0700 |
| Message-ID | <2017da18-ac49-4b0e-bec1-5ceffff9435e@pz10g2000pbb.googlegroups.com> |
| In reply to | #16411 |
On Oct 17, 2:56 pm, "Charles Richmond" <numer...@aquaporin4.com> wrote: > I'm sure there are better and more efficient ways to do all the things I'm > trying to do. I just want to know *why* this code is broken. > > (When I learn better... I will do better.) I recommend against implementing data structures as a way to learn Forth. I recommend that you write application programs in Forth first, and tinker with the language later on only *after* gaining some practical experience. You can use my novice package: http://www.forth.org/novice.html You get arrays and lists and associative arrays, and a lot of other stuff that is useful for writing programs.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web