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 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-08 17:02 -0800 |
| Message-ID | <9c4862b2-c5f1-48f4-ba5a-577769e6a74a@googlegroups.com> |
| In reply to | #35586 |
On Thursday, January 8, 2015 at 7:49:17 AM UTC-7, Alex McDonald wrote: > 2. Structs typically, unlike objects, do not have private variables. P.X > P.Y and P.Z are therefore just global variables. Using global variables > as implicit parameters is something I avoid at all costs; I am not a fan > of structs, and don't use them if they can be reasonably avoided. Objects > are a better mechanism, especially for graphics. I never suggested using global variables as implicit parameters --- that is a complete misrepresentation of what I said --- obviously, the structs would be on the heap. Also, the words "struct" and "object" are synonymous. You are always talking nonsense like this: On Sunday, February 16, 2014 at 4:21:59 AM UTC-7, hughag...@yahoo.com wrote: > On Sunday, February 16, 2014 2:48:34 AM UTC-7, Alex McDonald wrote: > > You and I have had a long discussion about the poor quality of the > > implementation of popular sorts you wrote in your novice package, where > > you have serious misunderstandings of how pointers work. > > My SORT works fine (it uses the HeapSort algorithm by default, although I also have a QuickSort version), and I'm pretty sure that I know how pointers work. > > We haven't had any "long conversations" --- that would imply that I was interested in what you were saying and that there was an exchange of ideas --- actually, you're just a troll, and you lob weird accusations like this at me routinely.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2015-01-06 04:42 -0600 |
| Message-ID | <XN2dnVGIi-2wITbJnZ2dnUU7-dWdnZ2d@supernews.com> |
| In reply to | #35496 |
Paul Rubin <no.email@nospam.invalid> wrote: >> So you can't take a standard text book like TAOCP or today Wikipedia, >> go to the R/B tree section and implement the operations described >> there, because the typechecker will complain that your intermediate >> values are incorrect? That's the "fighting against the typechecker" >> thing I mentioned > > Actually there's another issue: having the tree be mutable at all would > require a totally different type signature and (like the in-place > quicksort) wouldn't be idiomatic Haskell. So it's an immutable tree > which means insertion (creating a new tree) has to be done differently > anyway. Isn't that rather putting the cart before the horse? Surely you don't like to choose an algorithm based on how well it fits the type system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-06 08:13 -0800 |
| Message-ID | <874ms3sx90.fsf@jester.gateway.sonic.net> |
| In reply to | #35501 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> having the tree be mutable at all would require a totally different >> type signature and ... wouldn't be idiomatic Haskell. > > Isn't that rather putting the cart before the horse? Surely you don't > like to choose an algorithm based on how well it fits the type system. We all do that all the time: self-modifying code and coroutines are straightforward in assembler but not so much in C or Forth, for example. Java makes you use OOP for everything. Haskell is about immutability (although there are ways around it) and that does steer one's choice of algorithms. Erlang allows high concurrency but its concurrent processes can't share objects in memory, again affecting algorithm choices (plus it also doesn't have mutation). There's a whole book "Purely functional data structures" about how to do things with immutable structures that are traditionally done with things like hash tables. On the other hand using those algorithms is probably impractical in languages without GC. There's a more mutation-friendly Haskell dialect called Disciple. The first chapter (p. 17) of the author's dissertation http://benl.ouroborus.net/papers/thesis/lippmeier-impure-world.pdf has the best-informed critique of Haskell that I know of.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-09 02:52 +0100 |
| Message-ID | <m8nc8q$84i$1@dont-email.me> |
| In reply to | #35496 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Factor actually does that, but the problem is that Factor then knows >> you made a mistake, but can't tell you where. > > If Factor figures out that the TOS is a single when you call XYZ, and it > know that XYZ expects the TOS to be a double, why can't it say "wrong > stuff on the stack at the call to XYZ"? Of course then you have to > figure out how the wrong stuff got there. Ok, let's ignore that Factor doesn't have single/double, and in Forth, a double is just two singles (and operating only on one half of it may be ok, e.g. : 2! ( d addr -- ) tuck ! cell+ ! ; is 100% valid code how to deal with a double. The actual problem is that for checking stack errors, you compute the stack effect of the actual definition, and compare it with the specified stack effect. IMHO the way to deal with the problem of useless error reports in case of a mismatch is to print out the actual per-word computation of the stack effect. E.g. the above would result in <3> tuck <4> ! <2> cell+ <2> ! <0> ; and you then can look at the annotated picture and guess where things don't match your assumption. >> Well, I actually don't that often sprinkle ~~, it is far easier to >> "single step" on the command line through the definition by typing one >> call after the other and examing the stack. > > Aha, that sounds like you want a single step debugger ;-). I'll have > to try that technique though. Actually, I don't want a single step debugger, as while walking through the code and finding the problem, I want to continue with the correct code. Usually, this step happens *before* the actual code is written into a word. >> The [Ada] semantics is trap-on-overflow; the surprise is that it >> traps. In many cases, saturate-on-overflow or wrap-around is also a >> reasonable option (mod N is a very common case for assymetric crypto). > > I wonder if that's supported by some other integer type. > Trap-on-overflow is the right thing if you want an Integer type that > models mathematical integers. It's reasonable for it to be the default > integer type in a language without bignums. But there should also be a > wraparound type available. Ada actually has the mod n type to define wraparound: http://en.wikibooks.org/wiki/Ada_Programming/Types/mod The problem with mathematical concepts and languages close to hardware is that the way hardware uses data is not very mathematical. >> Hm, one of the design principles of Forth is that it consists of >> really easy to understand building blocks, and that you can comprehend >> the system in total. > > Forth's metaprogramming features are traditionally confusing, I think. Hm, probably if you have the wrong mental model of how Forth works. That doesn't make them complicated, but if you refuse to adjust your mental model, it will cause constant pain. When you come from the Algol-like side, you are confused by the metaprogramming model, because you have never seen any such thing, and when you come from Lisp, you are thinking about Lisp metaprogramming, which is completely different. > The stack is conceptually simple, I agree; then there's the matter of > becoming fluent with using it, amounting to doing some annoying > "register allocation" in one's head to juggle stuff to the return stack > etc. It almost seems like a fetish to program without using locals > freely. That reminds me on my girlfriend, who complains that I'm using "English Chinese" instead of just using Chinese the way it is meant to. Of course it requires to be fluent in a fundamental construct of a language, and when you use locals to avoid using the stack, you are using reverse polish Algol, and not Forth. >> And the idea behind that is that when you understand things >> completely, and don't have to treat a lot of things as abstract black >> box, boosts productivity and helps you to write correct programs. >> Because you understand what you are doing. > > I've never felt that way. Abstractions are good, as long as they don't > leak too much. I want to be able to write "hello world" to the screen > as characters without thinking about the pixels making up the displayed > letters. The window system takes care of that, using abstractions of > its own, and so on. Yes, and the result is onion programming with layers and layers of abstraction, mostly not necessary or ill-designed. People are now crushing those abstractions even in Desktop OS stacks, e.g. look at Wayland: No, the window system is not taking care about your pixels of "hello world", it just offers you a pixmap to paint into, and you or your widget library is responsible for the pixels. Because the window system has been found to be the wrong place to deal about pixels. >> Probably. But that's C and Java code. I've only implemented an AVL tree >> in Forth 25 years ago (to check if that's a viable dictionary structure, >> and dismissed it, because the hash was so much better), > > You're the guy who doesn't like quicksort? I do like quicksort. The only thing I said was that your Haskell quicksort actually isn't quicksort, and if you don't use the advantages of quicksort like in-place and the very simple exchange-loop, you should better use mergesort, which is made for lists. The counter-measure against quicksort worst case is to pick a random pivot in the first few stages. > The hash table has terrible > worst-case performance while AVL is guaranteed O(log N) lookup and > insertion. Yes, the actual worst-case performance of the hash is O(N), but the likelyhood is M^-N with M buckets... IIRC, there was an attack against PHP's hashes by injecting deliberately key-value pairs that collide, and the counter-measure is to have a randomized hash function. Gforth in current git implements a hash function which can be randomized, but the normal dictionary search uses a constant initializer (so you still can craft an attack). Likelyhood is important for worst-case behavior; e.g. if you don't take likelyhood into account, any crypto algorithm would be "broken". > AVL is maybe more interesting in functional programming > since it can be implemented as an immutable structure (so the insert > operation makes a new tree that shares most of its nodes with the old > one). Yes. >> and the C and Java implementations of AVL trees are pretty similar: >> littered with checks and assertions. My Forth code wasn't. There are >> a few textbook cases you have to check, and you do that interactively, > > What happens when someone wants to modify the code? Not having > automated tests is so last-century ;-). Ah, after evaluating AVL trees, I decided that they are not worth keeping. I don't think you need automated tests for code you threw away. > Actually there's another issue: having the tree be mutable at all would > require a totally different type signature and (like the in-place > quicksort) wouldn't be idiomatic Haskell. So it's an immutable tree > which means insertion (creating a new tree) has to be done differently > anyway. Yes, indeed. I don't know how you would do AVL where you specify the balancing conditions in the signatur, but then, AVL also works by first inserting the new element, and *then* fixing the tree, and that requires O(log(N)) operations. >> I'm pretty sure the x264 code GCC recently broke > > Is there an open GCC bug about that? I'm sure it's closed, as "invalid". It is obviously a x264 bug, haha. Let's check... "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 Yes, it's not fixed in GCC. It had to be worked around by x264. > 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. Assuming that there is an invariant where there actually isn't is wrong. > and this > apparently allows some loop optimizations that speed up the program > compared to wraparound arithmetic, at the cost of nasal demons if the > invariant breaks. The IMHO right way to optimize such code is to *first* prove that the invariant holds. >>> TCC has been tested, but there's a difference between "tested" and >>> "pounded by billions of LOC of production code over tens of years". >> Ah, the GCC team then marks all the feedback as "invalid", and we poor >> programmers have to work around them. > > I've seen annoying complaints like > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475#c36 > > where the guy just doesn't seem to understand the concept of undefined > behavior. His complaint should be against the standard, not the compiler. 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. 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. "Undefined" is different from "indeterministic", but apparently current language lawyers confuse the two things. I would define a crypto hardware primitive to give you entropy as "indeterministic", and add a pretty hard specification like "must pass dieharder after bias removal" or so. But I certainly would not expect to get good entropy by adding two constant signed integers that will overflow. The code GCC produces for that is completely deterministic, and well-defined by the underlying machine. As a compiler writer, you have two jobs: First of all, you must implement the language standard. People expect that standard programs compile as the standard defines it (that is *only* the "defined" part of the standard). On the other hand, you also have a legacy customer base, and the existing customer base expects that their programs continue to work and don't require a new workaround with every new compiler version. This means that the standard team is forced not to over-define things so that they cause incompatibilities with existing systems. E.g. if you have a hardware that's one complement, mandating two's complement is a no-go, because it would break non-portable code written for the one's complement machine. You can do that only when nobody is interested in one's complement machines anymore, i.e. nobody maintains a compiler for that machine. Most of those "undefined" things are things that can be this way on this machine, and that way on that machine, but are completely well-defined on either machine (just the definition is different). So if you say "please, GCC maintainers, keep two's complement wrap on overflow integers as you used to", they tell you "no, we won't, because the standard says this is undefined behavior, please go to the standard committee to complain", and 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 which is still in use in the cellar of the NSA to break DES in realtime don't work that way". It might be that the current C standard theme doesn't remember that this was the reason for making that behavior unspecified 20 years ago... -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/ net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-08 18:34 -0800 |
| Message-ID | <c2062246-3f55-4fc2-b1f7-d95f4ea4f50e@googlegroups.com> |
| In reply to | #35619 |
On Thursday, January 8, 2015 at 6:52:54 PM UTC-7, Bernd Paysan wrote: > So if you say "please, GCC maintainers, keep two's complement wrap on > overflow integers as you used to", they tell you "no, we won't, because the > standard says this is undefined behavior, please go to the standard > committee to complain", and 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 which is still in use in the cellar of the > NSA to break DES in realtime don't work that way". > > It might be that the current C standard theme doesn't remember that this was > the reason for making that behavior unspecified 20 years ago... > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself" If you want it done right, you have to ask the GCC maintainers and the ANSI-C standard-committee nicely, and hope that they consider you important enough to listen to (I'm sure Gforth is their highest priority!). Really, Bernd, why don't you just write Gforth in x86 assembly-language? The x86 is almost a high-level language with all of those addressing-modes, and Intel is smart enough not to pull the rug out from under their users (unlike Motorola who made every processor incompatible with the previous processors, and consequently lost almost all market share). FASM has a nice macro-language --- a lot better than #DEFINE in C, which is pretty much useless --- it is really not difficult to learn assembly-language, and nobody in the real world will take you seriously as a compiler-writer until you do.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-08 20:29 -0800 |
| Message-ID | <87mw5stw3h.fsf@jester.gateway.sonic.net> |
| In reply to | #35619 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> IMHO the way to deal with the problem of useless error reports in case
> of a mismatch is to print out the actual per-word computation of the
> stack effect. E.g. the above would result in
> <3> tuck <4> ! <2> cell+ <2> ! <0> ;
That looks a good approach, though I've never used Factor.
>>> The [Ada] semantics is trap-on-overflow;
> Ada actually has the mod n type to define wraparound:
> http://en.wikibooks.org/wiki/Ada_Programming/Types/mod
> The problem with mathematical concepts and languages close to hardware is
> that the way hardware uses data is not very mathematical.
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? Yeah, the trap could surprise
someone who expected wrapping, but the reverse is also true if wrap was
the default.
>> 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.
> there was an attack against PHP's hashes by injecting deliberately
> key-value pairs that collide, and the counter-measure is to have a
> randomized hash function. Gforth in current git implements a hash
> function which can be randomized, but the normal dictionary search
> uses a constant initializer (so you still can craft an attack).
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.
> "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.
> Yes, it's not fixed in GCC. It had to be worked around by x264.
It's not fixed in GCC because GCC wasn't broken. It's x264 that was
broken and maybe still is.
>> 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.
> 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.
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. 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.
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.
> 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.
> 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. In the C standard,
"undefined" should be interpreted as having a concrete meaning: "nasal
demons".
> 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.
> "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.
> 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/
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).
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.
> 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.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-08 21:30 -1000 |
| Message-ID | <fsOdnfWYe4M8HjLJnZ2dnUU7-SOdnZ2d@supernews.com> |
| In reply to | #35629 |
On 1/8/15 6:29 PM, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: ... >> 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. In the C standard, > "undefined" should be interpreted as having a concrete meaning: "nasal > demons". I can't comment usefully on C standard terminology, but Bernd's comment does apply to Forth standards in my experience. There are actually two defined waffles in Standard Forth: "implementation *defined*:" Denotes system behaviors or features that must be provided and documented by a system but whose further details are not prescribed by the Standard. (translation: do what you wish, but you have to document it.) "implementation *dependent*:" Denotes system behaviors or features that must be provided by a system but whose further details are *not* prescribed by the Standard. (translation: do what you wish, and document it if you feel like it.) The most general case of "undefined behavior" is actually "implementation dependent." 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-09 11:14 -0800 |
| Message-ID | <7d97bc77-ae8e-4e7d-81a9-a8efa5869ba5@googlegroups.com> |
| In reply to | #35640 |
On Friday, January 9, 2015 at 12:30:42 AM UTC-7, Elizabeth D. Rather wrote: > On 1/8/15 6:29 PM, Paul Rubin wrote: > > Bernd Paysan <bernd.paysan@gmx.de> writes: > ... > >> 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. In the C standard, > > "undefined" should be interpreted as having a concrete meaning: "nasal > > demons". > > I can't comment usefully on C standard terminology, but Bernd's comment > does apply to Forth standards in my experience. There are actually two > defined waffles in Standard Forth: > > "implementation *defined*:" Denotes system behaviors or features that > must be provided and documented by a system but whose further details > are not prescribed by the Standard. (translation: do what you wish, but > you have to document it.) > > "implementation *dependent*:" Denotes system behaviors or features that > must be provided by a system but whose further details are *not* > prescribed by the Standard. (translation: do what you wish, and document > it if you feel like it.) > > The most general case of "undefined behavior" is actually > "implementation dependent." You were the chair of the ANS-Forth standards committee, but you don't know what the purpose of a standard is. It is 20 years too late, but I will tell you that the purpose of a standard is to standardize --- you don't have "defined waffles" or "nasal demons" or any other such nonsense --- you make a decision and stick with it, and if your decisions are good then your language will be popular. 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. Adding a lot of "defined waffles" to ANS-Forth is worse than just declaring the worst-case scenario to be the standard because all of these "defined waffles" confuse the heck out of the programmers and nobody is really sure what is standard and what isn't standard. This brings to mind Rush's "Free Will" song: "If you choose not to decide, you still have made a choice." I said this to John Hart of Testra when I visited recently, and he replied: "[The ANS-Forth committee] should have just declared SwiftForth to be the standard." Note however, that he didn't say that he would follow the ANS-Forth standard by buying a copy of SwiftForth. LOL
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-09 22:18 +0000 |
| Subject | Standards (was FORTH on the ...) |
| Message-ID | <m8pk28$1op$1@dont-email.me> |
| In reply to | #35660 |
on 09/01/2015 19:14:44, wrote: > On Friday, January 9, 2015 at 12:30:42 AM UTC-7, Elizabeth D. Rather > > wrote: >> <snip> >> The most general case of "undefined behavior" is actually >> "implementation dependent." > > You were the chair of the ANS-Forth standards committee, but you don't > know what the purpose of a standard is. > > It is 20 years too late, but I will tell you that the purpose of a > standard is to standardize --- you don't have "defined waffles" or > "nasal demons" o r any other such nonsense --- you make a decision and > stick with it, and if your decisions are good then your language will > be popular. I sit on several standard bodies' technical work groups (one of which is an ISO standard). This is not how standards are created or maintained. The purpose of a standard is, in the main, to allow interoperability and bring consistency to a specific technical area. Some standards innovate, but they are few and far between. Many consolidate current practice. None make irreversible decisions and hope that they will be popular. > > Avoiding decisions is actually worse than making bad decisions because > the worst-case scenario allowed becomes the standard. If a person > wants his pro gram to run on any ANS-Forth compiler, he has to assume > the worst-case ever y time --- because SwiftForth is always the > worst-case, then SwiftForth eff ectively becomes the standard. Nonsense. Avoiding decisions is normally because (a) no-one recognises that a decision needs to be made (b) making a decision would create issues for existing products (c) uniformity is not required or is undesirable. > > Adding a lot of "defined waffles" to ANS-Forth is worse than just > declaring the worst-case scenario to be the standard because all of > these "defined w affles" confuse the heck out of the programmers and > nobody is really sure w hat is standard and what isn't standard. > > This brings to mind Rush's "Free Will" song: "If you choose not to > decide, you still have made a choice." > > I said this to John Hart of Testra when I visited recently, and he > replied: "[The ANS-Forth committee] should have just declared > SwiftForth to be the standard." Note however, that he didn't say that > he would follow the ANS-Fo rth standard by buying a copy of > SwiftForth. LOL > Then he, like you, doesn't understand how standards are developed, how committees work, nor what they mean in practice. I suspect he was humouring you.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-10 03:15 +0100 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m8q1vj$hij$1@dont-email.me> |
| In reply to | #35678 |
Alex McDonald wrote: > on 09/01/2015 19:14:44, wrote: >> Avoiding decisions is actually worse than making bad decisions because >> the worst-case scenario allowed becomes the standard. If a person >> wants his pro gram to run on any ANS-Forth compiler, he has to assume >> the worst-case ever y time --- because SwiftForth is always the >> worst-case, then SwiftForth eff ectively becomes the standard. > > Nonsense. Avoiding decisions is normally because (a) no-one recognises > that a decision needs to be made (b) making a decision would create > issues for existing products (c) uniformity is not required or is > undesirable. I must say, I've some sympathy with Hugh's argument, let's say with the first half of it - as usual, he starts reasonable and then his hate at Forth Inc. takes over... What he describes is what happened in the C world: the standard team left something open to be implementation defined, and the implementers think that entitles them to start games, or format the hard disk, or eat your cat, because they don't understand that they have a responsibility to let common practice emerge, but think the standard is a specification which they simply have to implement, and over which they don't have control. This is why the Forth 20xx team has some "tighten up the standard" tasks ongoing - and allows people to participate, so that people don't feel like the standard is out of their control (won't help on people like Hugh who choose to insult people so much that they don't want to work with him). I've to check the notes, but we want to at least make 1 CHARS equals 1 (because most systems already do that, most programs rely on thatn, and the few with 1 CHARS != 1 byte could be fixed), and to make two's complement number representation standard. The latter would remove some ambiguous conditions, the former would make common practice actually standardized. We all learned from the misinterpretation of the C standard, and want to avoid that. We probably should also write that if the standard allows implementers choice, a high quality implementation is one that makes the best possible choice, and if consensus emerges (because "best possible" can only be one thing, can't it?), we will standardize on that. Of course, if you want to have a portable program, the attitude of expecting the worst is the right attitude. Stephen Pelc said to me that the way I port my programs (by putting pressure on the vendor to implement all the things I need in a reasonable way), my programs will never really become portable. He's right, but I'm doing that with everybody I cooperate with, and in turn make their systems more uniform and more similar to each other, which means that not only *my* programs become more portable (within the set of implementers I cooperate), but those of other people as well. When we are discussion "egoistic programming", my style certainly is egoistic. Writing portable programs, as Stephen puts it, is an egoless discipline, because apparently writing Forth systems is an egoistic discipline, which is why if you know one Forth, you know one Forth. I don't like it that way. The implementers provide a service to the application and library developers, and we would certainly have more libraries if it was easier to write a library that did run on more than one single Forth system, without a lot of painful porting effort. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/ net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-09 20:56 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <3c9fbb8c-739d-4b3e-908f-ac62762b63b6@googlegroups.com> |
| In reply to | #35682 |
On Friday, January 9, 2015 at 7:15:44 PM UTC-7, Bernd Paysan wrote: > Alex McDonald wrote: > > > on 09/01/2015 19:14:44, wrote: > >> Avoiding decisions is actually worse than making bad decisions because > >> the worst-case scenario allowed becomes the standard. If a person > >> wants his pro gram to run on any ANS-Forth compiler, he has to assume > >> the worst-case ever y time --- because SwiftForth is always the > >> worst-case, then SwiftForth eff ectively becomes the standard. > > > > Nonsense. Avoiding decisions is normally because (a) no-one recognises > > that a decision needs to be made (b) making a decision would create > > issues for existing products (c) uniformity is not required or is > > undesirable. > > I must say, I've some sympathy with Hugh's argument, let's say with the > first half of it - as usual, he starts reasonable and then his hate at Forth > Inc. takes over... What he describes is what happened in the C world: the > standard team left something open to be implementation defined, and the > implementers think that entitles them to start games, or format the hard > disk, or eat your cat, because they don't understand that they have a > responsibility to let common practice emerge, but think the standard is a > specification which they simply have to implement, and over which they don't > have control. RMS's games with #pragma were actually malware --- I wouldn't use a compiler of his after a stunt like that --- the purpose of #pragma was to allow some kind of common practice to emerge that would possibly be standardized later on. Anybody who used #pragma had to admit straight up that their program was not standard --- presumably they had a good reason to do this --- most people just ignored #pragma and stuck with the standard. > This is why the Forth 20xx team has some "tighten up the standard" tasks > ongoing - and allows people to participate, so that people don't feel like > the standard is out of their control (won't help on people like Hugh who > choose to insult people so much that they don't want to work with him). > I've to check the notes, but we want to at least make 1 CHARS equals 1 > (because most systems already do that, most programs rely on thatn, and the > few with 1 CHARS != 1 byte could be fixed), and to make two's complement > number representation standard. > > The latter would remove some ambiguous conditions, the former would make > common practice actually standardized. We all learned from the > misinterpretation of the C standard, and want to avoid that. We probably > should also write that if the standard allows implementers choice, a high > quality implementation is one that makes the best possible choice, and if > consensus emerges (because "best possible" can only be one thing, can't > it?), we will standardize on that. I'm way ahead of you --- I dropped CHARS from my own language, and just defined chars as being size 1. Actually, CELLS is problematic too. Almost all mathematical software depends upon knowing what the size of a cell is. It is possible to make software that is portable no matter what CELLS is, but doing so is not easy. My solution is to require the cell size to be 64 bits for the desktop-computer version of my language (so it can be used for mathematical work), but allow the cell size to be 16 or 32 bits for the micro-controller version --- on that subject, I think it is a bad idea for one language to be used for both desktop-computers and micro-controllers, so I have different languages. > Of course, if you want to have a portable program, the attitude of expecting > the worst is the right attitude. The worst-case scenario that ANS-Forth allows is too low --- ANS-Forth looks like it was designed for 1970s vintage computers such as the PDP-11 --- in 1994, the bar could have been raised for the compiler-writers, and this was really necessary if anybody was going to take ANS-Forth seriously. If the bar was raised even slightly however, then the Forth Inc. programmers would have failed to clear the bar, as they really weren't capable of anything except maintaining a warmed-over cadaver from the 1970s (SwiftForth). > Stephen Pelc said to me that the way I > port my programs (by putting pressure on the vendor to implement all the > things I need in a reasonable way), my programs will never really become > portable. He's right, but I'm doing that with everybody I cooperate with, > and in turn make their systems more uniform and more similar to each other, > which means that not only *my* programs become more portable (within the set > of implementers I cooperate), but those of other people as well. Gforth will never be used for commercial work because it is too slow. I found it to be about half the speed of SwiftForth (version-2 of SwiftForth that did almost no optimization), and SwiftForth is too slow for most commercial work. I think that you and Anton made a Faustian with Elizabeth Rather --- she allows you to be on the Forth-200x committee, and in exchange you agree to cripple Gforth so it runs at half the speed of SwiftForth, so as to not undermine SwiftForth sales. You have delusions of grandeur. You think that the C compiler-writers care about Gforth, but they don't because it is a toy --- they will never listen to you because you aren't important. You are not going to: "make their systems more uniform and more similar to each other, which means that not only *my* programs become more portable (within the set of implementers I cooperate), but those of other people as well." --- you are going to be ignored, because you're a crack-pot. > When we are discussion "egoistic programming", my style certainly is > egoistic. Writing portable programs, as Stephen puts it, is an egoless > discipline, because apparently writing Forth systems is an egoistic > discipline, which is why if you know one Forth, you know one Forth. How would Pelc know anything about writing portable programs? VFX provides a lot of code that can't be implemented in ANS-Forth and hence traps the users --- or, in some cases it can be implemented in ANS-Forth (I know, because I did so in the novice-package), but VFX doesn't provide the source-code and most likely did not implement it in ANS-Forth (the C" and S" we have been discussing, for example). Pelc is not really the best champion of "egoless discipline" --- that is somewhat comparable to giving Obama the Nobel Peace Prize. LOL > I don't like it that way. The implementers provide a service to the > application and library developers, and we would certainly have more > libraries if it was easier to write a library that did run on more than one > single Forth system, without a lot of painful porting effort. A good first step would be a standard that is actually taken seriously, in the sense that people write software that doesn't casually break the standard and can be ported from compiler to compiler (my novice package is the only example that I know of, and it was a struggle for me as I had to work around the bugs in the ANS-Forth design at every turn). This isn't enough though --- COBOL had portability, but nobody wrote libraries of code for COBOL, and everybody just did cut-and-paste. If you want to support the writing of libraries of general-purpose data-structures, you need to have lambda functions (I mean real lambda functions that have access to the local variables of the parent function, not the Payson-fake lambda-functions that are just :NONAME with some syntactic sugar).
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-01-12 03:02 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m8vdg7$je$1@dont-email.me> |
| In reply to | #35683 |
hughaguilar96@gmail.com wrote: > I think that you and Anton made a Faustian with > Elizabeth Rather --- she allows you to be on the > Forth-200x committee, and in exchange you agree to > cripple Gforth so it runs at half the speed of > SwiftForth, so as to not undermine SwiftForth sales. Why is the same harridan that almost killed Forth allowed to be the "chairman" of Forth 200x? Forget ANS and ISO. The men who care about Forth and want it to be a viable programming language should form their own committee, making sure to exclude hermaphroditic bitches (even if they twirl their mustaches and try to scratch your eyes out).
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-12 10:14 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m906pi$e2j$1@dont-email.me> |
| In reply to | #35733 |
on 12/01/2015 03:02:35, "WJ" wrote: > hughaguilar96@gmail.com wrote: > >> I think that you and Anton made a Faustian with >> Elizabeth Rather --- she allows you to be on the >> Forth-200x committee, and in exchange you agree to >> cripple Gforth so it runs at half the speed of >> SwiftForth, so as to not undermine SwiftForth sales. > > > Why is the same harridan that almost killed Forth > allowed to be the "chairman" of Forth 200x? > > Forget ANS and ISO. The men who care about Forth and want it > to be a viable programming language should form their own > committee, making sure to exclude hermaphroditic bitches (even > if they twirl their mustaches and try to scratch your eyes > out). > "Men of Forth, rise up! Your enormous testicles and potent seed are needed to create new programming languages!" What is it about whackaloon nutjobs on the internet? Why are they so obsessed with their dicks?
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-10 11:39 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <94945f9c-c692-4726-a683-7212c1abd65c@googlegroups.com> |
| In reply to | #35682 |
on 10/01/2015 02:15:38, Bernd Paysan wrote: > Alex McDonald wrote: > >> on 09/01/2015 19:14:44, wrote: >>> Avoiding decisions is actually worse than making bad decisions because >>> the worst-case scenario allowed becomes the standard. If a person >>> wants his pro gram to run on any ANS-Forth compiler, he has to assume >>> the worst-case ever y time --- because SwiftForth is always the >>> worst-case, then SwiftForth eff ectively becomes the standard. >> >> Nonsense. Avoiding decisions is normally because (a) no-one recognises >> that a decision needs to be made (b) making a decision would create >> issues for existing products (c) uniformity is not required or is >> undesirable. > > I must say, I've some sympathy with Hugh's argument, let's say with > the first half of it - as usual, he starts reasonable and then his > hate at Forth Inc. takes over... What he describes is what happened in > the C world: the standard team left something open to be > implementation defined, and the implementers think that entitles them > to start games, or format the hard disk, or eat your cat, because they > don't understand that they have a responsibility to let common > practice emerge, but think the standard is a specification which they > simply have to implement, and over which they don't have control. The C standard may be a pathological example, but my experience and that of others I work with doesn't match up to Hugh's claim that "avoiding decisions is actually worse than making bad decisions because the worst-case scenario allowed becomes the standard." Avoiding decisions and bad decisions bite everyone, and hard. This is commercial hard-nosed pragmatism at work, and even though these bodies are made up of competitors, there is no sense in a bad, defective or incomplete standard. So given grey or accidentally or even deliberately undefined areas, the market does its imperfect sifting and a de jure standard appears. If the standards body is still active, the issue get recognised, and there's an informal to formal agreement process. There is sometimes the tendency to think that parts of standards that you find difficult or impossible or even stupid aren't seen that way by others. This is where Hugh would be a complete nightmare. Ranting and raving like a swivel eyed loon generally gets you nowhere. Standards processes requires pragmatism and a willingness to compromise. Your competitors might see a commercial advantage in having it his way rather than yours. You get to vote, but you can't dictate. In summary, I can't think of an example in my area of expertise where it has been the worst-case scenario becomes the standard. No-one wants that. > > This is why the Forth 20xx team has some "tighten up the standard" > tasks ongoing - and allows people to participate, so that people don't > feel like the standard is out of their control (won't help on people > like Hugh who choose to insult people so much that they don't want to > work with him). That is good. There might be a criticism or two about the slowness of the process, and the method by which the Forth200x committee does its work and reaches consensus. Hugh's problem is not the committee's concern however. > I've to check the notes, but we want to at least make > 1 CHARS equals 1 (because most systems already do that, most programs > rely on thatn, and the few with 1 CHARS != 1 byte could be fixed), and > to make two's complement number representation standard. Yes. That would make sense. > > The latter would remove some ambiguous conditions, the former would > make common practice actually standardized. We all learned from the > misinterpretation of the C standard, and want to avoid that. We > probably should also write that if the standard allows implementers > choice, a high quality implementation is one that makes the best > possible choice, and if consensus emerges (because "best possible" can > only be one thing, can't it?), we will standardize on that. There can be more than one "best possible". Technical goodness and commercial success sometimes don't reside in the same end product. > > Of course, if you want to have a portable program, the attitude of > expecting the worst is the right attitude. Stephen Pelc said to me > that the way I port my programs (by putting pressure on the vendor to > implement all the things I need in a reasonable way), my programs will > never really become portable. He's right, but I'm doing that with > everybody I cooperate with, and in turn make their systems more > uniform and more similar to each other, which means that not only *my* > programs become more portable (within the set of implementers I > cooperate), but those of other people as well. > > When we are discussion "egoistic programming", my style certainly is > egoistic. Writing portable programs, as Stephen puts it, is an egoless > discipline, because apparently writing Forth systems is an egoistic > discipline, which is why if you know one Forth, you know one Forth. > > I don't like it that way. The implementers provide a service to the > application and library developers, and we would certainly have more > libraries if it was easier to write a library that did run on more > than one single Forth system, without a lot of painful porting effort. > That's beyond my current professional experience, but I take your word for it. Regretably, I no longer code for a living.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-01-13 18:08 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2015Jan13.190823@mips.complang.tuwien.ac.at> |
| In reply to | #35688 |
Alex McDonald <blog@rivadpm.com> writes:
>on 10/01/2015 02:15:38, Bernd Paysan wrote:
>> I must say, I've some sympathy with Hugh's argument, let's say with
>> the first half of it - as usual, he starts reasonable and then his
>> hate at Forth Inc. takes over... What he describes is what happened in
>> the C world: the standard team left something open to be
>> implementation defined, and the implementers think that entitles them
>> to start games, or format the hard disk, or eat your cat, because they
>> don't understand that they have a responsibility to let common
>> practice emerge, but think the standard is a specification which they
>> simply have to implement, and over which they don't have control.
>
>The C standard may be a pathological example
The C standard is ok, the problem is the C compiler maintainers.
>but my experience and that
>of others I work with doesn't match up to Hugh's claim that "avoiding
>decisions is actually worse than making bad decisions because the
>worst-case scenario allowed becomes the standard."
Actually that's the mindset of the GCC maintainers and also of Ted
T'so (ext2 and ext4 creator, ext3 destroyer). They see it as their
right, and almost as their responsibility to behave as badly as
possible for non-standard usage; Ted T'so even apologized for not
destroying ext3 as soon as he took over the maintenance.
But that's the wrong mindset for standards like C, Forth, and POSIX
file systems. These standards are a minimal specification; they don't
specify some stuff for a number of reasons (e.g., because the language
is supposed to be implemented on a wide range of hardware in the case
of Forth and C). It's not intended as a license to miscompile all
non-standard programs, and fortunately, the Forth implementors don't
see it that way; they tend to compile programs that worked on the last
version of the Forth system as intended, and that's one of their major
goals.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-13 20:04 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m93tnq$ju0$1@dont-email.me> |
| In reply to | #35790 |
on 13/01/2015 18:08:21, wrote: > Alex McDonald <blog@rivadpm.com> writes: >>on 10/01/2015 02:15:38, Bernd Paysan wrote: >>> I must say, I've some sympathy with Hugh's argument, let's say with >>> the first half of it - as usual, he starts reasonable and then his >>> hate at Forth Inc. takes over... What he describes is what happened in >>> the C world: the standard team left something open to be >>> implementation defined, and the implementers think that entitles them >>> to start games, or format the hard disk, or eat your cat, because they >>> don't understand that they have a responsibility to let common >>> practice emerge, but think the standard is a specification which they >>> simply have to implement, and over which they don't have control. >> >>The C standard may be a pathological example > > The C standard is ok, the problem is the C compiler maintainers. > >>but my experience and that >>of others I work with doesn't match up to Hugh's claim that "avoiding >>decisions is actually worse than making bad decisions because the >>worst-case scenario allowed becomes the standard." > > Actually that's the mindset of the GCC maintainers and also of Ted > T'so (ext2 and ext4 creator, ext3 destroyer). They see it as their > right, and almost as their responsibility to behave as badly as > possible for non-standard usage; Ted T'so even apologized for not > destroying ext3 as soon as he took over the maintenance. I think you're being unfair here. I can't comment on your characterisation of Ted Ts'o since I have a professional relationship with him. But I would point out that ext4 has never been subject to any formal standards program; I think the closest is the documentation here https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout, and no-one would claim it's any more than a de facto standard. ISO, ANS, RFCs are quite different, as you know. > > But that's the wrong mindset for standards like C, Forth, and POSIX > file systems. These standards are a minimal specification; they don't > specify some stuff for a number of reasons (e.g., because the language > is supposed to be implemented on a wide range of hardware in the case > of Forth and C). It's not intended as a license to miscompile all > non-standard programs, and fortunately, the Forth implementors don't > see it that way; they tend to compile programs that worked on the last > version of the Forth system as intended, and that's one of their major > goals. Here I defer to your greater knowledge of the C standard and compilers. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-01-14 02:43 +0100 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m94hj2$1lk$1@dont-email.me> |
| In reply to | #35793 |
Alex McDonald wrote: > I think you're being unfair here. > > I can't comment on your characterisation of Ted Ts'o since I have a > professional relationship with him. But I would point out that ext4 has > never been subject to any formal standards program; I think the closest > is the documentation here > https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout, and no-one would > claim it's any more than a de facto standard. ISO, ANS, RFCs are quite > different, as you know. Anton is referring to the following blog posting by Ted Ts'o, where he explains a failure of his file system: "[...] and so they become shocked and angry when their system locks up and they lose data — even though POSIX never really made any such guarantee." http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ It's not POSIX' task to make a guarantee whether a file system loses data or not. It is your responsibility as developer of a file system that can be put in production use that it does not lose data. The entire lament about the users not doing fsync() on files where they want to keep the data, and pointing to POSIX was completely stupid. He didn't even understand the actual problem: The problem is that file allocation and writeback was delayed (including delay for going into the journal), while metadata allocation and writeback wasn't delayed. So you had a reordering of your operations, and after a crash, only parts were recovered, and not in the order the program has executed. Indeed, POSIX does not make such claims, and it should not. A RAM-disk will be completely empty after a crash, and no data whatsoever is preserved. Early Unix filesystems will contain garbage and you need fsck to sort out the mess. But a robust file system with journalling (that's what ext4 was developed for) should preserve the order of operations. Typical example how to replace files atomically: You create a new file, write to it, close it, and then rename the new file to the original name. Since the rename call is atomic, POSIX guarantees that anyone opening and reading that file will either see the old one or the new one, but not something in between. When a crash happened soon after with ext4, you would just see an empty file - neither the old, nor the new. That's because the metadata operations all went through the journal, but the data didn't. btrfs had the same bug at that time (being pretty early in development, such things happen), but its author fixed it promptly, and didn't argue much, other than saying that even while POSIX didn't require him to do so, it's a good idea. And Ted Ts'o backpedalled sometimes later, too, and ext4 now does save the data into the journal, as well, so it can be recovered. -- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-01-14 13:34 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2015Jan14.143457@mips.complang.tuwien.ac.at> |
| In reply to | #35793 |
"Alex McDonald" <blog@rivadpm.com> writes:
[Anton Ertl:]
>> Actually that's the mindset of the GCC maintainers and also of Ted
>> T'so (ext2 and ext4 creator, ext3 destroyer). They see it as their
>> right, and almost as their responsibility to behave as badly as
>> possible for non-standard usage; Ted T'so even apologized for not
>> destroying ext3 as soon as he took over the maintenance.
>
>I think you're being unfair here.
>
>I can't comment on your characterisation of Ted Ts'o since I have a
>professional relationship with him. But I would point out that ext4 has
>never been subject to any formal standards program; I think the closest
>is the documentation here
>https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout, and no-one would
>claim it's any more than a de facto standard. ISO, ANS, RFCs are quite
>different, as you know.
The standard that Ted Ts'o referred to to justify making ext3 less
crash-resistant is POSIX; this is a standard on Unix file systems in
general, not just for ext3 or ext4. It does (or did, at the time) not
say anything about the behaviour on crashes, an area where the quality
of the file systems varies widely. An example how a bad file system
loses data happened to me:
http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html
And here's a guarantee that a high-quality file system should give:
http://www.complang.tuwien.ac.at/papers/czezatke%26ertl00/#tth_sEc3.2
The problem with Ted Ts'o, like with the GCC maintainers, is that he
values benchmark results above real-user concerns like keeping data
across crashes.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-15 02:03 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m9775h$gtn$1@dont-email.me> |
| In reply to | #35811 |
on 14/01/2015 13:34:53, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: > [Anton Ertl:] >>> Actually that's the mindset of the GCC maintainers and also of Ted >>> T'so (ext2 and ext4 creator, ext3 destroyer). They see it as their >>> right, and almost as their responsibility to behave as badly as >>> possible for non-standard usage; Ted T'so even apologized for not >>> destroying ext3 as soon as he took over the maintenance. >> >>I think you're being unfair here. >> >>I can't comment on your characterisation of Ted Ts'o since I have a >>professional relationship with him. But I would point out that ext4 has >>never been subject to any formal standards program; I think the closest >>is the documentation here >>https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout, and no-one would >>claim it's any more than a de facto standard. ISO, ANS, RFCs are quite >>different, as you know. > > The standard that Ted Ts'o referred to to justify making ext3 less > crash-resistant is POSIX; this is a standard on Unix file systems in > general, not just for ext3 or ext4. It does (or did, at the time) not Some history. http://lwn.net/Articles/351422/ on POSIX. AFAIK there have been no changes since 2008 but I'd need to check. > say anything about the behaviour on crashes, an area where the quality > of the file systems varies widely. An example how a bad file system > loses data happened to me: > > http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html Also http://lwn.net/Articles/322823/ "Ext4 and data loss" which points to an Ubuntu buglist piece by Ts'o. He also blogged on the subject (see below). (Slightly off the subject, but if you're arguing for soft updates as an option -- which you mention without commment -- then see http://lwn.net/Articles/339337/; "Overall, soft updates is a sophisticated, insightful, clever idea - and an evolutionary dead end. Journaling and copy-on-write systems are easier to implement, require less special-purpose code, and demand far less of the programmer writing to the interface." Using flash or battery backed RAM, file systems using journals or CoW are commonplace. Many block based SANs use these techniques too.) > > And here's a guarantee that a high-quality file system should give: > > http://www.complang.tuwien.ac.at/papers/czezatke%26ertl00/#tth_sEc3.2 Ordered writes really don't make for decent performance, and write thru caching on disks can mess up even the most well behaved IO stream. > > The problem with Ted Ts'o, like with the GCC maintainers, is that he > values benchmark results above real-user concerns like keeping data > across crashes. Is this what you are referring to? http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/. I'd agree that there's perhaps too much "it's good enough" in this 2009 blog when it patently isn't good enough today; and it probably wasn't good enough then either.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-01-15 12:03 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2015Jan15.130316@mips.complang.tuwien.ac.at> |
| In reply to | #35819 |
"Alex McDonald" <blog@rivadpm.com> writes:
[Anton Ertl:]
>> The standard that Ted Ts'o referred to to justify making ext3 less
>> crash-resistant is POSIX; this is a standard on Unix file systems in
>> general, not just for ext3 or ext4. It does (or did, at the time) not
>
>Some history. http://lwn.net/Articles/351422/ on POSIX.
Any particular part of that long page that you want to point out?
Maybe one of my (anton's) comments? In any case, among other things
Val Aurora states what I stated:
|Fortunately for the file systems developers, the POSIX specification
|is so very minimal that it doesn't even mention the topic of file
|system behavior after a system crash. After all, the original
|FFS-style file systems (e.g., ext2) can theoretically lose your entire
|file system after a crash, and are still POSIX-compliant.
>(Slightly off the subject, but if you're arguing for soft updates as an
>option -- which you mention without commment -- then see
>http://lwn.net/Articles/339337/; "Overall, soft updates is a
>sophisticated, insightful, clever idea - and an evolutionary dead end.
>Journaling and copy-on-write systems are easier to implement, require
>less special-purpose code, and demand far less of the programmer writing
>to the interface."
Soft updates are only one of the approaches I mentioned. There are
interesting insights that can be gained from them:
Originally there was a design (FFS/UFS) that does not meet the
requirement of keeping a consistent snapshot of the data on crashes,
as demonstrated in my story.
Soft updates tried fulfill the requirement by keeping the on-disk
structure the same and ordering the writes; apparently that led to
complications in the code, so that other solutions won out:
Journaling puts (part of) the data in a journal, but keeps the on-disk
data structure the same otherwise, and writes the data there later.
The buffering offered by the journal relaxes the ordering constraints
to some extent.
Log-structured/copy-on-write file systems write the data to
unallocated places all the time, relaxing the ordering constraints
even more.
Lesson: It may be easier to redesign from scratch to meet a certain
requirement than to try to work the requirement into the existing
design, even if you find a way to do it.
>> And here's a guarantee that a high-quality file system should give:
>>
>> http://www.complang.tuwien.ac.at/papers/czezatke%26ertl00/#tth_sEc3.2
>
>Ordered writes really don't make for decent performance
I am much more interested in a file system that keeps my data than in
one that excels on benchmarks.
And the guarantee I ask for can be satisfied with very few ordering
constraints. E.g., if I want one commit per minute (i.e., I am
prepared to lose up to a minute of work on a crash), I need two disk
write barriers per minute (and having only one is almost as good). I
doubt that you can measure the perfomance impact of these write
barriers. If a minute is too much, I can do a commit every 10s, and
the overhead will still be hardly noticable.
You should not believe people who try to sell you on their misdesigned
file systems, and justify it with performance. Sure, fixing the
misdesigned file system in a cheap way by making all writes
synchronous (if that even works as a fix for ext4) will make it very
slow, but if you design a file system for the requirement, it will
cost relatively little.
> and write thru
>caching on disks can mess up even the most well behaved IO stream.
I guess you mean write(back) caching. Disk drives have stuff like
write barriers to allow to combine the performance advantages of write
caching while still giving enough guarantees about the order of
writes.
>> The problem with Ted Ts'o, like with the GCC maintainers, is that he
>> values benchmark results above real-user concerns like keeping data
>> across crashes.
>
>Is this what you are referring to?
>http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/.
He expressed his attitude in serveral places. I might have read this,
or might have read it somewhere else.
>I'd agree that there's perhaps too much "it's good enough" in this 2009
>blog when it patently isn't good enough today; and it probably wasn't
>good enough then either.
It certainly was not good enough in 2009; it never was. I have
written the first version of the page linked above in 1997 or earlier
<http://web.archive.org/web/19971016211234/http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html>
and yet Ted Ts'o developed ext4 in 2009 or so to have the same
problem, and at about the same time "optimized" ext3 so that it
acquired the same problem, and apologized for not making ext3 as bad
as he designed ext4 to be.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web