Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33379 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2014-09-16 11:22 -0400 |
| Last post | 2014-09-19 02:53 -0700 |
| Articles | 20 on this page of 230 — 25 participants |
Back to article view | Back to comp.lang.forth
Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 11:22 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 11:41 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:20 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 13:39 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:11 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 17:24 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:58 -0400
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 08:47 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 14:41 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-16 18:55 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 14:33 -1000
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 18:30 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-16 15:44 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:22 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 09:18 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:39 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:41 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 16:11 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 16:34 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-17 17:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 07:21 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 10:01 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 07:42 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 14:46 +0000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 08:09 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 03:41 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:31 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 14:53 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 16:44 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 15:52 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-30 00:08 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 04:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:48 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 12:26 -0500
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 17:07 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-17 07:20 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:03 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:40 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 09:56 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:54 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 15:13 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 13:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 11:13 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 21:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 16:57 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-23 00:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 19:53 -1000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 03:48 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-23 16:01 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 08:07 -1000
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-09-23 22:11 +0100
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 16:22 -0500
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 11:28 -1000
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-24 11:56 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:52 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:00 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:04 -0400
Re: Metrics on stack usage Michael Barry <barrym95838@yahoo.com> - 2014-09-24 16:08 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 12:23 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 19:33 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:02 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-25 18:48 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 16:58 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-24 16:02 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 19:14 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 10:15 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 13:54 -1000
Typing, was [Re: Metrics on stack usage] "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-24 21:07 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 15:25 -1000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-24 18:43 -0700
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 16:08 -1000
Re: Typing, was [Re: Metrics on stack usage] Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:11 -0700
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-10-01 09:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:38 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-29 17:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-30 09:13 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-30 22:37 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-03 16:10 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 08:42 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 14:59 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 09:07 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 17:28 -0400
Re: Typing, was [Re: Metrics on stack usage] Howerd <howerdo@yahoo.co.uk> - 2014-10-04 11:15 -0700
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-07 23:37 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-07 15:07 -1000
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-12 03:03 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 10:42 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-13 00:26 +0200
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-11 19:30 -1000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:42 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 02:46 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 00:43 +0200
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 18:45 +0000
Re: Typing, was [Re: Metrics on stack usage] "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-25 09:22 +0200
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 17:09 +0000
Re: Metrics on stack usage Kaz Kylheku <kaz@kylheku.com> - 2014-09-25 01:43 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:15 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:19 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:06 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 04:25 -0400
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 03:15 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 14:43 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 22:23 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:42 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 14:23 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 10:14 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 17:10 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 12:31 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 21:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 01:34 +0200
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:29 -0500
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-05 13:46 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-05 15:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 03:44 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 00:12 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 18:56 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 01:34 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 19:57 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-07 04:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:21 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 05:43 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 02:35 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 21:48 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 05:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 01:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 21:27 +0200
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:01 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 19:59 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 03:33 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:30 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-11 15:22 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-11 22:24 -0400
Loading libraries (was: Metrics on stack usage) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 09:23 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:11 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:36 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:38 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:39 -0400
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-11 12:25 +0100
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 07:52 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 00:34 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-01 23:26 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-01 16:15 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-01 21:57 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 01:20 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-02 15:59 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 19:29 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-03 15:03 +0000
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 02:27 +0200
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-05 09:22 +0100
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-23 19:36 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:40 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-16 17:06 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 07:43 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:04 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:34 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:30 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-17 12:42 -1000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:33 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-18 11:53 -1000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-19 01:14 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 03:32 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:41 +0000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 12:14 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:41 +0000
Re: Metrics on stack usage mhx@iae.nl - 2014-09-19 12:31 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 12:59 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:05 +0000
Re: Metrics on stack usage Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-09-21 07:44 +0200
Re: Metrics on stack usage Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-09-17 11:10 +0200
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-17 14:20 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:41 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-17 16:44 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-18 10:26 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-19 00:12 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-18 19:15 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-18 17:14 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:59 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-19 12:20 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-20 09:04 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 18:08 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-30 04:33 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 19:30 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-30 11:24 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-30 10:55 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-30 18:39 -0700
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-10-01 01:44 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-01 03:57 -0500
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 18:45 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-02 07:53 -0400
Re: Metrics on stack usage G Smith <do.not.use@tectimco.com> - 2014-10-02 13:22 +0100
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-02 08:36 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-02 15:34 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:08 +0000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 18:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-19 13:28 -1000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 19:57 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 13:09 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-20 13:27 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 08:04 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 08:55 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:01 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:15 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 06:57 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 07:31 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:04 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:17 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:49 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:57 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 19:47 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 02:58 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:28 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-21 11:24 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:55 -0400
Re: Metrics on stack usage Coos Haak <chforth@hccnet.nl> - 2014-09-20 14:57 +0200
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:22 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:25 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:08 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:38 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:19 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:35 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:00 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 08:54 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 03:26 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 10:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:29 -0400
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:53 -0700
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-25 01:06 -0700 |
| Message-ID | <00b269ab-767b-4e20-853c-7e70405cd99a@googlegroups.com> |
| In reply to | #33548 |
On Thursday, 25 September 2014 00:02:42 UTC+1, Paul Rubin wrote: > > The worst property of untyped languages like C and Forth is that they > don't crash when there's a type error. They can corrupt data or memory > and the program keeps running. > So test it then. Properly. Even (much) better, get someone else to test it. Preferably with a written test procedure that allows the test results to be documented. > > > I like the Chris Smith quote: > "I find it amusing when novice programmers believe their main job is > preventing programs from crashing. More experienced programmers > realize that correct code is great, code that crashes could use > improvement, but incorrect code that doesn't crash is a horrible > nightmare." Incorrect code that doesn't crash==code that has not been tested adequately. Code that crashes==bugged code.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-25 04:25 -0400 |
| Message-ID | <m00jim$bl5$1@dont-email.me> |
| In reply to | #33559 |
On 9/25/2014 4:06 AM, Mark Wills wrote: > On Thursday, 25 September 2014 00:02:42 UTC+1, Paul Rubin wrote: >> >> The worst property of untyped languages like C and Forth is that they >> don't crash when there's a type error. They can corrupt data or memory >> and the program keeps running. >> > > So test it then. Properly. Even (much) better, get someone else > to test it. Preferably with a written test procedure that allows > the test results to be documented. Come on. You know as well as everyone else that testing can't show that something works. It can only show that something has a problem vs. you just haven't found the problem yet. >> I like the Chris Smith quote: >> "I find it amusing when novice programmers believe their main job is >> preventing programs from crashing. More experienced programmers >> realize that correct code is great, code that crashes could use >> improvement, but incorrect code that doesn't crash is a horrible >> nightmare." > > Incorrect code that doesn't crash==code that has not been tested adequately. > Code that crashes==bugged code. Calling for better testing is the song of the eternal optimist. The kind of bugs that type mismatches cause are the kind of bugs that may not show up in testing easily or even with great pains. Bugs are better prevented than cured later. I believe this actually has been well documented. Finding bugs before you start testing is supposed to save huge amounts of money vs. finding them in system integration. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-25 03:15 -0700 |
| Message-ID | <6e715073-1a3c-4a85-b5b6-54d5f98915c7@googlegroups.com> |
| In reply to | #33562 |
On Thursday, 25 September 2014 09:26:00 UTC+1, rickman wrote: > > Come on. You know as well as everyone else that testing can't show that > something works. It can only show that something has a problem vs. you > just haven't found the problem yet. > Define "works". I know that just sounds like picky pedantry, but it's critical. Something can be said to "work" (perhaps "behave as designed" is a better definition) when it has been proven to "work" *within the operational parameters for which it has been designed*. Now, saying "within the operational parameters for which it has been designed" does not mean it's allowed to crash when given unexpected input, just that it should be able to gracefully detect and handle unexpected input. The authoring of a test procedure is an extremely responsible role, (not that I'm lecturing to you, I'm sure you understand that fully), possibly more responsible than the authoring of the code. The test procedure must fully encapsulate the range of expected inputs to a function/widget and set out appropriate test cases. In addition it should set out appropriate test cases for unexpected inputs. When both expected, and unexpected tests pass, the item under test can be signed off as passed. If, subsequently, a condition emerges that puts a system into an unknown or unanticipated state, it is really a failure of the testing procedure, rather than the software itself. Project manager to coder: "Hey, we found a scenario that crashes the code." Coder: "Speak to the test engineer. I defensively coded against all test scenarios. It passed the test. It *works*." Bringing this back to Forth (and there's nothing new in the following verbiage, so please feel free to skip it) that's why Forth is *so* cool in mission critical software systems. It's actually possible to prove to a certifying authority that the code does *exactly* what is coded - something that is getting harder and harder to do as software systems' complexity continues to grow. I work in the subsea oil and gas sector, and I kid you not, we're not doing anything any more complex than we were doing in the 70's (opening and closing valves, monitoring instruments (pressures and temperatures), monitoring flow meters, doing flow calculations, that sort of thing) but the hardware and software systems that employ to carry out these actions are orders of magnitude more complex than previous systems. Utterly bonkers. Then, when the SHTF people find it extremely difficult to determine where the problem is! In discussions we've had here at the office, we're starting to come to the conclusion that code written in Forth could be certified at least up to SIL-3, possibly SIL-4. In reality, SIL-4 would be hard to attain at a system level, since the hardware upon which the code is running is of course a factor in the PFD (Probability of Failure on Demand) calculations. So, getting to the point (sorry!) I have to disagree with your statement, or at least (again, pedantry) say that you *can* prove that something works, as long as you have defined what "works" means! Even failure can be said to be "as designed" and therefore "working" as long as it fails "as designed". An autopilot can fail a hundred times a day, as long as in doing so it returns (a) tells the pilots, and (b) returns full control to them. No problem at all. Customer: "Hey, your autopilot keeps failing" Vendor: "Does it alarm and return full control to the pilots?" Customer: "Yes." Vendor: "It's working fine." :-)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-25 14:43 -0400 |
| Message-ID | <m01nq7$gqi$1@dont-email.me> |
| In reply to | #33564 |
On 9/25/2014 6:15 AM, Mark Wills wrote: > On Thursday, 25 September 2014 09:26:00 UTC+1, rickman wrote: >> >> Come on. You know as well as everyone else that testing can't show that >> something works. It can only show that something has a problem vs. you >> just haven't found the problem yet. >> > > Define "works". I know that just sounds like picky pedantry, but it's > critical. Something can be said to "work" (perhaps "behave as designed" > is a better definition) when it has been proven to "work" *within the > operational parameters for which it has been designed*. > > Now, saying "within the operational parameters for which it has been > designed" does not mean it's allowed to crash when given unexpected > input, just that it should be able to gracefully detect and handle > unexpected input. > > The authoring of a test procedure is an extremely responsible role, > (not that I'm lecturing to you, I'm sure you understand that fully), > possibly more responsible than the authoring of the code. The test > procedure must fully encapsulate the range of expected inputs to > a function/widget and set out appropriate test cases. In addition > it should set out appropriate test cases for unexpected inputs. > When both expected, and unexpected tests pass, the item under test > can be signed off as passed. If, subsequently, a condition emerges > that puts a system into an unknown or unanticipated state, it is > really a failure of the testing procedure, rather than the software > itself. > > Project manager to coder: "Hey, we found a scenario that crashes > the code." > Coder: "Speak to the test engineer. I defensively coded against all > test scenarios. It passed the test. It *works*." > > Bringing this back to Forth (and there's nothing new in the following > verbiage, so please feel free to skip it) that's why Forth is *so* > cool in mission critical software systems. It's actually possible to > prove to a certifying authority that the code does *exactly* what is > coded - something that is getting harder and harder to do as software > systems' complexity continues to grow. I work in the subsea oil and > gas sector, and I kid you not, we're not doing anything any more > complex than we were doing in the 70's (opening and closing valves, > monitoring instruments (pressures and temperatures), monitoring flow > meters, doing flow calculations, that sort of thing) but the hardware > and software systems that employ to carry out these actions are orders > of magnitude more complex than previous systems. Utterly bonkers. Then, > when the SHTF people find it extremely difficult to determine where the > problem is! > > In discussions we've had here at the office, we're starting to come to > the conclusion that code written in Forth could be certified at least > up to SIL-3, possibly SIL-4. In reality, SIL-4 would be hard to attain > at a system level, since the hardware upon which the code is running > is of course a factor in the PFD (Probability of Failure on Demand) calculations. > > So, getting to the point (sorry!) I have to disagree with your statement, > or at least (again, pedantry) say that you *can* prove that something > works, as long as you have defined what "works" means! Even failure can > be said to be "as designed" and therefore "working" as long as it fails > "as designed". An autopilot can fail a hundred times a day, as long as > in doing so it returns (a) tells the pilots, and (b) returns full > control to them. No problem at all. > > Customer: "Hey, your autopilot keeps failing" > Vendor: "Does it alarm and return full control to the pilots?" > Customer: "Yes." > Vendor: "It's working fine." You may have stated your definition of "working" but that does not in any way change the limited nature of testing. The product is *not* designed to the test plan. Both the product and the test plan are designed to the requirements, a very different thing. If an engineer responded to a failure in the product by saying, "Speak to the test engineer. I defensively coded against all test scenarios. It passed the test. It *works*." I would fire that person or at least give them a "reeducation". Here is my counter example. I worked at a military contractor designing push to talk radios. A new unit was ready for production and as part of a separate effort involving some of this design being reused I was asked to do a timing analysis of the DSP memory bus. I found that the Flash part was not being used properly and one of it's timing specs were not being met. I reported this to the engineer who seemed to be in charge of the ongoing effort to get the radio into production. I explained the problem, which could be fixed in software I'm pretty sure, even if that software was in the FPGA. I was told that the radio had passed acceptance testing and that no fixes were needed! I believe that according to you the radio was "working". Clearly the fact that we were not meeting the spec for using a component in the radio it could fail under some combination of conditions, temperature, process (of at least two chips) and power supply voltage. So this is an example of things that *can not* be tested to verify they work. I am sure you will argue that analysis of component specs are part of your test... or something. I think your basic premise is wrong. In your example, the autopilot is failing according to the customer's expectations. You are writing it off since the "spec" says it shall return control to the pilot. But doing this every 5 minutes will get the unit yanked from the plane. Doing it even once in a flight consistently will get it yanked from the plane. Doing it once a month will result in an investigation about the high "failure" rate of the autopilot. I think it is pretty clear your definition of "working" is faulty and need to be repaired. Perhaps you didn't put it through enough testing? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-25 22:23 +0000 |
| Message-ID | <542495cf$0$6882$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33566 |
In article <m01nq7$gqi$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 9/25/2014 6:15 AM, Mark Wills wrote: >> On Thursday, 25 September 2014 09:26:00 UTC+1, rickman wrote: >>> >>> Come on. You know as well as everyone else that testing can't show that >>> something works. It can only show that something has a problem vs. you >>> just haven't found the problem yet. >>> >> >> Define "works". I know that just sounds like picky pedantry, but it's >> critical. Something can be said to "work" (perhaps "behave as designed" >> is a better definition) when it has been proven to "work" *within the >> operational parameters for which it has been designed*. >> >> Now, saying "within the operational parameters for which it has been >> designed" does not mean it's allowed to crash when given unexpected >> input, just that it should be able to gracefully detect and handle >> unexpected input. >> >> The authoring of a test procedure is an extremely responsible role, >> (not that I'm lecturing to you, I'm sure you understand that fully), >> possibly more responsible than the authoring of the code. The test >> procedure must fully encapsulate the range of expected inputs to >> a function/widget and set out appropriate test cases. In addition >> it should set out appropriate test cases for unexpected inputs. >> When both expected, and unexpected tests pass, the item under test >> can be signed off as passed. If, subsequently, a condition emerges >> that puts a system into an unknown or unanticipated state, it is >> really a failure of the testing procedure, rather than the software >> itself. >> >> Project manager to coder: "Hey, we found a scenario that crashes >> the code." >> Coder: "Speak to the test engineer. I defensively coded against all >> test scenarios. It passed the test. It *works*." >> >> Bringing this back to Forth (and there's nothing new in the following >> verbiage, so please feel free to skip it) that's why Forth is *so* >> cool in mission critical software systems. It's actually possible to >> prove to a certifying authority that the code does *exactly* what is >> coded - something that is getting harder and harder to do as software >> systems' complexity continues to grow. I work in the subsea oil and >> gas sector, and I kid you not, we're not doing anything any more >> complex than we were doing in the 70's (opening and closing valves, >> monitoring instruments (pressures and temperatures), monitoring flow >> meters, doing flow calculations, that sort of thing) but the hardware >> and software systems that employ to carry out these actions are orders >> of magnitude more complex than previous systems. Utterly bonkers. Then, >> when the SHTF people find it extremely difficult to determine where the >> problem is! >> >> In discussions we've had here at the office, we're starting to come to >> the conclusion that code written in Forth could be certified at least >> up to SIL-3, possibly SIL-4. In reality, SIL-4 would be hard to attain >> at a system level, since the hardware upon which the code is running >> is of course a factor in the PFD (Probability of Failure on Demand) >calculations. >> >> So, getting to the point (sorry!) I have to disagree with your statement, >> or at least (again, pedantry) say that you *can* prove that something >> works, as long as you have defined what "works" means! Even failure can >> be said to be "as designed" and therefore "working" as long as it fails >> "as designed". An autopilot can fail a hundred times a day, as long as >> in doing so it returns (a) tells the pilots, and (b) returns full >> control to them. No problem at all. >> >> Customer: "Hey, your autopilot keeps failing" >> Vendor: "Does it alarm and return full control to the pilots?" >> Customer: "Yes." >> Vendor: "It's working fine." > >You may have stated your definition of "working" but that does not in >any way change the limited nature of testing. The product is *not* >designed to the test plan. Both the product and the test plan are >designed to the requirements, a very different thing. If an engineer >responded to a failure in the product by saying, "Speak to the test >engineer. I defensively coded against all test scenarios. It passed the >test. It *works*." I would fire that person or at least give them a >"reeducation". > >Here is my counter example. I worked at a military contractor designing >push to talk radios. A new unit was ready for production and as part of >a separate effort involving some of this design being reused I was asked >to do a timing analysis of the DSP memory bus. I found that the Flash >part was not being used properly and one of it's timing specs were not >being met. I reported this to the engineer who seemed to be in charge >of the ongoing effort to get the radio into production. > >I explained the problem, which could be fixed in software I'm pretty >sure, even if that software was in the FPGA. I was told that the radio >had passed acceptance testing and that no fixes were needed! I believe >that according to you the radio was "working". Clearly the fact that we >were not meeting the spec for using a component in the radio it could >fail under some combination of conditions, temperature, process (of at >least two chips) and power supply voltage. So this is an example of >things that *can not* be tested to verify they work. > >I am sure you will argue that analysis of component specs are part of >your test... or something. I think your basic premise is wrong. In >your example, the autopilot is failing according to the customer's >expectations. You are writing it off since the "spec" says it shall >return control to the pilot. But doing this every 5 minutes will get >the unit yanked from the plane. Doing it even once in a flight >consistently will get it yanked from the plane. Doing it once a month >will result in an investigation about the high "failure" rate of the >autopilot. > >I think it is pretty clear your definition of "working" is faulty and >need to be repaired. Perhaps you didn't put it through enough testing? Another example is the infamous Pentium bug. Surely Intel knows how to test. But they overlooked a particular combination of inputs. Programs are to work in all circumstance, but that are just too many combinations to be tested. Somewhere in Knuth there is also an example of a situation where only a carefully designed white box test can guarantee proper coverage of paths through the software. Groetjes Albert > >-- > >Rick -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-29 13:42 +0000 |
| Message-ID | <2014Sep29.154247@mips.complang.tuwien.ac.at> |
| In reply to | #33562 |
rickman <gnuarm@gmail.com> writes:
>On 9/25/2014 4:06 AM, Mark Wills wrote:
>> On Thursday, 25 September 2014 00:02:42 UTC+1, Paul Rubin wrote:
>>>
>>> The worst property of untyped languages like C and Forth is that they
>>> don't crash when there's a type error. They can corrupt data or memory
>>> and the program keeps running.
>>>
>>
>> So test it then. Properly. Even (much) better, get someone else
>> to test it. Preferably with a written test procedure that allows
>> the test results to be documented.
>
>Come on. You know as well as everyone else that testing can't show that
>something works.
True. And neither can type checking. But if I have a program that is
only type checked and a program that has had a significant amount of
testing, I would have more trust in the tested program.
>The kind of bugs that type mismatches cause are the kind of bugs that
>may not show up in testing easily or even with great pains.
In my experience most type errors show up quickly in testing, plus
testing catches other bugs.
The exception is portability bugs (testing on one platform won't
reveal them), but interestingly my experience is that I have far fewer
portability bugs in Forth that in C. My explanation for that is that
the lack of type checking has lead to Forth avoiding the type zoo of
C, and the resulting portability bugs. There is just cells and
(rarely) double-cells, and for FP work, a unified FP type.
>Bugs are
>better prevented than cured later.
So Forth prevents these portability bugs by having only few types, and
it prevents a type zoo by having no type checking. C "cures" them
later by type checking, but somehow that fails often enough.
> Finding bugs before you start testing is supposed to
>save huge amounts of money vs. finding them in system integration.
Well, if the only testing you do is integration testing, then you need
to learn more about testing.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-29 14:23 -0400 |
| Message-ID | <m0c83p$ci2$1@dont-email.me> |
| In reply to | #33579 |
On 9/29/2014 9:42 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 9/25/2014 4:06 AM, Mark Wills wrote: >>> On Thursday, 25 September 2014 00:02:42 UTC+1, Paul Rubin wrote: >>>> >>>> The worst property of untyped languages like C and Forth is that they >>>> don't crash when there's a type error. They can corrupt data or memory >>>> and the program keeps running. >>>> >>> >>> So test it then. Properly. Even (much) better, get someone else >>> to test it. Preferably with a written test procedure that allows >>> the test results to be documented. >> >> Come on. You know as well as everyone else that testing can't show that >> something works. > > True. And neither can type checking. But if I have a program that is > only type checked and a program that has had a significant amount of > testing, I would have more trust in the tested program. That has nothing to do with the point I made. Paul talked about the problem of type errors corrupting memory *without* causing a crash which makes them harder to find. Mark's response was to test the code "properly" as if that is a complete solution. My point is that this is not a solution because testing can't find all the bugs in a complex system. Your comment is essentially that testing is better than no testing... duh! >> The kind of bugs that type mismatches cause are the kind of bugs that >> may not show up in testing easily or even with great pains. > > In my experience most type errors show up quickly in testing, plus > testing catches other bugs. "Most"? That is the point. Some do and some don't. So you can't count on finding them all easily. > The exception is portability bugs (testing on one platform won't > reveal them), but interestingly my experience is that I have far fewer > portability bugs in Forth that in C. My explanation for that is that > the lack of type checking has lead to Forth avoiding the type zoo of > C, and the resulting portability bugs. There is just cells and > (rarely) double-cells, and for FP work, a unified FP type. > >> Bugs are >> better prevented than cured later. > > So Forth prevents these portability bugs by having only few types, and > it prevents a type zoo by having no type checking. C "cures" them > later by type checking, but somehow that fails often enough. "Type zoo"? Interesting perspective. >> Finding bugs before you start testing is supposed to >> save huge amounts of money vs. finding them in system integration. > > Well, if the only testing you do is integration testing, then you need > to learn more about testing. Have you read anything about this? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-29 10:14 -1000 |
| Message-ID | <sNydnb5af_Q5ILTJnZ2dnUU7-fWdnZ2d@supernews.com> |
| In reply to | #33581 |
On 9/29/14 8:23 AM, rickman wrote: > On 9/29/2014 9:42 AM, Anton Ertl wrote: >> rickman <gnuarm@gmail.com> writes: >>> On 9/25/2014 4:06 AM, Mark Wills wrote: >>>> On Thursday, 25 September 2014 00:02:42 UTC+1, Paul Rubin wrote: >>>>> >>>>> The worst property of untyped languages like C and Forth is that they >>>>> don't crash when there's a type error. They can corrupt data or >>>>> memory >>>>> and the program keeps running. >>>>> >>>> >>>> So test it then. Properly. Even (much) better, get someone else >>>> to test it. Preferably with a written test procedure that allows >>>> the test results to be documented. >>> >>> Come on. You know as well as everyone else that testing can't show that >>> something works. >> >> True. And neither can type checking. But if I have a program that is >> only type checked and a program that has had a significant amount of >> testing, I would have more trust in the tested program. > > That has nothing to do with the point I made. Paul talked about the > problem of type errors corrupting memory *without* causing a crash which > makes them harder to find. Mark's response was to test the code > "properly" as if that is a complete solution. My point is that this is > not a solution because testing can't find all the bugs in a complex > system. Your comment is essentially that testing is better than no > testing... duh! The Forth approach is to do extensive testing long before it becomes a "complex system". Unit testing on individual words, working up the hierarchy, with appropriate ranges of data, can yield very reliable systems. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-29 17:10 -0400 |
| Message-ID | <m0chsr$q9i$1@dont-email.me> |
| In reply to | #33583 |
On 9/29/2014 4:14 PM, Elizabeth D. Rather wrote: > On 9/29/14 8:23 AM, rickman wrote: >> On 9/29/2014 9:42 AM, Anton Ertl wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> On 9/25/2014 4:06 AM, Mark Wills wrote: >>>>> On Thursday, 25 September 2014 00:02:42 UTC+1, Paul Rubin wrote: >>>>>> >>>>>> The worst property of untyped languages like C and Forth is that they >>>>>> don't crash when there's a type error. They can corrupt data or >>>>>> memory >>>>>> and the program keeps running. >>>>>> >>>>> >>>>> So test it then. Properly. Even (much) better, get someone else >>>>> to test it. Preferably with a written test procedure that allows >>>>> the test results to be documented. >>>> >>>> Come on. You know as well as everyone else that testing can't show >>>> that >>>> something works. >>> >>> True. And neither can type checking. But if I have a program that is >>> only type checked and a program that has had a significant amount of >>> testing, I would have more trust in the tested program. >> >> That has nothing to do with the point I made. Paul talked about the >> problem of type errors corrupting memory *without* causing a crash which >> makes them harder to find. Mark's response was to test the code >> "properly" as if that is a complete solution. My point is that this is >> not a solution because testing can't find all the bugs in a complex >> system. Your comment is essentially that testing is better than no >> testing... duh! > > The Forth approach is to do extensive testing long before it becomes a > "complex system". Unit testing on individual words, working up the > hierarchy, with appropriate ranges of data, can yield very reliable > systems. I don't believe that idea is unique to Forth actually. Besides I refer you to the premise I believe we are discussing... "testing can't show that something works." There are a few situations where you *can* exhaustively test a small section of code. But once the code is aggregated bugs can turn up at a higher level regarding the interactions of lower level code. The larger the aggregation the harder it is to test. Regardless, type checking is done about as early as you possibly can find errors in a system. That by itself has advantages. I believe that is part of the philosophy of Chuck's methods in Colorforth and his other recent tools. There are a number of errors that are actually flagged in the editor if I am not mistaken. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-29 12:31 -1000 |
| Message-ID | <-Y2dnV2LFsciQLTJnZ2dnUU7-eOdnZ2d@supernews.com> |
| In reply to | #33584 |
On 9/29/14 11:10 AM, rickman wrote: > On 9/29/2014 4:14 PM, Elizabeth D. Rather wrote: >> On 9/29/14 8:23 AM, rickman wrote: ... >> The Forth approach is to do extensive testing long before it becomes a >> "complex system". Unit testing on individual words, working up the >> hierarchy, with appropriate ranges of data, can yield very reliable >> systems. > > I don't believe that idea is unique to Forth actually. Besides I refer > you to the premise I believe we are discussing... > > "testing can't show that something works." Oh. I thought we were discussing why type checking isn't all it's cracked up to be :-) > There are a few situations where you *can* exhaustively test a small > section of code. But once the code is aggregated bugs can turn up at a > higher level regarding the interactions of lower level code. The larger > the aggregation the harder it is to test. > > Regardless, type checking is done about as early as you possibly can > find errors in a system. That by itself has advantages. I believe that > is part of the philosophy of Chuck's methods in Colorforth and his other > recent tools. There are a number of errors that are actually flagged in > the editor if I am not mistaken. Well, StrongForth (which is said to do extensive type checking) has been out for some time, and I really don't hear of a lot of people using it. If type checking really helped folks get their applications to work quicker, you'd think they would -- at least, the professionals, who are always struggling to get their code working as soon as possible, in my experience. Designing diagnostics and test procedures correctly is important, too. For example, data should be checked for validity at the point at which it enters the system. If your data is coming in from a device (e.g., an A/D) it has a known range, and the only worry is that it may be broken or turned off. Data coming from humans or external computers is much more error-prone, and needs more checking. But it's the application that knows what appropriate values are, not the compiler, so the application is where the responsibility lies. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-29 21:07 -0400 |
| Message-ID | <m0cvou$hh8$1@dont-email.me> |
| In reply to | #33587 |
On 9/29/2014 6:31 PM, Elizabeth D. Rather wrote: > On 9/29/14 11:10 AM, rickman wrote: >> On 9/29/2014 4:14 PM, Elizabeth D. Rather wrote: >>> On 9/29/14 8:23 AM, rickman wrote: > .... >>> The Forth approach is to do extensive testing long before it becomes a >>> "complex system". Unit testing on individual words, working up the >>> hierarchy, with appropriate ranges of data, can yield very reliable >>> systems. >> >> I don't believe that idea is unique to Forth actually. Besides I refer >> you to the premise I believe we are discussing... >> >> "testing can't show that something works." > > Oh. I thought we were discussing why type checking isn't all it's > cracked up to be :-) > >> There are a few situations where you *can* exhaustively test a small >> section of code. But once the code is aggregated bugs can turn up at a >> higher level regarding the interactions of lower level code. The larger >> the aggregation the harder it is to test. >> >> Regardless, type checking is done about as early as you possibly can >> find errors in a system. That by itself has advantages. I believe that >> is part of the philosophy of Chuck's methods in Colorforth and his other >> recent tools. There are a number of errors that are actually flagged in >> the editor if I am not mistaken. > > Well, StrongForth (which is said to do extensive type checking) has been > out for some time, and I really don't hear of a lot of people using it. Yes, well not so many use Ada either, but I'm pretty sure the ones who do feel type checking reduces their debugging time. But this is an odd comment to see in a Forth group. There really aren't many people using Forth for that matter. The value of finding bugs earlier in the development process has been documented many times. Type checking is just one way of finding bugs earlier. There was a recent thread in c.a.e with example code that for some reason didn't get flagged by the GNU C compiler when a boolean was compared numerically with an int. He was lamenting the lack of useful code reviews in small companies. > If type checking really helped folks get their applications to work > quicker, you'd think they would -- at least, the professionals, who are > always struggling to get their code working as soon as possible, in my > experience. Many of the "professional" code developers *do* use languages with type checking. C does type checking. How many developers use C? > Designing diagnostics and test procedures correctly is important, too. > For example, data should be checked for validity at the point at which > it enters the system. If your data is coming in from a device (e.g., an > A/D) it has a known range, and the only worry is that it may be broken > or turned off. Data coming from humans or external computers is much > more error-prone, and needs more checking. But it's the application that > knows what appropriate values are, not the compiler, so the application > is where the responsibility lies. I've never suggested that testing is not important. I was responding to a comment that you can replace type checking with good testing. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-05 01:34 +0200 |
| Message-ID | <m0q05g$hn9$1@online.de> |
| In reply to | #33589 |
rickman wrote: > Yes, well not so many use Ada either, but I'm pretty sure the ones who > do feel type checking reduces their debugging time. Well, maybe it actually does. As I posted here, the students I've met at the GNU Hacker's Meeting in mid August said it is so tedious and time- consuming to write and execute tests (in the languages they are used to) that they perceive it as beneficial that the compiler at least does some typechecking. Their world is an edit-compile-link-go world, where you don't have instant compilation and no interactive command line either. On the other hand, when you are used to Forth, and you have to write and debug a C/C++/Java program, it feels like wading through molasses, just because all these things you actually need for debugging (and a fast turnaround time after changing some small bit is part of that!) aren't readily available. When it takes long to compile, you would rather make large changes to your program instead of small incremental ones. When you make large changes, chances are high that they don't work. When you write big chunks of code, you tend to not factor them, which means you can't easily unit-test the units. Since there's no command line and no interpreter, writing unit-tests is tedious, anyways, so you skip that. And then you figure out that you urgently want some help from the compiler, because your programs all don't run. And the typecheck is giving that, at least it is giving you the illusion of the compiler doing something - complaining and making you change the program before you run it. Forth "has it backwards", and that's not just UPN. It makes compilation so fast that you don't feel the edit-compile-link-go cycle (even if you actually have it). It makes testing so easy, because a lot of things can be tested on the command line, or by some small interpretative code. This all removes the need to do typechecking in the compiler. And as I've said, some simple checks added e.g. by Factor (which does check your stack effect vs. the code - just the depth, nothing more) gets into the way of debugging. When I'm making a stack depth mistake, I need to know where the mismatch is. That's pretty easy to do by single-stepping through the word or inserting ~~ between the words (mostly around high-level words, because the stack-effect of low-level words is pretty clear). To do that, it has to compile the word, even though it's stack effect is wrong. A warning would be better, but as we know, warnings don't get read. So that's my story why typechecking is not useful in Forth - because you have something else, something better: Hands on to your code. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-05 03:29 -0500 |
| Message-ID | <o7idnZbVJK3FnKzJnZ2dnUU7-IGdnZ2d@supernews.com> |
| In reply to | #33693 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > rickman wrote: >> Yes, well not so many use Ada either, but I'm pretty sure the ones >> who do feel type checking reduces their debugging time. > > Well, maybe it actually does. As I posted here, the students I've > met at the GNU Hacker's Meeting in mid August said it is so tedious > and time- consuming to write and execute tests (in the languages > they are used to) that they perceive it as beneficial that the > compiler at least does some typechecking. Their world is an > edit-compile-link-go world, where you don't have instant compilation > and no interactive command line either. > > On the other hand, when you are used to Forth, and you have to write > and debug a C/C++/Java program, it feels like wading through > molasses, just because all these things you actually need for > debugging (and a fast turnaround time after changing some small bit > is part of that!) aren't readily available. When it takes long to > compile, you would rather make large changes to your program instead > of small incremental ones. I'm a bit surprised that's the case. It doesn't take very long to recompile a single Java file, and there's no relinking to do, so I certainly wouldn't work is that way. I think it's more to do with what people are used to. Even if you are using a language which requires linking it's not going to take that long unless you have a stupidly large module, and there's no excuse for that. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-05 13:46 +0000 |
| Message-ID | <54314b9a$0$15883$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33702 |
In article <o7idnZbVJK3FnKzJnZ2dnUU7-IGdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> wrote: >> rickman wrote: >>> Yes, well not so many use Ada either, but I'm pretty sure the ones >>> who do feel type checking reduces their debugging time. >> >> Well, maybe it actually does. As I posted here, the students I've >> met at the GNU Hacker's Meeting in mid August said it is so tedious >> and time- consuming to write and execute tests (in the languages >> they are used to) that they perceive it as beneficial that the >> compiler at least does some typechecking. Their world is an >> edit-compile-link-go world, where you don't have instant compilation >> and no interactive command line either. >> >> On the other hand, when you are used to Forth, and you have to write >> and debug a C/C++/Java program, it feels like wading through >> molasses, just because all these things you actually need for >> debugging (and a fast turnaround time after changing some small bit >> is part of that!) aren't readily available. When it takes long to >> compile, you would rather make large changes to your program instead >> of small incremental ones. > >I'm a bit surprised that's the case. It doesn't take very long to >recompile a single Java file, and there's no relinking to do, so I >certainly wouldn't work is that way. I think it's more to do with >what people are used to. Even if you are using a language which >requires linking it's not going to take that long unless you have a >stupidly large module, and there's no excuse for that. Indeed. In the Eclipse system, you can see what you data is all the time and edit your souce on the fly. I was never very good at it, bu I can imagine people can be very productive. Now Eclipse is a huge investment in time, but it is ubiquitous even for embedded systems. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-05 15:49 -0400 |
| Message-ID | <m0s7cl$ve6$1@dont-email.me> |
| In reply to | #33693 |
On 10/4/2014 7:34 PM, Bernd Paysan wrote: > rickman wrote: >> Yes, well not so many use Ada either, but I'm pretty sure the ones who >> do feel type checking reduces their debugging time. > > Well, maybe it actually does. As I posted here, the students I've met at > the GNU Hacker's Meeting in mid August said it is so tedious and time- > consuming to write and execute tests (in the languages they are used to) > that they perceive it as beneficial that the compiler at least does some > typechecking. Their world is an edit-compile-link-go world, where you don't > have instant compilation and no interactive command line either. I don't know that I would use the opinions of students as a good metric. Their skill levels are fairly low compared to professional programmers. I expect their tastes will change as their skill levels change. > On the other hand, when you are used to Forth, and you have to write and > debug a C/C++/Java program, it feels like wading through molasses, just > because all these things you actually need for debugging (and a fast > turnaround time after changing some small bit is part of that!) aren't > readily available. When it takes long to compile, you would rather make > large changes to your program instead of small incremental ones. When you > make large changes, chances are high that they don't work. When you write > big chunks of code, you tend to not factor them, which means you can't > easily unit-test the units. Since there's no command line and no > interpreter, writing unit-tests is tedious, anyways, so you skip that. I'm not sure the "fast turnaround time" is that big an advantage. I seem to recall the last time I used a C compiler that it produced results in a small number of seconds. But then I suppose that depends on the size of the program. The VHDL compiler I use is pretty fast and that is strongly typed like ADA. I don't see a significant impact from a 5 second compile time. > And then you figure out that you urgently want some help from the compiler, > because your programs all don't run. And the typecheck is giving that, at > least it is giving you the illusion of the compiler doing something - > complaining and making you change the program before you run it. I don't know about "illusion". I think the sort of problems I would have in VHDL from mismatched types can often be the sort that you spend significant debug time finding. > Forth "has it backwards", and that's not just UPN. It makes compilation so > fast that you don't feel the edit-compile-link-go cycle (even if you > actually have it). It makes testing so easy, because a lot of things can be > tested on the command line, or by some small interpretative code. This all > removes the need to do typechecking in the compiler. Certainly Forth makes easy debugging easy. The sort of range checking that people talk about requires significant thought. By the time I am writing a test bench for my VHDL I have already done all the hard work and writing the code is not a big deal. If I want the code to automatically detect errors I have to spend even more time thinking about it. I expect this is also true for Forth, but I am much less experience than most who use Forth. > And as I've said, some simple checks added e.g. by Factor (which does check > your stack effect vs. the code - just the depth, nothing more) gets into the > way of debugging. When I'm making a stack depth mistake, I need to know > where the mismatch is. That's pretty easy to do by single-stepping through > the word or inserting ~~ between the words (mostly around high-level words, > because the stack-effect of low-level words is pretty clear). To do that, > it has to compile the word, even though it's stack effect is wrong. A > warning would be better, but as we know, warnings don't get read. Are you saying the tool craps out on the compile, but doesn't tell you where the mistake is? You can always have bad tools, that doesn't make the idea poor. > So that's my story why typechecking is not useful in Forth - because you > have something else, something better: Hands on to your code. If the tool can save you from having to lay your hands on the code, that can be useful and time saving. People take the attitude that type checking prevents you from doing things... that is not correct in my experience. Type checking simply requires that your code be written to clearly show what your intent is rather than relying on default behaviors which may depend on implementation details. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-06 03:44 +0200 |
| Message-ID | <m0ss5f$r0s$1@online.de> |
| In reply to | #33708 |
rickman wrote: > On 10/4/2014 7:34 PM, Bernd Paysan wrote: >> rickman wrote: >>> Yes, well not so many use Ada either, but I'm pretty sure the ones who >>> do feel type checking reduces their debugging time. >> >> Well, maybe it actually does. As I posted here, the students I've met at >> the GNU Hacker's Meeting in mid August said it is so tedious and time- >> consuming to write and execute tests (in the languages they are used to) >> that they perceive it as beneficial that the compiler at least does some >> typechecking. Their world is an edit-compile-link-go world, where you >> don't have instant compilation and no interactive command line either. > > I don't know that I would use the opinions of students as a good metric. > Their skill levels are fairly low compared to professional > programmers. I expect their tastes will change as their skill levels > change. I don't think so. Preferrences are set pretty early in education. > I'm not sure the "fast turnaround time" is that big an advantage. I > seem to recall the last time I used a C compiler that it produced > results in a small number of seconds. But then I suppose that depends > on the size of the program. Sure. And maybe you underestimate the effect of "a few seconds": The flow of thinking is definitely broken if you insert a pause of 3 seconds. That is some sort of "upper limit" of time you can wait for, but it's much better if you have a delay no more than 0.3 seconds. You should listen to people who do GUIs and do the actual measurements about how non-responsive functions cause problems; this sort of "instant feedback" you get from Forth is really important. > The VHDL compiler I use is pretty fast and that is strongly typed like > ADA. I don't see a significant impact from a 5 second compile time. You get distracted. Maybe you just can't compare to the 0.5 second compile time compiler, because you don't have one, so you don't know how bad that is. If someone inserts an arbitrary 5 seconds delay into your workflow, it breaks your mental flow of thoughts. Of course, waiting another 10 times longer (50 seconds) would break your thoughts even more. You might want to check your e-mails, or Facebook or whatever. 5 minutes are even worse, you would do something completely unrelated like playing a casual game or such. This sort of thing is really bad for productivity, as an old Chinese saying goes: "you can't concentrate on two things". >> And then you figure out that you urgently want some help from the >> compiler, >> because your programs all don't run. And the typecheck is giving that, >> at least it is giving you the illusion of the compiler doing something - >> complaining and making you change the program before you run it. > > I don't know about "illusion". I think the sort of problems I would > have in VHDL from mismatched types can often be the sort that you spend > significant debug time finding. Verilog is about 3 times as productive as VHDL for the same problem space. This factor 3 is real data, backed up by research and papers. In contrast to VHDL, Verilog has essentially two synthesizable types, bits and bit vectors, and there's no problem to assign one to the other. The compiler might give a warning if you assing vectors of different width. So when a pretty much untyped language is known to be more productive in exactly the same field as a strongly typed language, there's something wrong with the idea that strong typing helps. The first year I worked in the semiconductor industry, I was working for Siemens, and they used VHDL. All those typechecking simply got in the way. E.g. the author of the code specified an integer in the range 0..15 as index into a register file. An index into an array needs to be an integer, for whatever stupid reason it can't be a bit vector. Of course, the actual selector of the register is a bit vector, it just gets converted to this integer. And then, the integer is incremented to get to the next register, and the desired operaion is "wrap around". This doesn't happen, it leads to an overflow. The author of the code went through 5000 lines of code, to replace all "+1" of these integers (he had several) with an "when 15 then 0 else +1" idiom. Obviously, what he did want was a modulo 16 integer. Verilog gives you that, it's a 4 bit vector. VHDL doesn't give you that - you can either have std_(u)logic, which can't be used as index, or you use an integer subtype, which can't wrap around. This sort of stuff is just plain idiotic and kills productivity. I then changed employer, and as one of the first actions at the new one, I politely suggested switching from VHDL to Verilog. We did, and the other programmers were happy; the productivity increase by a factor 3 is real. My experience of VHDL as opposed to Verilog is that you struggle much more to get it to compile, without any benefit (the type checking just is annoying). This is not limited to the typechecking, as in VHDL, there's way more boilerplate needed to instantiate a module, so people don't make small modules. But making small modules makes debugging so much easier! > Certainly Forth makes easy debugging easy. The sort of range checking > that people talk about requires significant thought. By the time I am > writing a test bench for my VHDL I have already done all the hard work > and writing the code is not a big deal. Yes, VHDL perception. It was hard to get the stuff to compile... and with the incentive to write big modules, you need to spent a lot of time before you actually can test it... and because you don't know any better, you think you've found the optimum. > If I want the code to > automatically detect errors I have to spend even more time thinking > about it. I expect this is also true for Forth, but I am much less > experience than most who use Forth. That's not how people write code in Forth - automatically detect errors? > Are you saying the tool craps out on the compile, but doesn't tell you > where the mistake is? You can always have bad tools, that doesn't make > the idea poor. This is due to the very nature of concatenated code: If you specify a stack effect, and the code doesn't have the stack effect, an automated tool can't tell you where the mistake is. How should it? The parameter passing is all implicit, so the tool can't know. >> So that's my story why typechecking is not useful in Forth - because you >> have something else, something better: Hands on to your code. > > If the tool can save you from having to lay your hands on the code, that > can be useful and time saving. People take the attitude that type > checking prevents you from doing things... that is not correct in my > experience. Type checking simply requires that your code be written to > clearly show what your intent is rather than relying on default > behaviors which may depend on implementation details. Or not, as Verilog shows: The default behaviors there are specified, and it just behaves reasonable - you simply don't have to typecast, it just works. This sort of "explicit is better than implicit" is pretty much the opposite of Forth, where, as said above, even the parameter passing is all implicit. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-06 00:12 -0400 |
| Message-ID | <m0t4sa$nj4$1@dont-email.me> |
| In reply to | #33710 |
On 10/5/2014 9:44 PM, Bernd Paysan wrote: > rickman wrote: > >> On 10/4/2014 7:34 PM, Bernd Paysan wrote: >>> rickman wrote: >>>> Yes, well not so many use Ada either, but I'm pretty sure the ones who >>>> do feel type checking reduces their debugging time. >>> >>> Well, maybe it actually does. As I posted here, the students I've met at >>> the GNU Hacker's Meeting in mid August said it is so tedious and time- >>> consuming to write and execute tests (in the languages they are used to) >>> that they perceive it as beneficial that the compiler at least does some >>> typechecking. Their world is an edit-compile-link-go world, where you >>> don't have instant compilation and no interactive command line either. >> >> I don't know that I would use the opinions of students as a good metric. >> Their skill levels are fairly low compared to professional >> programmers. I expect their tastes will change as their skill levels >> change. > > I don't think so. Preferrences are set pretty early in education. We aren't talking about "preferences", we are talking about skill sets. I know my techniques of design and debug have changed several times over my career. >> I'm not sure the "fast turnaround time" is that big an advantage. I >> seem to recall the last time I used a C compiler that it produced >> results in a small number of seconds. But then I suppose that depends >> on the size of the program. > > Sure. And maybe you underestimate the effect of "a few seconds": The flow > of thinking is definitely broken if you insert a pause of 3 seconds. That > is some sort of "upper limit" of time you can wait for, but it's much better > if you have a delay no more than 0.3 seconds. You should listen to people > who do GUIs and do the actual measurements about how non-responsive > functions cause problems; this sort of "instant feedback" you get from Forth > is really important. I am familiar with the Doherty threshold... lol The compile step is a natural change of pace in thinking, so the same issue you have in a GUI doesn't apply to the same extent. When changing from editing to compile/test the mode of thinking is different so a delay of a small number of seconds is much more readily accepted without impact on performance. >> The VHDL compiler I use is pretty fast and that is strongly typed like >> ADA. I don't see a significant impact from a 5 second compile time. > > You get distracted. Maybe you just can't compare to the 0.5 second compile > time compiler, because you don't have one, so you don't know how bad that > is. If someone inserts an arbitrary 5 seconds delay into your workflow, it > breaks your mental flow of thoughts. > > Of course, waiting another 10 times longer (50 seconds) would break your > thoughts even more. You might want to check your e-mails, or Facebook or > whatever. 5 minutes are even worse, you would do something completely > unrelated like playing a casual game or such. This sort of thing is really > bad for productivity, as an old Chinese saying goes: "you can't concentrate > on two things". There are several thresholds for this. The exact values are quoted differently, but anything less than about 0.3 seconds is normally not perceived as a delay. A delay less than about 3 seconds is tolerated without loosing focus, above 30 seconds is a significant disruption to workflow and often means the user leaves the task for another. As I said, my experience with both C compilers and VHDL compiles is that the delays are short enough they don't significantly impact my task completion time. I can't remember a compile that took anywhere near 30 seconds and often they are less than the 3 second attention threshold. Your experience may differ. >>> And then you figure out that you urgently want some help from the >>> compiler, >>> because your programs all don't run. And the typecheck is giving that, >>> at least it is giving you the illusion of the compiler doing something - >>> complaining and making you change the program before you run it. >> >> I don't know about "illusion". I think the sort of problems I would >> have in VHDL from mismatched types can often be the sort that you spend >> significant debug time finding. > > Verilog is about 3 times as productive as VHDL for the same problem space. I have never seen that substantiated... what do you base this on? > This factor 3 is real data, backed up by research and papers. In contrast > to VHDL, Verilog has essentially two synthesizable types, bits and bit > vectors, and there's no problem to assign one to the other. The compiler > might give a warning if you assing vectors of different width. I'd love to see that research. > So when a pretty much untyped language is known to be more productive in > exactly the same field as a strongly typed language, there's something wrong > with the idea that strong typing helps. > > The first year I worked in the semiconductor industry, I was working for > Siemens, and they used VHDL. All those typechecking simply got in the way. > E.g. the author of the code specified an integer in the range 0..15 as index > into a register file. An index into an array needs to be an integer, for > whatever stupid reason it can't be a bit vector. Of course, the actual > selector of the register is a bit vector, it just gets converted to this > integer. And then, the integer is incremented to get to the next register, > and the desired operaion is "wrap around". This doesn't happen, it leads to > an overflow. The author of the code went through 5000 lines of code, to > replace all "+1" of these integers (he had several) with an "when 15 then 0 > else +1" idiom. Sounds to me like a very inexperienced newbie... Why would anyone write 5000 lines of code before doing any simulation or even a test compile? How is that a problem with the language? Of course no one ever has any problems learning Forth... lol > Obviously, what he did want was a modulo 16 integer. Verilog gives you > that, it's a 4 bit vector. VHDL doesn't give you that - you can either have > std_(u)logic, which can't be used as index, or you use an integer subtype, > which can't wrap around. This sort of stuff is just plain idiotic and kills > productivity. Sounds like you are not at all familiar with VHDL. If you want a modulo 16 value you can use a 4 bit unsigned signal. This is easily converted to an integer when you use it to index an array. I believe the form for that is to_integer(). Not so hard - is it? > I then changed employer, and as one of the first actions at the new one, I > politely suggested switching from VHDL to Verilog. We did, and the other > programmers were happy; the productivity increase by a factor 3 is real. My > experience of VHDL as opposed to Verilog is that you struggle much more to > get it to compile, without any benefit (the type checking just is annoying). > This is not limited to the typechecking, as in VHDL, there's way more > boilerplate needed to instantiate a module, so people don't make small > modules. But making small modules makes debugging so much easier! You have your preferences based on your experiences. I believe you would have had a similar experience if you didn't know Forth and started working at a company that used Forth, but didn't really get it and misused it extensively. >> Certainly Forth makes easy debugging easy. The sort of range checking >> that people talk about requires significant thought. By the time I am >> writing a test bench for my VHDL I have already done all the hard work >> and writing the code is not a big deal. > > Yes, VHDL perception. It was hard to get the stuff to compile... and with > the incentive to write big modules, you need to spent a lot of time before > you actually can test it... and because you don't know any better, you think > you've found the optimum. What is the incentive to write "big" modules in VHDL? I don't typically write large ones. The only "incentive" I find is that I test all my modules with a test bench, so I have to construct that framework. I suppose in Forth you would manually type in the tests, but that wouldn't fly in a production environment where you need to document your testing, so each word needs a word to test it... thoroughly. >> If I want the code to >> automatically detect errors I have to spend even more time thinking >> about it. I expect this is also true for Forth, but I am much less >> experience than most who use Forth. > > That's not how people write code in Forth - automatically detect errors? I mean I write the test bench the same way you would write your test code in Forth, it reports a pass/fail, not a number for the user to interpret if that was a valid response. In an HDL you need to consider values of signals at various times. This is very hard to do without a good test bench or a lot of manual examination of detailed waveforms. Not very much like software really. >> Are you saying the tool craps out on the compile, but doesn't tell you >> where the mistake is? You can always have bad tools, that doesn't make >> the idea poor. > > This is due to the very nature of concatenated code: If you specify a stack > effect, and the code doesn't have the stack effect, an automated tool can't > tell you where the mistake is. How should it? The parameter passing is all > implicit, so the tool can't know. But if you are testing your code in small pieces it will be pretty obvious where the problem is. If the tool is checking stack effects at compile time, it surely can tell you which work has the problem. Otherwise what is it checking? >>> So that's my story why typechecking is not useful in Forth - because you >>> have something else, something better: Hands on to your code. >> >> If the tool can save you from having to lay your hands on the code, that >> can be useful and time saving. People take the attitude that type >> checking prevents you from doing things... that is not correct in my >> experience. Type checking simply requires that your code be written to >> clearly show what your intent is rather than relying on default >> behaviors which may depend on implementation details. > > Or not, as Verilog shows: The default behaviors there are specified, and it > just behaves reasonable - you simply don't have to typecast, it just works. > This sort of "explicit is better than implicit" is pretty much the opposite > of Forth, where, as said above, even the parameter passing is all implicit. You make claims about Verilog, but I would like to see some evidence that isn't anecdotal. That was one of my problems trying to justify Forth in the workplace. There isn't any real info on it's advantages, it is all anecdotal. Actually, there are a number of times the lack of type checking will get you into trouble in Verilog. The system makes assumptions about what you are trying to do and you need to be *completely* aware of those assumptions in all cases or it doesn't work right. So Verilog also has a learning curve. The difference is the VHDL issues slow you down until you learn to deal with them. Verilog issues create faulty code until you learn to deal with them. Verilog doesn't "just work". -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-05 18:56 -1000 |
| Message-ID | <_YednQn4OoWSvK_JnZ2dnUU7-KWdnZ2d@supernews.com> |
| In reply to | #33713 |
On 10/5/14 6:12 PM, rickman wrote: > On 10/5/2014 9:44 PM, Bernd Paysan wrote: >> rickman wrote: ... >>> I'm not sure the "fast turnaround time" is that big an advantage. I >>> seem to recall the last time I used a C compiler that it produced >>> results in a small number of seconds. But then I suppose that depends >>> on the size of the program. >> >> Sure. And maybe you underestimate the effect of "a few seconds": The >> flow >> of thinking is definitely broken if you insert a pause of 3 seconds. >> That >> is some sort of "upper limit" of time you can wait for, but it's much >> better >> if you have a delay no more than 0.3 seconds. You should listen to >> people >> who do GUIs and do the actual measurements about how non-responsive >> functions cause problems; this sort of "instant feedback" you get from >> Forth >> is really important. > > I am familiar with the Doherty threshold... lol The compile step is a > natural change of pace in thinking, so the same issue you have in a GUI > doesn't apply to the same extent. When changing from editing to > compile/test the mode of thinking is different so a delay of a small > number of seconds is much more readily accepted without impact on > performance. Ah, but the point is that when you are working in Forth you *don't* have different modes of thinking. It's one continuous creative process. Imagine a sculptor shaping an image in clay with his hands, vs. telling his assistant in the next room to make a change. Even if the assistant is capable and quick, it's still a discontinuity that affects the creative process. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-06 01:34 -0400 |
| Message-ID | <m0t9lo$15n$1@dont-email.me> |
| In reply to | #33714 |
On 10/6/2014 12:56 AM, Elizabeth D. Rather wrote: > On 10/5/14 6:12 PM, rickman wrote: >> On 10/5/2014 9:44 PM, Bernd Paysan wrote: >>> rickman wrote: > .... >>>> I'm not sure the "fast turnaround time" is that big an advantage. I >>>> seem to recall the last time I used a C compiler that it produced >>>> results in a small number of seconds. But then I suppose that depends >>>> on the size of the program. >>> >>> Sure. And maybe you underestimate the effect of "a few seconds": The >>> flow >>> of thinking is definitely broken if you insert a pause of 3 seconds. >>> That >>> is some sort of "upper limit" of time you can wait for, but it's much >>> better >>> if you have a delay no more than 0.3 seconds. You should listen to >>> people >>> who do GUIs and do the actual measurements about how non-responsive >>> functions cause problems; this sort of "instant feedback" you get from >>> Forth >>> is really important. >> >> I am familiar with the Doherty threshold... lol The compile step is a >> natural change of pace in thinking, so the same issue you have in a GUI >> doesn't apply to the same extent. When changing from editing to >> compile/test the mode of thinking is different so a delay of a small >> number of seconds is much more readily accepted without impact on >> performance. > > Ah, but the point is that when you are working in Forth you *don't* have > different modes of thinking. It's one continuous creative process. > Imagine a sculptor shaping an image in clay with his hands, vs. telling > his assistant in the next room to make a change. Even if the assistant > is capable and quick, it's still a discontinuity that affects the > creative process. I don't agree. When working with Forth it still requires planning the sculpture, working on the over all shape using the tools and periodically periodically gauging progress. Then refining the shape, again with more careful and more frequent gauging of progress vs. the goal. Finally work is on the fine detail with constant checking. Each time the sculptor switches from carving to checking the tool has to be moved out of the way and a mental switch is made. I know this is how I work with wood. This is also how I work with code regardless of the language, alternately planning, composing, testing and gauging my progress vs. the planning... repeat. I'm always stopping at points to review and rethink. Every time I reload my code it is a break in the cycle, no matter how short, because it is a mental shift from code to test. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-06 19:57 +0200 |
| Message-ID | <m0ul6o$76u$1@online.de> |
| In reply to | #33713 |
rickman wrote: >>> I don't know that I would use the opinions of students as a good metric. >>> Their skill levels are fairly low compared to professional >>> programmers. I expect their tastes will change as their skill levels >>> change. >> >> I don't think so. Preferrences are set pretty early in education. > > We aren't talking about "preferences", You said "taste". That's a "preference", not a "skill set". > we are talking about skill sets. > I know my techniques of design and debug have changed several times > over my career. The problem is: if the mainstream doesn't have that option (of a Forth-like environment), they will probably never see it. > I am familiar with the Doherty threshold... lol The compile step is a > natural change of pace in thinking, so the same issue you have in a GUI > doesn't apply to the same extent. When changing from editing to > compile/test the mode of thinking is different so a delay of a small > number of seconds is much more readily accepted without impact on > performance. I don't see it as that. The compile step always gets into my way of thinking. If you see coding and testing as something separate, you already have a mindset that doesn't allow you to get into the "flow" Forth programmer experience. Therefore, you don't know what I'm talking about. > There are several thresholds for this. The exact values are quoted > differently, but anything less than about 0.3 seconds is normally not > perceived as a delay. A delay less than about 3 seconds is tolerated > without loosing focus, above 30 seconds is a significant disruption to > workflow and often means the user leaves the task for another. > > As I said, my experience with both C compilers and VHDL compiles is that > the delays are short enough they don't significantly impact my task > completion time. I can't remember a compile that took anywhere near 30 > seconds and often they are less than the 3 second attention threshold. > Your experience may differ. Compiling Gforth after a make clean takes 43s on my core i7 here. That's not a particularly large project... and the majority of the source code is Forth. Compiling gforth.fi from the kernel + image sources takes 0.3s (that includes relocating stuff, so actually the image sources are compiled three times in this 0.3s). >>>> And then you figure out that you urgently want some help from the >>>> compiler, >>>> because your programs all don't run. And the typecheck is giving that, >>>> at least it is giving you the illusion of the compiler doing something >>>> - complaining and making you change the program before you run it. >>> >>> I don't know about "illusion". I think the sort of problems I would >>> have in VHDL from mismatched types can often be the sort that you spend >>> significant debug time finding. >> >> Verilog is about 3 times as productive as VHDL for the same problem >> space. > > I have never seen that substantiated... what do you base this on? John Cooley's competition was really funny: http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley.html That was 90 minutes for a trivial task with 9 Verilog and 5 VHDL participants. 5 fully functional netlists were produced, all of them from Verilog code; the VHDL participats all failed. Two of them acutally complained about being brought down by VHDL's type system: "Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of Easics, both complained of having to deal with type conversions in VHDL. Prasad confessed: "I can't believe I got caught on a simple typing error. I used IEEE std_logic_arith, which requires use of unsigned & signed subtypes, instead of std_logic_unsigned." Jan agreed and added: "I ran into a problem with VHDL or VSS (I'm still not sure.) This case statement doesn't analyze: "subtype two_bits is unsigned(1 downto 0); case two_bits'(up & down)..." But what worked was: "case two_bits'(up, down)..." Finally I solved this problem by assigning the concatenation first to a auxiliary variable."" There were other sources, but I forgot them. This is all early 90s stuff. >> The author of the code went through 5000 lines of code, to >> replace all "+1" of these integers (he had several) with an "when 15 then >> 0 else +1" idiom. > > Sounds to me like a very inexperienced newbie... You are repeating the standard VHDL bigot arguments John Cooley has been collecting: If someone fails in VHDL, it's because he is a clueless newbie. This was someone who taught VHDL to other people at Siemens HL. I'm not at all convinced that his coding style is a good idea, and I think it's a bad idea to teach this coding style to others. But that coding style is found widely in the VHDL world. I've even seen people who later in their career moved to Verilog keeping that coding style. Like you can write Fortran programs in any language, you can write VHDL programs in any HDL. > Why would anyone write > 5000 lines of code before doing any simulation or even a test compile? He did. The 5000 lines compiled, and synthesized (with a warning of 500 latches created from asynchronous processes... doh!). All those corner cases in which the VHDL simulator throw an exception were found by the test code I had written. > How is that a problem with the language? Your assumptions about the reasons were all wrong, so the conclusion that it isn't a problem of the language therefore is very likely to be wrong, too. > Of course no one ever has any problems learning Forth... lol Again: He wasn't a clueless newbie at all. > Sounds like you are not at all familiar with VHDL. If you want a modulo > 16 value you can use a 4 bit unsigned signal. This is easily converted > to an integer when you use it to index an array. I believe the form for > that is to_integer(). Not so hard - is it? It's not about me, I didn't make that design choice of using an integer subtype. The actual problem you refuse to acknowledge is that in a HDL you want an integer mod 2^n type, because that's what you use to build your logic of. Verilog gives you that (it is the only synthesizable type it has), VHDL denies you that. > You have your preferences based on your experiences. I believe you > would have had a similar experience if you didn't know Forth and started > working at a company that used Forth, but didn't really get it and > misused it extensively. The problem is that it was the professionals who ought to know who misused it extensively. The teaching material of HDL on my university was all VHDL, and the TU Munich is one of the best universities in Germany, especially on these electro engineering topics. I chose Verilog, because I looked at teaching material on the internet, and the Verilog stuff all makes way more sense. I then switched an entire small company from VHDL to Verilog in a few months, and all these VHDL coders liked Verilog. They weren't forced to, they were convinced. And not by my arguments, we had bought a "Verilog VHDL side by side" book to make the transition. > What is the incentive to write "big" modules in VHDL? I don't typically > write large ones. The incentive that it is more boilerplate: You need architecture, implementation and instantiation, which all takes way more to type in, especially for small modules, where the implicit port passing of Verilog is acceptable. Maybe we also disagree on what is "large" or "small"... > The only "incentive" I find is that I test all my > modules with a test bench, so I have to construct that framework. I > suppose in Forth you would manually type in the tests, but that wouldn't > fly in a production environment where you need to document your testing, > so each word needs a word to test it... thoroughly. You manually type in the tests while you develop the word. And if you then want to have a regression test, you cut&paste the tests out of the history file - or the command line, because there, you have the result, too. And then wrap them up in a facility like ttester.fs - this is not a word which tests another word. > I mean I write the test bench the same way you would write your test > code in Forth, it reports a pass/fail, not a number for the user to > interpret if that was a valid response. In an HDL you need to consider > values of signals at various times. This is very hard to do without a > good test bench or a lot of manual examination of detailed waveforms. > Not very much like software really. There's something I don't understand about many hardware designer, and that is this "not very much like software" stuff. My stuff usually is pretty small, and involves a microcontroller or similar microcode sequencer. This stuff is behaving like software, it is pretty fast to develop, it is robust and small, easy to get bug-free, doesn't consume much space on the chip, etc. And it just works a lot better than the "not like software" big state machines of the hardware engineers. And yes, I've written fancy test benches for these big state machines of the hardware engineers, too - I pretty well know what it takes to make them. You know what happened with the big state machine of this coworker? The other two people in the team, me and another VHDL guy, got fed up with debugging this hopeless stuff, and I designed a small CPU, which my coworker implemented. This did the same job in much less gate space, but the higher up bosses shelfed that approach, because our rescue came too late: The entire project had been so much out of budget that it was completely shelfed. I then left Siemens HL (I was just a consultant, and hired for that particular project), I think our approach was rescued a few months later. > But if you are testing your code in small pieces it will be pretty > obvious where the problem is. If the tool is checking stack effects at > compile time, it surely can tell you which work has the problem. > Otherwise what is it checking? It is checking the whole definition, all words together. One of these words doesn't have the stack effect I'm thinking it should have, and that's what causes the problem. However, the compiler can't know what I'm thinking, therefore, it can't tell me which particular word causes the problem. That's not a problem if your definition is just using one single word. But that's the silly cornercase ;-). > You make claims about Verilog, but I would like to see some evidence > that isn't anecdotal. That was one of my problems trying to justify > Forth in the workplace. There isn't any real info on it's advantages, > it is all anecdotal. I don't think that e.g. the stuff Paul Benett does qualifies as "anecdotal" - he has all his certificates to proof that his high reliability stuff really is high reliable. I think people just like to dismiss reports that don't fit into their believe system as "anecdotal". I've recently watched a presentation about getting towards scientific analysis of software engineering, i.e. providing solid studies instead of all the anecdotal evidence we have, and the conclusion was that solid studies cost an awful lot (it's just like a phamaceutical trial study). But the results of these few solid studies we actually have, all back up methods we have used in Forth for 40 years. Dismissing them, even though several of these methods are now backed up by solid studies is silly. > Actually, there are a number of times the lack of type checking will get > you into trouble in Verilog. The system makes assumptions about what > you are trying to do and you need to be *completely* aware of those > assumptions in all cases or it doesn't work right. Yes, that is true. That is true for every programming language - you always have to be completely aware of everything. The assumptions Verilog makes are very straight-forward and simple, which is why it doesn't take long to learn - the "everything" space is much less than with VHDL's contrived type system, which gives you almost everything, except the thing you actually need. > So Verilog also has > a learning curve. The difference is the VHDL issues slow you down until > you learn to deal with them. Verilog issues create faulty code until > you learn to deal with them. Verilog doesn't "just work". You need to be completely aware that all bit vectors in Verilog are mod 2^n numbers, that bits and bit vectors can be assigned to each other, concatenated together forming another bit vector, and you can select parts of bit vectors, creating new bits or bit vectors (depending on the selection style). That's all. That's a natural fit to what you want in a HDL. VHDL's type system doesn't fit, and therefore, it always gets into your way, newbie or expert. And the resulting code doesn't work, even though the VHDL bigot always tells you that the compiler catches all bugs. That's, because the VHDL bigot took a week to get his code to compile, and then is too exhausted to run extensive tests. I did run these tests, and they found tons of bugs, in the code declared bug-free by the VHDL bigot, because he finally managed to compile it (because it took so long to make it compile! Proof by effort!). It wasn't. The "when 15 then 0 else +1" wasn't the only type system cockup this code had. Your assumption is when you make an explicit typecast, you are aware of what you are doing. With a type system with std_logic, std_ulogic, int, subsets of int, tuples, and whatnot, you can't get your head around all this mess. You don't know what you are doing. You are inserting typecasts to make the damn'd thing compile. In Verilog, when you concat two bit vectors, the result is not a tuple, which is type-incompatible to everything else, it's just another bit vector. It just works - the default behavior fits the assumption you make about how it should work. In VHDL, it just doesn't work. And it's not just me who can't get his head around VHDL. I know that a lot of people can only think complex, and can't find simple solutions. Maybe they also don't *want* to have a simple solution. But nonetheless, the complexity they create doesn't work. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web