Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15684 > unrolled thread
| Started by | "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| First post | 2012-09-15 22:28 +0100 |
| Last post | 2012-10-15 18:00 -0400 |
| Articles | 20 on this page of 143 — 26 participants |
Back to article view | Back to comp.lang.forth
Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-09-15 22:28 +0100
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-09-18 02:08 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-18 11:58 +0000
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-09-18 05:55 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-19 12:50 +0000
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-06 01:40 -0700
Re: Olympic Spririt for Forth "A. K." <akk@nospam.org> - 2012-10-06 11:18 +0200
Re: Olympic Spririt for Forth Spam@ControlQ.com - 2012-09-18 11:13 -0400
Re: Olympic Spririt for Forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-19 15:56 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-09-29 00:56 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-09-30 12:31 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 11:53 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-09-30 17:38 -0400
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-02 04:16 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-02 10:52 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-02 20:20 +0200
Re: Olympic Spririt for Forth Spam@ControlQ.com - 2012-10-02 15:58 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-02 13:31 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 02:59 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-02 19:08 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 15:50 +0200
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-03 14:04 +0000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 10:29 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-04 16:07 +0000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 20:27 +0200
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-04 16:11 +0000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-04 20:12 +0200
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-05 13:08 +0000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-05 17:48 +0200
Re: Olympic Spririt for Forth Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-03 07:39 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 20:24 +0200
Re: Olympic Spririt for Forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-03 18:13 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 12:05 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 22:20 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 12:41 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-04 22:40 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 18:11 -0700
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-04 15:26 -1000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 18:54 -0700
Re: Olympic Spririt for Forth "A. K." <akk@nospam.org> - 2012-10-05 08:19 +0200
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-04 22:18 -1000
Re: Olympic Spririt for Forth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-05 08:20 +0100
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-05 11:08 +0000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 08:32 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-07 21:39 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 21:03 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 19:09 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-08 21:57 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:10 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-09 14:12 -0400
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-10 09:29 +0100
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-10 21:13 -0400
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-10 02:02 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-10 21:23 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 18:24 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-11 17:21 +0000
Re: Olympic Spririt for Forth Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-11 12:33 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-11 13:42 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-11 18:59 -0400
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-11 13:49 -1000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-12 03:27 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-12 19:18 -0700
Re: Olympic Spririt for Forth Elizabeth D Rather <erather@forth.com> - 2012-10-12 18:53 -1000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-12 22:55 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-13 22:07 +0200
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-13 00:56 -0400
Re: Olympic Spririt for Forth Doug Hoffman <glidedog@gmail.com> - 2012-10-13 18:41 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-13 16:05 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 02:57 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-14 00:26 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 19:28 +0200
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-15 04:21 -0500
Re: Olympic Spririt for Forth Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-14 03:17 -0700
Re: Olympic Spririt for Forth Alex McDonald <blog@rivadpm.com> - 2012-10-14 15:43 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-14 21:18 -0400
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-15 04:21 -0500
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-15 10:03 +0000
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-15 04:04 -0700
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-15 21:34 +0100
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 17:51 -0400
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-16 01:09 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-16 02:15 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-16 02:30 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-16 15:18 -0400
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-14 21:05 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-14 18:19 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 17:58 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-15 15:21 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 18:51 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-15 17:20 -0700
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-12 22:41 +0100
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-12 22:24 +0100
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:20 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-09 08:56 -0700
Re: Olympic Spririt for Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-09 11:14 -0500
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-09 22:47 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-09 18:31 -0700
Re: Olympic Spririt for Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-09 22:55 -0500
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:04 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-09 17:30 +0200
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-04 11:31 -1000
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-03 16:53 -0500
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 16:50 -0700
Re: Olympic Spririt for Forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-03 18:06 -0700
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-03 16:53 -0500
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-03 00:38 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 02:06 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-03 03:38 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 13:40 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-04 01:00 -0700
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-03 22:32 -1000
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-04 04:49 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-04 01:35 -0700
Re: Olympic Spririt for Forth Howerd <howerdo@yahoo.co.uk> - 2012-10-06 06:17 -0700
Re: Olympic Spririt for Forth arc <arc.deletethis@vorsicht-bissig.de> - 2012-10-07 23:45 +1300
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-10 09:34 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-10 12:16 -0700
Re: Olympic Spririt for Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-10 20:04 -0500
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 11:41 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-05 12:29 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-06 19:26 -0700
Re: Olympic Spririt for Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-05 19:09 +0000
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-02 22:03 +0100
Re: Olympic Spririt for Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2012-10-06 08:30 -0700
Re: Olympic Spririt for Forth ilya74.tarasov@gmail.com - 2012-09-29 07:09 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-09 14:30 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-09 18:27 -0400
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-10 09:46 +0100
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-10 03:52 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 06:01 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-10 07:42 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-10 09:10 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 10:34 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-11 17:17 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-13 01:03 -0400
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-10 21:59 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 20:57 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-11 02:05 -0700
Re: Olympic Spririt for Forth Matthias Koch <koch@pci.uni-hannover.de> - 2012-10-15 11:20 +0200
Re: Olympic Spririt for Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-15 11:53 +0000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-15 08:52 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-15 11:53 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 18:00 -0400
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-04 22:18 -1000 |
| Message-ID | <u4-dncJPoupYCvPNnZ2dnUVZ_qydnZ2d@supernews.com> |
| In reply to | #15938 |
On 10/4/12 3:54 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> A data type check certainly doesn't guarantee you've got the "right >> stuff." > > This was about stack effect, or correspondingly (in other languages) > making sure that the caller passed the right number of args to the > callee. Since DEPTH returns the number of things on the stack, you could test that. However, since the actual stack depth at any point is context-dependent (i.e., you never know which things on the stack are actually parameters for other words, not *this* one), that is strictly a early-stage debugging tool. But this is why many systems (including SwiftForth, SwiftX, etc.) have stack-monitoring facilities. In early-stage testing, if you have a word that is misbehaving you can type your way through it or use a stepper and watch the stack behavior. Such tools are "quality of implementation" issues, not language issues. >> I realize that programmers who have felt comforted by syntax/data type >> checking compilers feel a little naked getting used to Forth, but with >> a little experience you'll understand the Forth programming/testing >> cycle and feel more comfortable. > > I've written enough C code in my life to appreciate the difference > between having to find the bug by examining the state of memory with > gdb, and having the Python (etc.) interpreter tell me "wrong number of > args at line 237, called from line 415", showing the source code at each > of those two lines. I see the mismatch, say "oops" and fix the code. > (# of args isn't a good example of this, since C checks that statically, > but you get the idea). Different Forths have different programming aids, as I said above. I suggest you evaluate several different systems as regards programming aids. 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2012-10-05 08:20 +0100 |
| Message-ID | <k4m1ni$hn7$1@dont-email.me> |
| In reply to | #15936 |
On 05/10/2012 02:11, Paul Rubin wrote:
>> I try to make these modifications one little piece at a time, and then
>> test it, as well.
>
> OK, so you make a small modification and create a bug, which makes your
> test fail. What now? You have to figure out the cause of the bug.
> And, I think, this is much easier in a (runtime) type-checked and
> bounds-checked language, than something like Forth.
This is made easier by using a test file - see below
>
>> look at John Hayes ttester (in Gforth under test/ttester.fs;
>> require test/ttester.fs
>> : bounds ( addr len -- last first ) over + swap ;
>> t{ 3 5 bounds -> 8 3 }t
>
> Oh this is nice, and I didn't know about it. I'm going to start
using it.
>
Even better are further developments of it by David Williams and Josh
Grams. See
http://www-personal.umich.edu/~williams/archive/forth/utilities/xtester.fs
and associated files and
http://qualdan.com/forth/flex-tester-2012-05-30.tar.gz
These were written for application program development rather than Forth
system testing which was the original aim of the Hayes tester.
Like some others I routinely use a tester like this when writing a
program larger than a few words that I intend to maintain and use. After
all you only have to type a simple test once into a text file instead of
continually typing the same thing when manually testing at the keyboard.
Then just start the Forth up with a command line that includes the test
file - a simple double click in an IDE.
If such a test program is continually added to during development, you
have a regression test available when you've finished. This test program
can then be provided with the program for users e.g. see files
dstrings.fs and dstrings-test.fs at
www-personal.umich.edu/~williams/archive/forth/strings/
dstrings is a strings package with garbage collection - something you
mentioned as being desirable.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-05 11:08 +0000 |
| Message-ID | <2012Oct5.130829@mips.complang.tuwien.ac.at> |
| In reply to | #15936 |
Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> 4 red arms
>> green cylinder body
>> 4 black wheels
>>
>> Is this a data structure or a program? I don't know, I don't care. To
>> draw the robot, you have to interpret the data structure or to execute
>> the program.
>
>I'd rather that it be data since then I can write code to interpret the
>data in multiple ways, and it helps to be able to write data before
>starting to write code. E.g. in Python:
>
>programmers = [
> {'name':'Bernd' 'languages':['Forth','C']},
> {'name':'Elizabeth','languages':['Forth','Fortran']},
> {'name':'Paul','languages':['Python','Forth']}
>]
>
>I can type that directly into Python and have it create a nested data
>structure, without having to write and debug any specialized code.
This reminds me of what I do with data in charts written in Postscript.
In simple cases, the data is interpreted directly and drawn right away:
%trad
1
3040561373
3042635978
3043166570
3 copy median3 /scalefactor swap def
median3point mt
%doprims
3106897257
3103339195
3106836628
median3point lt
In more complex cases I put the data in arrays and drawn them later:
/compress
[ 0.0
0.0
29.3
41.5
29.3
0.0
0.0
] def
...
[ /compress /jess /db /javac /mpegaudio /mtrt /jack ]
{ << /bench rot >> begin bars end } forall
Finally, I put the data in procedures that can be used to draw things
or build arrays from the data several times in different ways, if
needed:
/core2 { %smaug
[
100383730 event0x0041008D@0
5370 event0x0041008E@1
5638338384 event0x00410000@0x40000000
3251152763 event0x00410000@0x40000001
100381820 event0x0041008D@0
5180 event0x0041008E@1
1638276480 event0x00410000@0x40000000
840453768 event0x00410000@0x40000001
(primitive) oneword
2400384720 event0x0041008D@0
300006874 event0x0041008E@1
7938302989 event0x00410000@0x40000000
9241083370 event0x00410000@0x40000001
400381976 event0x0041008D@0
5822 event0x0041008E@1
1938271683 event0x00410000@0x40000000
940217000 event0x00410000@0x40000001
(code-def) oneword
...
] /default oneforth
....
} def
/scalefactor 2000000000 def
/oneforth {load exec} def
/oneword {drop sub scalefactor div} def
%select none by default, later change one event and one forth from default
/event0x0041008D@0 {drop} def
/event0x0041008E@1 {drop} def
/event0x00410000@0x40000000 {drop} def
/event0x00410000@0x40000001 {drop} def
/tsc {drop} def
/event0x004100C0 {drop} def
/event0x004100C4 {drop} def
/event0x004100C5 {drop} def
...
<< /results {core2} /event0x00410000@0x40000000 {} >> bars
This selects the event0x00410000@0x40000000 records from the data and
draws a set of bars (for a bar chart). I guess I had to write _and
debug_ all these event* procedures before running the program
successfully. So what. The actual work was elsewhere.
These three steps are actually the evolution of how I write these
charts. The main driver here was to minimize the manual work for
integrating the data coming out of my measurement scripts into the
charts.
>If I'm supposed to implement such stuff myself, why do I want your
>toolkit in the first place? Obviously as a FOSS user I want to be able
>to extend the toolkit as a last resort, and obviously in the first
>releases of a toolkit, the important use cases haven't necessarily been
>identified. But after a few iterations I'd expect the toolkit to do
>pretty much everything needed, and modularity makes me not want to
>maintain my own fork if I can help it.
Yes, Knuth expected users to do their own forks of TeX for specialized
purposes, but this has not really happened, even though there is no
evolution of TeX to speak of (so merging changes back into the fork
would not have been an issue). People just don't want to much with
the internals of an existing program.
OTOH, the success of applications that support scripting and add-ons
shows that, no, you cannot expect a program to do everything that's
needed out of the box, even after a few iterations. So people are
willing to program extensions given a defined interface (e.g., various
packages on top of TeX, such as LaTeX, instead of a fork of TeX).
>OK, so you make a small modification and create a bug, which makes your
>test fail. What now? You have to figure out the cause of the bug.
>And, I think, this is much easier in a (runtime) type-checked and
>bounds-checked language, than something like Forth.
For a small modification, the bug is usually obvious. How can
something else be easier.
Debugging Forth code is usually easy in my experience, certainly for
things that would be caught by a type or bounds checker. But maybe it
takes experience to write programs such that such bugs are easy to
find.
>> If you haven't found Forth strings, arrays, hash tables, etc., by now,
>> it's because you were looking at an embedded Forth, where all these
>> features just don't fit.
>
>I'm using gforth and I didn't notice any of that in the manual.
Strings: http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Memory-Blocks.html
(no docs for Bernds strings package, though).
Arrays:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Address-arithmetic.html
Hash tables:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Word-Lists.html
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-07 08:32 -0700 |
| Message-ID | <7xa9vyuwlo.fsf@ruckus.brouhaha.com> |
| In reply to | #15945 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> {'name':'Paul','languages':['Python','Forth']}
> This reminds me of what I do with data in charts written in Postscript.
> In simple cases, the data is interpreted directly and drawn right away:
I couldn't follow the Postscript code details but I get the general
idea. It still goes against the usual wisdom that once you figure out
your program's data structures, the code takes care of itself.
Another issue is that Lisp and Python-like languages not only have a
convenient syntax for reading those structures, they can also print them
in a way they can read them back in. So you can easily compute data and
dump it out for later re-import. This is very convenient for fast
interactive development.
>
> OTOH, the success of applications that support scripting and add-ons
> shows that, no, you cannot expect a program to do everything that's
> needed out of the box, even after a few iterations.
I would say here, the toolkit is script interpreter and the stuff
exported to the scripting language, and the application is the user
script. So it's pretty usual in the iterative development of such
frameworks that in early versions, the script system can't quite do what
you want and you have to mess with the internals, such as to export new
functions that scripts can use. But eventually the scripting level
becomes pretty powerful. This happened with Emacs, with browsers, etc.
> Debugging Forth code is usually easy in my experience, certainly for
> things that would be caught by a type or bounds checker. But maybe it
> takes experience to write programs such that such bugs are easy to
> find.
It's well known that such bugs are a perennial drain on development time
and source of exploits in in C and C++ programs. I'm interested to know
if Forth somehow avoids these problems where C and C++ fail. The rest
of the development world dealt with it mostly by migrating to type-safe
and GC'd languages.
> Strings: .../Memory-Blocks.html
> Arrays: .../Address-arithmetic.html
These are very do-it-yourself approaches, to say the least ;-).
> Hash tables: .../Word-Lists.html
This seems to be a way to manage vocabularies visible to the
interpreter, rather than make dictionary-like data objects for use by
programs.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-07 21:39 +0200 |
| Message-ID | <8544930.KNqXtjcyQv@sunwukong.fritz.box> |
| In reply to | #16013 |
Paul Rubin wrote: >> Debugging Forth code is usually easy in my experience, certainly for >> things that would be caught by a type or bounds checker. But maybe >> it takes experience to write programs such that such bugs are easy to >> find. > > It's well known that such bugs are a perennial drain on development > time and source of exploits in in C and C++ programs. I'm interested > to know if Forth somehow avoids these problems where C and C++ fail. > The rest of the development world dealt with it mostly by migrating to > type-safe and GC'd languages. We had that discussion a while ago, stdlib strings are broken by design (and even though people here argue that zero-terminated strings in C are "optional", people learn this broken string functions when they learn C). The solution for this problem is to have string buffers growing and shrinking with the string. This doesn't require full GC and type-safe stuff, it only requires resize() of malloc-ed blocks. The little string words I use for that in Gforth are documented, though only in the current development branch. I've used them quite often, and I never had any sort of buffer overflow or alike with them. I think Forth program development differs in two important ways from C: * We don't write big chunks of code and then test them. This is done in C, because compiling takes long, and to debug stuff you need to write a debug harness etc.; in Forth we change little things and test immediately. * We extend the programming language to provide what's missing. C people use libraries and stick to their libraries even if there are serious flaws. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-07 21:03 -0700 |
| Message-ID | <7xwqz1vcdu.fsf@ruckus.brouhaha.com> |
| In reply to | #16035 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >>> things that would be caught by a type or bounds checker.... >> I'm interested to know if Forth somehow avoids these problems where C >> and C++ fail. > We had that discussion a while ago, stdlib strings are broken by design > (and even though people here argue that zero-terminated strings in C are > "optional", people learn this broken string functions when they learn C). It's not just strings, it's every sort of array, in every language except apparently for Forth. I guess Forth array users can always write access functions that check bounds, and use those at least during developent. > The solution for this problem is to have string buffers growing and > shrinking with the string. This doesn't require full GC and type-safe > stuff, it only requires resize() of malloc-ed blocks. C++ STL strings and vectors do this growing and shrinking, and are somewhat less vulnerable to these hazards than C stdlib strings, but you still have memory leaks and double-free errors to deal with. > The little string words I use for that in Gforth are documented, though > only in the current development branch. I've used them quite often, and > I never had any sort of buffer overflow or alike with them. Cool, I'll look for them. > I think Forth program development differs in two important ways from C: > * We don't write big chunks of code and then test them. This is done in > C, because compiling takes long, and to debug stuff you need to write a > debug harness etc.; in Forth we change little things and test > immediately. I'm not sure how much this really helps: it handles immediate, localized bugs, but not really bugs involving long-range interaction between components. I think Forth applications simply tend not to be of the type that uses dynamic memory or even strings all that much. The typical profile might be more like MISRA C. This is perfectly fine of course. > * We extend the programming language to provide what's missing. C > people use libraries and stick to their libraries even if there are > serious flaws. I'd say if the same stuff turns up missing again and again, it's time to factor it into the library.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-08 19:09 +0200 |
| Message-ID | <1755828.uKo66frh80@sunwukong.fritz.box> |
| In reply to | #16038 |
Paul Rubin wrote: > It's not just strings, it's every sort of array, in every language > except apparently for Forth. I guess Forth array users can always > write access functions that check bounds, and use those at least > during developent. Hehe, the word goes "using bound checking during development is like using a parachute while still on ground". The development style is "crash early, crash often"; you might do your bould checking there and crash, but the application program should rather be robust. The array function in my string package is auto-expanding the string array instead of crashing. This goes towards robustness, not towards crashing. >> The solution for this problem is to have string buffers growing and >> shrinking with the string. This doesn't require full GC and >> type-safe stuff, it only requires resize() of malloc-ed blocks. > > C++ STL strings and vectors do this growing and shrinking, and are > somewhat less vulnerable to these hazards than C stdlib strings, but > you still have memory leaks and double-free errors to deal with. That's why I only allow strings to live in global variables (or - when used within my OOP package - as instance variables of objects which know how to dispose themselfes). >> I think Forth program development differs in two important ways from >> C: >> * We don't write big chunks of code and then test them. This is done >> in C, because compiling takes long, and to debug stuff you need to >> write a debug harness etc.; in Forth we change little things and test >> immediately. > > I'm not sure how much this really helps: it handles immediate, > localized bugs, but not really bugs involving long-range interaction > between components. When our programs have interactions between components, testing that is part of the testing. > I think Forth applications simply tend not to be of the type that uses > dynamic memory or even strings all that much. The typical profile > might be more like MISRA C. This is perfectly fine of course. Applications like MINOS certainly are not that common Forth applications. >> * We extend the programming language to provide what's missing. C >> people use libraries and stick to their libraries even if there are >> serious flaws. > > I'd say if the same stuff turns up missing again and again, it's time > to factor it into the library. We do that, but our main problem is that we usually don't think the libraries others have created are any good. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-08 21:57 -0700 |
| Message-ID | <7xa9vw9r99.fsf@ruckus.brouhaha.com> |
| In reply to | #16058 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Hehe, the word goes "using bound checking during development is like > using a parachute while still on ground". Yeah, leaving bounds checks active all the time is probably best practice in most applications. >> you still have memory leaks and double-free errors to deal with. > That's why I only allow strings to live in global variables (or - when > used within my OOP package - as instance variables of objects which know > how to dispose themselfes). But now you've got the issue of leaking or double-freeing those objects. If you've got complex, dynamic data structures, storage management is a nontrivial issue. >>> in Forth we change little things and test immediately. ... > When our programs have interactions between components, testing that > is part of the testing. I guess I'm not seeing how this is different from C then. Code change is not topologically continuous. Sure you can write a new component bottom-up, but you can't really connect it up to other components til a substantial amount of the new component is working, and maybe then you find there you find an interaction problem you hadn't thought of in advance. What then?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-10-09 01:10 -0700 |
| Message-ID | <e81bb84a-d1ae-4793-b1ee-5bac36939907@p22g2000vby.googlegroups.com> |
| In reply to | #16078 |
On Oct 9, 5:57 am, Paul Rubin <no.em...@nospam.invalid> wrote: > > Yeah, leaving bounds checks active all the time is probably best > practice in most applications. > No. Testing the absolute living shit out of the application to prove that a bounds error cannot happen is the way. Detecting a bounds error is very nice in a spreadsheet, or an app to convert GIFs to JPGs or whatever. It's not really much use on the rocket firing system on the alignment correction system of a telecommunications satellite. Out of bounds? Whoop de doo... You're still going to fall out of orbit!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-09 14:12 -0400 |
| Message-ID | <k51pel$ah9$1@dont-email.me> |
| In reply to | #16085 |
On 10/9/2012 4:10 AM, Mark Wills wrote: > On Oct 9, 5:57 am, Paul Rubin<no.em...@nospam.invalid> wrote: >> >> Yeah, leaving bounds checks active all the time is probably best >> practice in most applications. >> > > No. Testing the absolute living shit out of the application to prove > that a bounds error cannot happen is the way. Detecting a bounds error > is very nice in a spreadsheet, or an app to convert GIFs to JPGs or > whatever. It's not really much use on the rocket firing system on the > alignment correction system of a telecommunications satellite. Out of > bounds? Whoop de doo... You're still going to fall out of orbit! Really, you think the way to design critical systems is to test them extensively? Unless you do an "exhaustive" test which means *proving* it is truly exhaustive, testing can't prove the absence of errors. NASA demonstrates this on a regular basis with some expensive and spectacular failures, not to mention the tragic ones. Do you really think their failures are because they didn't test the "absolute living shit" out of them? Rick
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2012-10-10 09:29 +0100 |
| Message-ID | <adkq1sFaesbU1@mid.individual.net> |
| In reply to | #16109 |
rickman wrote: > On 10/9/2012 4:10 AM, Mark Wills wrote: >> On Oct 9, 5:57 am, Paul Rubin<no.em...@nospam.invalid> wrote: >>> >>> Yeah, leaving bounds checks active all the time is probably best >>> practice in most applications. >>> >> >> No. Testing the absolute living shit out of the application to prove >> that a bounds error cannot happen is the way. Detecting a bounds error >> is very nice in a spreadsheet, or an app to convert GIFs to JPGs or >> whatever. It's not really much use on the rocket firing system on the >> alignment correction system of a telecommunications satellite. Out of >> bounds? Whoop de doo... You're still going to fall out of orbit! > > Really, you think the way to design critical systems is to test them > extensively? Unless you do an "exhaustive" test which means *proving* > it is truly exhaustive, testing can't prove the absence of errors. NASA > demonstrates this on a regular basis with some expensive and spectacular > failures, not to mention the tragic ones. Do you really think their > failures are because they didn't test the "absolute living shit" out of > them? As someone stated in another thread:- "Dijkstra had once said "Programs are either so simple that they contain obviously no bugs, or so complex that they contain no obvious bugs". Forth helps you to create lots of simple words which, even when gathered together, can still give the facility of remaining simple enough that errors become obvious (although programming style will have some impact on this). Even so, it is important to inspect and test each and every word to ensure they all meet their individual requirements (as you have stated them in the glossary entry). Part of the lesson to the younger generation should be how to analyse a problem and break it down into simpler fully understandable bits. They then need to explore suitable simple solutions that can build to solve the whole problem. Forth (philosophy and style) is great for such work. -- ******************************************************************** Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-10 21:13 -0400 |
| Message-ID | <k556g3$bco$1@dont-email.me> |
| In reply to | #16148 |
On 10/10/2012 4:29 AM, Paul E. Bennett wrote: > rickman wrote: > >> On 10/9/2012 4:10 AM, Mark Wills wrote: >>> On Oct 9, 5:57 am, Paul Rubin<no.em...@nospam.invalid> wrote: >>>> >>>> Yeah, leaving bounds checks active all the time is probably best >>>> practice in most applications. >>>> >>> >>> No. Testing the absolute living shit out of the application to prove >>> that a bounds error cannot happen is the way. Detecting a bounds error >>> is very nice in a spreadsheet, or an app to convert GIFs to JPGs or >>> whatever. It's not really much use on the rocket firing system on the >>> alignment correction system of a telecommunications satellite. Out of >>> bounds? Whoop de doo... You're still going to fall out of orbit! >> >> Really, you think the way to design critical systems is to test them >> extensively? Unless you do an "exhaustive" test which means *proving* >> it is truly exhaustive, testing can't prove the absence of errors. NASA >> demonstrates this on a regular basis with some expensive and spectacular >> failures, not to mention the tragic ones. Do you really think their >> failures are because they didn't test the "absolute living shit" out of >> them? > > As someone stated in another thread:- > > "Dijkstra had once said "Programs are either so simple that they contain > obviously no bugs, or so complex that they contain no obvious bugs". > > Forth helps you to create lots of simple words which, even when gathered > together, can still give the facility of remaining simple enough that errors > become obvious (although programming style will have some impact on this). > Even so, it is important to inspect and test each and every word to ensure > they all meet their individual requirements (as you have stated them in the > glossary entry). > > Part of the lesson to the younger generation should be how to analyse a > problem and break it down into simpler fully understandable bits. They then > need to explore suitable simple solutions that can build to solve the whole > problem. Forth (philosophy and style) is great for such work. That has little to do with my comment about testing. You can't prove that a complex system can't fail by testing. As to your comments about Forth, "No generalization is worth a damn, including this one", often attributed to Oliver Wendell Holmes, Jr., not sure if he ever said exactly this. Or to quote Mark Twain, "All generalizations are false, including this one." Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-10-10 02:02 -0700 |
| Message-ID | <f5162f01-efbd-43e9-a008-e714ba4b2c36@w2g2000vbc.googlegroups.com> |
| In reply to | #16109 |
On Oct 9, 7:12 pm, rickman <gnu...@gmail.com> wrote: > On 10/9/2012 4:10 AM, Mark Wills wrote: > > > On Oct 9, 5:57 am, Paul Rubin<no.em...@nospam.invalid> wrote: > > >> Yeah, leaving bounds checks active all the time is probably best > >> practice in most applications. > > > No. Testing the absolute living shit out of the application to prove > > that a bounds error cannot happen is the way. Detecting a bounds error > > is very nice in a spreadsheet, or an app to convert GIFs to JPGs or > > whatever. It's not really much use on the rocket firing system on the > > alignment correction system of a telecommunications satellite. Out of > > bounds? Whoop de doo... You're still going to fall out of orbit! > > Really, you think the way to design critical systems is to test them > extensively? Unless you do an "exhaustive" test which means *proving* > it is truly exhaustive, testing can't prove the absence of errors. NASA > demonstrates this on a regular basis with some expensive and spectacular > failures, not to mention the tragic ones. Do you really think their > failures are because they didn't test the "absolute living shit" out of > them? > > Rick > Unless you do an "exhaustive" test which means *proving* > it is truly exhaustive, testing can't prove the absence of errors. Well, I think you can prove it, but sure, it would be very difficult to come up with the every possible set of variables, be they hardware variables, software variables, environmental etc. So, all you can do is test test test test as extensively as possible, such that it becomes possible to compute the Probability of Failure on Demand (PFD) which is at the heart of designing, building, and testing SIL rated (mission critical) systems. There are different SIL ratings, depending on what (asset value) or who (number of lives potentially lost) that must be taken into account when considering these things. Testing the gear after it's built is only a part of the process, of course. A lot of effort goes into the design beforehand to (at least theoretically) mitigate the chances (chances, i.e. it's all about probability) of things going bad. Of course, it still happens - things go bad, though looking through past data (in my industry, the oil and gas industry) there are/were human factors that contributed to the disaster, rather than simply machinery going wrong. It seems even in the avaiation industry the triplex redundant systems are awesomely good at their job, and there are often human factors involved when we hear of planes crashing (fuel icing, pilot disorientation etc). It's an interesting topic!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-10 21:23 -0400 |
| Message-ID | <k5572j$dgl$1@dont-email.me> |
| In reply to | #16150 |
On 10/10/2012 5:02 AM, Mark Wills wrote: > On Oct 9, 7:12 pm, rickman<gnu...@gmail.com> wrote: >> On 10/9/2012 4:10 AM, Mark Wills wrote: >> >>> On Oct 9, 5:57 am, Paul Rubin<no.em...@nospam.invalid> wrote: >> >>>> Yeah, leaving bounds checks active all the time is probably best >>>> practice in most applications. >> >>> No. Testing the absolute living shit out of the application to prove >>> that a bounds error cannot happen is the way. Detecting a bounds error >>> is very nice in a spreadsheet, or an app to convert GIFs to JPGs or >>> whatever. It's not really much use on the rocket firing system on the >>> alignment correction system of a telecommunications satellite. Out of >>> bounds? Whoop de doo... You're still going to fall out of orbit! >> >> Really, you think the way to design critical systems is to test them >> extensively? Unless you do an "exhaustive" test which means *proving* >> it is truly exhaustive, testing can't prove the absence of errors. NASA >> demonstrates this on a regular basis with some expensive and spectacular >> failures, not to mention the tragic ones. Do you really think their >> failures are because they didn't test the "absolute living shit" out of >> them? >> >> Rick > >> Unless you do an "exhaustive" test which means *proving* >> it is truly exhaustive, testing can't prove the absence of errors. > > Well, I think you can prove it, but sure, it would be very difficult > to come up with the every possible set of variables, be they hardware > variables, software variables, environmental etc. So, all you can do > is test test test test as extensively as possible, such that it > becomes possible to compute the Probability of Failure on Demand (PFD) > which is at the heart of designing, building, and testing SIL rated > (mission critical) systems. Proving a system is correct means proving it in a mathematical sense, rigorous proof. Hard to do with any but fairly simple programs. Supposedly the reason why "structured programming" is used, or so I was told in school. As you say the other way it to test all possible combinations of inputs, an impossible job in any practical sense for most systems. > Of course, it still happens - things go bad, though looking through > past data (in my industry, the oil and gas industry) there are/were > human factors that contributed to the disaster, rather than simply > machinery going wrong. It seems even in the avaiation industry the > triplex redundant systems are awesomely good at their job, and there > are often human factors involved when we hear of planes crashing (fuel > icing, pilot disorientation etc). I'm not sure what this means. There are still problems with systems that cause accidents or in other cases the problems are caught by the personnel and the accident avoided, largely because the systems were tested for the problems that were expected. It is the unexpected that is the real problem. Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-10 18:24 -0700 |
| Message-ID | <7xwqyxyf5p.fsf@ruckus.brouhaha.com> |
| In reply to | #16150 |
Mark Wills <forthfreak@gmail.com> writes: > So, all you can do is test test test test as extensively as possible, > such that it becomes possible to compute the Probability of Failure on > Demand (PFD) I don't think testing lets you compute the PFD without a priority presumptions about the distribution of inputs. In particular, in the post-Stuxnet era, you have to presume that even non-networked control systems will have to deal with malicious input from attackers who have studied the system in detail. Apparently the security of an awful lot of SCADA systems is just pathetic. Testing is good but machine checking of correctness conditions is also good.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-11 17:21 +0000 |
| Message-ID | <2012Oct11.192115@mips.complang.tuwien.ac.at> |
| In reply to | #16109 |
rickman <gnuarm@gmail.com> writes:
>NASA
>demonstrates this on a regular basis with some expensive and spectacular
>failures, not to mention the tragic ones. Do you really think their
>failures are because they didn't test the "absolute living shit" out of
>them?
Yes. E.g.,
<http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Origin_of_the_problem>
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-10-11 12:33 -0700 |
| Message-ID | <fab34d93-2b23-4a0e-a717-089c243b48c6@a6g2000vbl.googlegroups.com> |
| In reply to | #16195 |
On Oct 11, 6:22 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > rickman <gnu...@gmail.com> writes: > >NASA > >demonstrates this on a regular basis with some expensive and spectacular > >failures, not to mention the tragic ones. Do you really think their > >failures are because they didn't test the "absolute living shit" out of > >them? > > Yes. E.g., > <http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Origin_of_the_pro...> > > - 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 2012:http://www.euroforth.org/ef12/ what about the mars probe where they mixed imperial and metric units? Q.E.D :-)
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-10-11 13:42 -0700 |
| Message-ID | <c71f87f1-6684-4fe5-85c4-33c0ba67a908@l7g2000vbj.googlegroups.com> |
| In reply to | #16199 |
On Oct 11, 8:33 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote: > On Oct 11, 6:22 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) > wrote: > > > > > > > > > rickman <gnu...@gmail.com> writes: > > >NASA > > >demonstrates this on a regular basis with some expensive and spectacular > > >failures, not to mention the tragic ones. Do you really think their > > >failures are because they didn't test the "absolute living shit" out of > > >them? > > > Yes. E.g., > > <http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Origin_of_the_pro...> > > > - 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 2012:http://www.euroforth.org/ef12/ > > what about the mars probe where they mixed imperial and metric units? > > Q.E.D :-) On September 23, 1999 NASA lost the $125 million Mars Climate Orbiter spacecraft after a 286-day journey to Mars. Miscalculations due to the use of English units instead of metric units apparently sent the craft slowly off course -- 60 miles in all. Thrusters used to help point the spacecraft had, over the course of months, been fired incorrectly because data used to control the wheels were calculated in incorrect units. Lockheed Martin, which was performing the calculations, was sending thruster data in English units (pounds) to NASA, while NASA's navigation team was expecting metric units (Newtons). Woops.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-11 18:59 -0400 |
| Message-ID | <k57j11$mrb$2@dont-email.me> |
| In reply to | #16200 |
On 10/11/2012 4:42 PM, Mark Wills wrote: > On Oct 11, 8:33 pm, Mark Wills<markrobertwi...@yahoo.co.uk> wrote: >> On Oct 11, 6:22 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) >> wrote: >> >> >> >> >> >> >> >>> rickman<gnu...@gmail.com> writes: >>>> NASA >>>> demonstrates this on a regular basis with some expensive and spectacular >>>> failures, not to mention the tragic ones. Do you really think their >>>> failures are because they didn't test the "absolute living shit" out of >>>> them? >> >>> Yes. E.g., >>> <http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Origin_of_the_pro....> >> >>> - 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 2012:http://www.euroforth.org/ef12/ >> >> what about the mars probe where they mixed imperial and metric units? >> >> Q.E.D :-) > > On September 23, 1999 NASA lost the $125 million Mars Climate Orbiter > spacecraft after a 286-day journey to Mars. Miscalculations due to the > use of English units instead of metric units apparently sent the craft > slowly off course -- 60 miles in all. Thrusters used to help point the > spacecraft had, over the course of months, been fired incorrectly > because data used to control the wheels were calculated in incorrect > units. Lockheed Martin, which was performing the calculations, was > sending thruster data in English units (pounds) to NASA, while NASA's > navigation team was expecting metric units (Newtons). > > Woops. That is my point. They *do* test the "living shit" out of their stuff, but sometimes they decide a given test is not required (Hubble) or they just don't think to test something (Mars Orbiter). There are just so many tests you can do that you *can't* do them all. So problems can't be tested out of a complex system. Of course I'm not saying you shouldn't test. I'm saying you can't produce complex systems that are 100% reliable. Then I read stuff like the post I replied to that makes it sound like they think there *is* a magic bullet to solve the problem. I'm just sayin'... Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-11 13:49 -1000 |
| Message-ID | <qdOdnSbY_8Jpx-rNnZ2dnUVZ_qydnZ2d@supernews.com> |
| In reply to | #16203 |
On 10/11/12 12:59 PM, rickman wrote: > On 10/11/2012 4:42 PM, Mark Wills wrote: >> On Oct 11, 8:33 pm, Mark Wills<markrobertwi...@yahoo.co.uk> wrote: >>> On Oct 11, 6:22 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) >>> wrote: >>> >>>> rickman<gnu...@gmail.com> writes: >>>>> NASA >>>>> demonstrates this on a regular basis with some expensive and >>>>> spectacular >>>>> failures, not to mention the tragic ones. Do you really think their >>>>> failures are because they didn't test the "absolute living shit" >>>>> out of >>>>> them? >>> >>>> Yes. E.g., >>>> <http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Origin_of_the_pro....> >>>> >>> >>> what about the mars probe where they mixed imperial and metric units? >>> >>> Q.E.D :-) >> >> On September 23, 1999 NASA lost the $125 million Mars Climate Orbiter >> spacecraft after a 286-day journey to Mars. Miscalculations due to the >> use of English units instead of metric units apparently sent the craft >> slowly off course -- 60 miles in all. Thrusters used to help point the >> spacecraft had, over the course of months, been fired incorrectly >> because data used to control the wheels were calculated in incorrect >> units. Lockheed Martin, which was performing the calculations, was >> sending thruster data in English units (pounds) to NASA, while NASA's >> navigation team was expecting metric units (Newtons). >> >> Woops. > > That is my point. They *do* test the "living shit" out of their stuff, > but sometimes they decide a given test is not required (Hubble) or they > just don't think to test something (Mars Orbiter). There are just so > many tests you can do that you *can't* do them all. So problems can't > be tested out of a complex system. > > Of course I'm not saying you shouldn't test. I'm saying you can't > produce complex systems that are 100% reliable. Then I read stuff like > the post I replied to that makes it sound like they think there *is* a > magic bullet to solve the problem. > > I'm just sayin'... So, where are we? Were any of these written in Forth? (not AFAIK). Could these errors have been prevented by data type checking? (no). 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]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web