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 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2015-01-12 09:09 +0300 |
| Message-ID | <m2lhl8o7hl.fsf@gmail.com> |
| In reply to | #35726 |
Coos Haak <chforth@hccnet.nl> writes: > Op Sat, 10 Jan 2015 14:43:03 +0300 schreef Alexander Skobelev: > >> Coos Haak <chforth@hccnet.nl> writes: >> >>> Op Fri, 09 Jan 2015 16:25:57 +0300 schreef Alexander Skobelev: >>> >>>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>> >>>>> On 1/8/15 7:04 PM, Alexander Skobelev wrote: >>>>>> hughaguilar96@gmail.com writes: >>>>>> >>>>>>> The ANS-Forth standard doesn't support the use of C" and S" in >>>>>>> interpretive mode, and SwiftForth and Gforth both fail at this. I >>>>>>> fixed the problem in my novice package --- this is really necessary to >>>>>>> interactively debug functions that take strings as arguments. >>>>>>> >>>>>> >>>>>> Perhaps you have meant C" only, as S" in interpretive mode seems to be >>>>>> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). >>>>> >>>>> C" is actually not used very much nowadays, AFAIK. It was retained in >>>>> Forth94 because at the time some people used it, but I think counted >>>>> strings are used much less nowadays. >>>> >>>> I think they still can be useful for storing short strings in structure >>>> fields with a fixed width. >>>> >>>> Something like in this: >>>> 0 >>>> 22 CHARS +FIELD person.name >>>> ... >>>> CONSTANT Person >>>> >>>> , – where the person.name field is supposed to store a counted string of >>>> no more than 21 characters length. >>> >>> You can also store uncounted strings (left aligned) in the field >>>: PUT ( c-addr u addr -- ) >>> dup len blank \ Erase storage >>> swap len min cmove ; \ Store string >>>: GET ( addr -- c-addr u ) >>> len -trailing ; >>> Where addr is the address of the field and len is the size of the field, in >>> this case 22. >>> >> >> Yes, this is a possible solution. But I still prefer the counted strings >> more here as they don't require -trailing in the getter. > > So, leave it away ;-) Seems this is the only option – to live with a trail of spaces. :)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-09 10:52 -0800 |
| Message-ID | <db7331b9-c1b6-4b53-9693-a0d6a26738d3@googlegroups.com> |
| In reply to | #35632 |
On Thursday, January 8, 2015 at 10:04:09 PM UTC-7, Alexander Skobelev wrote:
> hughaguilar96@gmail.com writes:
>
> > The ANS-Forth standard doesn't support the use of C" and S" in
> > interpretive mode, and SwiftForth and Gforth both fail at this. I
> > fixed the problem in my novice package --- this is really necessary to
> > interactively debug functions that take strings as arguments.
> >
>
> Perhaps you have meant C" only, as S" in interpretive mode seems to be
> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165).
C" (6.1.2165) is in the "core ext" words and S" (6.1.2165) in the "core" words, and both have this statement:
Interpretation: Interpretation semantics for this word are undefined.
This means, that the ANS-Forth compiler-writer can do anything that he wants --- including mining for BitCoins on the customer's computer.
There is no C" in the "file" words, but there is a S" (11.6.1.2165) and it has this statement:
Interpretation: ( "ccc<quote>" -- c-addr u )
Parse ccc delimited by " (double quote). Store the resulting string c-addr u at a temporary location. The maximum length of the temporary buffer is implementation-dependent but shall be no less than 80 characters. Subsequent uses of S" may overwrite the temporary buffer. At least one such buffer shall be provided.
Note: "Subsequent uses of S" may overwrite the temporary buffer." This means that it is ANS-Forth compliant for a compiler to allow only one S" string to be in use at any time!
The problem here is that the mandate for ANS-Forth was that SwiftForth would be made standard without any changes --- nobody at Forth Inc. knows how to implement a circular buffer, so SwiftForth allows only one S" to be in use at any time --- consequently, the ANS-Forth standard had to be written to make this limitation legal (SwiftForth is the boat anchor that holds down the entire ANS-Forth community at Elizabeth Rather's level of ignorance).
VFX allows more than one C" or S" to be in use at any time, but if the VFX users rely on this feature, then they become trapped in using VFX because they can't port their code over to other ANS-Forth compilers (SwiftForth). By comparison, I fixed the problem in my novice-package by writing my own C" and S", but I did it with ANS-Forth code, so my users (I don't actually have any) can compile their programs with any ANS-Forth compiler (including SwiftForth).
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2015-01-10 15:31 +0300 |
| Message-ID | <m2lhlaizpc.fsf@gmail.com> |
| In reply to | #35658 |
hughaguilar96@gmail.com writes: > On Thursday, January 8, 2015 at 10:04:09 PM UTC-7, Alexander Skobelev wrote: >> hughaguilar96@gmail.com writes: >> >> > The ANS-Forth standard doesn't support the use of C" and S" in >> > interpretive mode, and SwiftForth and Gforth both fail at this. I >> > fixed the problem in my novice package --- this is really necessary to >> > interactively debug functions that take strings as arguments. >> > >> >> Perhaps you have meant C" only, as S" in interpretive mode seems to be >> Gforth as well as ANS-Forth in FILE word set (see 11.6.1.2165). > > C" (6.1.2165) is in the "core ext" words and S" (6.1.2165) in the > "core" words, and both have this statement: > > Interpretation: Interpretation semantics for this word are undefined. > > This means, that the ANS-Forth compiler-writer can do anything that he > wants --- including mining for BitCoins on the customer's computer. > > There is no C" in the "file" words, but there is a S" (11.6.1.2165) > and it has this statement: > > Interpretation: ( "ccc<quote>" -- c-addr u ) > Parse ccc delimited by " (double quote). Store the resulting string > c-addr u at a temporary location. The maximum length of the temporary > buffer is implementation-dependent but shall be no less than 80 > characters. Subsequent uses of S" may overwrite the temporary > buffer. At least one such buffer shall be provided. > > Note: "Subsequent uses of S" may overwrite the temporary buffer." This > means that it is ANS-Forth compliant for a compiler to allow only one > S" string to be in use at any time! > > The problem here is that the mandate for ANS-Forth was that SwiftForth > would be made standard without any changes --- nobody at Forth > Inc. knows how to implement a circular buffer, so SwiftForth allows > only one S" to be in use at any time --- consequently, the ANS-Forth > standard had to be written to make this limitation legal (SwiftForth > is the boat anchor that holds down the entire ANS-Forth community at > Elizabeth Rather's level of ignorance). > > VFX allows more than one C" or S" to be in use at any time, but if the > VFX users rely on this feature, then they become trapped in using VFX > because they can't port their code over to other ANS-Forth compilers > (SwiftForth). By comparison, I fixed the problem in my novice-package > by writing my own C" and S", but I did it with ANS-Forth code, so my > users (I don't actually have any) can compile their programs with any > ANS-Forth compiler (including SwiftForth). Well, yes, there are definitely some limitations on using S" in interpretative mode. And, perhaps, it would be better if they were less restrictive. Gforth allocates its S" strings in interpretative mode, but this means that you want to free them to avoid leaks. Your solution with preallocated buffers better in that it doesn't have leaks and it doesn't requier allocating memory on every call to S". OTOH they are still transitive buffers, that supposed to live short, thereis a limited number of them and they always take 256 bytes even if string contains just several characters.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-05 23:34 -0800 |
| Message-ID | <87iogkweeq.fsf@jester.gateway.sonic.net> |
| In reply to | #35490 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >> it would be easier if the compiler said "word XYZ expects a double >> and you passed a single". > 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. > 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. > Yes. However, the slow compiler is slow on code inspection, too. I meant manual inspection. > 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. > 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. > You have some learning curve, especially with the stack, but the main > point there is that you need to automate the thinking about it to > become fast; the concept behind is very easy to learn. 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. > 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. > 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? The hash table has terrible worst-case performance while AVL is guaranteed O(log N) lookup and insertion. 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). > 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 ;-). >> the traditional imperative algorithm for updating a red-black tree >> involves sometimes breaking the invariant on purpose... > 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. > My experience is that harder to program makes the program > automatically less correct, because the programmer is more exhausted > and skips things. That's a reason for wanting the compiler to keep track of what hasn't been done yet. > I'm pretty sure the x264 code GCC recently broke Is there an open GCC bug about that? > Actually, all contemporary CPUs do have the + operation as defined in > Forth: Working both on signed and unsigned. If C was about writing > the fastest possible program, it would expose the underlying hardware, > and be just a lightweight portable assembler, as it was in K&R's days. C's signed int type assumes the invariant n+1 > n for all n, 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. >> 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.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-05 22:22 -1000 |
| Message-ID | <AOudnTWR6qqhBjbJnZ2dnUU7-b2dnZ2d@supernews.com> |
| In reply to | #35496 |
On 1/5/15 9:34 PM, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: ... >> 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. What Bernd is describing is simpler than a single step debugger. ... >> 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. It's really not that bad. People get confused by imagining it's more complicated than it is. But you can write most applications without having to think about metaprogramming at all. >> You have some learning curve, especially with the stack, but the main >> point there is that you need to automate the thinking about it to >> become fast; the concept behind is very easy to learn. > > 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. It's really just a matter of practice. Forget doing any "register allocation in one's head", that'll only complicate things for you. It's really simpler than that. Think "stack of plates". The set of problems in the first chapters of Forth Programmer's Handbook are designed to get you over the worst phase. Don't even bother thinking about the Return Stack until you're completely comfortable writing appication code with the Data Stack. >> 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. So does TYPE. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-06 08:41 -0800 |
| Message-ID | <87zj9vrhe5.fsf@jester.gateway.sonic.net> |
| In reply to | #35497 |
"Elizabeth D. Rather" <erather@forth.com> writes:
> But you can write most applications without having to think about
> metaprogramming at all.
Right, it's an advanced feature, but it's not too outlandish to think of
someone finding themselves needing to write a new defining word, getting
confused about POSTPONE, and asking for (and receiving) help on clf.
That's something like what happened with Bernd's Ada example. I mean
why does Forth Inc have a support department? If everything was so
simple, users would never need support ;-).
> Think "stack of plates". Don't even bother thinking about the Return
> Stack until you're completely comfortable writing appication code with
> the Data Stack.
Really, all the practical Forth code I've looked at is full of stack
manipulation that obviously took some concentration to write. Leaving
that to the compiler frees up those mental cycles for more important
things.
Here's a classic example, where you want to draw a rectangle given the
coordinates of its lower left and upper right corners. x y MOVE lifts
the pen and puts it at location x,y while x y DRAW moves the pen
to x,y without lifting it. Simple implementation:
: draw-rectangle {: x0 y0 x1 y1 :}
x0 y0 MOVE x0 y1 DRAW x1 y1 DRAW x1 y0 DRAW x0 y0 MOVE ;
I remember seeing Chuck's code using VARIABLES for intermediate values
that didn't fit on the stack, but that doesn't seem like an improvement
over locals. Phil Koopman's book has a bunch more material on how it's
difficult to translate register code to stack code.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-06 10:30 -1000 |
| Message-ID | <vIednRitCbxx2DHJnZ2dnUU7-LWdnZ2d@supernews.com> |
| In reply to | #35507 |
On 1/6/15 6:41 AM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> But you can write most applications without having to think about
>> metaprogramming at all.
>
> Right, it's an advanced feature, but it's not too outlandish to think of
> someone finding themselves needing to write a new defining word, getting
> confused about POSTPONE, and asking for (and receiving) help on clf.
> That's something like what happened with Bernd's Ada example. I mean
> why does Forth Inc have a support department? If everything was so
> simple, users would never need support ;-).
Sure we do. But we don't get a lot of questions about that.
>> Think "stack of plates". Don't even bother thinking about the Return
>> Stack until you're completely comfortable writing appication code with
>> the Data Stack.
>
> Really, all the practical Forth code I've looked at is full of stack
> manipulation that obviously took some concentration to write. Leaving
> that to the compiler frees up those mental cycles for more important
> things.
>
> Here's a classic example, where you want to draw a rectangle given the
> coordinates of its lower left and upper right corners. x y MOVE lifts
> the pen and puts it at location x,y while x y DRAW moves the pen
> to x,y without lifting it. Simple implementation:
>
> : draw-rectangle {: x0 y0 x1 y1 :}
> x0 y0 MOVE x0 y1 DRAW x1 y1 DRAW x1 y0 DRAW x0 y0 MOVE ;
>
> I remember seeing Chuck's code using VARIABLES for intermediate values
> that didn't fit on the stack, but that doesn't seem like an improvement
> over locals. Phil Koopman's book has a bunch more material on how it's
> difficult to translate register code to stack code.
This is an issue of application design. The graphics packages we use at
FORTH, Inc. certainly use VARIABLEs, and I think it's very appropriate.
It's not because they "don't fit on the stack" but because in the
application there will be multiple definitions that need to access these
values (which is not possible with locals).
For example, in a drawing package we will typically have variables that
describe the height and width of the drawing window and a "current
cursor position" (x and y), as well as others that provide scaling
conversions between screen and "world" coordinates. It will have vector
arithmetic words, scaling words, etc. The definitions end up being nice
and clean, but without requiring locals.
The notion that VARIABLEs are anathema is one I have never understood or
subscribed to (and neither did Chuck, in the years I worked with him).
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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-06 13:37 -0800 |
| Message-ID | <87mw5vbnf9.fsf@jester.gateway.sonic.net> |
| In reply to | #35515 |
"Elizabeth D. Rather" <erather@forth.com> writes:
> The graphics packages we use at FORTH, Inc. certainly use
> VARIABLEs,... not because they "don't fit on the stack" but because in
> the application there will be multiple definitions that need to access
> these values (which is not possible with locals).
Sure, but if access by multiple definitions isn't needed, why expose the
variables?
> The notion that VARIABLEs are anathema is one I have never understood
Using variables instead of locals to hold temporary values is
unattractive because
1) they burn memory even when they're not in use. You could possibly
alias or re-use them but that's basically register allocation;
2) they expose the data to other functions unnecessarily; lots of the
cleanliness of Forth comes from stack cells used inside a word being
private to that word;
3) they pollute the global namespace
4) they aren't re-entrant.
I admire the ability to have stack-juggling code intuitively flow from
one's fingertips, like the example Alex McDonald just posted, to swap
two words given pointers to them:
: exchange ( ptrA ptrB -- ) 2dup @ swap @ rot ! swap ! ;
I can write code like that, though with a bit of head scratching rather
than by intuition. But a locals version (to me) looks cleaner and
simpler:
: exchange {: x y -- :} x @ y @ x ! y ! ;
So in an implementation where the compiler can generate good code from
the locals version, what is gained from writing the dup/rot/swap
version?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-06 13:02 -1000 |
| Message-ID | <l8idnXSq96Yd9DHJnZ2dnUU7-U-dnZ2d@supernews.com> |
| In reply to | #35516 |
On 1/6/15 11:37 AM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> The graphics packages we use at FORTH, Inc. certainly use
>> VARIABLEs,... not because they "don't fit on the stack" but because in
>> the application there will be multiple definitions that need to access
>> these values (which is not possible with locals).
>
> Sure, but if access by multiple definitions isn't needed, why expose the
> variables?
I haven't actually seen the need to do drawing in a single definition
and nowhere else in the application. Much better to have a collection of
drawing words appropriate to the application.
>> The notion that VARIABLEs are anathema is one I have never understood
>
> Using variables instead of locals to hold temporary values is
> unattractive because
>
> 1) they burn memory even when they're not in use. You could possibly
> alias or re-use them but that's basically register allocation;
Forth programs generally use a microscopic amount of memory compared
with simillar applications in other languages. This is why garbage
collection hasn't really caught on in Forth. I don't see use of memory
for variables that are part of a well-designed application any less
appropriate than use of memory for definitions.
> 2) they expose the data to other functions unnecessarily; lots of the
> cleanliness of Forth comes from stack cells used inside a word being
> private to that word;
A lot of the power of Forth comes from re-usability of code. Sharing
appropriate variables is a similar concept. I do not recall encountering
problems in applications due "exposed" variables any more than "exposed"
definitions. Obviously communication within a programming group is
important, but no moreso for this reason than any other. And it's my
experience that in an application with a graphics component it's very
convenient to have a set of common data structures shared by all the
components of the application that need them.
> 3) they pollute the global namespace
Why do named variables "pollute" namespace more than names of other
kinds of words? Well-chosen names for data structures of all kinds
promotes readability. In some very large applications we have used
various scoping methods (most widely-used Forths have some), but when
overused they can cause more inconveniences rather than less.
> 4) they aren't re-entrant.
What, exactly, is the re-entrancy need you're thinking of? If it's a
multitasking system (which is what I'm accustomed to) and multiple tasks
need to share the graphics code for different purposes, they will define
user variables (i.e., each task has its own copy). But in many
applications, it's important for all tasks to share these variables.
Again, this is an aspect of application design.
> I admire the ability to have stack-juggling code intuitively flow from
> one's fingertips, like the example Alex McDonald just posted, to swap
> two words given pointers to them:
>
> : exchange ( ptrA ptrB -- ) 2dup @ swap @ rot ! swap ! ;
>
> I can write code like that, though with a bit of head scratching rather
> than by intuition. But a locals version (to me) looks cleaner and
> simpler:
>
> : exchange {: x y -- :} x @ y @ x ! y ! ;
>
> So in an implementation where the compiler can generate good code from
> the locals version, what is gained from writing the dup/rot/swap
> version?
Stack management facility comes with experience :-)
Stephen, who manages a very good code generator, has shown that use of
locals is costly in performance. And, as I have been stressing, the
ability to share data structures among various related definitions is
valuable, and an important capability that locals deny.
To become a good Forth programmer, you need to understand that the
economics and tradeoffs in Forth are quite different than in many other
languages. These unique economics mean different design considerations
for writing good Forth applications.
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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-06 15:31 -0800 |
| Message-ID | <87iogjwkp5.fsf@jester.gateway.sonic.net> |
| In reply to | #35517 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Forth programs generally use a microscopic amount of memory compared > with simillar applications in other languages. This is why garbage > collection hasn't really caught on in Forth. I think it's the other way: Forth is mostly attractive in environments where GC is not feasible, due to small memory or realtime requirements. > I don't see use of memory for variables that are part of a > well-designed application any less appropriate than use of memory for > definitions. Variables need ram while definitions can be in flash. This is a significant difference in today's MCU's. Think of 4e4th, which runs in a cpu with 16k of flash and 512 bytes of ram. That's plenty of code space for lots of things, but ram is quite cramped and extra variables can increase memory pressure. >> 3) they pollute the global namespace > Why do named variables "pollute" namespace more than names of other > kinds of words? Of course all kinds of words pollute the namespace. When I write a word XYZ with some auxiliary words I tend to name them XYZ.1, XYZ.2 etc. rather than descriptively and it seems to work ok and decrease pollution. But variables should have descriptive names, which pollutes more. >> 4) they aren't re-entrant. > What, exactly, is the re-entrancy need you're thinking of? Multitasking is one possibility, recursion is another, calling the word from interrupt level while it's already in use at the application level is another. > Stephen, who manages a very good code generator, has shown that use of > locals is costly in performance. I wonder what the issue is, if the compiler does the natural things with locals and puts them in registers. > And, as I have been stressing, the ability to share data structures > among various related definitions is valuable, and an important > capability that locals deny. Most non-Forth programmers consider global variables to be an evil that's occasionally necessary. They use locals when they can and lift them out to global if they have to. But, they use locals like Forth uses stack slots; i.e., temporarily. The issue with the Forth stack solved by locals is the frequent need to muck around getting at elements that aren't at the top.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-01-07 01:15 +0000 |
| Message-ID | <54ac88b0$0$6894$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #35518 |
In article <87iogjwkp5.fsf@jester.gateway.sonic.net>,
Paul Rubin <no.email@nospam.invalid> wrote:
<SNIP>
>
>Most non-Forth programmers consider global variables to be an evil
>that's occasionally necessary. They use locals when they can and lift
>them out to global if they have to. But, they use locals like Forth
>uses stack slots; i.e., temporarily. The issue with the Forth stack
>solved by locals is the frequent need to muck around getting at elements
>that aren't at the top.
The problem is that the fear for globals is just a stupid dogma.
Most languages have nested scopes. So I have a couple of
auxiliary functions within my main function to handle
variables that are at the function scope. They are as dangerous
and poluting as in a program of the size of that main function.
So it is a matter of restricting scopes to a level that there is no
harmful confusion and this has very much to do with size.
There is no principal difference between fields in an object,
variables in a named common block (FORTRAN), names restricted
to a name space in Java, wordlist usage in Forth, using
prefixes-conventions in assembler, or private ("static") variables
in a c-file. It is compartmentalizing.
If you remove the skill of the programmer, and the discipline
to apply rules, all is lost.
Stupid management believes that by forbidding globals unskilled
programmers can make reliable programs. They can't.
And reentrancy is overrated, as becomes clear in the era of
parallel computing. Needed for interrupts? Did it ever occur
to you that including a source another time to compile the
interrupt routine works quite well, at least in Forth?
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-06 15:23 -1000 |
| Message-ID | <JMCdnQsxA6Y0FzHJnZ2dnUU7-TednZ2d@supernews.com> |
| In reply to | #35518 |
On 1/6/15 1:31 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Forth programs generally use a microscopic amount of memory compared >> with simillar applications in other languages. This is why garbage >> collection hasn't really caught on in Forth. > > I think it's the other way: Forth is mostly attractive in environments > where GC is not feasible, due to small memory or realtime requirements. Forth's advantages are particularly critical in limited memory environments, but its us is by no means restricted to them. Our customers manage quite a few good-sized applications, both embedded (e.g. on 68K-class processors) and PC-based. In all cases, the memory footprint is tiny compared to an equivalent program in C or other languages. There really has never been a perceived need for GC except by folks who feel it's somehow "immoral" to program without it. >> I don't see use of memory for variables that are part of a >> well-designed application any less appropriate than use of memory for >> definitions. > > Variables need ram while definitions can be in flash. This is a > significant difference in today's MCU's. Think of 4e4th, which runs in > a cpu with 16k of flash and 512 bytes of ram. That's plenty of code > space for lots of things, but ram is quite cramped and extra variables > can increase memory pressure. Sure, if you're writing code for a tiny MCU you have to be careful, but as I said above, that's really a small minority of the applications we see. 512 bytes of RAM is snug for development (when you'd really like to have some code in RAM), but more than ample for a running application. We have some products running in the field with 128 bytes of RAM, for stacks and variables; obviously they required some care in programming, but no locals. >>> 3) they pollute the global namespace >> Why do named variables "pollute" namespace more than names of other >> kinds of words? > > Of course all kinds of words pollute the namespace. When I write a word > XYZ with some auxiliary words I tend to name them XYZ.1, XYZ.2 > etc. rather than descriptively and it seems to work ok and decrease > pollution. But variables should have descriptive names, which pollutes > more. On rare occasions when we have a definition that exists only as a component of a larger word 'name' we'll call it (name), but for the most part we stick to descriptive names for everything. It really makes the code much more readable. In really big programs (e.g. thousands of names) we use wordlists or other scoping mechanisms. SwiftForth has "Packages" as well as OOP features, but we always try to use names that describe what words do or are used for. >>> 4) they aren't re-entrant. >> What, exactly, is the re-entrancy need you're thinking of? > > Multitasking is one possibility, recursion is another, calling the word > from interrupt level while it's already in use at the application level > is another. Well, I told you how we handle multitasking (with USER variables). Interrupts are relatively few in number, and it's easy to avoid conflicts. Usually the kinds of things an interrupt routine does have no overlap with high-level application code. However, VARIABLEs are invaluable for interrupt routines. For example, if you're acquiring data in an interrupt routine and putting it in a circular buffer, the hich-level code that is picking up that data and processing it has to have access to the VARIABLEs that track where the lates stuff is, so they're not only useful they're essential. >> Stephen, who manages a very good code generator, has shown that use of >> locals is costly in performance. > > I wonder what the issue is, if the compiler does the natural things with > locals and puts them in registers. I haven't looked at the code, but at the very least there's the overhead of setting up and taking down the locals frame. >> And, as I have been stressing, the ability to share data structures >> among various related definitions is valuable, and an important >> capability that locals deny. > > Most non-Forth programmers consider global variables to be an evil > that's occasionally necessary. They use locals when they can and lift > them out to global if they have to. But, they use locals like Forth > uses stack slots; i.e., temporarily. The issue with the Forth stack > solved by locals is the frequent need to muck around getting at elements > that aren't at the top. Yes, I know. That's what I mean by saying the economics and design tradeoffs are very different between Forth and other languages. If you design and write Forth programs in the Forth way, these things aren't issues. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-06 19:25 -0800 |
| Message-ID | <87d26rw9v3.fsf@jester.gateway.sonic.net> |
| In reply to | #35522 |
"Elizabeth D. Rather" <erather@forth.com> writes: > In all cases, the memory footprint is tiny compared to an equivalent > program in C or other languages. There really has never been a > perceived need for GC except by folks who feel it's somehow "immoral" > to program without it. Well, in PC and server environments, memory footprint generally isn't terribly important, within reason. GC isn't a "moral" necessity--it just makes programming easier unless application constraints (memory, realtime, etc) get in the way of using it. > Sure, if you're writing code for a tiny MCU you have to be careful, > but as I said above, that's really a small minority of the > applications we see. 512 bytes of RAM is snug for development True. These days even for an MCU, 512 bytes is cramped and I wonder why TI doesn't ship some bigger cpu's in the DIP package that the cheap Launchpad uses. The nearest competition is Cortex M0 parts which tend to have 4k of ram minimum. > On rare occasions when we have a definition that exists only as a > component of a larger word 'name' we'll call it (name) Yeah, my "name.1" convention is about the same, but expands to multiple components. I picked it up from assembly code that I've seen. > VARIABLEs are invaluable for interrupt routines. To communicate with the high level, sure; but a VARIABLE intended for use by just one word seems like a bug magnet. > I haven't looked at the code, but at the very least there's the > overhead of setting up and taking down the locals frame. I'd expect most of the time, no locals frame is needed, depending on how fancy the compiler is. But I haven't looked at the code either. >> The issue with the Forth stack solved by locals is the frequent need >> to muck around getting at elements that aren't at the top. > ...If you design and write Forth programs in the Forth way, these > things aren't issues. When I look at actual Forth code written by experts, it still seems to be an issue in that the code contains ugly stack juggling to get to interior values. It's just that the programmers have gotten used to it. I can understand how a b16/f18-style processor gets enough hardware simplification to justify having to program its tiny applications in an inconvenient style, but I have to wonder what the more general Forth world really gains by taking a computer full of perfectly good RAM and then forsaking the ability to randomly access the busiest part of it (the stacks). Anton's paper on the gforth locals system asked similar questions.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-06 17:52 -1000 |
| Message-ID | <B7Cdnbw9cdXnMDHJnZ2dnUU7-cWdnZ2d@supernews.com> |
| In reply to | #35523 |
On 1/6/15 5:25 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> In all cases, the memory footprint is tiny compared to an equivalent >> program in C or other languages. There really has never been a >> perceived need for GC except by folks who feel it's somehow "immoral" >> to program without it. > > Well, in PC and server environments, memory footprint generally isn't > terribly important, within reason. GC isn't a "moral" necessity--it > just makes programming easier unless application constraints (memory, > realtime, etc) get in the way of using it. Good, so you don't need to worry about variables taking up memory space :-) ... >> VARIABLEs are invaluable for interrupt routines. > > To communicate with the high level, sure; but a VARIABLE intended for > use by just one word seems like a bug magnet. Who's talking about a VARIABLE for just one word? We were talking about a graphics package that keeps various operating parameters in VARIABLEs or other data structures. Given that you're doing it that way, your draw-rectangle word would use those and not need locals *or* tortuous stack fiddling. The difficulty with sample definitions like you see on c.l.f is that there is no context as there would be in an application. Once in a while I see some really nasty piece of logic that can be simplified by defining a VARIABLE, but that's surely easier and less costly than dragging in a whole locals facility. >> I haven't looked at the code, but at the very least there's the >> overhead of setting up and taking down the locals frame. > > I'd expect most of the time, no locals frame is needed, depending on > how fancy the compiler is. But I haven't looked at the code either. > >>> The issue with the Forth stack solved by locals is the frequent need >>> to muck around getting at elements that aren't at the top. >> ...If you design and write Forth programs in the Forth way, these >> things aren't issues. > > When I look at actual Forth code written by experts, it still seems to > be an issue in that the code contains ugly stack juggling to get to > interior values. It's just that the programmers have gotten used to it. > I can understand how a b16/f18-style processor gets enough hardware > simplification to justify having to program its tiny applications in an > inconvenient style, but I have to wonder what the more general Forth > world really gains by taking a computer full of perfectly good RAM and > then forsaking the ability to randomly access the busiest part of it > (the stacks). Anton's paper on the gforth locals system asked similar > questions. Well, I'm not sure either what "expert" code you've looked at or what your threshold for "ugly" stack juggling is. Some Forth learners are appalled by any need for direct stack manipulation. I rarely see code by the programmers I work with whose stack manipulations are difficult to follow. To be sure, there are times when things do get nasty. We use locals in SwiftForth because calls to Windows procedures may involve lots of parameters, and it's a real mess getting them all squared away and in order. Locals help there, without question, and a few other places as well. But we haven't seen a need to use them in our cross-compilers, nor any demand from our SwiftX customers for them. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-01-06 21:15 -0800 |
| Message-ID | <878uhfw4qm.fsf@jester.gateway.sonic.net> |
| In reply to | #35524 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>> To communicate with the high level, sure; but a VARIABLE intended for
>> use by just one word seems like a bug magnet.
> Who's talking about a VARIABLE for just one word? We were talking
> about a graphics package that keeps various operating parameters in
> VARIABLEs or other data structures. Given that you're doing it that
> way, your draw-rectangle word would use those and not need locals *or*
> tortuous stack fiddling.
What's wrong with draw-rectangle with the API that I described? Here's
another example we've talked about before: multiply two complex numbers.
Locals version:
: c* { a b c d -- ac-bd ad+bc } a c * b d * - a d * b c * + ;
No-locals version:
: ac-bd ( a b c d -- ac-bd ) >r rot * swap r> * - ;
: ad+bc ( a b c d -- ad+bc ) -rot * >r * r> + ;
: z* ( a b c d -- ac-bd ad+bc) 2over 2over ad+bc >r ac-bd r> ;
Last time we discussed this I asked how Chuck would have done it, and
the answer was that he would drop to assembler. So much for Forth's
universality ;-).
> The difficulty with sample definitions like you see on c.l.f is that
> there is no context as there would be in an application.
I'll append a Forth game that I wrote and posted last year: I'm happy to
hear any criticisms, about excessive stack noise or anything else.
> Well, I'm not sure either what "expert" code you've looked at or what
> your threshold for "ugly" stack juggling is. ... I rarely see code by
> the programmers I work with whose stack manipulations are difficult to
> follow.
How about the word I posted by Alex, that swaps two pointers. I
don't know I'd call it "difficult", but it wasn't exactly obvious
to me what it was doing. I can never remember which way ROT rotates
so I always have to test (and I use -ROT more than ROT).
================================================================
#! /usr/bin/gforth
\ fifteen puzzle, tested with gforth 0.7.0. Have fun.
64 constant ATSIGN \ ascii atsign @
variable move# 1 move# ! \ move counter
create board 16 cells allot
: board& ( n -- addr ) cells board + ;
: board@ ( n -- value ) board& @ ;
: board! ( v n -- ) board& ! ;
\ show the board
: hexn ( n -- ) base @ swap hex . base ! ;
: square-show ( n -- ) \ show n as a hex digit or @ for zero
dup 0= if drop ATSIGN emit space else hexn then ;
: bs.1 ( n -- n ) 4 0 do dup board@ square-show 1+ loop ;
: board-show ( -- ) cr 0 4 0 do bs.1 cr loop drop ;
: bs ( -- ) board-show ;
\ find the empty cell next to a specified cell, if it exists.
: ck@.1 ( t n -- n | t ) dup board@ 0<> if drop else nip then ;
: ck@ ( t f n -- n | t ) swap if ck@.1 else drop then ;
: up? ( t n -- n|t ) dup 4 >= swap 4 - ck@ ;
: down? ( t n -- n|t ) dup 12 < swap 4 + ck@ ;
: left? ( t n -- n|t ) dup 4 mod 0<> swap 1- ck@ ;
: right? ( t n -- n|t ) dup 4 mod 3 <> swap 1+ ck@ ;
\ find empty square next to src, or return -1 if no empty square.
: get-empty ( src -- dst ) >r -1 r@ up? r@ down? r@ left? r> right? ;
\ move piece from location to adjacent empty square, if it's there.
: invalid ( src dst -- ) ." ?invalid " . . cr ;
: valid ( src dst ) 2dup board@ >r board@ swap board! r> swap board! ;
: move.1 ( src -- src dst valid ) dup get-empty dup -1 <> ;
\ attempt move, print error message if invalid (used during play)
: bump-move# ( -- ) 1 move# +! ;
: move-noisy ( src -- ) move.1 if valid bump-move# else invalid then ;
\ attempt move, ignore if invalid (used during shuffling)
: move-quiet ( src -- ) move.1 if valid else 2drop then ;
\ read hex digit from keyboard
: decimal? ( ch -- f ) '0 '9 1+ within ; \ check for decimal digit
: dconvert ( ch -- n ) dup decimal? if '0 - else drop -1 then ;
: hexletter? ( ch -- f ) 'a 'g within ; \ check for hex letter
: hconvert ( ch -- n ) dup hexletter? if 'a - 10 + else drop -1 then ;
: conv-digit ( ch -- n ) dup dconvert swap hconvert and ;
: keydigit ( -- n ) begin key conv-digit dup -1 = while repeat ;
\ Marsaglia multiply-with-carry (MWC) prng. not well tested, don't rely on.
1234 value m_z 2345 value m_w
: random.1 ( n -- n ) 65536 /mod swap 36969 * + ;
: get-random ( -- n ) m_z random.1 to m_z m_w random.1 to m_w
m_z 16 lshift m_w + ;
: randomize ( -- ) utime drop 65536 /mod to m_z to m_w ;
: randnibble ( -- n ) get-random 1237 mod $f and ; \ slightly biased but ok
: random-move ( -- ) randnibble move-quiet ;
: shuffle ( -- ) \ shuffle whole board by attemping many random moves.
20000 0 do random-move loop ;
: timed-shuffle utime shuffle utime 2swap d- d. ; \ just for jollies
\ play the game
: lose? ( sq -- f ) dup 1+ $f and swap board@ <> ;
: win? ( -- f ) -1 16 0 do i lose? if 1+ leave then loop ;
: xfind ( n -- loc ) \ find location of square containing n
16 0 do i board@ over = if drop i leave then loop ;
: congrats ( -- ) ." congrats you have won." cr board-show ;
: nmoves ( -- ) ." move# " move# @ . cr ;
: play.1 ( -- ) nmoves keydigit xfind move-noisy ;
: play.2 ( -- ) begin board-show play.1 win? until congrats ;
: board-init 16 0 do i 1+ $f and i board! loop ;
: intro ( -- )
." @ is the empty square, enter adjacent tile # to move it." cr
." Your goal is: " board-show cr ." Start:" ;
\ : cheat board-init 14 move-noisy play.2 ;
: play ( -- ) board-init intro shuffle play.2 ;
randomize play
bye
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-06 19:30 -1000 |
| Message-ID | <Vd-dndK3Wa0TWTHJnZ2dnUU7-eOdnZ2d@supernews.com> |
| In reply to | #35526 |
On 1/6/15 7:15 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> To communicate with the high level, sure; but a VARIABLE intended for
>>> use by just one word seems like a bug magnet.
>> Who's talking about a VARIABLE for just one word? We were talking
>> about a graphics package that keeps various operating parameters in
>> VARIABLEs or other data structures. Given that you're doing it that
>> way, your draw-rectangle word would use those and not need locals *or*
>> tortuous stack fiddling.
>
> What's wrong with draw-rectangle with the API that I described?
It's just that it's presented as a single definition without the context
of being a component of or supported by a graphics library, which would
surely be the case in a real-world application, so the tradoff of using
VARIABLES vs locals vs stack manipulation is different.
> Here's
> another example we've talked about before: multiply two complex numbers.
> Locals version:
>
> : c* { a b c d -- ac-bd ad+bc } a c * b d * - a d * b c * + ;
>
> No-locals version:
>
> : ac-bd ( a b c d -- ac-bd ) >r rot * swap r> * - ;
> : ad+bc ( a b c d -- ad+bc ) -rot * >r * r> + ;
> : z* ( a b c d -- ac-bd ad+bc) 2over 2over ad+bc >r ac-bd r> ;
>
> Last time we discussed this I asked how Chuck would have done it, and
> the answer was that he would drop to assembler. So much for Forth's
> universality ;-).
That has nothing to do with universality, and much more to do with
application requirements for performance. A complex multiply is a
component of an FFT, and Chuck wrote plenty of those. He wouldn't
tolerate the performance of a high-level complex multiply because we
were transforming fairly large arrays, and every cycle counted.
But of course he didn't use an external assembler, but the Forth
assembler that all Forths we've ever produced include. This was in the
days before optimizing compilers; I'm not sure the same decision would
apply today.
>> The difficulty with sample definitions like you see on c.l.f is that
>> there is no context as there would be in an application.
>
> I'll append a Forth game that I wrote and posted last year: I'm happy to
> hear any criticisms, about excessive stack noise or anything else.
>
>> Well, I'm not sure either what "expert" code you've looked at or what
>> your threshold for "ugly" stack juggling is. ... I rarely see code by
>> the programmers I work with whose stack manipulations are difficult to
>> follow.
>
> How about the word I posted by Alex, that swaps two pointers. I
> don't know I'd call it "difficult", but it wasn't exactly obvious
> to me what it was doing. I can never remember which way ROT rotates
> so I always have to test (and I use -ROT more than ROT).
It was very clear to me :-)
Thanks for the puzzle. At first glance it looks nice, but I'll look more
tomorrow (and be interested in comments from others).
Cheers,
Elizabeth
> ================================================================
> #! /usr/bin/gforth
> \ fifteen puzzle, tested with gforth 0.7.0. Have fun.
> 64 constant ATSIGN \ ascii atsign @
> variable move# 1 move# ! \ move counter
>
> create board 16 cells allot
> : board& ( n -- addr ) cells board + ;
> : board@ ( n -- value ) board& @ ;
> : board! ( v n -- ) board& ! ;
>
> \ show the board
> : hexn ( n -- ) base @ swap hex . base ! ;
> : square-show ( n -- ) \ show n as a hex digit or @ for zero
> dup 0= if drop ATSIGN emit space else hexn then ;
> : bs.1 ( n -- n ) 4 0 do dup board@ square-show 1+ loop ;
> : board-show ( -- ) cr 0 4 0 do bs.1 cr loop drop ;
> : bs ( -- ) board-show ;
>
> \ find the empty cell next to a specified cell, if it exists.
> : ck@.1 ( t n -- n | t ) dup board@ 0<> if drop else nip then ;
> : ck@ ( t f n -- n | t ) swap if ck@.1 else drop then ;
> : up? ( t n -- n|t ) dup 4 >= swap 4 - ck@ ;
> : down? ( t n -- n|t ) dup 12 < swap 4 + ck@ ;
> : left? ( t n -- n|t ) dup 4 mod 0<> swap 1- ck@ ;
> : right? ( t n -- n|t ) dup 4 mod 3 <> swap 1+ ck@ ;
> \ find empty square next to src, or return -1 if no empty square.
> : get-empty ( src -- dst ) >r -1 r@ up? r@ down? r@ left? r> right? ;
>
> \ move piece from location to adjacent empty square, if it's there.
> : invalid ( src dst -- ) ." ?invalid " . . cr ;
> : valid ( src dst ) 2dup board@ >r board@ swap board! r> swap board! ;
> : move.1 ( src -- src dst valid ) dup get-empty dup -1 <> ;
> \ attempt move, print error message if invalid (used during play)
> : bump-move# ( -- ) 1 move# +! ;
> : move-noisy ( src -- ) move.1 if valid bump-move# else invalid then ;
> \ attempt move, ignore if invalid (used during shuffling)
> : move-quiet ( src -- ) move.1 if valid else 2drop then ;
>
> \ read hex digit from keyboard
> : decimal? ( ch -- f ) '0 '9 1+ within ; \ check for decimal digit
> : dconvert ( ch -- n ) dup decimal? if '0 - else drop -1 then ;
> : hexletter? ( ch -- f ) 'a 'g within ; \ check for hex letter
> : hconvert ( ch -- n ) dup hexletter? if 'a - 10 + else drop -1 then ;
> : conv-digit ( ch -- n ) dup dconvert swap hconvert and ;
> : keydigit ( -- n ) begin key conv-digit dup -1 = while repeat ;
>
> \ Marsaglia multiply-with-carry (MWC) prng. not well tested, don't rely on.
> 1234 value m_z 2345 value m_w
> : random.1 ( n -- n ) 65536 /mod swap 36969 * + ;
> : get-random ( -- n ) m_z random.1 to m_z m_w random.1 to m_w
> m_z 16 lshift m_w + ;
> : randomize ( -- ) utime drop 65536 /mod to m_z to m_w ;
> : randnibble ( -- n ) get-random 1237 mod $f and ; \ slightly biased but ok
>
> : random-move ( -- ) randnibble move-quiet ;
> : shuffle ( -- ) \ shuffle whole board by attemping many random moves.
> 20000 0 do random-move loop ;
> : timed-shuffle utime shuffle utime 2swap d- d. ; \ just for jollies
>
> \ play the game
> : lose? ( sq -- f ) dup 1+ $f and swap board@ <> ;
> : win? ( -- f ) -1 16 0 do i lose? if 1+ leave then loop ;
> : xfind ( n -- loc ) \ find location of square containing n
> 16 0 do i board@ over = if drop i leave then loop ;
> : congrats ( -- ) ." congrats you have won." cr board-show ;
> : nmoves ( -- ) ." move# " move# @ . cr ;
> : play.1 ( -- ) nmoves keydigit xfind move-noisy ;
> : play.2 ( -- ) begin board-show play.1 win? until congrats ;
> : board-init 16 0 do i 1+ $f and i board! loop ;
> : intro ( -- )
> ." @ is the empty square, enter adjacent tile # to move it." cr
> ." Your goal is: " board-show cr ." Start:" ;
> \ : cheat board-init 14 move-noisy play.2 ;
> : play ( -- ) board-init intro shuffle play.2 ;
>
> randomize play
> bye
>
--
==================================================
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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2015-01-07 05:07 -0600 |
| Message-ID | <p9adndUs5Nz7jjDJnZ2dnUU7-QOdnZ2d@supernews.com> |
| In reply to | #35526 |
Paul Rubin <no.email@nospam.invalid> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> To communicate with the high level, sure; but a VARIABLE intended for >>> use by just one word seems like a bug magnet. >> Who's talking about a VARIABLE for just one word? We were talking >> about a graphics package that keeps various operating parameters in >> VARIABLEs or other data structures. Given that you're doing it that >> way, your draw-rectangle word would use those and not need locals *or* >> tortuous stack fiddling. > > What's wrong with draw-rectangle with the API that I described? I don't think anyone would choose that API in a Forth graphics package. I have posted and re-posted a better way to draw a box over the years, but at the risk of boring everyone here it is again. If you have words @X and @Y that return the current X and Y position, then : >X ( x - y x) @Y SWAP ; : >Y ( y - y x) @X ; : DRAW-BOX ( top left bottom right) 2OVER AT >X DRAW >Y DRAW >X DRAW >Y DRAW ; Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-01-07 15:08 +0000 |
| Message-ID | <2015Jan7.160831@mips.complang.tuwien.ac.at> |
| In reply to | #35533 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I have posted and re-posted a better way to draw a box over
>the years, but at the risk of boring everyone here it is again.
>
>If you have words @X and @Y that return the current X and Y position,
>then
>
>: >X ( x - y x) @Y SWAP ;
>: >Y ( y - y x) @X ;
>
>: DRAW-BOX ( top left bottom right)
> 2OVER AT >X DRAW >Y DRAW >X DRAW >Y DRAW ;
I have followed this newsgroup over the years, but somehow missed this
solution every time you posted it. It's interesting, but I have not
found anything yet that helps me deal with other problems.
So IIUC you assume words
AT ( y x -- ) sets the current point
DRAW ( y x -- ) draws a line from the current point to the one given
as parameter and set the latter as current point.
So, apart from the parameter order, AT is like Postscript's moveto,
and DRAW is like Postscript's lineto. Passing the parameters in y x
order is unusual. Any particular reason for that?
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2015-01-07 12:41 -0600 |
| Message-ID | <aPudnVlwm5Nw4DDJnZ2dnUU7-d-dnZ2d@supernews.com> |
| In reply to | #35542 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I have posted and re-posted a better way to draw a box over >>the years, but at the risk of boring everyone here it is again. >> >>If you have words @X and @Y that return the current X and Y position, >>then >> >>: >X ( x - y x) @Y SWAP ; >>: >Y ( y - y x) @X ; >> >>: DRAW-BOX ( top left bottom right) >> 2OVER AT >X DRAW >Y DRAW >X DRAW >Y DRAW ; > > I have followed this newsgroup over the years, but somehow missed this > solution every time you posted it. It's interesting, but I have not > found anything yet that helps me deal with other problems. > > So IIUC you assume words > > AT ( y x -- ) sets the current point > DRAW ( y x -- ) draws a line from the current point to the one given > as parameter and set the latter as current point. Right. This is AFAIK how the earliest Forth graphics package did it, and how Forth Inc have done it since. > So, apart from the parameter order, AT is like Postscript's moveto, > and DRAW is like Postscript's lineto. Passing the parameters in y x > order is unusual. Any particular reason for that? "x on top" has been the convention in every use of co-ordinates in Forth Inc software since the year dot. AFAICR their experience with real-world applications was that x tended to vary more than y. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2015-01-07 11:09 -1000 |
| Message-ID | <4KydnV3iPKDsPTDJnZ2dnUU7-dmdnZ2d@supernews.com> |
| In reply to | #35559 |
On 1/7/2015 8:41 AM, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> I have posted and re-posted a better way to draw a box over >>> the years, but at the risk of boring everyone here it is again. >>> >>> If you have words @X and @Y that return the current X and Y position, >>> then >>> >>> : >X ( x - y x) @Y SWAP ; >>> : >Y ( y - y x) @X ; >>> >>> : DRAW-BOX ( top left bottom right) >>> 2OVER AT >X DRAW >Y DRAW >X DRAW >Y DRAW ; >> >> I have followed this newsgroup over the years, but somehow missed this >> solution every time you posted it. It's interesting, but I have not >> found anything yet that helps me deal with other problems. >> >> So IIUC you assume words >> >> AT ( y x -- ) sets the current point >> DRAW ( y x -- ) draws a line from the current point to the one given >> as parameter and set the latter as current point. > > Right. This is AFAIK how the earliest Forth graphics package did it, > and how Forth Inc have done it since. > >> So, apart from the parameter order, AT is like Postscript's moveto, >> and DRAW is like Postscript's lineto. Passing the parameters in y x >> order is unusual. Any particular reason for that? > > "x on top" has been the convention in every use of co-ordinates in > Forth Inc software since the year dot. AFAICR their experience with > real-world applications was that x tended to vary more than y. Correct. The 1973 Forth system at NRAO had a graphics package written by Chuck, and it's been the basis for Forth graphics at FORTH, Inc. ever since. polyFORTH had a very extensive graphics library. Current FORTH, Inc. products do not have it because on Windows people generally prefer to use Windows functions, and those embedded systems that have some kind of graphic facility generally have very specific hardware features and functional requirements (though when called upon to implement something we will use the old code as a guide). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web