Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49933 > unrolled thread
| Started by | foxaudioresearch@gmail.com |
|---|---|
| First post | 2016-08-10 13:06 -0700 |
| Last post | 2016-08-28 22:34 +0200 |
| Articles | 20 on this page of 202 — 33 participants |
Back to article view | Back to comp.lang.forth
"Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-10 13:06 -0700
Re: "Forth is Sudoku for programmers" "WJ" <w_a_x_man@yahoo.com> - 2016-08-10 21:00 +0000
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-10 23:26 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-11 00:25 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-11 01:29 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 16:09 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-11 19:31 -0500
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-12 12:22 +1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 19:59 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-11 18:23 -1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 21:57 -0700
Re: "Forth is Sudoku for programmers" mhx@iae.nl - 2016-08-11 23:20 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-11 23:49 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 08:52 +0000
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-15 02:31 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 22:43 +1000
Re: "Forth is Sudoku for programmers" stephen@mpeforth.com (Stephen Pelc) - 2016-08-15 14:49 +0000
Re: "Forth is Sudoku for programmers" Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-21 21:24 +0000
Re: "Forth is Sudoku for programmers" Ron Aaron <rambamist@gmail.com> - 2016-08-22 07:04 +0300
Re: "Forth is Sudoku for programmers" Lars Brinkhoff <lars.spam@nocrew.org> - 2016-08-26 07:12 +0200
Re: "Forth is Sudoku for programmers" Ron Aaron <rambamist@gmail.com> - 2016-08-26 09:18 +0300
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:12 +0200
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 00:04 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 01:34 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 02:17 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 08:53 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 11:54 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-12 17:38 -0400
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 20:02 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 07:10 +0000
Re: "Forth is Sudoku for programmers" Alex McDonald <alex@rivadpm.com> - 2016-08-15 08:34 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-15 01:11 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:23 +0200
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-28 14:26 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-29 01:44 -0500
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-29 00:45 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 14:56 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 15:02 -0700
Re: "Forth is Sudoku for programmers" Doug Hoffman <glidedog@gmail.com> - 2016-08-12 22:05 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 21:05 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:15 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 23:39 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 00:03 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-13 00:07 -0700
Re: "Forth is Sudoku for programmers" Doug Hoffman <glidedog@gmail.com> - 2016-08-13 07:35 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 17:17 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 20:04 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 20:38 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 20:46 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 06:02 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-14 23:04 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 16:01 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-13 21:53 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 07:45 -0700
Re: "Forth is Sudoku for programmers" franck.bensusan@gmail.com - 2016-08-15 06:44 -0700
Re: "Forth is Sudoku for programmers" Melzzzzz <mel@zzzzz.com> - 2016-08-14 19:57 +0200
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 11:17 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 13:59 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 14:09 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 15:48 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 18:34 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 02:24 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 19:26 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-21 14:58 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 15:51 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 15:52 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-24 16:35 -0700
Re: "Forth is Sudoku for programmers" jim.brakefield@ieee.org - 2016-08-14 10:32 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 13:55 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:37 +0200
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-28 15:25 -0700
Re: "Forth is Sudoku for programmers" jim.brakefield@ieee.org - 2016-08-28 16:16 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-28 16:44 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-13 20:00 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 20:39 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-12 22:11 -1000
Re: "Forth is Sudoku for programmers" dhoffman888@gmail.com - 2016-08-13 03:39 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 20:18 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:35 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:52 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 22:55 -0700
Re: "Forth is Sudoku for programmers" Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-08-13 11:31 +0100
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 11:47 +1000
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 12:05 +1000
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 08:21 +0000
Re: "Forth is Sudoku for programmers" Brad Eckert <hwfwguy@gmail.com> - 2016-08-17 22:54 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-12 14:51 +1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 21:59 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-13 18:04 +1000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-11 23:16 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-13 18:47 +1000
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-11 22:59 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 20:54 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-12 12:36 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 15:10 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 17:45 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-15 18:40 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-15 20:18 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:18 +0200
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-10 15:38 -0700
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-10 16:18 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:39 +0000
Re: "Forth is Sudoku for programmers" Brad Eckert <hwfwguy@gmail.com> - 2016-08-12 00:23 -0700
Re: "Forth is Sudoku for programmers" "WJ" <w_a_x_man@yahoo.com> - 2016-08-21 01:56 +0000
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-10 20:28 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 00:23 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:26 +0000
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-11 11:06 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 11:51 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-11 01:48 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-11 01:52 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-13 09:42 -0700
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-13 13:36 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-14 07:06 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-14 14:10 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-16 00:46 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-16 00:57 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-16 04:45 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-18 02:16 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-18 03:04 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-18 09:30 -0500
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-18 07:44 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-18 11:36 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-18 13:41 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-18 14:01 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-18 14:33 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-18 16:23 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-18 17:28 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-18 18:59 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-18 19:07 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-29 01:09 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-18 17:21 -1000
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-18 23:36 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 00:11 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-19 01:44 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 01:46 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:29 +0200
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-31 03:43 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-19 03:49 -0500
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 02:18 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-20 05:05 -0500
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-20 15:13 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-21 16:33 -0500
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-21 19:37 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 20:02 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 21:36 -1000
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-22 03:36 -0500
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-19 08:40 -0500
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-19 15:59 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-19 16:28 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 16:31 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-19 17:24 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 19:48 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-19 20:17 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-20 02:16 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-20 02:19 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-20 03:13 -0700
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-20 07:03 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-20 12:21 -0500
Re: "Forth is Sudoku for programmers" Coos Haak <htrofhc@gmail.com> - 2016-08-20 20:39 +0200
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-20 15:41 -0500
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 14:40 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-20 17:25 -0500
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 20:14 -0700
Re: "Forth is Sudoku for programmers" julian.fondren@endurance.com - 2016-08-20 20:30 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-21 13:46 -0500
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-21 20:13 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 12:37 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-21 21:11 +0100
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 13:19 -1000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 19:03 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-22 06:45 +0100
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 21:38 -1000
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:43 +0200
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-21 08:57 +0000
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:40 +0200
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-21 09:57 +0000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 11:29 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-21 11:56 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 12:11 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-21 12:26 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 12:52 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-22 07:12 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 23:43 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 21:40 -1000
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-22 17:20 +0000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 13:01 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-21 13:16 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-21 20:19 +0100
Re: "Forth is Sudoku for programmers" stephen@mpeforth.com (Stephen Pelc) - 2016-08-21 17:41 +0000
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-20 02:09 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-20 20:04 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-19 09:40 -1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 13:48 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-26 01:13 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-26 04:26 -0400
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-26 03:06 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-26 11:54 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-26 20:43 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-27 04:20 -0700
Re: "Forth is Sudoku for programmers" Bernd Paysan <bernd@net2o.de> - 2016-08-28 00:04 +0000
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:34 +0200
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-21 12:26 -0700 |
| Message-ID | <8db87724-dc68-43cd-94d6-1bebe2d13897@googlegroups.com> |
| In reply to | #50344 |
On Sunday, August 21, 2016 at 2:11:25 PM UTC-5, hughag...@gmail.com wrote: > > On Sunday, August 21, 2016 at 1:29:59 PM UTC-5, > > hughag...@gmail.com wrote: > > > That is not true! > > > > > > If ANS-Forth allows two contradictory systems to both be > > > considered standard-compliant, then you are going to have > > > programs for one system that don't work on the other system, and > > > vice-versa. > > > > Obviously, I was was referring to ambiguity within the core > functions, not within extensions Assuming you mean 'standardized functions' and 'non-standard extensions', respectively, this still allows two contradictory systems to be considered standards compliant, where programs on one system won't work on another. The problem - the entire problem, the problem that you are using as reason that the standard is bad - remains. Since the problem obtains as soon as anyone extends any system, ever, I contend that this is a not really a problem that a standard can address. By the way, and in particular context of this thread, ANS Forth also allows system to not implement all of it. So your standard program won't run on that standard system because, for example, it just doesn't implemement a feature it doesn't have to, that you need. And lest anyone ask about standard programs with environmental dependencies on the floating stack being a certain way, I'll just remind you that clf talked about this for *years*. There's plenty of lucid discussion about what standards are for and what ANS Forth actually does -- just skip any thread in which your name appears. > --- a typical example being FIND > that works differently on VFX, SwiftForth and gForth. FIND can work differently when used in non-standard ways. We just discussed this exact same thing with ABORT"
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-21 12:52 -0700 |
| Message-ID | <87a8g5sxvs.fsf@jester.gateway.pace.com> |
| In reply to | #50349 |
Julian Fondren <julian.fondren@gmail.com> writes: > Assuming you mean 'standardized functions' and 'non-standard > extensions', respectively, this still allows two contradictory systems > to be considered standards compliant, where programs on one system > won't work on another. The problem - the entire problem, the problem > that you are using as reason that the standard is bad - remains. My interpretation of Cecil's complaint is something like: word X might reasonably be used in situations A, B, C, and D, and there are several possible natural things for it to do in each of those situations. The standard says what to do in cases A, B, and C, but leaves D unspecified or ambiguous. Vendors implement cases A, B, and C the way the standard says, and are left to their own devices with D, so they implement it in different, incompatible ways. Now if someone comes along and says "hey, let's standardize case D", well, by now it can't be standardized without breaking existing code. So it becomes another point of difference between implementations. This is perhaps a complaint-worthy situation because if the standard had specified case D in the first place, those incompatible treatments wouldn't have gotten into the wild. They'd have all done the standard thing. So the committee screwed up by not standardizing D when they could, leaving a legacy problem that's hard to solve after the fact. Of course that imagines that the incompatible treatments of case D weren't already out there before the process started.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-08-22 07:12 +0100 |
| Message-ID | <npe53k$qkg$1@dont-email.me> |
| In reply to | #50351 |
On 21/08/2016 20:52, Paul Rubin wrote: > Julian Fondren <julian.fondren@gmail.com> writes: >> Assuming you mean 'standardized functions' and 'non-standard >> extensions', respectively, this still allows two contradictory systems >> to be considered standards compliant, where programs on one system >> won't work on another. The problem - the entire problem, the problem >> that you are using as reason that the standard is bad - remains. > > My interpretation of Cecil's complaint is something like: word X might > reasonably be used in situations A, B, C, and D, and there are several > possible natural things for it to do in each of those situations. > > The standard says what to do in cases A, B, and C, but leaves D > unspecified or ambiguous. > > Vendors implement cases A, B, and C the way the standard says, and are > left to their own devices with D, so they implement it in different, > incompatible ways. > > Now if someone comes along and says "hey, let's standardize case D", > well, by now it can't be standardized without breaking existing code. > So it becomes another point of difference between implementations. > > This is perhaps a complaint-worthy situation because if the standard had > specified case D in the first place, those incompatible treatments > wouldn't have gotten into the wild. They'd have all done the standard > thing. So the committee screwed up by not standardizing D when they > could, leaving a legacy problem that's hard to solve after the fact. > > Of course that imagines that the incompatible treatments of case D > weren't already out there before the process started. > There are currently two commercial companies that don't agree on some things that impede resolution of legacy issues. The ANS 94 standard lists 27 companies/organisations involved in creating the standard - it is probably certain that case D was already present in the early 90's. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-21 23:43 -0700 |
| Message-ID | <e0065899-70b1-4f02-b121-ec1149ee6793@googlegroups.com> |
| In reply to | #50389 |
On Sunday, August 21, 2016 at 11:12:05 PM UTC-7, Gerry wrote:
> On 21/08/2016 20:52, Paul Rubin wrote:
> > Julian Fondren <julian.fondren@gmail.com> writes:
> >> Assuming you mean 'standardized functions' and 'non-standard
> >> extensions', respectively, this still allows two contradictory systems
> >> to be considered standards compliant, where programs on one system
> >> won't work on another. The problem - the entire problem, the problem
> >> that you are using as reason that the standard is bad - remains.
> >
> > My interpretation of Cecil's complaint is something like: word X might
> > reasonably be used in situations A, B, C, and D, and there are several
> > possible natural things for it to do in each of those situations.
> >
> > The standard says what to do in cases A, B, and C, but leaves D
> > unspecified or ambiguous.
> >
> > Vendors implement cases A, B, and C the way the standard says, and are
> > left to their own devices with D, so they implement it in different,
> > incompatible ways.
> >
> > Now if someone comes along and says "hey, let's standardize case D",
> > well, by now it can't be standardized without breaking existing code.
> > So it becomes another point of difference between implementations.
> >
> > This is perhaps a complaint-worthy situation because if the standard had
> > specified case D in the first place, those incompatible treatments
> > wouldn't have gotten into the wild. They'd have all done the standard
> > thing. So the committee screwed up by not standardizing D when they
> > could, leaving a legacy problem that's hard to solve after the fact.
> >
> > Of course that imagines that the incompatible treatments of case D
> > weren't already out there before the process started.
> >
>
> There are currently two commercial companies that don't agree on some
> things that impede resolution of legacy issues. The ANS 94 standard
> lists 27 companies/organisations involved in creating the standard - it
> is probably certain that case D was already present in the early 90's.
There are a lot of gaps in ANS-Forth. For example, { was the de facto standard for defining locals long before ANS-Forth existed, but it did not get put into ANS-Forth and instead we got LOCALS| that has the parameters backwards. The result is that everybody had to write { for themselves (I have an implementation in the novice-package). There is no standard way to do this however, and so the implementations differ. I initialize everything to the right of the | to zero, and Anton Ertl does not. Also, I call it { because that is what it has been called for about 25 years, but Anton Ertl calls it {: because SwiftForth was using { for multi-line comments. This is one of those case-D situations that Cecil was talking about --- there is a common practice, but it didn't get put into ANS-Forth, and so we end up with a lot of ambiguity in how it gets defined.
Also, it is just a big pain in the butt. When I started learning ANS-Forth I just didn't use locals at all because, for all practical purpose, locals were not supported in ANS-Forth. I did not write my own { because I was just a novice at ANS-Forth and doing so was beyond me. It seems unfair to tell novices that they have to write { themselves; this is a big reason why all of the novices quit! I persevered; years later wrote { myself, which I put in the novice package. I only persevered with ANS-Forth because I had been a professional Forth programmer in the past and I care a lot about Forth --- your typical novice is not going to persevere --- your typical novice will abandon ANS-Forth and go back to programming in C, and I don't blame him.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-21 21:40 -1000 |
| Message-ID | <XNSdnROG8fn3MSfKnZ2dnUU7-b2dnZ2d@supernews.com> |
| In reply to | #50389 |
On 8/21/16 8:12 PM, Gerry Jackson wrote: > On 21/08/2016 20:52, Paul Rubin wrote: >> Julian Fondren <julian.fondren@gmail.com> writes: >>> Assuming you mean 'standardized functions' and 'non-standard >>> extensions', respectively, this still allows two contradictory systems >>> to be considered standards compliant, where programs on one system >>> won't work on another. The problem - the entire problem, the problem >>> that you are using as reason that the standard is bad - remains. >> >> My interpretation of Cecil's complaint is something like: word X might >> reasonably be used in situations A, B, C, and D, and there are several >> possible natural things for it to do in each of those situations. >> >> The standard says what to do in cases A, B, and C, but leaves D >> unspecified or ambiguous. >> >> Vendors implement cases A, B, and C the way the standard says, and are >> left to their own devices with D, so they implement it in different, >> incompatible ways. >> >> Now if someone comes along and says "hey, let's standardize case D", >> well, by now it can't be standardized without breaking existing code. >> So it becomes another point of difference between implementations. >> >> This is perhaps a complaint-worthy situation because if the standard had >> specified case D in the first place, those incompatible treatments >> wouldn't have gotten into the wild. They'd have all done the standard >> thing. So the committee screwed up by not standardizing D when they >> could, leaving a legacy problem that's hard to solve after the fact. >> >> Of course that imagines that the incompatible treatments of case D >> weren't already out there before the process started. >> > > There are currently two commercial companies that don't agree on some > things that impede resolution of legacy issues. The ANS 94 standard > lists 27 companies/organisations involved in creating the standard - it > is probably certain that case D was already present in the early 90's. Quite possibly, with at least a dozen different solutions in current projects. 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 | 2016-08-22 17:20 +0000 |
| Message-ID | <2016Aug22.192010@mips.complang.tuwien.ac.at> |
| In reply to | #50351 |
Paul Rubin <no.email@nospam.invalid> writes:
>Julian Fondren <julian.fondren@gmail.com> writes:
>My interpretation of Cecil's complaint is something like: word X might
>reasonably be used in situations A, B, C, and D, and there are several
>possible natural things for it to do in each of those situations.
>
>The standard says what to do in cases A, B, and C, but leaves D
>unspecified or ambiguous.
>
>Vendors implement cases A, B, and C the way the standard says, and are
>left to their own devices with D, so they implement it in different,
>incompatible ways.
>
>Now if someone comes along and says "hey, let's standardize case D",
>well, by now it can't be standardized without breaking existing code.
>So it becomes another point of difference between implementations.
>
>This is perhaps a complaint-worthy situation because if the standard had
>specified case D in the first place, those incompatible treatments
>wouldn't have gotten into the wild. They'd have all done the standard
>thing. So the committee screwed up by not standardizing D when they
>could, leaving a legacy problem that's hard to solve after the fact.
>
>Of course that imagines that the incompatible treatments of case D
>weren't already out there before the process started.
Yes, if something is explicitly ambiguous or undefined, it's typically
because there was no common practice there at the time of
standardization. E.g., undefined interpretation semantics of words
such as ABORT" etc.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-21 13:01 -0700 |
| Message-ID | <c8c89a45-dc12-4a0b-b69c-a1f50a0f66cb@googlegroups.com> |
| In reply to | #50349 |
On Sunday, August 21, 2016 at 12:26:32 PM UTC-7, Julian Fondren wrote:
> On Sunday, August 21, 2016 at 2:11:25 PM UTC-5, hughag...@gmail.com
> wrote:
> > --- a typical example being FIND
> > that works differently on VFX, SwiftForth and gForth.
>
> FIND can work differently when used in non-standard ways. We just
> discussed this exact same thing with ABORT"
Julien Fondren is so loyal to ANS-Forth! He lies routinely to support ANS-Forth --- ultimately, this is what killed Forth in 1994 --- the ANS-Forth community were a pack of liars, and this caused all of the Forth community to be tainted and consequently ignored by the world.
c" if" find
In gForth this will give one xt when FIND is used in interpretation mode and a different xt when FIND is used in compilation mode. In either case, FIND indicates that IF is immediate.
In VFX this will give an xt (execution token) that can't be executed (in compilation mode you would expect this to be executable, but it crashes). FIND indicates that IF is non-immediate.
In SwiftForth this will give an xt that can be executed (in compilation mode only, obviously). FIND indicates that IF is immediate (that is why it can only be executed in compilation mode).
ANS-Forth fails to define words such as IF as being immediate, and so it is ANS-Forth compliant for them to be non-immediate (as was done in VFX). This is just another form of ambiguity --- words can be immediate in one ANS-Forth system and non-immediate in another ANS-Forth system.
I fix all of this ambiguity regarding FIND with my disambiguifiers. Here is an example of a disambiguifier:
: if state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate
Now FIND works the same way in every system.
c" if" find
This returns an xt that can be executed in compilation mode (it will abort with the error message shown if executed in interpretation mode). FIND indicates that IF is immediate.
To paraphrase Stephen Pelc: "Disambiguifiers are the dog's bollocks!" (note: I'm making a joke here at Stephen Pelc's expense; he actually said "Bollocks!" when I said that FIND was ambiguous and that my disambiguifiers made FIND consistent, but I looked up "bollocks" in Urban Dictionary and found that the word is ambiguous).
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-21 13:16 -0700 |
| Message-ID | <d91220a4-e7af-4f18-806a-51c33ff28f7e@googlegroups.com> |
| In reply to | #50352 |
On Sunday, August 21, 2016 at 3:01:16 PM UTC-5, hughag...@gmail.com wrote: > I fix all of this ambiguity regarding FIND with my disambiguifiers. Here is an example of a disambiguifier: 1. ANS Forth has this crippling, nightmarish, deadly problem. It is probably the result of an evil conspiracy. Satan may have been involved. My life is at risk, just for telling you people this. 2. Anyway I fixed the problem :-) Don't need to worry about *that* anymore. I fixed it. It's fixed. Satan is probably pretty pissed now (lol). 3. Therefore, ANS Forth is worse than ever! We need to get rid of this thing ASAP! Every day is agony due to ANS Forth. #JustHughThings
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-08-21 20:19 +0100 |
| Message-ID | <npcuse$i3o$1@dont-email.me> |
| In reply to | #50336 |
On 21/08/2016 19:29, hughaguilar96@gmail.com wrote: >>> that is not what a standard is supposed to be.. >> > >> >And that is? > A Forth standard should allow standard-compliant programs to be ported between standard-compliant Forth systems --- this is what ANS-Forth doesn't allow. But using ABORT" in interpretation mode is not a 'standard-compliant program' so why should it behave the same in different systems? If you really want ABORT" to be standardised when interpreting write an RfD and get support for it sufficient to win the voting in an CfV. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-08-21 17:41 +0000 |
| Message-ID | <57b9e73e.436569936@news.eternal-september.org> |
| In reply to | #50272 |
On Sat, 20 Aug 2016 02:16:06 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: >With a serial port on the Arduino, I can: > >* Use a bluetooth adapter (cost: approx $3, about 2cm square) > you communicate with it with good old fashioned AT modem commands > once it's set up it's transparent. Just code as if you have a wired > serial port. >* Use a WIFI adapter. It does the TCP/IP and DHCP. >* Use a USB serial port adapter (the Windows/Linux box box sees your > device as a virtual serial port and you can communicate via serial > port). Sounds very much like an RPi3 which already has BT, TCP/IP Ethernet, Wifi, USB hosts, I2C, SPI and SD card. An RPi3 is usually cheaper than an Arduino. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-08-20 02:09 -0700 |
| Message-ID | <852ea5b8-831f-473b-b15c-aa048c6b0708@googlegroups.com> |
| In reply to | #50262 |
On Saturday, 20 August 2016 00:28:07 UTC+1, Paul Rubin wrote: > Mark Wills <markwills1970@gmail.com> writes: > > Forget it! It's 2016 and we don't have a standard way to open an > > obsolete serial port, much less a socket, or invoke various screen > > resolutions and bit depths. I feel your pain. > > I don't know of any language spec that says how to do those things. > That's left to OS API specs like POSIX, if anything. Noted, but given that Forth often doesn't run on an OS (in embedded scenarios) it should do. Forth is minimalist. When did we start assuming there's an underlying OS that does all this stuff for us? ;-)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-20 20:04 -0700 |
| Message-ID | <9afab04b-cdb0-4f56-8fae-6a59708c2c69@googlegroups.com> |
| In reply to | #50271 |
On Saturday, August 20, 2016 at 2:09:52 AM UTC-7, Mark Wills wrote: > On Saturday, 20 August 2016 00:28:07 UTC+1, Paul Rubin wrote: > > Mark Wills <markwills1970@gmail.com> writes: > > > Forget it! It's 2016 and we don't have a standard way to open an > > > obsolete serial port, much less a socket, or invoke various screen > > > resolutions and bit depths. I feel your pain. > > > > I don't know of any language spec that says how to do those things. > > That's left to OS API specs like POSIX, if anything. > > Noted, but given that Forth often doesn't run on an OS (in embedded > scenarios) it should do. Forth is minimalist. When did we start assuming > there's an underlying OS that does all this stuff for us? ;-) Straight Forth is intended to run on desktop computers --- so, yes, it does assume that there is an underlying OS that does a lot of stuff for us --- for example, it would use the OS device-drivers for I/O (such as your serial port that you mention so often) rather than directly access the hardware as was done in the bad old days of MS-DOS. The primary purpose of Straight Forth is to be the host for cross-compilers that generate Forth code for micro-controllers. This micro-controller Forth code would not be compatible with Straight Forth (for one thing, Straight Forth assumes a 64-bit cell size, which you aren't going to find on a micro-controller). I don't really know enough about micro-controllers to be in charge of designing a standard Forth for micro-controllers --- Raimond's LFTforth looks good, and he has experience with micro-controllers, so that would be a start --- I will leave micro-controllers to people who know about the subject, but Straight Forth should be able to cross-compile any Forth that they might design (I very much doubt that they are going to come up with any language features that I would find difficult to write a cross-compiler for). For the most part, my only area of expertise is Forth cross-compilation --- my primary experience as a professional Forth programmer was writing MFX at Testra --- I didn't write the motion-control program though, although that is the only program that MFX was ever used to cross-compile.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-19 09:40 -1000 |
| Message-ID | <3IydneKaAaM7_SrKnZ2dnUU7-bPNnZ2d@supernews.com> |
| In reply to | #50235 |
On 8/18/16 8:36 PM, lehs wrote: > Den fredag 19 augusti 2016 kl. 05:21:50 UTC+2 skrev Elizabeth D. Rather: >> On 8/17/16 11:16 PM, lehs wrote: >>> I guess that Forth is more of an idea than a computer language and that the idea of Forth will develop as other good ideas develop in a long-term perspective. Charles Moore have said that Forth is an approach to programming and he never seems to use any standards. I guess he use no libraries neither, but copy and paste from his own code. >>> >>> I think a lot of forthers is a bit like Charles Moore. It's all about the idea and our own code. I rather use a less effective code (in progress) of my own, than some alien code by someone else, especially when it comes to packages. What I do use is others definitions and Forth implementations. And I also like to test other peoples code from time to time, last the fancy Lisp implementation that humptydumpty manage to get running. And I want the possibility of other people to run my code if they want. >>> >>> The CORE and DOUBLE words in ANS Forth are the most important definitions to be standardized. And they shouldn't change from standard to standard. FLOATING and FILE are nice but could maybe be developed further. Personally I'm not interested at all in future implementations of various computer scientific ideas that maybe not belong in Forth at all. >>> >>> Recognizers seems to be a good idea if implemented in a smart and simple way. From there really nice implementations of new data types would be possible. >>> >>> Also, why are there no discussion of a standard for rudimentary graphic words? Or are there? >>> >> >> There was a fairly graphics library in polyFORTH. If there is interest, >> I could investigate getting it published. It would have to be modified >> to ANS Forth or Forth2012. > > > That graphic library could be nice to see. But I think standard Forth has to be more and more like an operating system with standard words for access to a lot of devices, which should be implemented by the Forth vendors. That would at least increase portability and maybe make libraries more attractive. > Graphics is an application domain, not an OS feature. I don't really propose a graphics library to be adopted in the standard, but the code to be made conformant to current standards and published as a library. 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 | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-19 13:48 -0700 |
| Message-ID | <cf9cf103-2072-4795-b444-5130e4763bd6@googlegroups.com> |
| In reply to | #50254 |
On Saturday, August 20, 2016 at 7:40:28 AM UTC+12, Elizabeth D. Rather wrote: > > Graphics is an application domain, not an OS feature. Considering that just about every “smart” device has a screen with a GUI...
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2016-08-26 01:13 -0700 |
| Message-ID | <fc7ee8ae-ad71-4dbf-b066-d2eb8da6816c@googlegroups.com> |
| In reply to | #50254 |
Den fredag 19 augusti 2016 kl. 21:40:28 UTC+2 skrev Elizabeth D. Rather: > On 8/18/16 8:36 PM, lehs wrote: > > Den fredag 19 augusti 2016 kl. 05:21:50 UTC+2 skrev Elizabeth D. Rather: > >> On 8/17/16 11:16 PM, lehs wrote: > >>> I guess that Forth is more of an idea than a computer language and that the idea of Forth will develop as other good ideas develop in a long-term perspective. Charles Moore have said that Forth is an approach to programming and he never seems to use any standards. I guess he use no libraries neither, but copy and paste from his own code. > >>> > >>> I think a lot of forthers is a bit like Charles Moore. It's all about the idea and our own code. I rather use a less effective code (in progress) of my own, than some alien code by someone else, especially when it comes to packages. What I do use is others definitions and Forth implementations. And I also like to test other peoples code from time to time, last the fancy Lisp implementation that humptydumpty manage to get running. And I want the possibility of other people to run my code if they want. > >>> > >>> The CORE and DOUBLE words in ANS Forth are the most important definitions to be standardized. And they shouldn't change from standard to standard. FLOATING and FILE are nice but could maybe be developed further. Personally I'm not interested at all in future implementations of various computer scientific ideas that maybe not belong in Forth at all. > >>> > >>> Recognizers seems to be a good idea if implemented in a smart and simple way. From there really nice implementations of new data types would be possible. > >>> > >>> Also, why are there no discussion of a standard for rudimentary graphic words? Or are there? > >>> > >> > >> There was a fairly graphics library in polyFORTH. If there is interest, > >> I could investigate getting it published. It would have to be modified > >> to ANS Forth or Forth2012. > > > > > > That graphic library could be nice to see. But I think standard Forth has to be more and more like an operating system with standard words for access to a lot of devices, which should be implemented by the Forth vendors. That would at least increase portability and maybe make libraries more attractive. > > > > Graphics is an application domain, not an OS feature. I don't really > propose a graphics library to be adopted in the standard, but the code > to be made conformant to current standards and published as a library. > > 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." > ================================================== Why must Forth adopt random ideas? Forth could be implemented on a traditional operating system or as native. Traditional languages are applikations only, the is probably no native c for example. In a native Forth all operations inclusive disk operations is defined as a part of Forth. What I mean is that Forth need standards for communicating with things connected to the computer, including mouses, graphic screens and sticks. When implementing a native Forth or an other Forth there should be words for all this.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-08-26 04:26 -0400 |
| Message-ID | <npouf1$a2h$1@dont-email.me> |
| In reply to | #50489 |
On 8/26/2016 4:13 AM, lehs wrote: > > Why must Forth adopt random ideas? Forth could be implemented on a > traditional operating system or as native. Traditional languages are > applikations only, the is probably no native c for example. In a > native Forth all operations inclusive disk operations is defined as a > part of Forth. What I mean is that Forth need standards for > communicating with things connected to the computer, including > mouses, graphic screens and sticks. When implementing a native Forth > or an other Forth there should be words for all this. What random ideas? Graphics is something that has changed hugely over time as well as having variations between systems. Simple graphics is adequate for a embedded system using a small LCD screen for prompting the user. Graphics becomes much more complex in higher end devices showing video supported by a GPU for example. There is little that could be coded into a standard as an API for accessing all the features on many devices, OS or no OS. If you think Forth needs graphics as part of the standard, go ahead and design that and propose it for addition to the standard. If you do a good enough job to meet the needs of a wide range of systems, I'm sure it will be adopted. But I think that is a big IF. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2016-08-26 03:06 -0700 |
| Message-ID | <a9206691-dec9-4142-b41f-d20d4ecd1820@googlegroups.com> |
| In reply to | #50491 |
Den fredag 26 augusti 2016 kl. 10:26:10 UTC+2 skrev rickman: > On 8/26/2016 4:13 AM, lehs wrote: > > > > Why must Forth adopt random ideas? Forth could be implemented on a > > traditional operating system or as native. Traditional languages are > > applikations only, the is probably no native c for example. In a > > native Forth all operations inclusive disk operations is defined as a > > part of Forth. What I mean is that Forth need standards for > > communicating with things connected to the computer, including > > mouses, graphic screens and sticks. When implementing a native Forth > > or an other Forth there should be words for all this. > > What random ideas? > > Graphics is something that has changed hugely over time as well as > having variations between systems. Simple graphics is adequate for a > embedded system using a small LCD screen for prompting the user. > Graphics becomes much more complex in higher end devices showing video > supported by a GPU for example. There is little that could be coded > into a standard as an API for accessing all the features on many > devices, OS or no OS. > > If you think Forth needs graphics as part of the standard, go ahead and > design that and propose it for addition to the standard. If you do a > good enough job to meet the needs of a wide range of systems, I'm sure > it will be adopted. But I think that is a big IF. > > -- > > Rick C The random idea in this case is the traditional separation of OS and language. Unix adopted c but native Forth is a rudimentary OS with integrated language. I would be glad if there was words for plotting pixels in different colors, setting graphic modes/standards etc. As rudimentary as BLOCK, KEY, EMIT etc. Re-directions for printing and addressing other devices. No, I wont enter the arena of standards.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-08-26 11:54 -0400 |
| Message-ID | <nppon2$3h1$1@dont-email.me> |
| In reply to | #50493 |
On 8/26/2016 6:06 AM, lehs wrote: > Den fredag 26 augusti 2016 kl. 10:26:10 UTC+2 skrev rickman: >> On 8/26/2016 4:13 AM, lehs wrote: >>> >>> Why must Forth adopt random ideas? Forth could be implemented on a >>> traditional operating system or as native. Traditional languages are >>> applikations only, the is probably no native c for example. In a >>> native Forth all operations inclusive disk operations is defined as a >>> part of Forth. What I mean is that Forth need standards for >>> communicating with things connected to the computer, including >>> mouses, graphic screens and sticks. When implementing a native Forth >>> or an other Forth there should be words for all this. >> >> What random ideas? >> >> Graphics is something that has changed hugely over time as well as >> having variations between systems. Simple graphics is adequate for a >> embedded system using a small LCD screen for prompting the user. >> Graphics becomes much more complex in higher end devices showing video >> supported by a GPU for example. There is little that could be coded >> into a standard as an API for accessing all the features on many >> devices, OS or no OS. >> >> If you think Forth needs graphics as part of the standard, go ahead and >> design that and propose it for addition to the standard. If you do a >> good enough job to meet the needs of a wide range of systems, I'm sure >> it will be adopted. But I think that is a big IF. >> >> -- >> >> Rick C > > The random idea in this case is the traditional separation of OS and language. Unix adopted c but native Forth is a rudimentary OS with integrated language. > > I would be glad if there was words for plotting pixels in different colors, setting graphic modes/standards etc. As rudimentary as BLOCK, KEY, EMIT etc. Re-directions for printing and addressing other devices. > > No, I wont enter the arena of standards. I thought you already had. In fact, I thought that was your entire point, "That graphic library could be nice to see. But I think standard Forth has to be more and more like an operating system with standard words for access to a lot of devices, which should be implemented by the Forth vendors." Perhaps I am reading too much into this. What exactly is the shortcoming you see? If there is a library you would like to see written, why not start that yourself? If you feel this should be part of the standard, why not create that proposal and pitch it to the committee? I worked on a user interface once and chose to use an ANSI terminal just so I could control things like color, bold and such. In the end it didn't work out great as in the real world there is little consistency in terminal emulators. I have seen no common words for display output in Forth other than EMIT and its brethren. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-26 20:43 -0700 |
| Message-ID | <9c0d28ef-65dc-4b1a-9572-2a71dba0a241@googlegroups.com> |
| In reply to | #50493 |
On Friday, August 26, 2016 at 10:06:22 PM UTC+12, lehs wrote: > I would be glad if there was words for plotting pixels in different colors, > setting graphic modes/standards etc. These days, most on-screen drawing is done via OpenGL, to take advantage of hardware acceleration. Even GUI toolkits use this for on-screen 2D rendering.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-08-27 04:20 -0700 |
| Message-ID | <90ac9912-08d3-490a-bd84-68989b069c94@googlegroups.com> |
| In reply to | #50503 |
An embedded morphine dosing system with colour OLED display for cancer patient treatment won't be running OpenGL. That's implementation. Irrelevant. It's the software interfaces that matter.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web