Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27495 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2013-12-28 23:39 -0800 |
| Last post | 2014-01-03 14:52 +0000 |
| Articles | 20 on this page of 330 — 25 participants |
Back to article view | Back to comp.lang.forth
PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2013-12-28 23:39 -0800
Re: PICK changed from 1-based to 0-based? Elizabeth D Rather <erather@forth.com> - 2013-12-28 21:52 -1000
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-29 11:28 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-29 23:12 +1100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 07:45 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-29 18:33 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 16:57 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-30 00:25 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-01 13:29 +1100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-01 14:18 +0000
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-01 15:46 +0100
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-01 15:26 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-03 13:22 +1100
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 11:54 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 10:57 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 14:07 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 12:42 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:22 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 09:06 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 11:10 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-04 11:49 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:14 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 16:35 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-05 11:35 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 06:15 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-05 15:11 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 10:07 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-05 21:14 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-06 04:44 -0600
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 12:42 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-06 21:51 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-06 22:41 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 03:29 +0100
Re: PICK changed from 1-based to 0-based? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-01-07 11:48 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-07 12:58 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 15:13 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-07 10:22 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-08 02:20 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 14:13 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-09 23:19 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-10 17:19 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-10 09:02 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 13:28 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 09:05 +0000
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-14 04:05 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 12:36 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-15 11:37 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 17:07 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-11 01:40 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 11:21 +1100
Re: PICK changed from 1-based to 0-based? Coos Haak <chforth@hccnet.nl> - 2014-01-13 01:50 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 12:05 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 03:19 +0100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 03:36 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-12 19:22 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-11 17:09 +1100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 17:06 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 08:13 -1000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 18:59 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 12:54 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:19 -0600
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 22:32 -0500
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:46 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-30 18:37 -0500
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-31 11:53 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:21 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:03 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 18:09 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:43 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 16:52 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 08:32 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:26 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 16:55 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-07 12:45 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-06 22:15 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-15 08:39 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-05 12:53 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 13:45 -0600
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:17 -0500
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:03 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 13:43 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 11:53 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-01 23:57 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-01 13:19 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 19:48 +0100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 19:13 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 15:44 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:56 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-02 15:43 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 15:34 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:14 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 17:49 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 12:03 -0600
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 10:31 -0800
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-03 19:19 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 09:56 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 04:18 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-04 12:39 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 21:43 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 13:45 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 23:10 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 15:41 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:05 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 04:21 -0600
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 06:46 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 13:33 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-07 08:44 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 14:52 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:41 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:14 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 18:41 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 15:09 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-08 20:00 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 12:45 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 00:16 +0100
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:34 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:41 -0800
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 23:12 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 23:04 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-10 22:08 -1000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-09 02:16 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 04:18 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 11:19 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:04 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-10 17:27 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 11:37 -0800
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 12:47 -0800
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 13:37 -0800
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 14:24 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:53 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:50 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:08 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 18:33 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 12:32 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-09 20:49 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 09:10 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:37 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-07 08:48 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 15:24 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:50 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:28 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-08 16:21 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 09:39 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 04:28 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 11:27 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:42 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:41 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 18:44 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 12:35 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-10 00:20 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-10 05:22 -0600
Re: PICK changed from 1-based to 0-based? m.a.m.hendrix@tue.nl - 2014-01-10 03:48 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-10 09:31 -0600
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:40 -0600
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 21:54 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 03:41 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-11 13:33 +0000
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-11 11:44 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 10:40 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 04:11 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 13:31 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 07:52 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 19:35 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 02:57 -0600
chipFORTH [Was: PICK changed from 1-based to 0-based?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 03:12 -0600
Re: chipFORTH Paul Rubin <no.email@nospam.invalid> - 2014-01-12 08:43 -0800
Re: chipFORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 10:40 -0600
Re: chipFORTH albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 18:00 +0000
Re: chipFORTH Alex McDonald <blog@rivadpm.com> - 2014-01-12 11:18 -0800
Re: chipFORTH anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:03 +0000
Re: chipFORTH "Alex McDonald" <blog@rivadpm.com> - 2014-01-13 17:21 +0000
Re: chipFORTH stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-13 19:10 +0000
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 02:28 -0500
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] Elizabeth D Rather <erather@forth.com> - 2014-01-12 21:39 -1000
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-13 03:16 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 11:38 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 07:46 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 15:46 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-13 10:45 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-13 19:05 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 20:53 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 03:41 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-14 13:07 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-14 17:53 +0100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-14 17:35 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 08:23 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 13:19 -0600
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-14 12:31 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-14 21:37 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 16:12 -0600
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 12:18 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-15 04:19 +0100
DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-15 17:52 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-15 21:56 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-16 09:30 +0000
Re: DOES> and flash Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-17 12:44 +0100
Re: DOES> and flash oh2aun@gmail.com - 2014-01-17 08:05 -0800
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-17 16:43 +0000
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-17 20:37 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 04:40 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 11:56 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 10:54 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 17:36 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 12:17 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 18:23 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 14:00 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 20:24 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 14:05 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 23:12 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 03:38 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-19 14:03 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 09:17 -0600
Re: DOES> and flash albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 15:31 +0000
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-19 19:48 +0100
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 18:11 +0100
Re: DOES> and flash Coos Haak <chforth@hccnet.nl> - 2014-01-19 01:12 +0100
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:53 +0000
Re: DOES> and flash Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-20 11:32 +0100
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 02:02 +0100
Re: DOES> and flash Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-16 07:19 +0100
Re: DOES> and flash Paul Rubin <no.email@nospam.invalid> - 2014-01-16 00:22 -0800
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 15:38 +0100
Re: DOES> and flash Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-20 09:45 +0100
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-16 09:33 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 16:09 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-17 03:28 -0600
Re: DOES> and flash albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-17 11:39 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-17 08:16 -0600
Re: DOES> and flash "Alex McDonald" <blog@rivadpm.com> - 2014-01-17 16:06 +0000
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 17:21 +0000
Re: DOES> and flash stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-19 12:32 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 09:19 -0600
Re: DOES> and flash stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-19 18:20 +0000
Re: DOES> and flash Paul Rubin <no.email@nospam.invalid> - 2014-01-20 01:25 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 08:31 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-14 01:33 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 10:05 +0000
CREATE...DOES> on program-in-flash systems anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 11:58 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 08:43 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 19:37 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-11 11:28 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-11 12:24 -0800
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-03 18:19 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 22:03 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 13:28 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 15:09 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 03:41 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 18:09 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:16 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 22:58 +0100
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 22:34 -0500
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-29 19:30 -1000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 22:49 -0800
Re: PICK changed from 1-based to 0-based? AKK <akk@nospam.org> - 2013-12-30 08:48 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:24 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 11:18 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:32 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:05 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 11:02 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 05:48 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:00 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-31 21:42 +1100
Re: PICK changed from 1-based to 0-based? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-12-30 09:14 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 03:35 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:06 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 10:41 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:50 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:21 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 11:21 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 07:08 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:13 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:36 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 15:23 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 16:02 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 08:54 -1000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 19:59 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 10:12 -1000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <st@trstn.net> - 2014-01-03 20:17 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 20:29 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 11:48 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-04 12:00 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-04 13:12 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 08:22 -0600
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 21:37 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 16:58 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-02 16:41 +0000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 16:54 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:22 +0100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:20 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:56 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-30 08:14 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:54 -0600
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-31 23:15 +1100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-31 07:05 -0600
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-31 09:26 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-01 13:27 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-31 18:21 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-01 12:12 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-03 15:59 +1100
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-03 00:19 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:25 +1100
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-04 19:03 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 14:08 +1100
Re: PICK changed from 1-based to 0-based? m.a.m.hendrix@tue.nl - 2014-01-06 01:47 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-07 12:43 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 13:29 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-08 16:30 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-11 23:12 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:30 +0000
Re: PICK changed from 1-based to 0-based? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-01-04 13:57 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 12:17 -1000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-04 15:08 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 04:57 -0600
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-05 09:14 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 12:20 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 13:05 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:55 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:49 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 11:24 -0500
Re: PICK changed from 1-based to 0-based? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-01-04 16:06 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 13:47 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2013-12-30 18:29 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 09:34 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:06 -0500
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 11:34 +0100
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-03 08:04 -0500
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:38 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 15:57 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:17 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 14:52 +0000
Page 7 of 17 — ← Prev page 1 … 5 6 [7] 8 9 … 17 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-09 02:16 +0000 |
| Message-ID | <52ce067b$0$9211$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #27741 |
In article <lak78m$5lc$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Anton Ertl wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> writes: >>>Anton Ertl wrote: >>>> We standardized BUFFER: and N>R NR> for less. The problem is not >>>> standardizing <BUILDS, the problem would be in taking away the >>>> guarantee that DOES> can be applied to CREATEd words. >>> >>>No, that would be an "environmental restriction". This environmental >>>restriction also comes with the restriction that you can use DOES> on >>><BUILDS only *once*. >> >> Somehow standardizing a word (<BUILDS) that's intended to be used only >> in the context of some environmental restrictions seems wrong. > >IMHO the wrong thing to do was to standardize a word that can be implemented >with clever tricks only; the tricks becoming more clever with the >restriction of the enviroment. Both Gforth EC R8C and noForth manage to use >normal CREATE for DOES> in a flash-programmed system, by deploying two >different, clever tricks. This sort of trickery is counter the "keep it >stupid simple" philosophy of Forth. <BUILDS is easy to implement straight- >forward. The whole CREATE DOES> stuff is already more demanding than the >entire rest of Forth, so why artificially make it even more complicated? > >> If a significant use case of <BUILDS is to only use DOES> on each >> child once, then specify that in the specification. >> >> Having two alternative ways to achieve the same thing in the standard, >> with a number of systems not implementing one of the ways, and the >> others preferring that way, does not look like a well-designed >> standard either. > >Of course. But what would be the alternative? Use <BUILDS exclusively for >DOES>? That would break existing code. > >The question here is: Why are the small embedded system programmers only >losely following the standard? Even though Forth is most popular in that >niche? The reason is that it is too hard to implement it. Too hard does >not mean "impossible", but requiring that sort of guru code only a few >people will be able to write. Do they? As far as I can tell, the only deviations from ISO in noforth are imposed by the hardware flash restrictions. There are no gratuitous deviations, and there was some effort ( CREATE DOES> ) to implement some standard words that are not trivial. So it may be true for inhouse, build-your-own Forth's but not for Forth's that are intended for publication. (To my surprise noforth doesn't advertise itself as ISO, but even the metacompiler and source are accepted by at least 4 Forth's. Even more if I count 32/64 gForth on Intel/ARM separately, and 32/64 bits lina/wina. >-- >Bernd Paysan 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-09 04:18 -0600 |
| Message-ID | <cs6dnavurarz6lPPnZ2dnUVZ_rudnZ2d@supernews.com> |
| In reply to | #27746 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <lak78m$5lc$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >>Anton Ertl wrote: >> >>> Bernd Paysan <bernd.paysan@gmx.de> writes: >>>>Anton Ertl wrote: >>>>> We standardized BUFFER: and N>R NR> for less. The problem is not >>>>> standardizing <BUILDS, the problem would be in taking away the >>>>> guarantee that DOES> can be applied to CREATEd words. >>>> >>>>No, that would be an "environmental restriction". This environmental >>>>restriction also comes with the restriction that you can use DOES> on >>>><BUILDS only *once*. >>> >>> Somehow standardizing a word (<BUILDS) that's intended to be used only >>> in the context of some environmental restrictions seems wrong. >> >>IMHO the wrong thing to do was to standardize a word that can be implemented >>with clever tricks only; the tricks becoming more clever with the >>restriction of the enviroment. Both Gforth EC R8C and noForth manage to use >>normal CREATE for DOES> in a flash-programmed system, by deploying two >>different, clever tricks. But a flash-programmed system, as you describe it, cannot be standard anyway, not just because of multiple DOES> but also because of FORGET et al, although I'll grant those words aren't CORE . On the face of it, your argument -- that <BUILDS should be standard because it's needed to simplify implementations in such an environment -- is ludicrous. There are tricks/techniques (your choice) that work in that environment with CREATE ... DOES> . >>This sort of trickery is counter the "keep it stupid simple" >>philosophy of Forth. <BUILDS is easy to implement straight- >>forward. The whole CREATE DOES> stuff is already more demanding >>than the entire rest of Forth, so why artificially make it even more >>complicated? Because you have an environment that is so very odd as to need it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-09 11:19 +0000 |
| Message-ID | <2014Jan9.121923@mips.complang.tuwien.ac.at> |
| In reply to | #27752 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>But a flash-programmed system, as you describe it, cannot be standard
>anyway, not just because of multiple DOES> but also because of FORGET
>et al, although I'll grant those words aren't CORE .
I cannot make any sense of this. What do you mean?
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-09 09:04 -0600 |
| Message-ID | <BO2dna1KvcLhJ1PPnZ2dnUVZ_tKdnZ2d@supernews.com> |
| In reply to | #27756 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>But a flash-programmed system, as you describe it, cannot be standard >>anyway, not just because of multiple DOES> but also because of FORGET >>et al, although I'll grant those words aren't CORE . > > I cannot make any sense of this. What do you mean? The system that Bernd described can't do e.g. FORGET, because a while page has to be erased. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-10 17:27 +0000 |
| Message-ID | <2014Jan10.182735@mips.complang.tuwien.ac.at> |
| In reply to | #27766 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>But a flash-programmed system, as you describe it, cannot be standard
>>>anyway, not just because of multiple DOES> but also because of FORGET
>>>et al, although I'll grant those words aren't CORE .
>>
>> I cannot make any sense of this. What do you mean?
>
>The system that Bernd described can't do e.g. FORGET, because a while
>page has to be erased.
Well, first of all FORGET is not necessary for a standard system.
E.g., Gforth does not implement it.
Second, FORGET is perfectly possible on such a system: Only erase
pages that only contain forgotten stuff, and then set the flash
dictionary pointer to the start of the first erased page. Yes, some
forgotten stuff will stay in flash; So what? Flash is not tight on
these systems, and if it is, just don't use FORGET.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-10 11:37 -0800 |
| Message-ID | <7xmwj3mxvz.fsf@ruckus.brouhaha.com> |
| In reply to | #27781 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Second, FORGET is perfectly possible on such a system: Only erase > pages that only contain forgotten stuff, and then set the flash > dictionary pointer to the start of the first erased page. Yes, some > forgotten stuff will stay in flash; So what? Flash is not tight on > these systems, and if it is, just don't use FORGET. Say you want to forget back to the middle of page N. Does the obvious way work? I.e. erase pages N+1, N+2, etc. Then copy page N to page N+1, erase page N, copy page N+1 back to page N, and erase page N+1 again. Or if you have enough RAM to buffer page N, then you can avoid some of the flash writing and erasing.
[toc] | [prev] | [next] | [standalone]
| From | oh2aun@gmail.com |
|---|---|
| Date | 2014-01-10 12:47 -0800 |
| Message-ID | <64d28249-25c0-4ae9-b892-a56e631468ec@googlegroups.com> |
| In reply to | #27783 |
On Friday, January 10, 2014 9:37:20 PM UTC+2, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > > Second, FORGET is perfectly possible on such a system: Only erase > > pages that only contain forgotten stuff, and then set the flash > > dictionary pointer to the start of the first erased page. Yes, some > > forgotten stuff will stay in flash; So what? Flash is not tight on > > these systems, and if it is, just don't use FORGET. > > Say you want to forget back to the middle of page N. Does the obvious > way work? I.e. erase pages N+1, N+2, etc. Then copy page N to page > N+1, erase page N, copy page N+1 back to page N, and erase page N+1 > again. Or if you have enough RAM to buffer page N, then you can avoid > some of the flash writing and erasing. I have considered a strategy for FORGET/MARKER which does not erase any flash at all. FORGET would just make LATEST(in EEPROM) point to before the forgetted word. Flash would be written until it is full. When the flash is full you would need to EMPTY, and start filling the device with the now hopefully debugged code. This strategy would even out the wear on flash. But I have not used this method since usually flash has been quite reliable.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-10 13:37 -0800 |
| Message-ID | <7xbnzjr00o.fsf@ruckus.brouhaha.com> |
| In reply to | #27784 |
oh2aun@gmail.com writes: > When the flash is full you would need to EMPTY, and start > filling the device with the now hopefully debugged code. I guess that's ok since reloading flash from the host is pretty quick. The device I'm currently thinking about (attiny85) has 8k of flash and 512B of ram, so flash isn't exactly plentiful. It does have some eeprom, I think 1k.
[toc] | [prev] | [next] | [standalone]
| From | oh2aun@gmail.com |
|---|---|
| Date | 2014-01-10 14:24 -0800 |
| Message-ID | <e80ab71d-3e15-4ee9-9081-94781dc56bce@googlegroups.com> |
| In reply to | #27785 |
On Friday, January 10, 2014 11:37:43 PM UTC+2, Paul Rubin wrote: > Mikael Nordman writes: > > When the flash is full you would need to EMPTY, and start > > filling the device with the now hopefully debugged code. > > I guess that's ok since reloading flash from the host is pretty quick. > The device I'm currently thinking about (attiny85) has 8k of flash and > 512B of ram, so flash isn't exactly plentiful. It does have some > eeprom, I think 1k. I have just scoped out those very small devices from a resident Forth. For me, 16K flash, 768 bytes ram, 256 bytes eeprom, are the smallest devices to have a reasonable system in.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-13 16:53 +0000 |
| Message-ID | <2014Jan13.175350@mips.complang.tuwien.ac.at> |
| In reply to | #27783 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Second, FORGET is perfectly possible on such a system: Only erase
>> pages that only contain forgotten stuff, and then set the flash
>> dictionary pointer to the start of the first erased page. Yes, some
>> forgotten stuff will stay in flash; So what? Flash is not tight on
>> these systems, and if it is, just don't use FORGET.
>
>Say you want to forget back to the middle of page N. Does the obvious
>way work? I.e. erase pages N+1, N+2, etc. Then copy page N to page
>N+1, erase page N, copy page N+1 back to page N, and erase page N+1
>again.
That's also a possibility, but my thinking was to just leave page N as
it is, and set the dictionary pointer to the start of page N+1. So
FORGET usually would not reclaim all the flash memory that is
forgotten.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-09 14:50 +0100 |
| Message-ID | <lam9ep$f9j$2@online.de> |
| In reply to | #27752 |
Andrew Haley wrote: > But a flash-programmed system, as you describe it, cannot be standard > anyway, not just because of multiple DOES> but also because of FORGET > et al, although I'll grant those words aren't CORE . Words not in CORE don't count. You won't have floating point, you won't have file words. It's still standard. You can read a typical introduction to Forth, which focuses on CORE words, and things work on your target. Some of these systems actually have MARKER (which wastes at most one flash page), most of them have EMPTY (that's resetting the system, removing all user-defined words); this is much better than FORGET for such an environment. Multiple DOES> is something you can easily avoid. > On the face of > it, your argument -- that <BUILDS should be standard because it's > needed to simplify implementations in such an environment -- is > ludicrous. There are tricks/techniques (your choice) that work in > that environment with CREATE ... DOES> . We standardized BUFFER: for much less, the trickery to implement something similar to BUFFER: is much easier to do. Why are you so violently opposing this one? Because it requires to acknowledge that merging <BUILDS and CREATE was a mistake? Come on! Were you personally involved in this mistake? -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-09 09:08 -0600 |
| Message-ID | <BO2dnaxKvcLvJlPPnZ2dnUVZ_tKdnZ2d@supernews.com> |
| In reply to | #27764 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >> On the face of it, your argument -- that <BUILDS should be standard >> because it's needed to simplify implementations in such an >> environment -- is ludicrous. There are tricks/techniques (your >> choice) that work in that environment with CREATE ... DOES> . > > We standardized BUFFER: for much less, the trickery to implement > something similar to BUFFER: is much easier to do. There's no portable way to do it, though. > Why are you so violently opposing this one? Because it requires to > acknowledge that merging <BUILDS and CREATE was a mistake? Come on! > Were you personally involved in this mistake? No, I was not: it was before my time. I think it was a brilliant idea, and far too valuable to miss because of some marginal systems, and besides that, they can implement CREATE ... DOES anyway. The only problem is that you don't like the way that has to be done. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-09 18:33 +0100 |
| Message-ID | <lammi3$516$1@online.de> |
| In reply to | #27767 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Andrew Haley wrote: >>> On the face of it, your argument -- that <BUILDS should be standard >>> because it's needed to simplify implementations in such an >>> environment -- is ludicrous. There are tricks/techniques (your >>> choice) that work in that environment with CREATE ... DOES> . >> >> We standardized BUFFER: for much less, the trickery to implement >> something similar to BUFFER: is much easier to do. > > There's no portable way to do it, though. CREATE ALLOT is 100% portable. The point for why a BSS segment is needed is that you don't want to store tons of zeros. But the amount of "trickery" necessary to compress (and expand) long runs of zeros in you image, which you have to copy to RAM anyways at startup is very small, and it will compress all zero-initialized stuff regardless how it was allocated. >> Why are you so violently opposing this one? Because it requires to >> acknowledge that merging <BUILDS and CREATE was a mistake? Come on! >> Were you personally involved in this mistake? > > No, I was not: it was before my time. I think it was a brilliant > idea, and far too valuable to miss because of some marginal systems, > and besides that, they can implement CREATE ... DOES anyway. The only > problem is that you don't like the way that has to be done. It's not just about not liking that way, it's about imposing things on implementors that can be quite difficult to achieve. This sort of thing should not go into a standard, especially not a Forth standard (you can put very difficult to implement stuff into C++ or Java if you like; these are language standards with very few people actually writing compilers). Almost anything in Forth is very easy to achieve and to implement, and as BUFFER: above shows, we encourage people to code hints to the system so that it is easier to implement the system. So I still don't understand this violent opposition to <BUILDS, whereas you apparently seem to like a completely superfluous word like BUFFER:. Implement RLE compression on your initialized data, and you'd be done. Expanding RLE is really trivial, and when you do a high-quality compression, it will provide way more opportunity to compress your image than BUFFER:. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-09 12:32 -0600 |
| Message-ID | <MKOdneGmTeurdlPPnZ2dnUVZ_tKdnZ2d@supernews.com> |
| In reply to | #27770 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Andrew Haley wrote: >>>> On the face of it, your argument -- that <BUILDS should be standard >>>> because it's needed to simplify implementations in such an >>>> environment -- is ludicrous. There are tricks/techniques (your >>>> choice) that work in that environment with CREATE ... DOES> . >>> >>> We standardized BUFFER: for much less, the trickery to implement >>> something similar to BUFFER: is much easier to do. >> >> There's no portable way to do it, though. > > CREATE ALLOT is 100% portable. The point for why a BSS segment is > needed is that you don't want to store tons of zeros. But the > amount of "trickery" necessary to compress (and expand) long runs of > zeros in you image, which you have to copy to RAM anyways at startup > is very small, and it will compress all zero-initialized stuff > regardless how it was allocated. > >>> Why are you so violently opposing this one? Because it requires to >>> acknowledge that merging <BUILDS and CREATE was a mistake? Come on! >>> Were you personally involved in this mistake? >> >> No, I was not: it was before my time. I think it was a brilliant >> idea, and far too valuable to miss because of some marginal systems, >> and besides that, they can implement CREATE ... DOES anyway. The only >> problem is that you don't like the way that has to be done. > > It's not just about not liking that way, it's about imposing things > on implementors that can be quite difficult to achieve. This sort > of thing should not go into a standard, especially not a Forth > standard (you can put very difficult to implement stuff into C++ or > Java if you like; these are language standards with very few people > actually writing compilers). Almost anything in Forth is very easy > to achieve and to implement, and as BUFFER: above shows, we > encourage people to code hints to the system so that it is easier to > implement the system. > > So I still don't understand this violent opposition to <BUILDS, > whereas you apparently seem to like a completely superfluous word > like BUFFER:. Implement RLE compression on your initialized data, > and you'd be done. Expanding RLE is really trivial, and when you do > a high-quality compression, it will provide way more opportunity to > compress your image than BUFFER:. I guess I don't much care about BUFFER, but do care about CREATE ... DOES> . BUFFER: seems mostly harmless, and makes sense on some embedded systems. All this talk about BSS is bizarre, given that BUFFER: is explicitly uninitialized. In a real-time system you may not have time to zero anything. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-09 20:49 +0000 |
| Message-ID | <52cf0b58$0$9231$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #27752 |
In article <cs6dnavurarz6lPPnZ2dnUVZ_rudnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> In article <lak78m$5lc$1@online.de>, Bernd Paysan ><bernd.paysan@gmx.de> wrote: >>>Anton Ertl wrote: >>> >>>> Bernd Paysan <bernd.paysan@gmx.de> writes: >>>>>Anton Ertl wrote: >>>>>> We standardized BUFFER: and N>R NR> for less. The problem is not >>>>>> standardizing <BUILDS, the problem would be in taking away the >>>>>> guarantee that DOES> can be applied to CREATEd words. >>>>> >>>>>No, that would be an "environmental restriction". This environmental >>>>>restriction also comes with the restriction that you can use DOES> on >>>>><BUILDS only *once*. >>>> >>>> Somehow standardizing a word (<BUILDS) that's intended to be used only >>>> in the context of some environmental restrictions seems wrong. >>> >>>IMHO the wrong thing to do was to standardize a word that can be implemented >>>with clever tricks only; the tricks becoming more clever with the >>>restriction of the enviroment. Both Gforth EC R8C and noForth manage to use >>>normal CREATE for DOES> in a flash-programmed system, by deploying two >>>different, clever tricks. > >But a flash-programmed system, as you describe it, cannot be standard >anyway, not just because of multiple DOES> but also because of FORGET >et al, although I'll grant those words aren't CORE . On the face of >it, your argument -- that <BUILDS should be standard because it's >needed to simplify implementations in such an environment -- is >ludicrous. There are tricks/techniques (your choice) that work in >that environment with CREATE ... DOES> . FORGET is obsolescent. noforth supplies MARKER that replaces it. It is urban legend that MARKER couldn't be supplied transparently with a Forth in flash. > >>>This sort of trickery is counter the "keep it stupid simple" >>>philosophy of Forth. <BUILDS is easy to implement straight- >>>forward. The whole CREATE DOES> stuff is already more demanding >>>than the entire rest of Forth, so why artificially make it even more >>>complicated? > >Because you have an environment that is so very odd as to need it. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-09 09:10 +0000 |
| Message-ID | <2014Jan9.101043@mips.complang.tuwien.ac.at> |
| In reply to | #27741 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> We standardized BUFFER: and N>R NR> for less. The problem is not
>>>> standardizing <BUILDS, the problem would be in taking away the
>>>> guarantee that DOES> can be applied to CREATEd words.
>>>
>>>No, that would be an "environmental restriction". This environmental
>>>restriction also comes with the restriction that you can use DOES> on
>>><BUILDS only *once*.
>>
>> Somehow standardizing a word (<BUILDS) that's intended to be used only
>> in the context of some environmental restrictions seems wrong.
>
>IMHO the wrong thing to do was to standardize a word that can be implemented
>with clever tricks only
Maybe, but it's now standard and has been standard since Forth-79. So
the question is how to proceed. We could just stick with it and
continue rely on the ability of Forth implementors to come up with
clever tricks. But if you want to standardize something that does not
need them, it should really provide portability; otherwise there is no
point in standardizing this.
>> Having two alternative ways to achieve the same thing in the standard,
>> with a number of systems not implementing one of the ways, and the
>> others preferring that way, does not look like a well-designed
>> standard either.
>
>Of course. But what would be the alternative? Use <BUILDS exclusively for
>DOES>? That would break existing code.
First consider the possible alternatives, then how to manage the
transition.
It seems to me that there are the following uses of CREATE:
1) without DOES> with uninitialized data: There is now BUFFER: for that.
2) without DOES> with initialized data.
3) with DOES> applied once to CREATE's child, and the child is not
executed before the DOES> is applied. That's the usual usage of
DOES> and you suggest using <BUILDS instead of CREATE here.
4) others: child called, later DOES> applied to that child; more than
one DOES> applied. These uses are rare and you do not want to
support them.
We could have different names for the CREATEs of the different use
cases. Or maybe there is another way.
>The question here is: Why are the small embedded system programmers only
>losely following the standard? Even though Forth is most popular in that
>niche? The reason is that it is too hard to implement it. Too hard does
>not mean "impossible", but requiring that sort of guru code only a few
>people will be able to write.
I believe that the reason is that the standard provides little benefit
to small embedded systems. Porting programs? That's not really going
to happen there. And for programmer portability a loosely following
the standard is good enough.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-09 14:37 +0100 |
| Message-ID | <lam8mf$e3b$1@online.de> |
| In reply to | #27750 |
Anton Ertl wrote: > I believe that the reason is that the standard provides little benefit > to small embedded systems. Porting programs? That's not really going > to happen there. Porting programmers. People read Forth introduction material that is using the standard. > And for programmer portability a loosely following > the standard is good enough. All those implementors of small embedded systems I know try to follow the standard where it's easy to do. Some even invent clever tricks to be standard-compliant except for some arcane usage (like multiple DOES> on a create with intermediate execution of that word). So people like Albert Nijhof and Willem Ouwerkerk or I manage to create completely standard embedded systems; others fail at some corner cases, or at least want support for some things like BUFFER:, which we already standardized. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-07 08:48 -1000 |
| Message-ID | <rLydnVsGq8l01lHPnZ2dnUVZ_rKdnZ2d@supernews.com> |
| In reply to | #27715 |
On 1/7/14 3:33 AM, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> No, only if you are doing something exceedingly odd: interactively >> programming a system, with no cross compiler, > > Doing an ordinary Forth system is "exceedingly odd"? > >> with the dictionary in >> flash. > > Ok, that's a difference from the Forth system of the old days, but > "exceedingly odd"? Hardware platforms with RAM as limited as you find on many microcontroller boards are not comparable to the systems for which Forth was developed. Forth was designed for interactive development assuming a reasonable amount of RAM, a terminal, and read/write mass storage. With the advent of microcontrollers, the Forth community has developed appropriate support systems including interactive cross-compilers that provide all the programming facilities and conveniences of a resident Forth even for very limited targets. If you care about getting the work done, you use the tool best suited for the task. >> Sure, you can do that, but I can't think of any reason that >> anyone would do it. > > It's Forth! It's a lot simpler than an umbilical/tethered > cross-development environment. If your message is that people should > use a cross compiler instead of an ordinary Forth system, why should > they be using a Forth cross compiler instead of, say, a C cross > compiler (with some debugger for the interactivity)? Interactive cross-compilers are only slightly more complicated than resident Forths, and the resulting development capabilities are equally comfortable. And there is simply no comparison between the natural Forth interactivity and the comparatively formal, convoluted process supported by C tool chains and debuggers. >> I'm not saying that you're wrong to want to do >> that, but I am saying that edge case is not worth standardizing >> <BUILDS for. > > We standardized BUFFER: and N>R NR> for less. The problem is not > standardizing <BUILDS, the problem would be in taking away the > guarantee that DOES> can be applied to CREATEd words. BUFFER: etc. are useful for everyone. <BUILDS is not. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-08 15:24 +0000 |
| Message-ID | <2014Jan8.162413@mips.complang.tuwien.ac.at> |
| In reply to | #27725 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>With the advent of microcontrollers, the Forth community has developed
>appropriate support systems including interactive cross-compilers that
>provide all the programming facilities and conveniences of a resident
>Forth even for very limited targets.
"All the programming facilities and conveniences" includes, in
particular, that there is no language-specified line between
compilation and run-time; yet in such a cross-compilation system you
have this separation in two ways: The separation between target and
host, and the separation between development time (when the host is
connected to the target) and use time (when the target is on its own).
>If you care about getting the work
>done, you use the tool best suited for the task.
And if that tool is a resident Forth that compiles to flash, you use
that. So why again should the standard ignore this particular use
case?
>> We standardized BUFFER: and N>R NR> for less. The problem is not
>> standardizing <BUILDS, the problem would be in taking away the
>> guarantee that DOES> can be applied to CREATEd words.
>
>BUFFER: etc. are useful for everyone.
I named these particular words because I find them utterly useless.
In particular, the justification for BUFFER: had to do with embedded
systems, and one could easily also call that an "edge case [...] not
worth standardizing".
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-08 08:50 -1000 |
| Message-ID | <EKqdnT4ii-GYA1DPnZ2dnUVZ_uidnZ2d@supernews.com> |
| In reply to | #27736 |
On 1/8/14 5:24 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> With the advent of microcontrollers, the Forth community has developed >> appropriate support systems including interactive cross-compilers that >> provide all the programming facilities and conveniences of a resident >> Forth even for very limited targets. > > "All the programming facilities and conveniences" includes, in > particular, that there is no language-specified line between > compilation and run-time; yet in such a cross-compilation system you > have this separation in two ways: The separation between target and > host, and the separation between development time (when the host is > connected to the target) and use time (when the target is on its own). Operationally, that line is not so major. When you're connected to a target, you can type in a definition and execute it, examine target memory, do practically anything without special procedures. When your target is fully tested, you unplug the umbilical. That's it. I think you've never tried one, and are imagining difficulties that don't exist. >> If you care about getting the work >> done, you use the tool best suited for the task. > > And if that tool is a resident Forth that compiles to flash, you use > that. So why again should the standard ignore this particular use > case? It's not clear from this conversation that the standard needs to be changed to accomodate it. >>> We standardized BUFFER: and N>R NR> for less. The problem is not >>> standardizing <BUILDS, the problem would be in taking away the >>> guarantee that DOES> can be applied to CREATEd words. >> >> BUFFER: etc. are useful for everyone. > > I named these particular words because I find them utterly useless. > In particular, the justification for BUFFER: had to do with embedded > systems, and one could easily also call that an "edge case [...] not > worth standardizing". I see a lot of people using BUFFER: on resident Forths. For many years we took flack for not having a word that defines an array, and had to defensively show how easy it is to build an array with CREATE/ALLOT. A lot of people are happy with BUFFER: as a general capability. 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 7 of 17 — ← Prev page 1 … 5 6 [7] 8 9 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web