Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #35035 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2014-12-19 15:59 -0800 |
| Last post | 2014-12-23 15:16 +0000 |
| Articles | 20 on this page of 340 — 34 participants |
Back to article view | Back to comp.lang.forth
FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2014-12-19 15:59 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-20 08:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-20 03:40 -0600
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-20 13:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-21 04:38 -0600
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-21 21:38 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-21 16:32 -0600
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-22 03:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! mhx@iae.nl - 2014-12-22 00:53 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-22 13:43 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 02:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 03:38 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 02:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2014-12-22 11:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! rickman <gnuarm@gmail.com> - 2014-12-22 07:51 -0500
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2014-12-22 15:59 +0000
Re: FORTH on the Advanced Placement Computer Science ! rickman <gnuarm@gmail.com> - 2014-12-23 11:17 -0500
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 02:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 06:09 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2014-12-23 12:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 13:12 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 07:57 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-23 10:31 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 12:27 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-23 15:04 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 19:28 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-25 02:43 -0600
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-25 20:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 11:43 +0000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-25 20:40 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 13:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2014-12-26 11:40 -1000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-05 19:33 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-05 21:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-05 21:33 -1000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-06 10:24 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 10:13 -1000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 00:41 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 14:59 -1000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-06 11:53 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 10:16 -1000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 18:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 12:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 18:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2014-12-25 12:46 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 14:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2014-12-27 09:48 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-27 12:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2014-12-29 13:08 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 20:13 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 20:21 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 12:39 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-23 15:16 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 17:40 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-24 05:34 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 21:12 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-24 12:40 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 09:40 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 08:52 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 09:18 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 11:14 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-24 12:53 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 09:15 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 12:07 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 11:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-24 03:26 -0600
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-25 19:45 +0100
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-24 05:31 +0100
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-24 03:28 -0600
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-24 11:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 22:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 14:27 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 22:58 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 15:38 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 02:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 19:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 06:30 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 22:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 07:15 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 23:32 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 10:39 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 10:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 01:21 +0100
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 09:06 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 09:39 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 21:15 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-25 23:34 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 17:09 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 02:22 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 17:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 05:22 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 14:00 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 16:13 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-27 09:50 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-27 04:41 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-27 10:21 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-30 11:50 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-31 15:02 +0100
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-26 03:28 -0600
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-26 10:35 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-26 14:54 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-26 16:36 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-26 21:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-27 10:17 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-27 12:09 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-01 21:07 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-02 11:42 -0800
Re: FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2015-01-02 12:45 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-02 23:42 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-04 14:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-06 03:51 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-05 20:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-05 19:25 -1000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 14:52 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-09 08:04 +0300
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:14 -1000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-09 16:25 +0300
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-09 09:10 -1000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 14:35 +0300
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-10 20:51 -1000
Re: FORTH on the Advanced Placement Computer Science ! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-11 11:29 +0100
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-11 03:46 -0800
Re: FORTH on the Advanced Placement Computer Science ! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-11 15:58 +0100
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 23:01 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-11 16:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-11 16:50 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 08:53 +0300
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-12 08:28 +0000
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-12 11:10 +0000
Re: FORTH on the Advanced Placement Computer Science ! stephen@mpeforth.com (Stephen Pelc) - 2015-01-11 11:30 +0000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-11 16:56 +0300
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 19:47 +0000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 08:03 +0300
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2015-01-11 23:44 +0100
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 09:05 +0300
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-12 10:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-31 10:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2015-01-09 23:01 +0100
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 14:43 +0300
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2015-01-11 23:45 +0100
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 09:09 +0300
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-09 10:52 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 15:31 +0300
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-05 23:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-05 22:22 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 08:41 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 10:30 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 13:37 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 13:02 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 15:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 01:15 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 15:23 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 19:25 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 17:52 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 21:15 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 19:30 -1000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 05:07 -0600
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-07 15:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 12:41 -0600
Re: FORTH on the Advanced Placement Computer Science ! Elizabeth D Rather <erather@forth.com> - 2015-01-07 11:09 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 08:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-07 11:52 +0000
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-09 14:14 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-09 20:04 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-10 20:57 -1000
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-11 08:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-11 19:59 +0000
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-11 22:51 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-15 22:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-16 08:56 -0800
Re: FORTH on the Advanced Placement Computer Science ! Mark Wills <markwills1970@gmail.com> - 2015-01-07 01:54 -0800
Re: FORTH on the Advanced Placement Computer Science ! stephen@mpeforth.com (Stephen Pelc) - 2015-01-07 12:33 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-07 14:25 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-07 16:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 15:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-07 06:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 08:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-07 10:06 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-07 18:09 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-07 10:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 16:48 +0300
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 16:25 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 08:50 -1000
Re: FORTH on the Advanced Placement Computer Science ! mhx@iae.nl - 2015-01-07 10:37 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 16:32 +0000
Re: FORTH on the Advanced Placement Computer Science ! Doug Hoffman <glidedog@gmail.com> - 2015-01-09 18:28 -0500
Re: FORTH on the Advanced Placement Computer Science ! Doug Hoffman <glidedog@gmail.com> - 2015-01-07 07:31 -0500
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 16:24 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-08 14:02 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-08 09:26 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-08 17:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-08 11:01 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-07 17:18 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 09:44 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 09:31 +0000
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 03:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 15:21 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 18:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 09:40 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-08 14:49 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-08 17:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 04:42 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 08:13 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 02:52 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-08 18:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-08 20:29 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:30 -1000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-09 11:14 -0800
Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-09 22:18 +0000
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-10 03:15 +0100
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-09 20:56 -0800
Re: Standards (was FORTH on the ...) "WJ" <w_a_x_man@yahoo.com> - 2015-01-12 03:02 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-12 10:14 +0000
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-10 11:39 -0800
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-13 18:08 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-13 20:04 +0000
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-14 02:43 +0100
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-14 13:34 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-15 02:03 +0000
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-15 12:03 +0000
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-15 06:47 -0800
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-10 19:15 +0000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-10 12:52 -0800
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-10 19:05 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-11 09:28 -0800
Re: Standards (was FORTH on the ...) "Elizabeth D. Rather" <erather@forth.com> - 2015-01-11 14:45 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-12 18:28 -0800
Re: Standards (was FORTH on the ...) Elizabeth D Rather <erather@forth.com> - 2015-01-12 17:12 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-12 20:55 -0800
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-13 03:48 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-13 06:05 -0800
Re: Standards (was FORTH on the ...) Julian Fondren <julian.fondren@gmail.com> - 2015-01-13 06:34 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-13 06:51 -0800
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-13 08:03 -0800
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-13 19:18 -0800
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-13 08:26 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-13 09:54 -0800
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-13 17:35 +0000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-13 18:19 -0800
Re: Standards (was FORTH on the ...) "WJ" <w_a_x_man@yahoo.com> - 2015-01-14 21:03 +0000
Re: Standards (was FORTH on the ...) "WJ" <w_a_x_man@yahoo.com> - 2015-01-14 21:07 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-15 01:06 +0000
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-15 00:52 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-15 01:17 -0800
Re: Standards (was FORTH on the ...) "Elizabeth D. Rather" <erather@forth.com> - 2015-01-15 17:35 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-15 20:38 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-16 10:47 -0800
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-16 20:47 +0100
Re: Standards (was FORTH on the ...) krishna.myneni@ccreweb.org - 2015-01-16 14:37 -0800
Re: Standards (was FORTH on the ...) krishna.myneni@ccreweb.org - 2015-01-16 17:26 -0800
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 03:03 +0100
Re: Standards (was FORTH on the ...) "Elizabeth D. Rather" <erather@forth.com> - 2015-01-13 10:40 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-13 19:04 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 23:24 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 18:09 +0100
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-09 09:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-09 11:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 22:38 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-16 13:44 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 02:39 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-17 13:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 18:44 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-18 12:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-18 22:48 +0100
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-19 03:10 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-18 18:41 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-17 11:45 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-17 17:57 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-18 14:57 -0800
Re: FORTH on the Advanced Placement Computer Science ! awegel@arcor.de (Alexander Wegel) - 2015-01-19 00:49 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-19 15:04 +0000
Re: FORTH on the Advanced Placement Computer Science ! beeflo <beeflobill@gmail.com> - 2015-01-19 16:24 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 03:26 +0100
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2015-01-20 04:23 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-23 21:42 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-20 20:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-20 07:10 +0000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-20 12:04 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-20 16:11 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-20 20:40 -0800
Re: FORTH on the Advanced Placement Computer Science ! Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-01-20 23:29 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-20 20:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-21 01:55 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-22 00:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! Mark Wills <markwills1970@gmail.com> - 2015-01-19 07:42 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-06 09:50 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 04:38 -0600
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-09 21:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2015-01-09 23:28 -0800
Re: FORTH on the Advanced Placement Computer Science ! "hughaguilar96@yahoo.com" <hughaguilar96@gmail.com> - 2015-01-10 11:10 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2015-01-11 00:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-12 22:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-12 17:33 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-12 19:17 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-12 21:06 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-13 04:08 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-13 15:00 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-13 18:45 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-13 21:12 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-16 20:41 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-21 20:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-21 23:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-26 20:20 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-05 10:31 +0000
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-27 07:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-27 13:08 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2014-12-27 10:54 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-27 11:01 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2014-12-27 21:25 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-29 05:20 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-04 11:53 +0000
Re: FORTH on the Advanced Placement Computer Science ! mhx@iae.nl - 2015-01-04 05:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2015-01-04 08:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2014-12-26 15:00 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 13:35 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 10:55 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 07:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 23:27 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 10:34 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 09:47 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 19:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 11:00 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 12:01 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 16:03 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 17:20 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2014-12-26 21:53 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-08 22:30 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-25 20:00 +0100
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 08:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-25 19:36 +0100
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-05 19:09 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-23 15:35 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-05 19:16 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 15:51 +0000
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2014-12-21 16:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2014-12-22 10:51 -0800
Re: FORTH on the Advanced Placement Computer Science ! JUERGEN <epldfpga@aol.com> - 2014-12-22 05:47 -0800
Re: FORTH on the Advanced Placement Computer Science ! rickman <gnuarm@gmail.com> - 2014-12-22 09:10 -0500
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-22 15:23 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-23 15:16 +0000
Page 6 of 17 — ← Prev page 1 … 4 5 [6] 7 8 … 17 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-12-26 14:54 -0800 |
| Message-ID | <7xbnmquimp.fsf@ruckus.brouhaha.com> |
| In reply to | #35267 |
Tom O'Donnell <tod@nospam.com> writes: > What you said isn't the reason. Assembler is completely appropriate > and the best choice for systems programming in this environment. You're saying the environment has special demands that can only be filled by asm, so you have to you use asm come what may. That is fine. But you can't say asm is the best "choice", since if there's no practical alternative then it's not really a choice at all. > We are not talking about application programming. Right, at least in the application area (contra Melzzz), asm isn't competitive with COBOL. > Consider the IBM assembler a DSL for systems programming on IBM > mainframes because that's exactly what it is. 1) I'd still like to get a sense of what "system programming" means in your industry. I.e. a customer or your marketing dept asks for a new feature. Since they are not programmers themselves, they describe the desired feature in terms of the new functionality that they want, rather than how it is implemented. What would a typical such request look like? 2) Is z/OS asm programming somehow easier than in other OS's? 2x easier? 5x? Like if I wanted to write a new system program under Linux, in principle I could use assembler but in practice I probably wouldn't. If the tradeoff is different on z/OS because HLL's on z/OS are harder to use than on Linux, that just means z/OS is a pain. If it's because z/OS asm is easier than Linux asm, then that's interesting. > The OS is not a legacy OS. It's the oldest OS still being *developed* > sold and marketed. The clocks on mainframe CPUs are up to over 5 > GHz. There's tons and tons of high tech in every mainframe. The use of > "legacy" to describe any of this is factually wrong. My impression is that there are very few new mainframe customers these days, especially running those OS's. Most anyone who buys a z/OS system today does it to upgrade or augment their existing installation, i.e. so they can keep running their old COBOL applications. That's what I mean by legacy. New customer means they have never had a mainframe before, but after evaluating their requirements they decide to buy one. How often does that happen? IBM tries to also sell mainframe hardware to run containerized Linux, but that's somewhat different and I don't know how successful it is. > that crashing isn't acceptable ever, failures have to leave all > resources in known, consistent states... We also have to build in ways > to fix the product in the field right now when somebody is down. Those requirements are why Erlang was invented ;-). > Mainframes scale up, not out. Your stuff has to work on not require a > failover box. They may have some load balancing and failover but we can't > rely on that. Our stuff has to stay up. If it doesn't heads roll. In the Erlang world they say there's no such thing as a reliable non-distributed system, since the power cord is a single point of failure. They build their stuff (phone switches) to stay running for 40 years with zero downtime. They can do complete hardware and software replacements without dropping any calls, by hot-patching code and adroitly moving connections between boards. And what is Erlang? Basically a restricted Lisp with multitasking and distribution features. >Yes, it takes longer to design a Boeing 747 than it takes to design a >Piper Cub because the values are different. All that costs money. I don't know about the 747, but the 787 is being done in Ada: http://www.adacore.com/customers/787-dreamliner-common-core-system/ Doing it in assembler would be terrifying, besides being much more expensive.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2014-12-26 16:36 -0800 |
| Message-ID | <3d03e403-7181-4ab3-8a2f-a23d0c4843f7@googlegroups.com> |
| In reply to | #35276 |
On Friday, December 26, 2014 4:54:42 PM UTC-6, Paul Rubin wrote: > Tom O'Donnell <tod@nospam.com> writes: > > What you said isn't the reason. Assembler is completely appropriate > > and the best choice for systems programming in this environment. ... > I don't know about the 747, but the 787 is being done in Ada: > > http://www.adacore.com/customers/787-dreamliner-common-core-system/ > > Doing it in assembler would be terrifying, besides being much more > expensive. Really? Why would it be more terrifying to write a large portion of it in assembler? And, on what basis do you think it might be significantly more expensive? From a reliability point of view, I might suggest that well-debugged assembler code is more reliable than code written in a high-level language, where there is a more mysterious black box between the code one writes, and the machine instructions themselves. I coded the virtual machine and many primitives for kForth in assembler. Originally, I wasn't entirely sure that it was the right approach because of the problems of portability. Today, I'm convinced it was the right approach. My VM has control of the machine registers, not a C compiler. This turns out to be critical for implementing a robust and simple interface between Forth code and assembly code. The VM is dirt simple and robust, and I've had to do little maintenance on the Forth primitives which were coded in assembly to start with. Now, this is certainly no large scale application, but I wouldn't bet that the approach can't scale to large pieces of software. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-12-26 21:19 -0800 |
| Message-ID | <87y4pt4qkl.fsf@jester.gateway.sonic.net> |
| In reply to | #35280 |
krishna.myneni@ccreweb.org writes: >> the 787 is being done in Ada > Really? Why would it be more terrifying to write a large portion of it > in assembler? Much more code written by humans, so much more places for those humans to make errors. Lack of machine-checked assurance for just about anything. > And, on what basis do you think it might be significantly more > expensive? Increased development and analysis time, mostly. > From a reliability point of view, I might suggest that well-debugged > assembler code is more reliable than code written in a high-level > language, where there is a more mysterious black box between the code > one writes, and the machine instructions themselves. The Ada critical systems crowd seems to want formal verification of the absence of many types of errors (not all errors). No amount of debugging can assure that. Verification is harder to do in assembler than Ada afaik. > I coded the virtual machine and many primitives for kForth in > assembler. ... The VM is dirt simple and robust There's perfectly reasonable, the Ada runtime (or any other language at its lowest level) also has to be in assembler. Then you have a higher level (Forth in this case) running on top of that. > Now, this is certainly no large scale application, but I wouldn't bet > that the approach can't scale to large pieces of software. If it were that practical then why did you bother implementing Forth, instead of coding in assembler directly?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-12-27 10:17 +0000 |
| Message-ID | <2014Dec27.111715@mips.complang.tuwien.ac.at> |
| In reply to | #35285 |
Paul Rubin <no.email@nospam.invalid> writes:
>Verification is harder to do in assembler
>than Ada afaik.
Doubtful.
1) Ada is a more complex language.
2) Verification of code code used to be (maybe still is) done by
verifying the assembly output of the compiler.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-12-27 12:09 -0800 |
| Message-ID | <878uhs4zxk.fsf@jester.gateway.sonic.net> |
| In reply to | #35290 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>Verification is harder to do in assembler>than Ada afaik. > Doubtful. > 1) Ada is a more complex language. Ada is a more restricted language so it's easier to prove things about program behaviour. Also the source code comes supplies some verification info for "free", e.g. that some classes of type errors are absent (or else the program won't compile). Finally there are more tools available, like SPARK etc. > 2) Verification of code code used to be (maybe still is) done by > verifying the assembly output of the compiler. That would be a separate verification, maybe reserved for the most critical parts of the most critical programs. The stuff I've looked at operates just on the Ada program.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-01 21:07 +0100 |
| Message-ID | <m849cr$15b$1@dont-email.me> |
| In reply to | #35298 |
Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>>Verification is harder to do in assembler>than Ada afaik. >> Doubtful. >> 1) Ada is a more complex language. > > Ada is a more restricted language so it's easier to prove things about > program behaviour. Also the source code comes supplies some > verification info for "free", e.g. that some classes of type errors are > absent (or else the program won't compile). How many of these errors are actually happening? Paul Bennett on EuroForth presented a slide which shows that 44% of the bugs are specification bugs. No amount of formal verification can detect specification bugs. A specification bug is a mismatch between what you really want and what you specified. These are the worst bugs, the most expensive ones, because you only find them when your product meets reality. On the other hand, there are bugs in Ada where the program compiles, but the type system still causes surprises to the programmer. The idea that a typesystem catches all type bugs is silly, because maybe Ada doesn't even have the types the user wants. What about saturated arithmetics for values which may overflow, but an overflow should be handled gracefully? And how much effort is it to use that type? http://compgroups.net/comp.lang.ada/saturation-arithmetic-woes/1411714 This tells a story that using Ada is far from easy. The impression I have with Ada programmers is that they are 100% exhausted when their program finally compiles, so they simply omit the testing part, and pray that the promise of "Ada programs, once compiled, run flawless" holds. It doesn't. Furtermore, with huge bloated compilers, you can't even trust your compiler. I haven't looked up how many unresolved bugs GCC's Ada frontend has, but GCC's backend (used by everything) has way too many bugs to be trustwurthy. I know it miscompiles, you should know it, too. And "miscompile" here even includes miscompilation where the GCC team agrees, and which could be solved by formal matching of source and assembly language. But GHC is even worse: you have a wonderful framework with a really clever typesystem, and the compiler is so buggy that you can't rely on it. > Finally there are more > tools available, like SPARK etc. > >> 2) Verification of code code used to be (maybe still is) done by >> verifying the assembly output of the compiler. > > That would be a separate verification, maybe reserved for the most > critical parts of the most critical programs. The stuff I've looked at > operates just on the Ada program. Due to the fact that many Verilog and VHDL synthesis tools of the 90s did miscompile Verilog and VHDL, and produce netlists that did something else, the formal verification step (i.e. to compare RTL vs. netlist) became a routine job in the chip design flow, and did a good job to detect the bugs in the synthesis tools, so by 2010, the tools were rock solid, and the formal verification was just another annoying thing to do, with little benefit. The actual problem for unreliable systems IMHO is bloat. Almost half of the bugs are in the spec, and therefore outside of the scope of most formal method, including testing - only the "release often, release early" methology is known to find spec bugs; but only so if the maintainer is willing to accept the existence of spec bugs (the GCC maintainer don't). That means the only way to get to reliable software is to make it compact and simple, so that you don't have a gazillion features most people never use, but only those essential to your users. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-02 11:42 -0800 |
| Message-ID | <871tnd9dg0.fsf@jester.gateway.pace.com> |
| In reply to | #35401 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >> Also the source code comes supplies some verification info for >> "free", e.g. that some classes of type errors are absent (or else the >> program won't compile). > How many of these errors are actually happening? I'm not sure what you mean by this question. I get type errors all the time when developing. Most of them are fairly trivial. With static types I look at the line pointed to by the compiler, see what's wrong, and fix it. With runtime checks (like in Lisp or Python) the error shows up in testing, and there's a crash with a stack trace saying what happened and pointing to the offending line, so I see what's wrong and fix it, though this is often less convenient than getting the problem reported at compile time. With no checks (like in assembly language) there's more likely to be silent memory corruption followed by a crash sometime later, with a bunch of annoying debugging needed to figure out what happened. I get the idea that by being extra careful when programming, one can avoid a lot of these errors happening in the first place; but taking that to its conclusion, a sufficiently careful programmer should never need to test code at all. Just write it perfectly and ship it without testing because you know you got it right. Experience shows that this is not a practical approach. Programmers make errors, the errors have to be observed before they can be fixed, and anything the computer can do to help you observe the errors is generally a goodness. > Paul Bennett on EuroForth presented a slide which shows that 44% of > the bugs are specification bugs. That's interesting, is it online? > On the other hand, there are bugs in Ada where the program compiles, > but the type system still causes surprises to the programmer. Not sure if you're getting at anything in particular here. > The idea that a typesystem catches all type bugs is silly, because > maybe Ada doesn't even have the types the user wants. Tautologically, the type system catches exactly the bugs that the type system catches. Lots of the activity in language design these days is designing type systems that look for a sweet spot between expressiveness and convenience. Ada's type system is rather primitive compared to Haskell's. Haskell's type system is relatively fine grained and (if you stay away from the more advanced hackery) fairly convenient, making Haskell fun to use. Coq's is even finer grained than Haskell, but far less convenient. > What about saturated arithmetics for values which may overflow, but an > overflow should be handled gracefully? And how much effort is it to > use that type? > http://compgroups.net/comp.lang.ada/saturation-arithmetic-woes/1411714 I looked at that thread but again I'm not sure what you're getting at. The person tried to use Ada generics and ran into a snag, so he asked for help and got some. What's the issue? > This tells a story that using Ada is far from easy. The impression I have > with Ada programmers is that they are 100% exhausted when their program > finally compiles, so they simply omit the testing part, and pray that the > promise of "Ada programs, once compiled, run flawless" holds. It > doesn't. There's never been such a promise about Ada. Every programmer makes errors, both subtle errors and silly ones. Type checking generally can't do much about subtle errors, but it catches a surprisingly helpful amount of the silly ones. I haven't actually used Ada so I'm having a hard time imagining the exhaustion you're describing about getting programs to compile: could it possibly be as annoying as C++? Dealing with those errors are just part of the process. From everything I've heard about Ada shops, they tend to be very rigorous and process-driven about design, testing, documentation, etc. As a consequence, they burn a lot of money, but their stuff tends to work solidly. > I haven't looked up how many unresolved bugs GCC's Ada frontend has, but > GCC's backend (used by everything) has way too many bugs to be trustwurthy. > I know it miscompiles, you should know it, too. And "miscompile" here even > includes miscompilation where the GCC team agrees, and which could be solved > by formal matching of source and assembly language. But GHC is even worse: > you have a wonderful framework with a really clever typesystem, and the > compiler is so buggy that you can't rely on it. It's not a great situation but people do ship critical systems compiled by both GCC and GHC. Obviously any such systems have to be tested very thoroughly no matter how verified they are, and I know sometimes critical systems developers will check the emitted assembly code to make sure it's what they want. But, the compilers have evolved enough by now that the remaining compiler bugs are mostly in places that don't affect realistic code. And, any user-code bugs found by static analysis don't have to be found by testing, so that reduces the number of test-debug iterations. So static analysis is still helpful. There's a paper "the unreasonable effectiveness of testing" that explains why verification hasn't gotten that much traction in mainstream programming, fwiw. > The actual problem for unreliable systems IMHO is bloat. Almost half of the > bugs are in the spec, and therefore outside of the scope of most formal > method, including testing - only the "release often, release early" > methology is known to find spec bugs; but only so if the maintainer is > willing to accept the existence of spec bugs (the GCC maintainer > don't). The GCC maintainer takes the view that someone claiming there is a spec bug ought to be able to convince the standards committee that there is a bug. If that doesn't happen, it's just a difference of opinion between the complainer and the standards committee. > That means the only way to get to reliable software is to make it compact > and simple, so that you don't have a gazillion features most people never > use, but only those essential to your users. There's something to be said for that, although a paper by Regehr that I linked a while back says that TCC has more bugs than GCC since it hasn't been banged on as much.
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2015-01-02 12:45 -0800 |
| Message-ID | <bd4a2a8b-a037-4056-89fa-0b59b505de14@googlegroups.com> |
| In reply to | #35413 |
On Friday, January 2, 2015 2:42:44 PM UTC-5, Paul Rubin wrote: > > There's a paper "the unreasonable effectiveness of testing" that > explains why verification hasn't gotten that much traction in mainstream > programming, fwiw. Thanks for this paper, Paul! It's an amazing praise on Forth: "Think about what you need to test your code. You need to be able to test its components in isolation, or test a subset of its components. To do this, you need to be able to assemble the components of your system in different configurations, with components missing, stubbed, or mocked out. If you want to stub components out, they need simple interfaces, that can be readily faked/stubbed/mocked... Look carefully at these requirements. They're also the requirements for re-usable, modular code. At some point in the future, you'll need to re-use your code for something you never thought of. When that happens, you'll thank your lucky stars that your system's composed of small, interchangable components, that have simple interfaces, that can be recombined in different ways, and aren't bound too tightly to each other, or your current configuration. Similarly, at some point in the future, a nasty bug will show up in your code. When that happens, you'll be glad that the bug is confined to a small, easily replacable component, and not woven into the fabric of your application. I've been there. I was working on a project that had a front-end and a back-end. I wanted to be able to test the front-end in isolation, so I added the ability to inject a stub back-end. A few weeks later, a requirement surfaced which required the back-end to be configurable. So, a piece of code that was originally added to facilitate testing was pressed into service for a production requirement." Source: http://blog.trustiv.co.uk/2013/03/unreasonable-effectiveness-testing James Pickering writes "I specialise in Java, Unix, and Open Source" - does he mean "Forth" when writing "Open Source"? We should thank our lucky stars that our Forth system's are composed of small, interchangable components, that have simple interfaces, that can be recombined in different ways, and aren't bound too tightly to each other, or your current configuration! I wrote this as a comment to his blog and got the answer "Your comment has been queued for review by site administrators and will be published after approval." Would be the first published blog there for nearly a year! Happy New Year!
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-02 23:42 +0100 |
| Message-ID | <m876ri$huv$1@dont-email.me> |
| In reply to | #35413 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Also the source code comes supplies some verification info for >>> "free", e.g. that some classes of type errors are absent (or else the >>> program won't compile). >> How many of these errors are actually happening? > > I'm not sure what you mean by this question. I get type errors all the > time when developing. Most of them are fairly trivial. I get type errors all the time when developing with C and alike, and I fix them by adding the correct typecast. Which means the whole thing was perfectly ok, I just didn't tell the compiler to shut up. With an OOP system, I would agree that your compiler should check that you are using the right member variables and methods that are applicable to the object you have, and not for some other objects; in Forth OOP systems you typically implement this by using a per-class wordlist. So you can't find the member variables and methods if you aren't in the right context, and that can be considered as a type error of sorts. Or a scope error, which it really is. I've to add such a thing to Mini-OOF2, because there isn't any protection for that now. > With static > types I look at the line pointed to by the compiler, see what's wrong, > and fix it. With runtime checks (like in Lisp or Python) the error > shows up in testing, and there's a crash with a stack trace saying what > happened and pointing to the offending line, so I see what's wrong and > fix it, though this is often less convenient than getting the problem > reported at compile time. So you think testing is less convenient than compiling? I've heard that from other people, too, and I think if testing is less convenient than compiling, you are in deep trouble. As you say, you can program as carefully as you like, humans make mistakes, and testing is important. If your development environment makes testing a second-class method of getting correctness, and compiling a fist-class method, you will try to push every correctness stuff on the compilation. But we know you can't. And testing includes verifying the assumptions vs. reality, i.e. if the spec sucks, testing can help finding that, too. Not the unit-test one, where you just check if you meet the spec, of course. > With no checks (like in assembly language) > there's more likely to be silent memory corruption followed by a crash > sometime later, with a bunch of annoying debugging needed to figure out > what happened. I understand what you mean. > I get the idea that by being extra careful when programming, one can > avoid a lot of these errors happening in the first place; but taking > that to its conclusion, a sufficiently careful programmer should never > need to test code at all. Just write it perfectly and ship it without > testing because you know you got it right. Experience shows that this > is not a practical approach. Programmers make errors, the errors have > to be observed before they can be fixed, and anything the computer can > do to help you observe the errors is generally a goodness. No, the question was how many bugs of the total number of bugs are type errors. In comparison to other typical bugs. >> Paul Bennett on EuroForth presented a slide which shows that 44% of >> the bugs are specification bugs. > > That's interesting, is it online? Of course all the EuroForth presentations are online, both the slides and the videos, in the usual place: http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/ >> On the other hand, there are bugs in Ada where the program compiles, >> but the type system still causes surprises to the programmer. > > Not sure if you're getting at anything in particular here. Typical example: Out-of-range behavior. You have somewhat four possibilities to handle integer-out-of-range: 1. Wraparound (that's what the machine does) 2. Trap on overflow/underflow 3. Saturation 4. Dynamically increase the size of the integer >> The idea that a typesystem catches all type bugs is silly, because >> maybe Ada doesn't even have the types the user wants. > > Tautologically, the type system catches exactly the bugs that the type > system catches. Lots of the activity in language design these days is > designing type systems that look for a sweet spot between expressiveness > and convenience. Ada's type system is rather primitive compared to > Haskell's. Haskell's type system is relatively fine grained and (if you > stay away from the more advanced hackery) fairly convenient, making > Haskell fun to use. Coq's is even finer grained than Haskell, but far > less convenient. Yes, Haskell has one of the most convenient type systems, because it is building on type inference, which is much easier to use than a traditional Algol-style type system. >> What about saturated arithmetics for values which may overflow, but an >> overflow should be handled gracefully? And how much effort is it to >> use that type? >> http://compgroups.net/comp.lang.ada/saturation-arithmetic-woes/1411714 > > I looked at that thread but again I'm not sure what you're getting at. > The person tried to use Ada generics and ran into a snag, so he asked > for help and got some. What's the issue? That it's too complicated to be used. The thing is that the compiler should support the programmer, and not work against him. You can argue that Haskell generics are easier to use, and that's actually true. The conclusion therefore is that strong typechecking and having generics is not helpful just because it is there; it must be convenient and easy to use to be useful. Just like when you say that you find it easier to get your bugs figured out by the compiler instead of by testing: that is an indication that your framework is weak at testing, and needs improvement. > There's never been such a promise about Ada. Every programmer makes > errors, both subtle errors and silly ones. Type checking generally > can't do much about subtle errors, but it catches a surprisingly helpful > amount of the silly ones. I haven't actually used Ada so I'm having a > hard time imagining the exhaustion you're describing about getting > programs to compile: could it possibly be as annoying as C++? Even worse! > Dealing > with those errors are just part of the process. From everything I've > heard about Ada shops, they tend to be very rigorous and process-driven > about design, testing, documentation, etc. As a consequence, they burn > a lot of money, but their stuff tends to work solidly. Apparently, it seems to be much easier to get a Forth program through the necessary audit processes involved in that typical environment, which is Paul Bennett's job. > It's not a great situation but people do ship critical systems compiled > by both GCC and GHC. Obviously any such systems have to be tested very > thoroughly no matter how verified they are, and I know sometimes > critical systems developers will check the emitted assembly code to make > sure it's what they want. But, the compilers have evolved enough by now > that the remaining compiler bugs are mostly in places that don't affect > realistic code. Considering that we have to work around new bugs in GCC for every new release of GCC in Gforth, that statement is not matching with my reality. And the last versions of GCC even broke very popular programs like x264 - even though they had broken the reference implementation of h.264 (which is a SPEC benchmark they care about) and they just fixed the problem in the h.264 code, and not the very similar problem in x264. > And, any user-code bugs found by static analysis don't > have to be found by testing, so that reduces the number of test-debug > iterations. So static analysis is still helpful. Well, there is the tradeoff of making it harder to program, when the type system is annoying and gets into your way. You sound like there is a zero cost attached to the static analysis, which certainly isn't the case. Static analysis is helpful, if its costs are less than those of testing the thing. Haskell goes into the direction of reducing the cost of the static typesystem to make it actually fun to use (which it usually isn't), and Forth goes the direction to reduce the cost of testing to make it actually fun. On the other hand, Forth tries to do very little to do static analysis (apart from scoping in OOP extensions). > There's a paper "the unreasonable effectiveness of testing" that > explains why verification hasn't gotten that much traction in mainstream > programming, fwiw. I've only found this: http://blog.trustiv.co.uk/2013/03/unreasonable-effectiveness-testing This blog entry with the same title actually says something different: The process of planning to test your stuff alone reduces the errors (even without ever running the tests), because you need to factor your code so that the components are testable. And the factored definitions are easier to write, and therefore easier to get right, easier to maintain. So the corollary is that if you find it hard to test your stuff, you already have done something wrong. To be honest, there is a pretty big overlap between functional language programming and Forth from the approach how to solve things, and the only difference is with typechecking and garbage collection. We Forthers think these two are annoying complexities, and the functional programming language users think they are extremely important. Worth to watch from the 31c3: http://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_saal_2_-_201412271245_-_trustworthy_secure_modular_operating_system_engineering_-_hannes_-_david_kaloper.html#video&t=712 The message they give is not much different from my message; I just think that 20kLoCs for a secure connection is still an order of magnitude too much, and they should throw away SSL completely ;-). > The GCC maintainer takes the view that someone claiming there is a spec > bug ought to be able to convince the standards committee that there is a > bug. If that doesn't happen, it's just a difference of opinion between > the complainer and the standards committee. A standard committee is there to find common practice. If it fails to find such common practice, it will warn programmers that there is no common practice. That is not the same thing as telling the compiler maintainer to simply change the way he dealt with overflows, because there had no common practice emerged when the last standard was issued. The C standard itself tells the implementer that they can and should (if possible) define the undefined parts of C. The specification bug comes from ignoring that advice, so it turns an issue where different compilers simply behave different into an actual bug. >> That means the only way to get to reliable software is to make it compact >> and simple, so that you don't have a gazillion features most people never >> use, but only those essential to your users. > > There's something to be said for that, although a paper by Regehr that I > linked a while back says that TCC has more bugs than GCC since it hasn't > been banged on as much. Yes, of course: if you don't test, you are doomed. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-04 14:05 -0800 |
| Message-ID | <87387q5hi8.fsf@jester.gateway.sonic.net> |
| In reply to | #35416 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> I get type errors all the time when developing with C and alike, and I fix
> them by adding the correct typecast. Which means the whole thing was
> perfectly ok, I just didn't tell the compiler to shut up.
I keep hearing that from Elizabeth but I can't help wondering if you're
doing something weird. I'm used to not having to use very many casts in
C. Even in a program like a Lisp interpreter that uses casts for
putting multiple value types in a single memory cell, the casts are
generally put in a few accessor macros rather than spewed all over the
program. Most of the time though, you can use a union, with no casts at
all.
> With an OOP system, I would agree that your compiler should check that
> you are using the right member variables and methods
I'd consider that to be a form of static typing and agree that it's
useful.
>> With runtime checks ...there's a crash with a stack trace ... this is
>> often less convenient than getting the problem reported at compile
>> time.
> So you think testing is less convenient than compiling?
For something like passing the wrong number of args to a function, sure.
Think of Forth: I write a word that mistakenly passes a single int to
some word that wants a double, test it, and it crashes with a stack
underflow. Now I have to sprinkle ~~ through it and test multiple more
times to find the problem. Not terrible, but it would be easier if the
compiler said "word XYZ expects a double and you passed a single". It
could figure this out based on the stack comments that we're all
supposed to write. Of course it's worse if memory is involved, like if
I wrote @ instead of 2@ .
> I've heard that from other people, too, and I think if testing is less
> convenient than compiling, you are in deep trouble.
To compile I usually just say "M-x compile" in Emacs, or in the case of
Haskell, I just type C-c C-l. To test, I have to concoct some test
inputs and enter them, or write a test routine (unit test) for that
function. And I have to re-test every time something changes, not so
good if I'm testing interactively. And if I write a unit test and then
change the interface of the function being tested, I have to change the
test too. If the compiler spots the easy, silly stuff, that saves some
hassle even if more complicated stuff still has to be tested the usual
way.
> If your development environment makes testing a second-class method of
> getting correctness, and compiling a first-class method, you will try
> to push every correctness stuff on the compilation.
Why is pushing correctness checks on the compilation a bad thing?
There's a motto of some OCaml users, "make illegal states
unrepresentable". That is, design your datatypes so you can't create an
invalid value.
> No, the question was how many bugs of the total number of bugs are type
> errors. In comparison to other typical bugs.
Well, if you develop interactively in a style that relies on a
typechecker, then you'll get lots of type errors, fix them, and end up
with something that works or where you might have to hunt a bug or two.
Let's say you have to compile 5 times to get rid of type errors, then 2
more times to fix bugs found by testing. That means 71% of your bugs
were type bugs. Of course this is something like interactive testing in
Forth: you'll probably tend to test and recompile wrong code more times
than you would with some slow batch compiler that makes you rely more on
code inspection.
>>> Paul Bennett on EuroForth presented a slide which shows that 44% of
>>> the bugs are specification bugs....
> http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/
Interesting slide deck (I haven't watched the video yet). It didn't
say much about that statistic though. I'd be interested in hearing more.
>>> bugs in Ada where... the type system still causes surprises to the
>>> programmer.... Typical example: Out-of-range behavior.
I don't see what that has to do with the Ada type system. Ada supports
ranged integers and if you use them, the compiler checks for range
errors. If you use unranged integers, it doesn't check and you get the
normal semantics (whatever those are; I'm sure they're well-defined,
unlike in C) for overflow.
>> The person tried to use Ada generics and ran into a snag, so he asked
>> for help and got some. What's the issue?
> That it's too complicated to be used.
Eh? A non-expert tried an advanced feature and had some trouble
understanding it at first. That happens with Forth too (think of
create/does). Haskell's type system is much more complicated than
anything in Ada or Forth. It has a steep learning curve (think of the
notorious monads) but it's a powerful tool once you understand it. You
can't expect to become a good programmer without sometimes expending
effort understanding difficult things. It's no different than having to
study linear algebra and calculus if you want to design electronics.
> Just like when you say that you find it easier to get your bugs figured out
> by the compiler instead of by testing: that is an indication that your
> framework is weak at testing, and needs improvement.
No really. Here's a whizzy Haskell example that I like, of red-black
trees. Red-black trees are binary trees where each node is marked with
a color, and the tree itself has some invariants described here:
https://en.wikipedia.org/wiki/Red-black_tree#Properties
(All leaves are black, all red nodes have only black children, and all
paths from any node to the leaves pass through the same number of black
nodes). So a node would look something like
struct node {
enum { red, black } color;
Value_t value;
struct node *left, *right;
}
I've looked at various C and Java implementations of structures like
this, and they generally include some test code to traverse a tree and
make sure that the properties hold, plus unit tests to run the traversal
check on a bunch of sample trees. Of course you have to write your unit
tests carefully to make sure you covered all possible edge cases, and
even then you can't really be sure. So you better write more tests that
generate a lot of random trees and check them, and there are usually
some assert statements in the implementation itself, to do some local
runtime checks in case something broke. And if you're really careful or
if something seems to be misbehaving, you might want to run production
data in "debug mode" for a while, which means calling the full slow tree
traversal check every single time you access a tree, to make sure
nothing messed it up. All of this is not very convenient.
In Haskell you can encode the tree invariants in the type system. This
is based on https://gist.github.com/rampion/2659812 using some newer GHC
features for more clarity:
data Color = Red | Black
data Height = Zero | Succ Height
data Node :: Color -> Height -> * -> * where
Leaf :: Node Black Zero a
RedNode :: a -> Node Black h a -> Node Black h a -> Node Red h a
BlackNode :: a -> Node c1 h a -> Node c2 h a -> Node Black (Succ h) a
data RBTree a = forall h. RBTree (Node Black h a)
[Explanation: The Color type is like an enum, so Red and Black are
values, but with the GHC DataKinds extension they can also be used as
types. Height encodes a natural number as a value or type, saying how
many levels of Black nodes: a Height is either Zero or the successor of
a Height. This encoding of Peano numbers in types is a Haskell idiom
though there's now something better (type-level naturals) built into GHC
that I haven't tried yet. The Node type then encodes the invariants of
the tree: a Leaf is black and has zero height, a Red node has two Black
children that must both have the same height h, and a Black node has two
children of arbitrary color but the same height, and its height is the
successor of (i.e. one plus) the childrens' height. Finally, a RBTree
(representing the root of a red-black tree) wraps a Black node of
arbitrary ("forall h.") height.]
What does that buy you? Any value of type RBTree *must* be a properly
formed red-black tree that obeys the invariants. If your code messed up
the invariants, it won't compile. So you can get rid of the intricately
concocted unit tests and the assert statements left waiting to crash
your production code if there was a remaining error. At least with
regard to the tree invariants, this is the "correct by construction" of
Paul Bennett's slide (of course there are other things that can go
wrong). Ada's type system is not expressive enough to do this. On the
other hand, Coq or Idris types can go even further, and encode things
like the order properties on the values in the nodes.
Side note: the traditional imperative algorithm for updating a red-black
tree involves sometimes breaking the invariant on purpose, then fixing
it by juggling the nodes around the broken spot until the invariant is
restored. With the type-enforced scheme, the tree can't take on
intermediate values with broken invariants, so the update algorithm ends
up being different. A fancier system might be able to handle the
improper trees with more types to track the exact breakage and make sure
it's undone properly.
> Well, there is the tradeoff of making it harder to program, when the
> type system is annoying and gets into your way. You sound like there
> is a zero cost attached to the static analysis, which certainly isn't
> the case.
For sure, there's a tradeoff, and in practice I still do most of my
stuff in Python 2, which has only runtime types. But, I think there
should be a practical sweet spot somewhere between Python and Haskell.
OCaml might come closest though it has its own issues. I have to say
from using the Erlang Dialyzer that I'm not too keen on "optional"
static types which also seem to be appearing in Python 3.
In critical systems, saving coding time is much less important than
assuring correctness, so "harder to program" is less of an issue.
>> There's a paper "the unreasonable effectiveness of testing"
> I've only found this:
> http://blog.trustiv.co.uk/2013/03/unreasonable-effectiveness-testing
Hmm, yeah, I must have confused two articles, sorry. That one was
pretty good but the one I was thinking of was different. This comes a
little closer but it's just a brief quote:
https://en.wikipedia.org/w/index.php?title=Tony_Hoare&oldid=630420817#cite_ref-22
> To be honest, there is a pretty big overlap between functional language
> programming and Forth from the approach how to solve things, and the only
> difference is with typechecking and garbage collection.
I've noticed that similarity too (it's one of the things that keeps me
interested in Forth) but another important difference is that FP
generally avoids mutating the data store, which dictates a lot of
algorithm and data structure choices that are different from what we're
used to in imperative programming.
> Worth to watch from the 31c3:
> http://media.ccc.de/browse/congress/2014/31c3_-_...
Nice, that is pretty good. It's about Mirage (Ocaml on Xen,
openmirage.org) and there are similar things for Erlang
(erlangonxen.org) and Haskell (halvm.org). Is gforth next? :-)
> 20kLoCs for a secure connection is still an order of magnitude too
> much, and they should throw away SSL completely ;-).
There are much smaller SSL implementations but the situation isn't
great.
> A standard committee is there to find common practice.... The C
> standard itself tells the implementer that they can and should (if
> possible) define the undefined parts of C. The specification bug
> comes from ignoring that advice
I think the C standards committee has different goals than the Forth
committee. The C committee aims to specify a language for writing the
fastest possible programs, which means they deliberately choose to
expose the programmer to nasal demons on the slightest mistake, in order
to enable more aggressive optimizations. So e.g. in the int overflow
case, the "undefined" doesn't mean there's no common practice, but
rather that well-defined C programs are flat-out prohibited from
overflowing signed ints, based on the notion that the C community cares
more the non-overflow case running faster than on the overflow case
having well-defined behaviour.
If there's a disconnect between that and what the C community actually
wants, the community should take it up with the committee. I just think
it makes C a bloody dangerous language to be avoided for anything
complicated and critical, so I look for different language choices, but
if that's what C programmers want, it's their look-out ;-).
>> a paper by Regehr... says that TCC has more bugs than GCC since it
>> hasn't been banged on as much.
> Yes, of course: if you don't test, you are doomed.
TCC has been tested, but there's a difference between "tested" and
"pounded by billions of LOC of production code over tens of years".
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-06 03:51 +0100 |
| Message-ID | <m8fiiv$dam$1@dont-email.me> |
| In reply to | #35462 |
Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> I get type errors all the time when developing with C and alike, and I
>> fix
>> them by adding the correct typecast. Which means the whole thing was
>> perfectly ok, I just didn't tell the compiler to shut up.
>
> I keep hearing that from Elizabeth but I can't help wondering if you're
> doing something weird. I'm used to not having to use very many casts in
> C.
Hah, I'm implementing Forth in C ;-). Of course that's something completely
weird C never has been designed for...
>> With an OOP system, I would agree that your compiler should check that
>> you are using the right member variables and methods
>
> I'd consider that to be a form of static typing and agree that it's
> useful.
Well, I consider that as scoping, because the object has its own namespace,
not as static typing, but if you want that to be called typing, it's
perfectly reasonable to do that.
>>> With runtime checks ...there's a crash with a stack trace ... this is
>>> often less convenient than getting the problem reported at compile
>>> time.
>
>> So you think testing is less convenient than compiling?
>
> For something like passing the wrong number of args to a function, sure.
> Think of Forth: I write a word that mistakenly passes a single int to
> some word that wants a double, test it, and it crashes with a stack
> underflow. Now I have to sprinkle ~~ through it and test multiple more
> times to find the problem. Not terrible, but it would be easier if the
> compiler said "word XYZ expects a double and you passed a single". It
> could figure this out based on the stack comments that we're all
> supposed to write.
Factor actually does that, but the problem is that Factor then knows you
made a mistake, but can't tell you where. Because without the parenthesis,
it is not clear which value is intented as argument for which call.
The result is that debugging Factor is then actually way harder than
debugging Forth, because all you get is this error message (you would have
got that "stack empty" out of Forth, too), but you can't even sprinkle ~~
into the word to find where the problem is.
Well, I actually don't that often sprinkle ~~, it is far easier to "single
step" on the command line through the definition by typing one call after
the other and examing the stack.
I think you should get more aquainted with the command line; you treat Forth
like yet another edit-compile-link-go language, where you edit the source in
an editor, and then let the program run in total. That's not how Forth
development is meant.
> Of course it's worse if memory is involved, like if
> I wrote @ instead of 2@ .
I think you get it why this is difficult.
> Why is pushing correctness checks on the compilation a bad thing?
Debugging involves understanding what happens. The problem I have with
typechecker error messages is that they complain about something abstract,
while the testing works on actual data.
>> No, the question was how many bugs of the total number of bugs are type
>> errors. In comparison to other typical bugs.
>
> Well, if you develop interactively in a style that relies on a
> typechecker, then you'll get lots of type errors, fix them, and end up
> with something that works or where you might have to hunt a bug or two.
> Let's say you have to compile 5 times to get rid of type errors, then 2
> more times to fix bugs found by testing. That means 71% of your bugs
> were type bugs. Of course this is something like interactive testing in
> Forth: you'll probably tend to test and recompile wrong code more times
> than you would with some slow batch compiler that makes you rely more on
> code inspection.
Yes. However, the slow compiler is slow on code inspection, too. It's not
like you are getting your inspection results quickly and it then takes ages
to produce the binary - it takes ages to get your inspection results. And
due to the problems of follow-up errors, you fix them one by one, and have
to re-inspect on every go.
>>>> bugs in Ada where... the type system still causes surprises to the
>>>> programmer.... Typical example: Out-of-range behavior.
>
> I don't see what that has to do with the Ada type system. Ada supports
> ranged integers and if you use them, the compiler checks for range
> errors. If you use unranged integers, it doesn't check and you get the
> normal semantics (whatever those are; I'm sure they're well-defined,
> unlike in C) for overflow.
The semantics is trap-on-overflow; the surprise is that it traps. In many
cases, saturate-on-overflow or wrap-around is also a reasonable option (mod
N is a very common case for assymetric crypto).
>>> The person tried to use Ada generics and ran into a snag, so he asked
>>> for help and got some. What's the issue?
>> That it's too complicated to be used.
>
> Eh? A non-expert tried an advanced feature and had some trouble
> understanding it at first. That happens with Forth too (think of
> create/does). Haskell's type system is much more complicated than
> anything in Ada or Forth. It has a steep learning curve (think of the
> notorious monads) but it's a powerful tool once you understand it. You
> can't expect to become a good programmer without sometimes expending
> effort understanding difficult things. It's no different than having to
> study linear algebra and calculus if you want to design electronics.
Hm, one of the design principles of Forth is that it consists of really easy
to understand building blocks, and that you can comprehend the system in
total. You have some learning curve, especially with the stack, but the
main point there is that you need to automate the thinking about it to
become fast; the concept behind is very easy to learn.
And the idea behind that is that when you understand things completely, and
don't have to treat a lot of things as abstract black box, boosts
productivity and helps you to write correct programs. Because you
understand what you are doing.
>> Just like when you say that you find it easier to get your bugs figured
>> out by the compiler instead of by testing: that is an indication that
>> your framework is weak at testing, and needs improvement.
>
> No really. Here's a whizzy Haskell example that I like, of red-black
> trees. Red-black trees are binary trees where each node is marked with
> a color, and the tree itself has some invariants described here:
>
> https://en.wikipedia.org/wiki/Red-black_tree#Properties
>
> (All leaves are black, all red nodes have only black children, and all
> paths from any node to the leaves pass through the same number of black
> nodes). So a node would look something like
>
> struct node {
> enum { red, black } color;
> Value_t value;
> struct node *left, *right;
> }
>
> I've looked at various C and Java implementations of structures like
> this, and they generally include some test code to traverse a tree and
> make sure that the properties hold, plus unit tests to run the traversal
> check on a bunch of sample trees. Of course you have to write your unit
> tests carefully to make sure you covered all possible edge cases, and
> even then you can't really be sure. So you better write more tests that
> generate a lot of random trees and check them, and there are usually
> some assert statements in the implementation itself, to do some local
> runtime checks in case something broke. And if you're really careful or
> if something seems to be misbehaving, you might want to run production
> data in "debug mode" for a while, which means calling the full slow tree
> traversal check every single time you access a tree, to make sure
> nothing messed it up. All of this is not very convenient.
Probably. But that's C and Java code. I've only implemented an AVL tree in
Forth 25 years ago (to check if that's a viable dictionary structure, and
dismissed it, because the hash was so much better), and the C and Java
implementations of AVL trees are pretty similar: littered with checks and
assertions. My Forth code wasn't. There are a few textbook cases you have
to check, and you do that interactively, so all you write is a print-the-
tree word, with checks that it is balanced. And of course then you test it
with the dictionary as "lots of random data" and see if it is still
balanced.
> Side note: the traditional imperative algorithm for updating a red-black
> tree involves sometimes breaking the invariant on purpose, then fixing
> it by juggling the nodes around the broken spot until the invariant is
> restored. With the type-enforced scheme, the tree can't take on
> intermediate values with broken invariants, so the update algorithm ends
> up being different. A fancier system might be able to handle the
> improper trees with more types to track the exact breakage and make sure
> it's undone properly.
Hm, that sounds complicated. So you can't take a standard text book like
TAOCP or today Wikipedia, go to the R/B tree section and implement the
operations described there, because the typechecker will complain that your
intermediate values are incorrect? That's the "fighting against the
typechecker" thing I mentioned: and you agree with me that a fancier system
maybe could help... maybe, and could, and of course a fancier system is even
harder to use.
> In critical systems, saving coding time is much less important than
> assuring correctness, so "harder to program" is less of an issue.
My experience is that harder to program makes the program automatically less
correct, because the programmer is more exhausted and skips things.
>> To be honest, there is a pretty big overlap between functional language
>> programming and Forth from the approach how to solve things, and the only
>> difference is with typechecking and garbage collection.
>
> I've noticed that similarity too (it's one of the things that keeps me
> interested in Forth) but another important difference is that FP
> generally avoids mutating the data store, which dictates a lot of
> algorithm and data structure choices that are different from what we're
> used to in imperative programming.
Yes, Forth is far less shy at modifying memory. It's not exactly the same
as with usual imperative languages, as the stacks allow to do more things
without having a global state, but I consider everything that isn't straight
on a stack as "memory", which includes all the more complicated data
structures.
>> Worth to watch from the 31c3:
>> http://media.ccc.de/browse/congress/2014/31c3_-_...
>
> Nice, that is pretty good. It's about Mirage (Ocaml on Xen,
> openmirage.org) and there are similar things for Erlang
> (erlangonxen.org) and Haskell (halvm.org). Is gforth next? :-)
Maybe ;-). Gforth is pretty easy to get to run on bare hardware.
> I think the C standards committee has different goals than the Forth
> committee. The C committee aims to specify a language for writing the
> fastest possible programs, which means they deliberately choose to
> expose the programmer to nasal demons on the slightest mistake, in order
> to enable more aggressive optimizations. So e.g. in the int overflow
> case, the "undefined" doesn't mean there's no common practice, but
> rather that well-defined C programs are flat-out prohibited from
> overflowing signed ints, based on the notion that the C community cares
> more the non-overflow case running faster than on the overflow case
> having well-defined behaviour.
I'm pretty sure the x264 code GCC recently broke was written with the
intention to be the fastest h.264 encoder in the world, and the CPUs do
really wrap-around very, very fast. Just as fast as the non-wrap-around
case.
Actually, all contemporary CPUs do have the + operation as defined in Forth:
Working both on signed and unsigned. If C was about writing the fastest
possible program, it would expose the underlying hardware, and be just a
lightweight portable assembler, as it was in K&R's days.
The problem is however, that C is not about writing the fastest possible
program, but about executing some benchmarks as fast as possible, and
thereby not allowing to rewrite bad code in the benchmark. This means the
compiler must transform that code into something good, and that could be
arbitrary complicated; and is simplified if you are allowed to ignore all
kinds of corner-cases.
That's however not how reality looks like, because all those benchmark
compilers *only* know how to transform the benchmark patterns, and don't do
anything good on the real world pattern. I saw a degradation in performance
of several crypto cores when going from GCC 4.7 to 4.8 (and no improvement
in 4.9), so it's pretty obvious that there is no universal speed
improvement. It is just very local to some selected benchmarks.
> If there's a disconnect between that and what the C community actually
> wants, the community should take it up with the committee. I just think
> it makes C a bloody dangerous language to be avoided for anything
> complicated and critical, so I look for different language choices, but
> if that's what C programmers want, it's their look-out ;-).
Yeah, we do agree on that one.
> TCC has been tested, but there's a difference between "tested" and
> "pounded by billions of LOC of production code over tens of years".
Ah, the GCC team then marks all the feedback as "invalid", and we poor
programmers have to work around them.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-05 20:02 -0800 |
| Message-ID | <812da404-7b9c-4daa-9532-b246a4a77c5c@googlegroups.com> |
| In reply to | #35490 |
On Monday, January 5, 2015 7:51:39 PM UTC-7, Bernd Paysan wrote: > Hah, I'm implementing Forth in C ;-). Of course that's something completely > weird C never has been designed for... > ... > Ah, the GCC team then marks all the feedback as "invalid", and we poor > programmers have to work around them. Why don't you just learn how to program in assembly language, Bernd? You've got a place on the Forth-200x committee so long as you kow-tow to Elizabeth Rather --- but nobody in the real world is going to take your claim of being a compiler-writer seriously until you learn assembly-language.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-05 19:25 -1000 |
| Message-ID | <AMOdnffCRaVT7DbJnZ2dnUU7-VudnZ2d@supernews.com> |
| In reply to | #35490 |
On 1/5/15 4:51 PM, Bernd Paysan wrote: > Paul Rubin wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> writes: ... >>> So you think testing is less convenient than compiling? >> >> For something like passing the wrong number of args to a function, sure. >> Think of Forth: I write a word that mistakenly passes a single int to >> some word that wants a double, test it, and it crashes with a stack >> underflow. Now I have to sprinkle ~~ through it and test multiple more >> times to find the problem. Not terrible, but it would be easier if the >> compiler said "word XYZ expects a double and you passed a single". It >> could figure this out based on the stack comments that we're all >> supposed to write. > [ Factor comments snipped ] > > Well, I actually don't that often sprinkle ~~, it is far easier to "single > step" on the command line through the definition by typing one call after > the other and examing the stack. > > I think you should get more aquainted with the command line; you treat Forth > like yet another edit-compile-link-go language, where you edit the source in > an editor, and then let the program run in total. That's not how Forth > development is meant. This is a really important point. The whole process of debugging in Forth is different from most languages, because the system will work with you if you let it. When I was programming I virtually never used ~~ type things. >> Of course it's worse if memory is involved, like if >> I wrote @ instead of 2@ . > > I think you get it why this is difficult. > >> Why is pushing correctness checks on the compilation a bad thing? > > Debugging involves understanding what happens. The problem I have with > typechecker error messages is that they complain about something abstract, > while the testing works on actual data. Yes. In my experience, more problems are related to the content of the data or the environment around the word in which the abort or error you're tracking occurred. The compiler can't know anything about the dynamic situation. Bernd's process (type each word in the definition that's misbehaving and look at the stack) takes virtually no time (far less time than "sprinkling ~~s), and is immediately revealing. In Forth, the debugging process involves a very intimate interaction between brain and code. Compilers that take more than a second break that concentration and the whole procedure takes way longer. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-07 14:52 -0800 |
| Message-ID | <43c6114f-8d41-4005-9131-fe93ec3d3696@googlegroups.com> |
| In reply to | #35493 |
On Monday, January 5, 2015 10:25:35 PM UTC-7, Elizabeth D Rather wrote: > On 1/5/15 4:51 PM, Bernd Paysan wrote: > > I think you should get more aquainted with the command line; you treat Forth > > like yet another edit-compile-link-go language, where you edit the source in > > an editor, and then let the program run in total. That's not how Forth > > development is meant. > > This is a really important point. The whole process of debugging in > Forth is different from most languages, because the system will work > with you if you let it. When I was programming I virtually never used ~~ > type things. The ANS-Forth standard doesn't support the use of C" and S" in interpretive mode, and SwiftForth and Gforth both fail at this. I fixed the problem in my novice package --- this is really necessary to interactively debug functions that take strings as arguments. VFX supports C" and S" in interpretive mode, but Pelc doesn't provide the source-code for this, and it is most likely not ANS-Forth --- he knows about the problems in ANS-Forth, but he didn't make any effort in 1994 to fix these problems in ANS-Forth --- instead he fixes the problems with non-standard code in an effort to prevent his users from migrating from VFX to other ANS-Forth compilers (vendor-trapping is exactly what having a standard was supposed to stop!).
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2015-01-09 08:04 +0300 |
| Message-ID | <m2mw5sfstz.fsf@gmail.com> |
| In reply to | #35570 |
hughaguilar96@gmail.com writes: > The ANS-Forth standard doesn't support the use of C" and S" in > interpretive mode, and SwiftForth and Gforth both fail at this. I > fixed the problem in my novice package --- this is really necessary to > interactively debug functions that take strings as arguments. > Perhaps you have meant C" only, as S" in interpretive mode seems to be Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165).
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-08 21:14 -1000 |
| Message-ID | <ZaCdnaBV9oFG4jLJnZ2dnUU7-e2dnZ2d@supernews.com> |
| In reply to | #35632 |
On 1/8/15 7:04 PM, Alexander Skobelev wrote: > hughaguilar96@gmail.com writes: > >> The ANS-Forth standard doesn't support the use of C" and S" in >> interpretive mode, and SwiftForth and Gforth both fail at this. I >> fixed the problem in my novice package --- this is really necessary to >> interactively debug functions that take strings as arguments. >> > > Perhaps you have meant C" only, as S" in interpretive mode seems to be > Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). C" is actually not used very much nowadays, AFAIK. It was retained in Forth94 because at the time some people used it, but I think counted strings are used much less nowadays. 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 | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2015-01-09 16:25 +0300 |
| Message-ID | <m27fwwf5lm.fsf@gmail.com> |
| In reply to | #35638 |
"Elizabeth D. Rather" <erather@forth.com> writes: > On 1/8/15 7:04 PM, Alexander Skobelev wrote: >> hughaguilar96@gmail.com writes: >> >>> The ANS-Forth standard doesn't support the use of C" and S" in >>> interpretive mode, and SwiftForth and Gforth both fail at this. I >>> fixed the problem in my novice package --- this is really necessary to >>> interactively debug functions that take strings as arguments. >>> >> >> Perhaps you have meant C" only, as S" in interpretive mode seems to be >> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). > > C" is actually not used very much nowadays, AFAIK. It was retained in > Forth94 because at the time some people used it, but I think counted > strings are used much less nowadays. I think they still can be useful for storing short strings in structure fields with a fixed width. Something like in this: 0 22 CHARS +FIELD person.name ... CONSTANT Person , – where the person.name field is supposed to store a counted string of no more than 21 characters length.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-09 09:10 -1000 |
| Message-ID | <quadnTBVSYEoui3JnZ2dnUU7-I-dnZ2d@supernews.com> |
| In reply to | #35649 |
On 1/9/15 3:25 AM, Alexander Skobelev wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > >> On 1/8/15 7:04 PM, Alexander Skobelev wrote: >>> hughaguilar96@gmail.com writes: >>> >>>> The ANS-Forth standard doesn't support the use of C" and S" in >>>> interpretive mode, and SwiftForth and Gforth both fail at this. I >>>> fixed the problem in my novice package --- this is really necessary to >>>> interactively debug functions that take strings as arguments. >>>> >>> >>> Perhaps you have meant C" only, as S" in interpretive mode seems to be >>> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). >> >> C" is actually not used very much nowadays, AFAIK. It was retained in >> Forth94 because at the time some people used it, but I think counted >> strings are used much less nowadays. > > I think they still can be useful for storing short strings in structure > fields with a fixed width. > > Something like in this: > 0 > 22 CHARS +FIELD person.name > ... > CONSTANT Person > > , – where the person.name field is supposed to store a counted string of > no more than 21 characters length. Oh, counted strings are wonderful! IMO they are the preferred way to store strings internally, for many reasons. The vast majority of internal strings work with an 8-bit count. But for some years we have been gravitating toward using addr-cnt pairs for passing references to strings on the stack. In our implementation, S" stores its string as a counted string, likewise names and other strings, but we pass addr-cnt on the stack. That is why C" (which passes the address of a counted string) is not often used and there was no pressure to make an interpretive version. 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 | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2015-01-10 14:35 +0300 |
| Message-ID | <m2twzyj2ar.fsf@gmail.com> |
| In reply to | #35659 |
"Elizabeth D. Rather" <erather@forth.com> writes: > On 1/9/15 3:25 AM, Alexander Skobelev wrote: >> "Elizabeth D. Rather" <erather@forth.com> writes: >> >>> On 1/8/15 7:04 PM, Alexander Skobelev wrote: >>>> hughaguilar96@gmail.com writes: >>>> >>>>> The ANS-Forth standard doesn't support the use of C" and S" in >>>>> interpretive mode, and SwiftForth and Gforth both fail at this. I >>>>> fixed the problem in my novice package --- this is really necessary to >>>>> interactively debug functions that take strings as arguments. >>>>> >>>> >>>> Perhaps you have meant C" only, as S" in interpretive mode seems to be >>>> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). >>> >>> C" is actually not used very much nowadays, AFAIK. It was retained in >>> Forth94 because at the time some people used it, but I think counted >>> strings are used much less nowadays. >> >> I think they still can be useful for storing short strings in structure >> fields with a fixed width. >> >> Something like in this: >> 0 >> 22 CHARS +FIELD person.name >> ... >> CONSTANT Person >> >> , – where the person.name field is supposed to store a counted string of >> no more than 21 characters length. > > Oh, counted strings are wonderful! IMO they are the preferred way to > store strings internally, for many reasons. The vast majority of > internal strings work with an 8-bit count. But for some years we have > been gravitating toward using addr-cnt pairs for passing references to > strings on the stack. In our implementation, S" stores its string as a > counted string, likewise names and other strings, but we pass addr-cnt > on the stack. That is why C" (which passes the address of a counted > string) is not often used and there was no pressure to make an > interpretive version. > This is interesting. But that means that either your implementation the S" strings limited to 256 characters or you should use some tricks in the counted strings to store more characters there.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-10 20:51 -1000 |
| Message-ID | <wqydnX5nqb7qgC_JnZ2dnUU7-KudnZ2d@supernews.com> |
| In reply to | #35698 |
On 1/10/15 1:35 AM, Alexander Skobelev wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > >> On 1/9/15 3:25 AM, Alexander Skobelev wrote: >>> "Elizabeth D. Rather" <erather@forth.com> writes: >>> >>>> On 1/8/15 7:04 PM, Alexander Skobelev wrote: >>>>> hughaguilar96@gmail.com writes: >>>>> >>>>>> The ANS-Forth standard doesn't support the use of C" and S" in >>>>>> interpretive mode, and SwiftForth and Gforth both fail at this. I >>>>>> fixed the problem in my novice package --- this is really necessary to >>>>>> interactively debug functions that take strings as arguments. >>>>>> >>>>> >>>>> Perhaps you have meant C" only, as S" in interpretive mode seems to be >>>>> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). >>>> >>>> C" is actually not used very much nowadays, AFAIK. It was retained in >>>> Forth94 because at the time some people used it, but I think counted >>>> strings are used much less nowadays. >>> >>> I think they still can be useful for storing short strings in structure >>> fields with a fixed width. >>> >>> Something like in this: >>> 0 >>> 22 CHARS +FIELD person.name >>> ... >>> CONSTANT Person >>> >>> , – where the person.name field is supposed to store a counted string of >>> no more than 21 characters length. >> >> Oh, counted strings are wonderful! IMO they are the preferred way to >> store strings internally, for many reasons. The vast majority of >> internal strings work with an 8-bit count. But for some years we have >> been gravitating toward using addr-cnt pairs for passing references to >> strings on the stack. In our implementation, S" stores its string as a >> counted string, likewise names and other strings, but we pass addr-cnt >> on the stack. That is why C" (which passes the address of a counted >> string) is not often used and there was no pressure to make an >> interpretive version. >> > > This is interesting. But that means that either your implementation the > S" strings limited to 256 characters or you should use some tricks in > the counted strings to store more characters there. I don't think S" is the right mechanism to handle strings longer than 256 bytes. Very few applications actually require such long strings, particularly in definitions. The few string-intensive applications I've been involved with have developed application-specific data structures for the long strings. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 6 of 17 — ← Prev page 1 … 4 5 [6] 7 8 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web