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 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-01-14 21:07 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m96lre$j1p$1@dont-email.me> |
| In reply to | #35815 |
WJ wrote: > Anton wants to keep things easy for meciocre implementors mediocre > of Forth.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-15 01:06 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m973q6$7ce$1@dont-email.me> |
| In reply to | #35798 |
on 14/01/2015 02:19:14, wrote: > > The compiler-writers of the X and Y compilers are going to say: > X: "Whatever. I'm already there, so this doesn't have any direct > affect on me." > Y. "Drat! Now I'll have to spend time in rewriting my compiler to make > the control-flow stack its own stack --- there goes the weekend!" And your credibility. If there's one thing that marks out amateur software writers, it's dreamin' that yer bangin' out those changes over a weekend fuelled by pizza and some beers.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-01-15 00:52 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <10447ac1-b4c2-4526-a42c-73edcdca6eac@googlegroups.com> |
| In reply to | #35818 |
On Thursday, 15 January 2015 01:06:44 UTC, Alex McDonald wrote: > And your credibility. If there's one thing that marks out amateur > software writers, it's dreamin' that yer bangin' out those changes over a > weekend fuelled by pizza and some beers. Look who's talking! I could change the control flow words in my own system to use a dedicated control flow stack in about an hour. No big deal. What would take longer is find the applications that would subsequently break as a result of the change. Probably not many (in my case, at least). I don't have any code that does dodgy stuff like indexing down the return stack to get at loop indexes or anything like that. The change would likely be very portable. In my own system, there wouldn't even be performance penalty: My CPU doesn't have any stacks anyway, so adding a third would make no difference to performance!
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-15 01:17 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <01698de1-f0b3-4ddc-9aab-654c70cc8d02@googlegroups.com> |
| In reply to | #35820 |
On Thursday, 15 January 2015 08:52:46 UTC, Mark Wills wrote: > On Thursday, 15 January 2015 01:06:44 UTC, Alex McDonald wrote: > > And your credibility. If there's one thing that marks out amateur > > software writers, it's dreamin' that yer bangin' out those changes over a > > weekend fuelled by pizza and some beers. > > Look who's talking! I could change the control flow words in my own system > to use a dedicated control flow stack in about an hour. No big deal. But you're not running a business with hundreds to thousands of customers who expect you to write it, test it, write migration notes, support and and generally take more effort than announcing the "Hey, it's no big deal" version. Software changes are a big deal and they cost both providers and consumers. > > What would take longer is find the applications that would subsequently > break as a result of the change. Probably not many (in my case, at least). > I don't have any code > that does dodgy stuff like indexing down the return stack to get at loop > indexes or anything like that. The change would likely be very portable. <sarcasm> Good for you. I'm glad you've let us know that the change is likely to be very portable. I'm sure MPE and Forth Inc. will be taking notes. </sarcasm> You're not being serious here. > > In my own system, there wouldn't even be performance penalty: My CPU > doesn't have any stacks anyway, so adding a third would make no difference > to performance! The standard won't be changed for you unless you make a very strong case for it. Hugh thinks it was written by a cult to make his life miserable and doesn't know how to engage with humans to propose the change. I guess that's where this conversation on the control flow stack ends.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-15 17:35 -1000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <6aqdnR2xiYCOGiXJnZ2dnUU7-aOdnZ2d@supernews.com> |
| In reply to | #35820 |
On 1/14/15 10:52 PM, Mark Wills wrote: > On Thursday, 15 January 2015 01:06:44 UTC, Alex McDonald wrote: >> And your credibility. If there's one thing that marks out amateur >> software writers, it's dreamin' that yer bangin' out those changes over a >> weekend fuelled by pizza and some beers. > > Look who's talking! I could change the control flow words in my own system > to use a dedicated control flow stack in about an hour. No big deal. > > What would take longer is find the applications that would subsequently > break as a result of the change. Probably not many (in my case, at least). > I don't have any code > that does dodgy stuff like indexing down the return stack to get at loop > indexes or anything like that. The change would likely be very portable. Even if you did, adopting a separate control flow stack wouldn't affect them, because the control flow stack only exists during compilation, so loop indices are never on it. > In my own system, there wouldn't even be performance penalty: My CPU > doesn't have any stacks anyway, so adding a third would make no difference > to performance! > The only possible cost would be compile time. I am suspecting you don't fully understand the control flow stack. 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-15 20:38 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <01b90928-981d-47de-9d60-202964fca4ad@googlegroups.com> |
| In reply to | #35820 |
On Thursday, January 15, 2015 at 1:52:46 AM UTC-7, Mark Wills wrote: > On Thursday, 15 January 2015 01:06:44 UTC, Alex McDonald wrote: > > And your credibility. If there's one thing that marks out amateur > > software writers, it's dreamin' that yer bangin' out those changes over a > > weekend fuelled by pizza and some beers. > > Look who's talking! I could change the control flow words in my own system > to use a dedicated control flow stack in about an hour. No big deal. It is just a stack, so a full weekend is an overestimate --- Alex is telling us a lot about his programming ability when he complains that this is too difficult. > What would take longer is find the applications that would subsequently > break as a result of the change. Probably not many (in my case, at least). > I don't have any code > that does dodgy stuff like indexing down the return stack to get at loop > indexes or anything like that. The change would likely be very portable. No code would break as a result, because there is no code that depends upon having the control-flow data and the user's compile-time data mixed together (the user can't access the control-flow data because he doesn't know what format it is in, or even how big each datum is). The control-flow data was in the way previously, so the only result is that people who want to write metacompiling words would now be able to pass data on the data-stack at compile-time without any system control-flow data getting in the way. > In my own system, there wouldn't even be performance penalty: My CPU > doesn't have any stacks anyway, so adding a third would make no difference > to performance! Any performance penalty is unimportant anyway, because the control-flow stack is used at compile-time --- the worst that could happen is that compiling a program may take a few milliseconds longer.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-16 10:47 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <42c2b419-a4a5-4fb0-9137-868e0d1f625e@googlegroups.com> |
| In reply to | #35835 |
On Friday, 16 January 2015 04:38:29 UTC, hughag...@gmail.com wrote: > It is just a stack, so a full weekend is an overestimate --- Alex is telling us a lot about his programming ability when he complains that this is too difficult. > Which is a complaint I didn't make, but hey, that's Hugh the hyperfabulist we all love and know, eh? Since you're so hot! hot!! hot!!!, I expect you to announce Straight Forth this afternoon. You've had since 2012; that's more than 100 weekends! What's holding you up? You miss the point. Changes to software come with all sorts of ancilliary requirements. Documentation, testing, regression, compliance, safety, security, packaging, distribution, maintenance and so on. Hotshot coders tend not to count these efforts, since they often aren't responsible for them; and when they are, often don't bother making them.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-16 20:47 +0100 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m9bpr5$go7$1@dont-email.me> |
| In reply to | #35850 |
Alex McDonald wrote: > You miss the point. Changes to software come with all sorts of ancilliary > requirements. Documentation, testing, regression, compliance, safety, > security, packaging, distribution, maintenance and so on. > > Hotshot coders tend not to count these efforts, since they often aren't > responsible for them; and when they are, often don't bother making them. That's all true. For beginners, it is sufficient that it "works for me", so it is fast and quick to change. However, for professionals, the build system takes care of most of that, so you just have to make the change and write a few lines of documentation what you changed, and your build system does the rest. -- 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 | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2015-01-16 14:37 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <b5eafec0-ce3f-46ef-afa2-a1d7343c0e18@googlegroups.com> |
| In reply to | #35852 |
"Professional" is one of the most meaningless words. In one context, it might refer to someone who is meticulous about the performance of his/her product. In another context it might refer to someone who follows a standardized template of actions without much thought about whether or not those actions make any sense. </rant> Krishna
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2015-01-16 17:26 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <78ef1d56-57c2-4433-8d59-98f96a47da44@googlegroups.com> |
| In reply to | #35854 |
On Friday, January 16, 2015 at 4:37:57 PM UTC-6, krishna...@ccreweb.org wrote: > "Professional" is one of the most meaningless words. In one context, it might refer to someone who is meticulous about the performance of his/her product. In another context it might refer to someone who follows a standardized template of actions without much thought about whether or not those actions make any sense. > > </rant> > > Krishna I was trying to reply to Bernd's last post. KM
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-17 03:03 +0100 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m9cft3$uh4$1@dont-email.me> |
| In reply to | #35854 |
krishna.myneni@ccreweb.org wrote: > "Professional" is one of the most meaningless words. In one context, it > might refer to someone who is meticulous about the performance of his/her > product. In another context it might refer to someone who follows a > standardized template of actions without much thought about whether or not > those actions make any sense. In German, "professional" (in the female form) means a whore. It means somebody who takes money instead of doing it for love. The one doing it for love is the "amateur", which actually is French for "lover". I'm actually not insulted by this argument; I'm ok with some heat. I think I've found what these people didn't understand, it's the non-portable possibility. -- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-13 10:40 -1000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <YdadnZ_5l8g3HyjJnZ2dnUU7-UmdnZ2d@supernews.com> |
| In reply to | #35787 |
On 1/13/15 6:26 AM, Mark Wills wrote:
> On Tuesday, 13 January 2015 14:05:07 UTC, Alex McDonald wrote:
>> on 13/01/2015 11:48:28, Mark Wills wrote:
>>> On Tuesday, 13 January 2015 04:55:08 UTC, hughag...@gmail.com wrote:
>>>> (3.2.3.2.)
>>>> The control-flow stack may, but need not, physically exist in an implemen
>>> tation. If it does exist, it may be, but need not be, implemented
>>> using the data stack. The format of the control-flow stack is
>>> implementation defined . Since the control-flow stack may be
>>> implemented using the data stack, ite ms placed on the data stack are
>>> unavailable to a program after items are pl aced on the control-flow
>>> stack and remain unavailable until the control-flo w stack items are
>>>> removed.
>>>>
>>> removed.
>>>
>>> Yep. This is a total mess.
>>
>> Point out the mess. It seems pretty clear to me. If you don't understand
>> it, I'd suggest that you need to think about these questions.
>
> I understand. It's just that it's too permissive. There's one could write
> compliant code the runs on one system, but not on another, because the
> standard has granted what amounts to (in this particular case) too much
> freedom to the implementor.
The critical concept here is code that is dependent on a particular
implementation strategy. The Standard is posting a warning that if you
choose to allow carrying something on the stack into or out of a
definition (which, it seems, is what you're really concerned about) you
have a dependency on a system that doesn't implement checks on this.
Your code is not *fully compliant* unless it declares this dependency,
and it's up to you to look at systems you wish to run it on and
determine whether they will support your dependency or not.
Historically, the issue of passing values on the stack into or out of
definitions arose in about 1982 when many FIG members were implementing
strict compile-time checks. One of the easiest ways to detect an
incomplete structure (e.g., an IF without a THEN) is to look for
something on the stack at ;-time, so that's one of the checking
strategies they implemented. It's supposed to be a benefit :-)
>> What is the control flow stack?
>> What words (potentially) use it?
>> When & how is it used?
>>
>> How do we standardise control flow?
>>
>> Do we always need a control flow stack?
>> . If no, does it need to exist?
>> . If yes, what forces us to require it? Can the requirement be relaxed?
>> Does the control flow stack need to be a separate stack from the data
>> stack? . If no, should the standard force it to be so? What advantages
>> does that have? . If yes, what causes this implementation requirement?
>> Can the requirement be relaxed?
The easiest way to implement structures such as loops and conditionals
is to let the words at the beginning of the structure leave an address
on the stack (e.g. of the cell where the address of a branch is to go)
and let the word that completes the structure fill it in. Chuck did it
that way, and so do many if not most implementers today. This is using
the stack appropriately at compile time. As I noted above, the
restriction about carrying things on the stack into or out of colon
definitions was conceived primarily as an error checking policy. Systems
that do this are supposed to document this ("format of the control flow
stack" listed in Section 4.1.1 Implementation-defined Options), so if
your code has a dependency on being able to carry things into a
definition you know it won't run on those systems.
...
>>>> Using the data-stack as the control-flow stack is not an "implementation
>>> strategy" decision. This is behavior!
>>>
>>> Here here!
As others have noted, the phrase you're looking for is "Hear, hear!"
This is a traditional cry in the UK Parliament agreeing with a statement
("everybody *hear* this!").
> I'm agreeing with Hugh. More specifically, deciding on a particular
> implementation strategy absolutely *will* lead to a particular *behaviour*.
> If your "control flow stack" is the data stack, then you can't pass data
> into a colon defintion (see Hugh's specific objection for the details)
> because the system *may* have put non-specific (colon-sys stuff) entries
> on the stack, above your data. My system might work like that. Yours may not.
> Both would be compliant. The coder pulls his hair out.
Some systems use the data stack as the control flow stack but don't
impose the restriction on passing data into a definition. The important
thing is that systems are supposed to document whether they do or do
not, in order to be compliant. So, these things shouldn't come as a
surprise unless you fail to check the system documentation.
...
>>> Bravo. Totally agree. It's possible to write a totally
>>> standard-compliant Forth program that follows all the guidance in the
>>> ANS standard, it will run on system A, and not on System B, where both
>>> systems A and B claim to be compliant. That's a failure IMO. It's a
If the system is "standard", it should document a list of practices
called for in Section 4.1. If your program is "standard", it will have
documented any dependencies on those practices. It's all about
documenting choices to ensure predictability.
...
> Perhaps. I'm trying to reflect on why the standard is like it is in as fair
> a manner as I can. I did state, and have stated before that I'm sure it's
> a terribly miserable, un-rewarding process to ratify a standard.
>
>>
>>>
>>> I think it's fairly obvious that the standard evolved in the way that
>>> it did
>>> for two reasons:
>>>
>>> 1) A desire to carry forward as much backwards compatibility with
>>> Forth-83 as possible (perfectly reasonable).
>>>
>>> 2) Commercial intertia. Vendors and implementors wanted to be able to
>>> stamp their systems as ANS compatible with the minimum (preferably
>>> none) of work. There's good reasons for this: They don't want to
>>> introduce backwards compatibility problems with previous versions of
>>> their products - it hurts their customers.
People who go to the trouble and expense of working on standards (and it
takes a lot of both) hope that *users* (including both system
implementers and program writers) will follow them. The fewer
incompatibilities with past practice they introduce, the easier it will
be for users to adopt the new standard. Therefore, there is a great (and
appropriate) concern for backwards compatibility.
In fact, in the years since the adoption of Forth94 Forth systems have
become far more compatible than they were. As a company, FORTH, Inc. is
often called upon to work on applications written for some other Forth,
and it has become quite easy to do that, as well as to cooperate with
other companies such as MPE in projects.
...
>>>
>>> I would not have like to have been the chairperson on that committee,
>>> for sure!
>>
>> Elizabeth Rather fulfilled what is often an unrewarding task. Herding
>> cats is easier.
>
> I'm sure that's true. Hat's off to the entire committee. A standard is
> better than no standard. That's worth bearing in mind, too.
>
Thank you!
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-13 19:04 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <d640951a-36fd-4d75-802d-3db274e5ad8b@googlegroups.com> |
| In reply to | #35794 |
On Tuesday, January 13, 2015 at 1:40:12 PM UTC-7, Elizabeth D. Rather wrote:
> On 1/13/15 6:26 AM, Mark Wills wrote:
> Historically, the issue of passing values on the stack into or out of
> definitions arose in about 1982 when many FIG members were implementing
> strict compile-time checks. One of the easiest ways to detect an
> incomplete structure (e.g., an IF without a THEN) is to look for
> something on the stack at ;-time, so that's one of the checking
> strategies they implemented. It's supposed to be a benefit :-)
This can be done if the control-flow stack is independent of the data-stack, because words like THEN and REPEAT have access to the control-flow data.
Are you really suggesting that I'm trying to prevent the control-flow words from having access to the control-flow data? That's nonsense.
> > I'm agreeing with Hugh. More specifically, deciding on a particular
> > implementation strategy absolutely *will* lead to a particular *behaviour*.
> > If your "control flow stack" is the data stack, then you can't pass data
> > into a colon defintion (see Hugh's specific objection for the details)
> > because the system *may* have put non-specific (colon-sys stuff) entries
> > on the stack, above your data. My system might work like that. Yours may not.
> > Both would be compliant. The coder pulls his hair out.
>
> Some systems use the data stack as the control flow stack but don't
> impose the restriction on passing data into a definition. The important
> thing is that systems are supposed to document whether they do or do
> not, in order to be compliant. So, these things shouldn't come as a
> surprise unless you fail to check the system documentation.
> ...
> >>> Bravo. Totally agree. It's possible to write a totally
> >>> standard-compliant Forth program that follows all the guidance in the
> >>> ANS standard, it will run on system A, and not on System B, where both
> >>> systems A and B claim to be compliant. That's a failure IMO. It's a
>
> If the system is "standard", it should document a list of practices
> called for in Section 4.1. If your program is "standard", it will have
> documented any dependencies on those practices. It's all about
> documenting choices to ensure predictability.
No, it is not "all about documenting choices to ensure predictability" --- it is about minimizing choices to ensure predictability.
When people have to document choices, then this implies that their program will only work on a subset of the standard-compliant compilers --- and this implies a failure of the standard to ensure uniformity in behavior of the compilers.
> >>>> Using the data-stack as the control-flow stack is not an "implementation
> >>> strategy" decision. This is behavior!
> >>>
> >>> Here here!
>
> As others have noted, the phrase you're looking for is "Hear, hear!"
> This is a traditional cry in the UK Parliament agreeing with a statement
> ("everybody *hear* this!").
I'm reminded of a Kurt Vonnegut novel, "The Sirens of Titan." In this novel, there were alien creatures discovered who would repeat the same phrase over and over again throughout their lives. Linguists were called upon to translate this "language" (just one phrase) into English, and they found that the phrase means: "Here I am!"
This is actually what most people on Earth spend their life saying too, even though English is a more complex language than those aliens' language --- so Mark's spelling is also valid.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-01-11 23:24 +0000 |
| Message-ID | <m8v0o1$699$1@dont-email.me> |
| In reply to | #35660 |
hughaguilar96@gmail.com wrote:
> Avoiding decisions is actually worse than making bad
> decisions because the worst-case scenario allowed
> becomes the standard. If a person wants his program
> to run on any ANS-Forth compiler, he has to assume
> the worst-case every time --- because SwiftForth is
> always the worst-case, then SwiftForth effectively
> becomes the standard.
Gauche Scheme:
(use gauche.sequence)
(string-join
(permute
(string-split "
Avoiding decisions is actually worse than making bad
decisions because the worst-case scenario allowed
becomes the standard. If a person wants his program
to run on any ANS-Forth compiler, he has to assume
the worst-case every time --- because SwiftForth is
always the worst-case, then SwiftForth effectively
becomes the standard."
#/\W+/)
'(42 3 11 12 31)))
===>
"SwiftForth is the worst compiler"
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-09 18:09 +0100 |
| Message-ID | <m8p1un$kuv$1@dont-email.me> |
| In reply to | #35629 |
Paul Rubin wrote:
> I don't see the problem here: both behaviours that you might want are
> available in Ada, and the really bad one (nasal demon on overflow) never
> happens, what more can you ask for?
Have you ever worked with real hardware? There is a lot more crazy stuff
than what Ada allows. I think the worst thing I've ever seen was HP's PA-
RISC, where the assem
> Yeah, the trap could surprise
> someone who expected wrapping, but the reverse is also true if wrap was
> the default.
Sure. The expectation is set by what people already know.
>>> Forth's metaprogramming features are traditionally confusing, I think.
>> Hm, probably if you have the wrong mental model of how Forth works.
>
> That could be. I haven't explored that aspect of Forth all that
> carefully. It's fairly advanced Forth.
Yes, indeed. IMHO, the ]] ... [[ stuff has an easier mental model, you just
think about it as inserting that stuff between the brackets as sort-of macro
into the definition you are compiling to. The CREATE DOES> mental model
seems to make more difficulties, but the DOES> part is the "execution
method" of the word you defined.
> This is a well known attack and simply randomly initializing a
> traditional hash function doesn't always help much, since the attacker
> can figure out the random value with timing attacks. You need a
> cryptographic hash, see: https://131002.net/siphash/ (DJB and Aumasson).
> DJB actually for a long time has advocated balanced trees over hashing
> but Siphash is for those who still want to use hash tables.
We use a similarly design as SipHash, but instead of using xors and rotate,
we use xors, multiplication and rotate. Multiplication provides faster
mixing on current CPUs than ARX.
>> "Compile using -fno-aggressive-loop-optimizations to work around
>> segfault caused by changes in gcc 4.8 (LP: #1241772)."
>> https://bugs.launchpad.net/ubuntu/+source/x264/+bug/1241772
>
> OK, I looked: That description is misleading, the segfault was actually
> caused by buggy x264 code that happened to work with some legacy
> compilers. The code was reading past the end of an array, which is not
> allowed in C.
Are we talking about the same thing? Not using the aggressive unrolling
fixes the problem, so how can that come from reading past the end of the
array? There have been more x264 bugs that caused miscompilation, one was
some "too clever" coded piece, like
for(dd=d[k=0]; k<15; dd=d[++k])
d[k] = dd < 0 ? -dd : dd;
which did work after making it simpler.
>>> C's signed int type assumes the invariant n+1 > n for all n,
>> No, it doesn't. It simply is undefined by the standard, what happens
>> if n+1 overflows.
>
> To be more precise, for certain values of n (specifically INT_MAX),
> there is simply no such thing as n+1, so a program that attempts to add
> 1 to INT_MAX is not a valid C program.
No, you still get it wrong. It is a *non-portable* C program. There's a
difference between non-portable and invalid. The C standard is very
specific in defining the term "undefined" and it allows implementations to
step in and define behavior in case the standard marks it as undefined.
E.g. wrapv is a valid way of defining the successor of INT_MAX (which is
then INT_MIN), though it is outside the scope of the standard, and therefore
relying on wrapv behavior is simply non-portable. In the 80s and most of
the 90s, relying on wrapv behavior worked across all existing C compilers on
two's complement machines; it was a de facto standard.
>> Assuming that there is an invariant where there actually isn't is
>> wrong.
>
> The invariant is always there, for all valid C programs. A program that
> adds 1 to INT_MAX is not valid and the standard doesn't dictate what
> invalid programs are supposed to do.
It's not invalid. From flawed assumptions comes only flawed conclusions.
The C standard is not a strict standard, i.e. programs that are outside the
scope of the C standard still can be valid programs to a particular
compiler. That is deliberately so, the C standard both allows implementers
to experiment with C extensions *and* implementers to be specific on what
happens on undefined conditions of the C standard; it even encourages
implementers to do so!
This "invalid" is a totally flawed assumption. If the C standard wanted to
make some programs invalid, it would require completely different wordings.
> Look, I'm with you in that (like you) I personally think this is
> horrible, but I can understand why the committee did it that way.
It didn't do it that way. The GCC maintainers interpret it that way.
> I'm
> not going to accuse their product of having bugs, since it does what
> exactly they intended and advertised it to do. My reaction is that I
> simply don't want to use their product.
I'm with you, I don't want to use the product of the GCC maintainers. But
it's not the fault of the C standard committee.
> Meanwhile, I wrote my first Ada program last night (it prints the
> integers from 1 to 10 along with their squares) and fooled around with
> it some more today, mostly reading docs and mucking with the build
> tools. I haven't dealt with the type system yet, but I actually like
> what I see so far.
You are a type system guy, it probably is for you. I like the type system
of Go more, because most of the time, you can just let the compiler chose
the type for you, and Go gets it right (just like Haskell's inferred types).
>> The IMHO right way to optimize such code is to *first* prove that the
>> invariant holds.
>
> The invariant always holds, for every valid C program. That's how C is
> defined.
C is not defined that way. "Undefined" deliberately means "we did *not*
define what happens". It's not "invalid". There's a clear distinction
between "invalid" and "undefined".
Example: If you have a struct
struct v { union { struct { int i, j; }; struct { int k, l} w; }; } vl;
then
vl.i = 3; // valid
vl.k = 5; // invalid
vl.w.k = 5; // valid
That's invalid, and the compiler should reject vl.k (though of course, the C
standard allows a compiler to compile an invalid program).
Just search
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
for "invalid" and "undefined", and check the definition of terms.
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of
erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a diagnostic
message).
3 EXAMPLE An example of undefined behavior is the behavior on integer
overflow.
It even says here that this can be a nonportable program, and the program
execution can result in documented manner (dependent on the environment). A
nonportable program is certainly not invalid, most real world programs are
non-portable.
>> No, you apparently don't understand what "undefined behavior" means in
>> a standard, either. It means that there is no common ground on this
>> behavior within different implementations, and therefore a standard,
>> which bases on rough consensus can't find that consensus.
>
> I've heard that said of the Forth standard, from yourself, Elizabeth,
> and others. Since you are involved in the process I believe you when
> you say that's the goal of the Forth standard. The goal of the C
> standard is apparently something different, unless you can point me at
> someone from the C committee saying otherwise.
No, both standards come from a pretty similar background within ANSI, they
use a very related approach, there is little difference in their goals.
There are just some idiots out there who don't understand what they write.
> In the C standard,
> "undefined" should be interpreted as having a concrete meaning: "nasal
> demons".
No. Read the C standard, it tells you otherwise.
>> Each implementation can choose to define that behavior in a particular
>> way, e.g. define integer overflows to wrap around. GCC had defined
>> wraparound until 2.95.x, and introduced a workaround to restore the
>> old behavior (-fwrapv) in 3.3 or 3.4.
>
> If they documented wraparound in 2.95 and changed it in 2.96 that's bad;
> but in a new major release the change is more understandable, especially
> if they warned people. Every Python developer I know is still using
> Python 2 because of stuff that changed in Python 3, even though 3 has
> lots of actual improvements.
Python 2 and Python 3 are different, incompatible languages. For a single-
implementer language, breaking backwards compatibility may be feasible,
though people don't like it. For a critical infrastructure piece like GCC,
breaking existing programs just for fun is certainly a no-go and
disqualifies the maintainers.
>> "Undefined" is different from "indeterministic", but apparently current
>> language lawyers confuse the two things.
>
> I don't think the standard uses the term "indeterministic". They use
> "unspecified" for what you seem to think "undefined" means. E.g. if you
> say
> x = f(a(), b());
> then it's unspecified whether a or b is to be called first, but the
> compiler has to choose one or the other. The program is valid but it
> can't rely on calling a and b in a specific order. OTOH, "undefined"
> means that the program is invalid and can delete the hard disk.
I've copy-pasted what they mean with "undefined" above. "Undefined" *can*
mean that, but it can also be perfectly well documented and reliable on a
particular environment. As a maintainer, you can't move a feature from
"documented and reliable" into the "eat your cat" bin. This is just failing
to maintain the program.
"Undefined" simply is outside the scope of the standard, so relying on
undefined, but documented behavior results in nonportable programs. There
is no such thing as a portability police.
>> On the other hand, you also have a legacy customer base, and the
>> existing customer base expects that their programs continue to work
>
> http://xkcd.com/1172/
Yes, you need good reasons to change things. E.g. when 100 people complain
that holding down the space bar overheads their CPU, and then 1 person
complains that it is breaking his workflow. Then you can triage that and
say "I fixed the problem for a hundred, and created one for one person", and
that is an overall improvement.
> Fwiw, I knew a guy who worked on medical devices long before this
> undefined behaviour stuff became an issue. He said after you tested and
> certified the code on those things, it wasn't enough to check the code
> into source control: you also checked in the compiler. That was because
> you wanted to be sure you could reproduce the build, meaning the
> compiler had to have the exact same bugs as before (all compilers were
> even buggier then than they are now).
There are some critics to this way of certification, because it makes all
changes very hard to do, and that results in very long turnaround times to
fix bugs. That's also a bad thing.
Auditing the compiler is a good thing, Paul Bennett does that for his
audited Forth code (it's fairly straight-forward, because the Forth compiler
is so small and simple). The thing is: If the audited compiler is found to
have a bug later, I'd say the audit becomes invalid, and insisting on the
audited compiler is wrong. After all, the bug has not been discovered in
the audit, so the compiler to the current knowledge does not match the audit
documentation (even though it is the same compiler - it's the documentation
which is wrong).
> In the wrapv case, the 2.95 manual made a claim that people relied on,
> so it's reasonable to say it shouldn't be changed abruptly (N years and
> two major release number bumps later is not abrupt), and there's some
> sympathy. In the x264 case, the code was apparently invalid from day 1,
> so it's harder to claim it's the compiler's job to keep it working.
Maybe I picked the wrong x264 example... I didn't see the code in that
question, I only saw that not doing excessive unrolling fixes the problem;
so I doubt it really does read beyond the array boundaries (this would be a
problem regardless of unrolling or not). There were several cases of x264
code miscompilation, through the code was perfectly fine, and maybe just a
bit too complicated for the compiler to parse it correctly.
>> the standard committee tells you "no, we won't specify two's
>> complement wrapv integers, because these three weird DSPs and this
>> supercomputer from the 60s..."
>
> But, I gather the actual reason they won't specify wrapv and the
> compiler guys don't make wrapv the default, is that wrapv costs
> performance on modern machines. There are some benchmarks on Regehr's
> blog about this, IIRC.
Actually, they added a switch to enforce -fwrapv in 3.3 or so. A lot of
people use it. There are some optimizations which get disabled when you
select that switch, like dropping "if(n+1<n)" code; but that code usually
occurs *only* in software which relies on wrapv. You can make it faster,
but then it outputs wrong results.
--
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 | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-01-09 09:31 -0800 |
| Message-ID | <8d599454-5ef7-4fac-a2c1-b0a125e4f048@googlegroups.com> |
| In reply to | #35655 |
On Friday, January 9, 2015 at 11:09:08 AM UTC-6, Bernd Paysan wrote: > That is deliberately so, the C standard both allows implementers > to experiment with C extensions *and* implementers to be specific on what > happens on undefined conditions of the C standard; it even encourages > implementers to do so! You've said this repeatedly, and to this same guy. After you say it, he forgets it and then gives you a lecture on 'invalid' code as if you'd never heard such arguments and might possibly be enlightened by them. I think this is what's going on: the term 'nasal demon' is just so adorably cute, the C community collectively decided that getting to say 'nasal demon' a lot was more important than whatever the truth of the matter might be. If Paul ever understands your argument, he won't then be able to joke about how forgetting a cast would permit GCC to start mining for bitcoins on behalf of GCC's maintainers. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-09 11:16 -0800 |
| Message-ID | <87bnm7sr1u.fsf@jester.gateway.sonic.net> |
| In reply to | #35656 |
Julian Fondren <julian.fondren@gmail.com> writes: > You've said this repeatedly, and to this same guy. After you say > it, he forgets it and then gives you a lecture on 'invalid' code > as if you'd never heard such arguments and might possibly be > enlightened by them. That is a somewhat symmetric statement, Bernd keeps forgetting the same things too ;-). > I think this is what's going on: the term 'nasal demon' is just so > adorably cute, the C community collectively decided that getting > to say 'nasal demon' a lot was more important than whatever the > truth of the matter might be. I don't think there's serious disagreement on the truth of the matter--there's differing views on what to do about it. And if we're onto "adorably cute" phrases, try "portable assembler". That is what Bernd seems to have decided that the standard committee is supposed to be specifying, but they don't seem to have signed on to it, and sticking to that cute notion is IMHO preventing Bernd from understanding what the committee is really trying to do. Their belief (from what I can tell) is different: that they are specifying an HLL that enables ultra-aggressive optimization for very careful programmers at the acceptable cost of rude surprises for the unwary. We similarly hear all the time that Forth intentionally lets users shoot themselves in the foot. Be careful what you ask for. > If Paul ever understands your argument, he won't then be able to > joke about how forgetting a cast would permit GCC to start mining > for bitcoins on behalf of GCC's maintainers. We were way ahead of you. Early versions of GCC launched a Rogue game if you used a #pragma directive in your program. That was implemented by me at RMS's suggestion, since he thought it was crazy that #pragma should be "implementation-defined". That behaviour was his way of making fun of what the standard said. I don't remember the exact details but it was something like this: http://marc.info/?l=novalug&m=99658727803021
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-09 22:38 +0100 |
| Message-ID | <m8phni$o6b$1@dont-email.me> |
| In reply to | #35661 |
Paul Rubin wrote: > Julian Fondren <julian.fondren@gmail.com> writes: >> You've said this repeatedly, and to this same guy. After you say >> it, he forgets it and then gives you a lecture on 'invalid' code >> as if you'd never heard such arguments and might possibly be >> enlightened by them. > > That is a somewhat symmetric statement, Bernd keeps forgetting the same > things too ;-). No, I always refuted your argument by pointing to the same parts of the C standard, which tell you different, but it never sinks into your brain. Instead of citing the standard, you cite C maintainer's culture. >> I think this is what's going on: the term 'nasal demon' is just so >> adorably cute, the C community collectively decided that getting >> to say 'nasal demon' a lot was more important than whatever the >> truth of the matter might be. > > I don't think there's serious disagreement on the truth of the > matter--there's differing views on what to do about it. And if we're > onto "adorably cute" phrases, try "portable assembler". That is what > Bernd seems to have decided that the standard committee is supposed to > be specifying, but they don't seem to have signed on to it, and sticking > to that cute notion is IMHO preventing Bernd from understanding what the > committee is really trying to do. No, the committee is pretty clear in what they want to do. Please, for once, *read* the definition of "undefined" in the C standard. It includes invalid programs, but also includes pretty valid non-portable programs. And the issue with overflow is just non-portability (mostly outside the two's complement world). > Their belief (from what I can tell) > is different: that they are specifying an HLL that enables > ultra-aggressive optimization for very careful programmers at the > acceptable cost of rude surprises for the unwary. No, they aren't. Please cite the place where they do so. That is what the GCC maintainer think their job is. > We similarly hear all the time that Forth intentionally lets users shoot > themselves in the foot. Be careful what you ask for. Yes, Forth does so. But it's not about that the Forth system can take your well-tested code of today, and break it tomorrow. Nor do we say that only Forth2012 programs are valid Forth programs; we do acknowledge that people write non-portable code. That code is valid for a particular system (or even several systems), but doesn't work on other systems. That is what implementation defined is about. It's not about playing pranks. And the Forth standard also tells you that a standard program can't rely on a particular behavior on overflow (though it is impossible to have anything else than wrapv in two's complement through the implication that + deals with both signed and unsigned numbers). There's some minor difference in how the Forth standard talks about ambiguous conditions (as we call them), but apart from wording, the concept is the same. >> If Paul ever understands your argument, he won't then be able to >> joke about how forgetting a cast would permit GCC to start mining >> for bitcoins on behalf of GCC's maintainers. > > We were way ahead of you. Early versions of GCC launched a Rogue game > if you used a #pragma directive in your program. That was implemented > by me at RMS's suggestion, since he thought it was crazy that #pragma > should be "implementation-defined". That behaviour was his way of > making fun of what the standard said. I don't remember the exact > details but it was something like this: > > http://marc.info/?l=novalug&m=99658727803021 Ah, the misunderstanding that "implementation defined" equals to "doing something completely useless and completely unrelated" comes from RMS, and you are part of that culture. That makes it pretty obvious why you can't understand this, and why you keep insisting on your point of view. This point of view is your invention! Making fun of the C standard committee is ok, but failing to understand what they meant, and insisting in that this failure to understand them is their actual intention is just plain stupid. I know that RMS is a difficult person, and launching a game on #pragma is pretty close to adding malware into his system. It's an easter egg, it's the funny and harmless side of malware. The C standard committee certainly never meant #pragma to start some games. Actually, in the meantime, the GCC maintainer found a few uses for #pragma, but continue to use __attribute__ (which is also non-portable, and is not even allowed in standard C programs) instead: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html Thanks for explaining how this broken culture of what "implementation defined" means in the GCC maintainer community came about. Given that __attribute__ is completely invalid, and #pragma is not used, it shows that GCC maintainers don't understand what #pragma was for, even though they had the same thing. #pragma tells you "here is the non-portable stuff". It became worse after RMS left. With RMS, at least the idea was there that GCC should be the portable assembler of the GNU system - RMS is a Lisp guy, he would never think of C as a high level language, but he did a quite good job at making it a portable assembler - with extensions like long long or computed goto. Of course, computed gotos already worked in K&R C (with a different syntax, a label was just an address, you didn't have to write && before; from the concept, this is pretty obvious that "goto foo;" equals "void *a = foo; goto *a;"), but were never standardized. But now we have this twist that GCC is supposed to be a benchmarking HLL instead of a portable assembler. As long as it compiles the spec benchmark suite, it is ok. Anything outside is unimportant. Unfortunately, the competition, clang, has the same philosophy. So it is the usual religious thing: It started with a joke of the religion founder, with good intention, and next generation we expect terrorist attacks by the language djihadists of the church of emacs when you do something undefined in C. -- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-16 13:44 -0800 |
| Message-ID | <87ppaemmd8.fsf@jester.gateway.pace.com> |
| In reply to | #35672 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> No, I always refuted your argument by pointing to the same parts of the C
> standard, which tell you different, but it never sinks into your brain.
I'd say you gave your personal interpretation of the text of the
standard, which isn't a crazy interpretation but which hasn't gotten
that much traction (that I know of) with implementers (gcc/llvm),
academics (Regehr, etc) or the standards committee. Note that the
passage you cited talked about erroneous input and consider that
"erroneous" means "invalid" (synonym shown at thesaurus.com).
> It includes invalid programs, but also includes pretty valid
> non-portable programs.
Non-conformant programs are valid only if the documentation for the
local environment says they are. So if the ANSI says that signed
integer overflow is undefined and the local environment doc (GCC manual
in this case) doesn't say otherwise, then it's invalid.
In the GCC 2.95 era the compiler manual specified wrapv behavior for
signed overflow, so your claim that an overflow-triggering program is
merely non-portable (instead of invalid) made sense in that environment.
In other environments whose docs don't include such a statement, you're
simply making unjustified assumptions.
>> The [committee's] belief [is] ... that they are specifying an HLL
>> that enables ultra-aggressive optimization
> No, they aren't. Please cite the place where they do so.
That's my summary of long discussions and debates with committee members
(mostly one person, but still). There's not a single document I can
point to. But here's an old post that gives some of the flavor:
https://groups.google.com/forum/message/raw?msg=sci.crypt/uPyldDtWV_Y/GubXCyF-o-4J
The guy who wrote that post was on the ANSI C committee and gave various
justifications for particular constructs being undefined because of
optimizations they enabled. IIRC he was a supercomputer programmer at
some military site, so he probably placed higher emphasis than most of
us about squeezing every drop of speed out of code. He wrote stuff like
that all the time. Unfortunately Google Groups has gotten almost
impossible to use so I'm not in a position to hunt down more quotes,
but that sci.crypt thread is likely to have more.
http://blog.regehr.org/archives/1180#comment-16431 is not from a
committee member AFAIK, but also illustrates that viewpoint about C:
UB is the only thing that has kept C compilers ahead of other
languages in terms of performance, and by extension, the only thing
that has kept C alive for so long. If you remove all of the small
competitive advantages that keep C “fast”, then it may as well not
exist as a language, since it has *very* little else going for it,
except for providing an system ABI for others to build on.
>> Early versions of GCC launched a Rogue game if you used a #pragma
> Actually, in the meantime, the GCC maintainer found a few uses for #pragma,
> but continue to use __attribute__ ...
> https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
I remember a few more details of that situation now, and your
Pragmas.html link refers to it indirectly. RMS didn't like #pragma
because the standard didn't permit generating them from preprocessor
#defines. So (when there was no inline keyword) you might want to use
an "inline" pragma optionally on a bunch of different functions, like
#if LOTS_OF_RAM
#define INLINE #pragma inline
#else
#define INLINE
#endif
INLINE f() { ... }
INLINE g() { ... }
but that wasn't allowed by the cpp specification. RMS complained about
this to the committee (along with a lot of other things) but they didn't
accept his advice about it, so he considered #pragma to be useless and
__attribute__ to be better. Having #pragma launch a game was one way he
showed his disapproval. The link you posted says
C99 introduces the _Pragma operator. This feature addresses a major
problem with ‘#pragma’: being a directive, it cannot be produced as the
result of macro expansion. _Pragma is an operator, much like sizeof or
defined, and can be embedded in a macro.
which means the committee finally fixed the problem RMS complained about
10+ years earlier, before even the first version of the standard was
approved, and that had inspired the rogue-launching hack. So now I
guess _Pragma can be used instead of __attribute__ .
> RMS is a Lisp guy, he would never think of C as a high level language,
> but he did a quite good job at making it a portable assembler
There's a proposal for a "friendly dialect of C" that you might like:
http://blog.regehr.org/archives/1180
I notice most of the support in the comments comes from embedded
developers. I think at the time C was first standardized, there may
have been an unnoticed divide between the embedded programmers and the
HPC programmers: the stuff you're saying is reasonable from the embedded
side, but doesn't really acknowledge the desires of the HPC side or how
those desires influenced the standard. These days there's a third set
of concerns arising from internet security that turns C into nightmare.
Meanwhile, I recently learned the really cool German word
"Gretchenfrage", a question that cuts to the center of an issue.
Suppose the "friendly" C dialect is implemented in GCC, and suppose it's
even made the default, so to get all that UB you have to use the
"-faggressive-ansi" option. I know that lots of the gforth development
work went into making it fast, and lots of gforth-related publications
contain benchmark data comparing it to competing Forths. You find that
with -faggressive-ansi, gforth and gforth-fast still passes all their
tests and runs 10% faster than with the friendly setting.
So do you use the option? If yes, how are your complaints about ANSI
legitimate? If not, what does that say about your confidence in your
development skills and testing processes?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-17 02:39 +0100 |
| Message-ID | <m9cefo$qd6$1@dont-email.me> |
| In reply to | #35853 |
Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> No, I always refuted your argument by pointing to the same parts of the C
>> standard, which tell you different, but it never sinks into your brain.
>
> I'd say you gave your personal interpretation of the text of the
> standard, which isn't a crazy interpretation but which hasn't gotten
> that much traction (that I know of) with implementers (gcc/llvm),
> academics (Regehr, etc) or the standards committee. Note that the
> passage you cited talked about erroneous input and consider that
> "erroneous" means "invalid" (synonym shown at thesaurus.com).
It does, but that's not the point at all.
I insist that you all *can't* read. The passage says "non-portable programs
*or* erroneous program constructs *or* erroneous data". *or* - two times
*or*, this is a list of three possible cases. What is so difficult to
understand that there are *three* possible ways to get to undefined
behaviors, of which one is simply a non-portable program? Why do you always
omit the first one? A non-portable program construct is *not* erroneous!
I think you are all binary types, and you forgot that there was a first
possibility after reading the other two. Brain buffer overflow ;-).
> Non-conformant programs are valid only if the documentation for the
> local environment says they are. So if the ANSI says that signed
> integer overflow is undefined and the local environment doc (GCC manual
> in this case) doesn't say otherwise, then it's invalid.
The environment, i.e. the "add" instruction on two's complement machines
makes GCC behave with wrapv behavior. If you map + to add, you have made a
choice. And you again forgot that there is a third option: It's
a) defined
b) non-portable
c) invalid
Don't omit the b) case!
> In the GCC 2.95 era the compiler manual specified wrapv behavior for
> signed overflow, so your claim that an overflow-triggering program is
> merely non-portable (instead of invalid) made sense in that environment.
> In other environments whose docs don't include such a statement, you're
> simply making unjustified assumptions.
Actually, you can write a test program that simply does "return a+b;", and
pass it ample of test data, and then prove that this "a+b" does wrapv. The
unjustified assumption is that of the compiler writher who thinks his
architecture is undefined on overflows. It isn't. The code the compiler
emits (without optimization) is 100% well-defined on overflow.
The assumption of the C compiler writers is that UB == anything, and
therefore, they are allowed to remove all code that is undefined behavior.
You are the one who likes formal proofs most here, and you certainly will
understand that by definition, UB != everything else. Because it's
undefined.
Well, actually they assume that a program that reaches undefined behavior is
buggy, and they are allowed to break all buggy programs. But, as I
repeatedly stated, the *third* possibility for reaching an UB is a non-
portable program. The non-portable program is not buggy, removing the UB in
that case is a compiler bug, not a program bug.
Almost all useful programs written in a Linux system are platform specific
programs. People don't write to a standard, they usually write to a
platform, because making a fully standard program is way harder than making
a pretty portable, bot somewhat still platform-specific program.
The Gforth team uses GCC extensions, which makes Gforth a non-portable
program. We do so for at least two reasons: a) performance, b) promoting
free software (you can't compile Gforth with proprietary compilers; maybe
today, you can, because they all support GCC extensions; but we still think
that your soul will burn in the vi hell - that's a keyboard without escape
key - if you do so ;-).
>>> The [committee's] belief [is] ... that they are specifying an HLL
>>> that enables ultra-aggressive optimization
>
>> No, they aren't. Please cite the place where they do so.
>
> That's my summary of long discussions and debates with committee members
> (mostly one person, but still). There's not a single document I can
> point to. But here's an old post that gives some of the flavor:
>
>
https://groups.google.com/forum/message/raw?msg=sci.crypt/uPyldDtWV_Y/GubXCyF-o-4J
Hm, that looks at defending one of C's flaws, that it passes pointers only,
and has no internal way to pass an array (pointer+length) as a single
argument, and then forgets to implement that length check throughout the
standard library...
> The guy who wrote that post was on the ANSI C committee and gave various
> justifications for particular constructs being undefined because of
> optimizations they enabled. IIRC he was a supercomputer programmer at
> some military site, so he probably placed higher emphasis than most of
> us about squeezing every drop of speed out of code. He wrote stuff like
> that all the time. Unfortunately Google Groups has gotten almost
> impossible to use so I'm not in a position to hunt down more quotes,
> but that sci.crypt thread is likely to have more.
I'm perfectly ok with the goal that C should be a portable assembler, and
should not enforce checks on things where the programmer hasn't put an
explicit check.
However, "portable assembler" does not mean "many things are undefined". It
means that "the things are defined by the underlying hardware". Just like
in Fortran, you want + on integers to be mapped to the fastest add operation
your machine has. That's the one without overflow check, usually.
> http://blog.regehr.org/archives/1180#comment-16431 is not from a
> committee member AFAIK, but also illustrates that viewpoint about C:
>
> UB is the only thing that has kept C compilers ahead of other
> languages in terms of performance, and by extension, the only thing
> that has kept C alive for so long. If you remove all of the small
> competitive advantages that keep C “fast”, then it may as well not
> exist as a language, since it has *very* little else going for it,
> except for providing an system ABI for others to build on.
Yes, but you are reading it wrong, again: UB makes C fast, because the
underlying machine defines the behavior, not the C standard. Same as with
Fortran. There's a culture of making fast compilers which comes back to the
early 60s, and it is that the compiler should target the machine directly,
instead of trying to do some abstract stuff on its own. Fortran follows
that principle, Forth follows it, and C does/did so, too. That's a
different understanding of *why* things are UB: They are UB, because
different hardware behaves different. It's UB, because it is non-portable.
> I remember a few more details of that situation now, and your
> Pragmas.html link refers to it indirectly. RMS didn't like #pragma
> because the standard didn't permit generating them from preprocessor
> #defines. So (when there was no inline keyword) you might want to use
> an "inline" pragma optionally on a bunch of different functions, like
>
> #if LOTS_OF_RAM
> #define INLINE #pragma inline
> #else
> #define INLINE
> #endif
>
> INLINE f() { ... }
> INLINE g() { ... }
>
> but that wasn't allowed by the cpp specification.
Yes, that sounds pretty stupid. But that's not about #pragma being
implementation-defined, that's about #pragma being ill-conceived. These are
two completely different things.
> RMS complained about
> this to the committee (along with a lot of other things) but they didn't
> accept his advice about it, so he considered #pragma to be useless and
> __attribute__ to be better. Having #pragma launch a game was one way he
> showed his disapproval. The link you posted says
>
> C99 introduces the _Pragma operator. This feature addresses a major
> problem with ‘#pragma’: being a directive, it cannot be produced as
> the result of macro expansion. _Pragma is an operator, much like
> sizeof or defined, and can be embedded in a macro.
>
> which means the committee finally fixed the problem RMS complained about
> 10+ years earlier, before even the first version of the standard was
> approved, and that had inspired the rogue-launching hack. So now I
> guess _Pragma can be used instead of __attribute__ .
No, it's simply equal to #pragma <some thing>
https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
>> RMS is a Lisp guy, he would never think of C as a high level language,
>> but he did a quite good job at making it a portable assembler
>
> There's a proposal for a "friendly dialect of C" that you might like:
>
> http://blog.regehr.org/archives/1180
Ah, yeah, they got it. This doesn't mean I actually like C, but that's the
right spirit.
> I notice most of the support in the comments comes from embedded
> developers. I think at the time C was first standardized, there may
> have been an unnoticed divide between the embedded programmers and the
> HPC programmers: the stuff you're saying is reasonable from the embedded
> side, but doesn't really acknowledge the desires of the HPC side or how
> those desires influenced the standard. These days there's a third set
> of concerns arising from internet security that turns C into nightmare.
Yes, and the third set simply thinks that C sucks way too much to be
considered a programming language for secure software ;-). They are more on
your side, with formal proofs and that stuff. Personally, I'd think C has
too many flaws to make it useful fo security, and "you have to be careful"
is somewhat ok (you have to be careful about other things, too), but the
combination of not checking array bounds automatically *and* a standard
libary that has many calls who don't check array bounds manually is a
recipie for disaster.
> Meanwhile, I recently learned the really cool German word
> "Gretchenfrage", a question that cuts to the center of an issue.
> Suppose the "friendly" C dialect is implemented in GCC, and suppose it's
> even made the default, so to get all that UB you have to use the
> "-faggressive-ansi" option. I know that lots of the gforth development
> work went into making it fast, and lots of gforth-related publications
> contain benchmark data comparing it to competing Forths. You find that
> with -faggressive-ansi, gforth and gforth-fast still passes all their
> tests and runs 10% faster than with the friendly setting.
Then this other language still would be friendly C, because we rely on
friendly C. That's because we write a friendly Forth, where a number of
things are defined just like they are in friendly C. I don't think we can
write an unfriendly Forth, because that would be non-standard.
In other words: There's simply no 1:1 map from unfriendly C to Forth, so we
can't write a Forth VM in unfriendly C - it's impossible. Unfriendly C is a
useless programming language, and people start getting it.
> So do you use the option? If yes, how are your complaints about ANSI
> legitimate? If not, what does that say about your confidence in your
> development skills and testing processes?
Sorry, I think you still don't understand it: I'm perfectly fine with
writing a non-portable program, when I know where it won't be ported to,
e.g. to one's complement machines. This is not insane to write a program
that runs only on two's complement machines or only on byte-addressed
machines, because these are the vast majority of machines around now. Note
that I'm assuming the machine is defining that behavior, *not* the compiler.
The compiler should map operations to instructions.
I'm also fine to write for POSIX and to ignore Windows (you can still use
Cygwin to make your Windows Gforth-friendly). After all, I'm *also*
promoting free software with Gforth - as a GNU maintainer, this is my duty.
Proprietary software is evil. Your soul shall burn in vi hell if you use it
(and there is no escape! ;-).
A program that runs only on those machines is obviously non-standard by
design, because a true standard program works on one's complement and word-
addressed machines, and non-POSIX operating systems, too. Actually, nobody
really writes larger fully standard programs, so saying that a non-portable
program is non-standard is simply silly beyond any reason. In Forth, we say
the program is standard, but it has an environmental dependency (which
restricts portability). That sort of thinking makes live a lot easier.
I think the whole problem bogs down that you forgot the "non-portable
program" part of that sentence. You are very consistent with your
argumentation that this first option doesn't have a representation in your
mind. It is first for a good reason.
--
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]
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web