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 1 of 11 [1] 2 3 … 11 Next page →
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-08-10 13:06 -0700 |
| Subject | "Forth is Sudoku for programmers" |
| Message-ID | <1e1c16c6-300f-4c4f-8590-379029478232@googlegroups.com> |
*Don't shoot the messenger please** I was doing some research on Lisp internals having found some old code by Martin Tracy on my drive. I went looking around and found this discussion: http://forums.parallax.com/discussion/160027/lisp-technically-scheme-written-in-forth <quote>"Dave Hein Posts: 4,831 February 2015 edited February 2015 0 I found a lisp interpreter written in C at http://www.umcs.maine.edu/~chaitin /lisp.c . I was able to get it to run on the Prop in a matter of minutes by changing the #define for SIZE from 1000000 to 400, and using the CMM model. The program is 950 lines of C code. I don't know lisp, but the program seems to do the right thing when I type in (+ 1 2). I've officially given up trying to port lisp.fs to pfth. I could probably get it to work in another day or so, but it seems a bit pointless. This exercise has reinforced my belief that Forth is just not a good language for writing large programs. It's fine for peeking and poking and dinking around. However, serious programming should really have library support and standards and compilers that assist the developer. Forth is fine if you want a challenge, but if you want to get something done use something else. As I've said before, Forth is Sudoku for programmers." </quote> The Scheme they were trying to port was for Gforth. (http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp) And of course moving it to the little Parallax board was not possible. The Forth on the board is not quite standard. It seems a shame that we don't have code examples like the 'C' Scheme example that are as easily configured for different hardware. The comments in the posts mentioned the fact the the C code used arrays and the Forth code used Structs (and locals). Maybe simpler is better? Now where have I heard that before? It looks like a good project for my spare time. BF So much code so little time.
[toc] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-08-10 21:00 +0000 |
| Message-ID | <nog4kk$m95$1@dont-email.me> |
| In reply to | #49933 |
foxaudioresearch@gmail.com wrote:
> *Don't shoot the messenger please**
>
> I was doing some research on Lisp internals having found some old code
> by Martin Tracy on my drive. I went looking around and found this discussion:
>
> http://forums.parallax.com/discussion/160027/lisp-technically-scheme-written-in-forth
>
>
> <quote>"Dave Hein Posts: 4,831
> February 2015 edited February 2015 0
> I found a lisp interpreter written in C at http://www.umcs.maine.edu/~chaitin
> /lisp.c . I was able to get it to run on the Prop in a matter of minutes by
> changing the #define for SIZE from 1000000 to 400, and using the CMM model. The
> program is 950 lines of C code. I don't know lisp, but the program seems to do
> the right thing when I type in (+ 1 2).
>
> I've officially given up trying to port lisp.fs to pfth.
> I could probably get
> it to work in another day or so, but it
> seems a bit pointless. This exercise has reinforced my belief
> that Forth is just not a good language for writing large programs.
> It's fine for peeking and poking and dinking around. However,
> serious programming should really have library support and standards
> and compilers that assist the developer. Forth is fine if you want
> a challenge, but if you want to get something done use something else.
>
> As I've said before, Forth is Sudoku for programmers."
> </quote>
>
> The Scheme they were trying to port was for Gforth.
> (http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp)
>
> And of course moving it to the little Parallax board was not possible.
> The Forth on the board is not quite standard.
>
> It seems a shame that we don't have code examples like the 'C' Scheme
> example that are as easily configured for different hardware.
>
> The comments in the posts mentioned the fact the the C code used arrays
> and the Forth code used Structs (and locals). Maybe simpler is better?
>
> Now where have I heard that before?
>
> It looks like a good project for my spare time.
>
>
> BF
>
> So much code so little time.
Forth is a toy language. The only ones who attempt to use
it outside of embedded controllers are those so bone-headed
that they cannot learn a real language. Gavino thinks that
it is awe-inspiring.
Speaking of Lisp:
> But if you're going to allow LOOP, then why use FORMAT at all?!?
> Since FORMAT probably uses WITH-OUTPUT-TO-STRING "under the hood",
> just do so directly:
>
> > (let ((list '(a b c))
> (delim #\,))
> (with-output-to-string (s)
> (loop for tail on list
> do (princ (first tail) s)
> (when (rest tail)
> (princ delim s)))))
>
> "A,B,C"
MatzLisp (Ruby):
[:a,:b,:c].join ", "
==>"a, b, c"
--
Africans gang-rape and clitorectomize Finnish girl; government arrests Finn whom
they accuse of complaining: http://www.wvwnews.net/story.php?id=6746
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2016-08-10 23:26 -0700 |
| Message-ID | <4e7daff2-c07b-4cd2-86ff-97b40d2ebad8@googlegroups.com> |
| In reply to | #49934 |
Some prefer languages where "everything" is built in and rather use their time searching in manuals than being more creative and use Forth. Sometimes because of their personality and sometimes because it is more efficient to use libraries. Making really nice code is a kind of sudoku in what ever language.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-11 00:25 -0700 |
| Message-ID | <6834ab99-c4e7-490e-993d-20faa122c65c@googlegroups.com> |
| In reply to | #49940 |
On Wednesday, August 10, 2016 at 11:26:27 PM UTC-7, lehs wrote: > Some prefer languages where "everything" is built in and rather use their time searching in manuals than being more creative and use Forth. Sometimes because of their personality and sometimes because it is more efficient to use libraries. > > Making really nice code is a kind of sudoku in what ever language. People program computers for many reasons, one of which is that they get paid to do it --- nobody gets paid to solve sudoku problems --- if programming is like sudoku then you aren't going to get paid. All programmers are creative. You can't really be a programmer if you aren't at least somewhat creative. It is possible to waste your creativity however. If you are writing a program that needs to store data (every program needs to store data) then you need a general-purpose data-structure. There is going to be plenty of opportunity for creativity in regard to the design of your program. If you have to write your own self-balancing binary-tree however, then this is just a distraction. By the time that you have this figured out, you will have forgotten what the purpose of the program was. Also, your creativity is wasted because the subject has been done to death already. Implementing a self-balancing binary-tree is not really what programming is about --- there are no programmers getting paid to do this --- programmers get paid to write programs.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2016-08-11 01:29 -0700 |
| Message-ID | <a01e9374-e5d6-4721-b780-228e8acb28e6@googlegroups.com> |
| In reply to | #49942 |
Den torsdag 11 augusti 2016 kl. 09:25:17 UTC+2 skrev hughag...@gmail.com: > On Wednesday, August 10, 2016 at 11:26:27 PM UTC-7, lehs wrote: > > Some prefer languages where "everything" is built in and rather use their time searching in manuals than being more creative and use Forth. Sometimes because of their personality and sometimes because it is more efficient to use libraries. > > > > Making really nice code is a kind of sudoku in what ever language. > > People program computers for many reasons, one of which is that they get paid to do it --- nobody gets paid to solve sudoku problems --- if programming is like sudoku then you aren't going to get paid. > > All programmers are creative. You can't really be a programmer if you aren't at least somewhat creative. It is possible to waste your creativity however. If you are writing a program that needs to store data (every program needs to store data) then you need a general-purpose data-structure. There is going to be plenty of opportunity for creativity in regard to the design of your program. If you have to write your own self-balancing binary-tree however, then this is just a distraction. By the time that you have this figured out, you will have forgotten what the purpose of the program was. Also, your creativity is wasted because the subject has been done to death already. Implementing a self-balancing binary-tree is not really what programming is about --- there are no programmers getting paid to do this --- programmers get paid to write programs. Yes there should be libraries for a lot of things in Forth, built upon some standard. But what can you do with self-balancing trees that could be done better with some kind of stack?
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-11 16:09 -0700 |
| Message-ID | <44627617-846e-4fa7-a44d-ca30bacca909@googlegroups.com> |
| In reply to | #49940 |
On Thursday, August 11, 2016 at 6:26:27 PM UTC+12, lehs wrote: > Some prefer languages where "everything" is built in and rather use their > time searching in manuals than being more creative and use Forth. Sometimes > because of their personality and sometimes because it is more efficient to > use libraries. As Isaac Newton said, “if I have seen farther, it is by standing on the shoulders of giants”. A language that lets you leverage the power of prewritten libraries is a much more productive language than one that does not.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-08-11 19:31 -0500 |
| Message-ID | <noj5ch$sn1$1@dont-email.me> |
| In reply to | #49962 |
On 8/11/2016 6:09 PM, lawrencedo99@gmail.com wrote: > On Thursday, August 11, 2016 at 6:26:27 PM UTC+12, lehs wrote: > >> Some prefer languages where "everything" is built in and rather use their >> time searching in manuals than being more creative and use Forth. Sometimes >> because of their personality and sometimes because it is more efficient to >> use libraries. > > As Isaac Newton said, “if I have seen farther, it is by standing on the shoulders of giants”. > > A language that lets you leverage the power of prewritten libraries is a much more productive language than one that does not. > But that is against the spirit of Forth, in case you are not aware, and is a great sin, I am being sarcastic, troglodytes can be applied to many Forth programmers, well maybe not programmers, but people that claim to be. The funny thing, ANS Forth uses libraries but very primitive versions called word sets. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-08-12 12:22 +1000 |
| Message-ID | <nojbt6$1l4v$1@gioia.aioe.org> |
| In reply to | #49964 |
Cecil Bayona wrote: > On 8/11/2016 6:09 PM, lawrencedo99@gmail.com wrote: > > On Thursday, August 11, 2016 at 6:26:27 PM UTC+12, lehs wrote: > > > >> Some prefer languages where "everything" is built in and rather use their > >> time searching in manuals than being more creative and use Forth. Sometimes > >> because of their personality and sometimes because it is more efficient to > >> use libraries. > > > > As Isaac Newton said, "if I have seen farther, it is by standing on the shoulders of > > giants". > > > > A language that lets you leverage the power of prewritten libraries is a much more > > productive language than one that does not. > > > But that is against the spirit of Forth, in case you are not aware, and > is a great sin, I am being sarcastic, troglodytes can be applied to many > Forth programmers, well maybe not programmers, but people that claim to > be. The funny thing, ANS Forth uses libraries but very primitive > versions called word sets. I don't claim to be a programmer but it would take a lot before I'd trust a pre-written library. If it was a 'portable' library written by an ANS-programmer, I definitely wouldn't touch it. Forth was never aimed at the masses. It was intended for those who can exploit a given situation - and that can't be done by using a library of which you have no idea how it works, or what's contained therein. More thought and less code is what Forth is about.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-11 19:59 -0700 |
| Message-ID | <d181569f-d136-4d5d-9447-1da05b6253f1@googlegroups.com> |
| In reply to | #49965 |
On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote: > I don't claim to be a programmer but it would take a lot before I'd trust a > pre-written library. You trust the browser and the OS it’s running on when you read and post to this group, do you not? And all the servers between you and me that are relaying your words to me, and mine to you. The time is long past when you could do any serious computing without putting a lot of “trust” in pre-written code.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-11 18:23 -1000 |
| Message-ID | <-pednXDWiZK50jDKnZ2dnUU7-bfNnZ2d@supernews.com> |
| In reply to | #49967 |
On 8/11/16 4:59 PM, lawrencedo99@gmail.com wrote: > On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote: > >> I don't claim to be a programmer but it would take a lot before I'd trust a >> pre-written library. > > You trust the browser and the OS it’s running on when you read and post to > this group, do you not? And all the servers between you and me that are > relaying your words to me, and mine to you. > > The time is long past when you could do any serious computing without putting > a lot of “trust” in pre-written code. There's a big difference between using a completed, production program and using a body of code that is intended to be a component of a program that you're writing. Most libraries that I've aren't totally black boxes, but have many options and things that can be included or not, etc. To be useful it would have to be provided in source, be both readable and well-documented, and fully compatible with the Forth system I'm using. This is certainly not impossible; polyFORTH came with extensive database and graphics libraries, for example, and SwiftForth and SwiftX include a number of smaller application-oriented bodies of code. But we were disappointed in the math library that was circulated many years ago, due to issues both with code quality and documentation. Good libraries could in theory be a great asset to Forth, but every time this subject comes up it's always structured as "somebody [else] should write more libraries," not "here's a great library I have written." People on clf would rather write a DIY Forth system than 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-11 21:57 -0700 |
| Message-ID | <ef288cc3-8cc6-48bc-978b-a0e1b22382f9@googlegroups.com> |
| In reply to | #49972 |
On Friday, August 12, 2016 at 4:23:05 PM UTC+12, Elizabeth D. Rather wrote:
> There's a big difference between using a completed, production program
> and using a body of code that is intended to be a component of a program
> that you're writing.
No there isn’t really. On my Debian system:
ldo@theon:~> dpkg-query --showformat $'${Package} ${Depends}\n' --show firefox-esr
firefox-esr libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.17), libcairo2 (>= 1.2.4), libdbus-1-3 (>= 1.9.14), libdbus-glib-1-2 (>= 0.78), libevent-2.0-5 (>= 2.0.10-stable), libffi6 (>= 3.0.4), libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.20.0), libgtk2.0-0 (>= 2.24.0), libhunspell-1.4-0, libnspr4 (>= 2:4.10.3), libnss3 (>= 2:3.19), libpango-1.0-0 (>= 1.14.0), libsqlite3-0 (>= 3.7.12-1~), libstartup-notification0 (>= 0.8), libstdc++6 (>= 5.2), libvpx3 (>= 1.5.0), libx11-6, libxcomposite1 (>= 1:0.3-1), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxrender1, libxt6, zlib1g (>= 1:1.2.0), fontconfig, procps, debianutils (>= 1.16)
As you can see, the Firefox package reuses code from a whole bunch of others. What’s the difference between a “completed, production program” and a “component”? Everything can be a “component” of something at a higher layer.
> Most libraries that I've aren't totally black boxes, but have many
> options and things that can be included or not, etc.
Same with lots of executables I have built. Ask me about my custom script for building Blender <https://www.blender.org/> from source...
> Good libraries could in theory be a great asset to Forth, but every time
> this subject comes up it's always structured as "somebody [else] should
> write more libraries," not "here's a great library I have written."
> People on clf would rather write a DIY Forth system than a library.
Seems like a cultural issue, then. The Perl, Python and Ruby worlds, by contrast, are full of good libraries, with more being added all the time.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-08-11 23:20 -0700 |
| Message-ID | <10a472dc-3233-4611-b7f1-cacd4d4dcedb@googlegroups.com> |
| In reply to | #49972 |
"Elizabeth D. Rather" <erather@forth.com> writes Re: "Forth is Sudoku for programmers" > On 8/11/16 4:59 PM, lawrencedo99@gmail.com wrote: >> On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote: >> >>> I don't claim to be a programmer but it would take a lot before I'd trust a >>> pre-written library. >> >> You trust the browser and the OS it's running on when you read and post to >> this group, do you not? And all the servers between you and me that are >> relaying your words to me, and mine to you. >> >> The time is long past when you could do any serious computing without putting >> a lot of 'trust' in pre-written code. Look at hardware: We use opamps, comparators, timers, voltage stabilizers etc. all over the place. For digital parts it's even worse: almost everything is at least MSI and some engineers don't even bother to look up more than the pin numbering. All these IC's are horribly complex and not at all documented as to their nuts and bolts. In almost every case they do much more than is needed for the application. But everybody uses them. Engineers that would insist on designing their own opamp would get very strange looks indeed. And even if they succeeded in designing their perfect opamp, it certainly wouldn't improve the quality of the complex and large application that it is to be used in. Of course, there are the very good engineers that can take a board full of LSI chips and bring it down to the essentials (which then somebody would produce an single IC for). Now why doesn't this work analogously with (Forth) software? The inverse question is easier. Say that engineers would have the designs of all these IC's at their fingertips, and changing functionality or interface pins would be as simple as pressing a key or a double-click, because we could reprogram any chip at zero cost? Being human nature what it is, it would instantly kill the general-purpose IC market (and probably bring industry to a grinding halt). The focussed engineers that still want to use the general-purpose stuff would be unable to buy it because the market for these IC's would shrink. (You design it the old way and it works according to spec., but then costs must be cut and out go the general IC's because a few cents can be inevitably saved by a pin swap or making an output stage less powerful). If you follow this train of thought, then libraries of source code will never make it: they can't gain momentum as the user base is too small (at most the programmers of the language-du-jour). What could make it (if you want to follow my analogy) is open source software that is compiled as a shared library. In this way everybody/every language can use the library. Improvements are still possible but they have to go through the package maintainers. In principle it is still possible for an engineer to fork an existing package and maintain it privately, but in most cases it is not unlike designing and manufacturing your own IC: too many different skills are needed, can't bother. So, the question is not the programming language(s) to use, but how well what we use is able to interface to all the binary packaged stuff that is out there. What about using a .dll or .so in Standard Forth? We still can't do this in a standard way! Own quote: "Of course, there are the very good engineers that can take a board full of LSI chips and bring it down to the essentials (which then somebody would produce an single IC for)." I guess this is the spot for a Forth PROGRAM, which then might become a library. > There's a big difference between using a completed, production program > and using a body of code that is intended to be a component of a program > that you're writing. Most libraries that I've aren't totally black > boxes, but have many options and things that can be included or not, > etc. To be useful it would have to be provided in source, be both > readable and well-documented, and fully compatible with the Forth system > I'm using. It sound very reasonable and I like it a lot. However, it is *completely* at odds with my analogy above. > This is certainly not impossible; polyFORTH came with > extensive database and graphics libraries, for example, and SwiftForth > and SwiftX include a number of smaller application-oriented bodies of > code. But we were disappointed in the math library that was circulated > many years ago, due to issues both with code quality and documentation. Your stab at the FSL is not nice. What did Forth Inc. do to improve this situation? Code quality of a Forth library could be excellent: distribute the output of VFX or iForth, or F2C or whatever else we can come up with. For documentation the obvious candidate is Forth Inc :-) > Good libraries could in theory be a great asset to Forth, but every time > this subject comes up it's always structured as "somebody [else] should > write more libraries," not "here's a great library I have written." > People on clf would rather write a DIY Forth system than a library. I wonder what would happen if Forth source could be compiled with the best systems around and be distributed as shared libraries. It would separate the tasks of writing code and designing something that runs efficiently. Of course, not every (not many?) Forth programs can or should work as a shared library. -marcel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-11 23:49 -0700 |
| Message-ID | <1ef156ba-b37d-445c-8b66-5575f144ce1e@googlegroups.com> |
| In reply to | #49979 |
On Thursday, August 11, 2016 at 11:20:48 PM UTC-7, m...@iae.nl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes Re: "Forth is Sudoku for programmers" > > > On 8/11/16 4:59 PM, lawrencedo99@gmail.com wrote: > >> On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote: > >> > >>> I don't claim to be a programmer but it would take a lot before I'd trust a > >>> pre-written library. > >> > >> You trust the browser and the OS it's running on when you read and post to > >> this group, do you not? And all the servers between you and me that are > >> relaying your words to me, and mine to you. > >> > >> The time is long past when you could do any serious computing without putting > >> a lot of 'trust' in pre-written code. > > Look at hardware: We use opamps, comparators, timers, > voltage stabilizers etc. all over the place. For digital > parts it's even worse: almost everything is at least MSI > and some engineers don't even bother to look up more than > the pin numbering. > > All these IC's are horribly complex and not at all > documented as to their nuts and bolts. In almost every case > they do much more than is needed for the application. But > everybody uses them. Engineers that would insist on designing > their own opamp would get very strange looks indeed. And even > if they succeeded in designing their perfect opamp, it certainly > wouldn't improve the quality of the complex and large application > that it is to be used in. Of course, there are the very good > engineers that can take a board full of LSI chips and bring > it down to the essentials (which then somebody would produce > an single IC for). > > Now why doesn't this work analogously with (Forth) software? > The inverse question is easier. Say that engineers would have > the designs of all these IC's at their fingertips, and changing > functionality or interface pins would be as simple as pressing a > key or a double-click, because we could reprogram any chip at > zero cost? > Being human nature what it is, it would instantly kill > the general-purpose IC market (and probably bring industry to > a grinding halt). The focussed engineers that still want to > use the general-purpose stuff would be unable to buy it because > the market for these IC's would shrink. (You design it the old > way and it works according to spec., but then costs must be cut > and out go the general IC's because a few cents can be inevitably > saved by a pin swap or making an output stage less powerful). > > If you follow this train of thought, then libraries of source > code will never make it: they can't gain momentum as the user > base is too small (at most the programmers of the language-du-jour). > > What could make it (if you want to follow my analogy) is open > source software that is compiled as a shared library. In this > way everybody/every language can use the library. Improvements > are still possible but they have to go through the package > maintainers. In principle it is still possible for an engineer > to fork an existing package and maintain it privately, but in > most cases it is not unlike designing and manufacturing your > own IC: too many different skills are needed, can't bother. > > So, the question is not the programming language(s) to use, > but how well what we use is able to interface to all the > binary packaged stuff that is out there. What about using > a .dll or .so in Standard Forth? We still can't do this > in a standard way! > > Own quote: > "Of course, there are the very good engineers that can take > a board full of LSI chips and bring it down to the essentials > (which then somebody would produce an single IC for)." > > I guess this is the spot for a Forth PROGRAM, which then > might become a library. > > > There's a big difference between using a completed, production program > > and using a body of code that is intended to be a component of a program > > that you're writing. Most libraries that I've aren't totally black > > boxes, but have many options and things that can be included or not, > > etc. To be useful it would have to be provided in source, be both > > readable and well-documented, and fully compatible with the Forth system > > I'm using. > > It sound very reasonable and I like it a lot. However, it is > *completely* at odds with my analogy above. > > > This is certainly not impossible; polyFORTH came with > > extensive database and graphics libraries, for example, and SwiftForth > > and SwiftX include a number of smaller application-oriented bodies of > > code. But we were disappointed in the math library that was circulated > > many years ago, due to issues both with code quality and documentation. > > Your stab at the FSL is not nice. What did Forth Inc. do to improve this > situation? Code quality of a Forth library could be excellent: distribute > the output of VFX or iForth, or F2C or whatever else we can come up with. > For documentation the obvious candidate is Forth Inc :-) > > > Good libraries could in theory be a great asset to Forth, but every time > > this subject comes up it's always structured as "somebody [else] should > > write more libraries," not "here's a great library I have written." > > > People on clf would rather write a DIY Forth system than a library. > > I wonder what would happen if Forth source could be compiled with > the best systems around and be distributed as shared libraries. > It would separate the tasks of writing code and designing something > that runs efficiently. Of course, not every (not many?) Forth programs > can or should work as a shared library. > > -marcel All of this sounds like a well-made argument for code-libraries. I haven't forgotten however, that you took my LC53 encryption-cracking program and posted it on comp.lang.forth with my name removed from the copyright notice, then later on you admitted that you didn't know what my algorithm did: https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D I agree with this statement that you made: > What could make it (if you want to follow my analogy) is open > source software that is compiled as a shared library. In this > way everybody/every language can use the library. Improvements > are still possible but they have to go through the package > maintainers. In principle it is still possible for an engineer > to fork an existing package and maintain it privately, but in > most cases it is not unlike designing and manufacturing your > own IC: too many different skills are needed, can't bother. What will most likely happen however, is that somebody like you will take a code-library written by somebody like me and claim that you wrote it yourself --- just so you can pretend to be a better programmer than you are --- the result will be a disincentive for future code-library writers and a balkanization of present code-libraries.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-15 08:52 +0000 |
| Message-ID | <2016Aug15.105240@mips.complang.tuwien.ac.at> |
| In reply to | #49979 |
mhx@iae.nl writes:
>If you follow this train of thought, then libraries of source
>code will never make it: they can't gain momentum as the user
>base is too small (at most the programmers of the language-du-jour).
>
>What could make it (if you want to follow my analogy) is open
>source software that is compiled as a shared library. In this
>way everybody/every language can use the library. Improvements
>are still possible but they have to go through the package
>maintainers. In principle it is still possible for an engineer
>to fork an existing package and maintain it privately, but in
>most cases it is not unlike designing and manufacturing your
>own IC: too many different skills are needed, can't bother.
The practice of other programming languages (e.g., JavaScript or
Python) demonstrates that source code libraries do make it. In the
case of Javascript, even very small ones that just provide some
substring function or something.
Why have they not made it in Forth (yet)? I can think of several
factors:
* A culture rejecting libraries; after all, Chuck Moore spoke against
them and his saying about favouring rewriting instead of reusing
code as-is are frequently repeated here.
* Along with that, we get vendors who do not understand what is needed
to support source code libraries, and fight hard against including
the necessary features in the standard.
* Small embedded systems play a big role in the minds of many Forth
programmers, and there you generally cannot afford the inefficiency
of using a library as-is (neither source code, nor binary).
* We have a small community, and thanks to the factors above, the
number of people working on source code libraries is even smaller,
so it does not reach the critical mass, unlike JavaScript or Python.
* There are also technical issues. We have explicit memory
management, and often this means that you can have one library that
manages memory in one way, but is good only for some uses, and
another library that manages memory in another way and is also good
for some uses. As a result, we have, e.g., lots of different string
libraries, and none gains general acceptance.
>So, the question is not the programming language(s) to use,
>but how well what we use is able to interface to all the
>binary packaged stuff that is out there. What about using
>a .dll or .so in Standard Forth? We still can't do this
>in a standard way!
Various Forth systems offer C interfaces and you can call shared
libraries containing C code (or other ABI-compatible code) with this,
and certainly standardizing the C interface is on the agenda.
But Forth systems producing shared libraries from Forth source code
are rare; IIRC bigForth can do binary modules, but they are not
standard .so or .dll files, are they?
So in terms of binary Forth libraries, we don't have anything. But I
also doubt that they would help. None of the points I made above go
away when the library is supplied in binary. We have a way to deal
with source libraries; it needs some more standardizations, but we are
certainly much farther there than for binary libraries.
- 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 | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2016-08-15 02:31 -0700 |
| Message-ID | <2f1e095c-3f09-4bcc-b82f-79d620f1941f@googlegroups.com> |
| In reply to | #50142 |
Den måndag 15 augusti 2016 kl. 11:25:47 UTC+2 skrev Anton Ertl: > mhx@iae.nl writes: > >If you follow this train of thought, then libraries of source > >code will never make it: they can't gain momentum as the user > >base is too small (at most the programmers of the language-du-jour). > > > >What could make it (if you want to follow my analogy) is open > >source software that is compiled as a shared library. In this > >way everybody/every language can use the library. Improvements > >are still possible but they have to go through the package > >maintainers. In principle it is still possible for an engineer > >to fork an existing package and maintain it privately, but in > >most cases it is not unlike designing and manufacturing your > >own IC: too many different skills are needed, can't bother. > > The practice of other programming languages (e.g., JavaScript or > Python) demonstrates that source code libraries do make it. In the > case of Javascript, even very small ones that just provide some > substring function or something. > > Why have they not made it in Forth (yet)? I can think of several > factors: > > * A culture rejecting libraries; after all, Chuck Moore spoke against > them and his saying about favouring rewriting instead of reusing > code as-is are frequently repeated here. > > * Along with that, we get vendors who do not understand what is needed > to support source code libraries, and fight hard against including > the necessary features in the standard. > > * Small embedded systems play a big role in the minds of many Forth > programmers, and there you generally cannot afford the inefficiency > of using a library as-is (neither source code, nor binary). > > * We have a small community, and thanks to the factors above, the > number of people working on source code libraries is even smaller, > so it does not reach the critical mass, unlike JavaScript or Python. > > * There are also technical issues. We have explicit memory > management, and often this means that you can have one library that > manages memory in one way, but is good only for some uses, and > another library that manages memory in another way and is also good > for some uses. As a result, we have, e.g., lots of different string > libraries, and none gains general acceptance. > > >So, the question is not the programming language(s) to use, > >but how well what we use is able to interface to all the > >binary packaged stuff that is out there. What about using > >a .dll or .so in Standard Forth? We still can't do this > >in a standard way! > > Various Forth systems offer C interfaces and you can call shared > libraries containing C code (or other ABI-compatible code) with this, > and certainly standardizing the C interface is on the agenda. > > But Forth systems producing shared libraries from Forth source code > are rare; IIRC bigForth can do binary modules, but they are not > standard .so or .dll files, are they? > > So in terms of binary Forth libraries, we don't have anything. But I > also doubt that they would help. None of the points I made above go > away when the library is supplied in binary. We have a way to deal > with source libraries; it needs some more standardizations, but we are > certainly much farther there than for binary libraries. > > - 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/ Does it have to be binary libraries? Isn't INCLUDE fast enough?
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-08-15 22:43 +1000 |
| Message-ID | <nosde3$1d2$1@gioia.aioe.org> |
| In reply to | #50142 |
Anton Ertl wrote: > ... > The practice of other programming languages (e.g., JavaScript or > Python) demonstrates that source code libraries do make it. In the > case of Javascript, even very small ones that just provide some > substring function or something. > > Why have they not made it in Forth (yet)? I can think of several > factors: > > * A culture rejecting libraries; after all, Chuck Moore spoke against > them and his saying about favouring rewriting instead of reusing > code as-is are frequently repeated here. > > * Along with that, we get vendors who do not understand what is needed > to support source code libraries, and fight hard against including > the necessary features in the standard. > > * Small embedded systems play a big role in the minds of many Forth > programmers, and there you generally cannot afford the inefficiency > of using a library as-is (neither source code, nor binary). > > * We have a small community, and thanks to the factors above, the > number of people working on source code libraries is even smaller, > so it does not reach the critical mass, unlike JavaScript or Python. > > * There are also technical issues. We have explicit memory > management, and often this means that you can have one library that > manages memory in one way, but is good only for some uses, and > another library that manages memory in another way and is also good > for some uses. As a result, we have, e.g., lots of different string > libraries, and none gains general acceptance. So whenever an idea fails to fly, we can blame it on Forth's creator, the Standard, the vendors, the users or lack of numbers :)
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-08-15 14:49 +0000 |
| Message-ID | <57b1cf52.387071037@news.eternal-september.org> |
| In reply to | #50142 |
On Mon, 15 Aug 2016 08:52:40 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Why have they not made it in Forth (yet)? I can think of several >factors: > >* A culture rejecting libraries; after all, Chuck Moore spoke against > them and his saying about favouring rewriting instead of reusing > code as-is are frequently repeated here. This certainly not true for the commercial vendors. Our clients want as much functionality as they can get. What distinguishes them from other users is that they have to pay for code. They also have different expectations of the code. >* Along with that, we get vendors who do not understand what is needed > to support source code libraries, and fight hard against including > the necessary features in the standard. Rubbish. We have code bases and clients of 30 years standing. We are just not prepared to break that code. >* Small embedded systems play a big role in the minds of many Forth > programmers, and there you generally cannot afford the inefficiency > of using a library as-is (neither source code, nor binary). Since the ANS standard, portability of embedded code above the driver layer has improved enourmously. However, this has required authors to consider portability from the outset. To add another issue, there is a resistance in some areas to add necessary complexity to parsing to reduce application programmer effort. MPE released the source code for our EXTERN: interface to shared libraries some years ago. I only know of one system adopting it. It may be significant that the interface is designed for ease of use rather than ease of implementation. >>So, the question is not the programming language(s) to use, >>but how well what we use is able to interface to all the >>binary packaged stuff that is out there. What about using >>a .dll or .so in Standard Forth? We still can't do this >>in a standard way! > >Various Forth systems offer C interfaces and you can call shared >libraries containing C code (or other ABI-compatible code) with this, >and certainly standardizing the C interface is on the agenda. I would certainly support standardising this, even if we end up with a notation driven by implementation requirements. However, a notation that ignores type information just won't cut it. Note also that we are not just discussing hosted systems here. The MPE Sockpuppet interface (thank you, Robert Sexton) to C for embedded systems uses the same notation as the EXTERN: interface but for linking embedded Forth to embedded C code. >But Forth systems producing shared libraries from Forth source code >are rare; IIRC bigForth can do binary modules, but they are not >standard .so or .dll files, are they? VFX Forth for Windows has been able to produce DLLs for many years, and other commercial systems can do so too. It isn't always easy and the implementation cost is often considerable. Once you include embedded systems, source code portability is still far more valuable than binary portability. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-08-21 21:24 +0000 |
| Message-ID | <npd674$vqt$1@dont-email.me> |
| In reply to | #50154 |
Am Mon, 15 Aug 2016 14:49:12 +0000 schrieb Stephen Pelc:
> To add another issue, there is a resistance in some areas to add
> necessary complexity to parsing to reduce application programmer effort.
> MPE released the source code for our EXTERN: interface to shared
> libraries some years ago. I only know of one system adopting it. It may
> be significant that the interface is designed for ease of use rather
> than ease of implementation.
Is it? Do you think the Gforth interface is not easy to use? Gforth's
interface is
c-function <forth-name> <c-name> <inputs> -- <output>
with the inputs and outputs written in a typical Forth stack notation,
i.e. a for address type, n for integer, u for unsigned, and r for float.
VFX's interface is
extern: <out type> <forth-name> ( <in type>, <in type>, ... );
or LocalExtern: if you want a different name for Forth and C.
and the types are C style types, with typemapping for Windows provided by
the system, and you can define your own typemap by adding definitions to
a certain vocabulary.
Not so much different, it is a bit easier to manually convert C headers
into VFX style code.
We however figured out that trying to parse the C header files ourselves
is not cutting the mustard, you always need tons of adjustments, and it
is boring to do that for thousands of lines. We want this automated, C
libraries tend to be pretty huge and bloated these days (OpenGL 4.5 has
almost 3000 C-functions, and 5300 constants), and they are cluttered with
preprocessor magic. Therefore, Gerald Wodni wrote a Swig module which
parses the C header file and outputs SwiftForth, VFX, and Gforth-style
bindings. While we were at it, it turned out that we also needed
function pointer based calls (for C++-like interfaces) and callbacks. At
the moment, you only get fully working output on a variety of typical C
libraries in Gforth style. Feature completeness is also important.
That thing made the C libraries actually accessible for me, that is "easy
to use". I got MESA's first Vulkan implementation, and I wrote
// this file is in the public domain
%module gl
%insert("include")
%{
#include <vulkan/vulkan.h>
%}
%apply unsigned long long { uint64_t };
%apply unsigned long { size_t };
%apply int { int32_t };
%apply unsigned int { uint32_t };
%apply SWIGTYPE *
{ VkBuffer,VkBufferView,VkCommandPool,VkDebugReportCallbackEXT,VkDescriptorPool,VkDescriptorSetLayout,VkDeviceMemory,VkDisplayKHR,VkDisplayModeKHR,VkEvent,VkFence,VkFramebuffer,VkImage,VkImageView,VkPipeline,VkPipelineCache,VkPipelineLayout,VkQueryPool,VkRenderPass,VkSampler,VkSemaphore,VkShaderModule,VkSurfaceKHR,VkSwapchainKHR };
#define VKAPI_PTR
#define VKAPI_ATTR
#define VKAPI_CALL
%include <vulkan/vk_platform.h>
%include <vulkan/vulkan.h>
Of course, you have to specify the type mapping (especially for the many
pointer types), and which files should be parsed, and that's it.
That is easy to use, though still difficult to install, but we are
working on integration into Swig mainline, then it is easy to install.
That thing solves the parsing problem, and especially it solves it with
the same tool Python and Co. use to generate their interface bindings.
This means a C library maintainer will write header files that can be
parsed by Swig. Swig is a tool to generate source code, so the Forth
system just loads the generated source.
And it turned out to me that it is not sufficient to do this once for a
particular interface, you need to do it over and over again, when you
port. Android has some subtle differences in JNI compared to Oracle's
SDK, so if you want JNI on Android, you need to generate bindings for the
Android jni.h. OpenGL is much worse with all the ARBs and stuff, and a
moving target (probably it stops moving when everybody jumps on Vulkan,
but then Vulkan is the moving target).
So you definitely want automated tools that take a C header and generate
the library bindings for the Forth you use. The actual functionality
matters (I got you to agree on some functionality, e.g. how to call
floating point functions, and you would likely agree on functionality
like function pointers, too; we agree on parameter passing order, that is
the important stuff), but the actual syntax doesn't really matter, unless
you have to support legacy libraries. Take C headers, output somewhat
system specific Forth code through Swig magic, and off you go.
That's far more important than having the same syntax on extern C
functions, and starting with a library that was created for Windows and
x86, and now also works on Linux and MacOS, x86 only.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-08-22 07:04 +0300 |
| Message-ID | <npdtkg$94e$2@dont-email.me> |
| In reply to | #50357 |
On 22/08/2016 00:24, Bernd Paysan wrote: > We however figured out that trying to parse the C header files ourselves > is not cutting the mustard, you always need tons of adjustments, and it > is boring to do that for thousands of lines. We want this automated, C > libraries tend to be pretty huge and bloated these days (OpenGL 4.5 has > almost 3000 C-functions, and 5300 constants), and they are cluttered with > preprocessor magic. Therefore, Gerald Wodni wrote a Swig module which > parses the C header file and outputs SwiftForth, VFX, and Gforth-style > bindings. This sounds interesting. Is it publicly available?
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-08-26 07:12 +0200 |
| Message-ID | <867fb4t8ok.fsf@molnjunk.nocrew.org> |
| In reply to | #50381 |
Ron Aaron wrote: > Bernd Paysan wrote: >> Gerald Wodni wrote a Swig module which parses the C header file and >> outputs SwiftForth, VFX, and Gforth-style bindings. > > This sounds interesting. Is it publicly available? It's probably this: https://github.com/GeraldWodni/swig
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web