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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-12 22:15 -0700 |
| Message-ID | <065b6c2a-66ea-4f31-998d-e50f6b9ebd7e@googlegroups.com> |
| In reply to | #50013 |
On Friday, August 12, 2016 at 9:05:53 PM UTC-7, lawren...@gmail.com wrote: > On Saturday, August 13, 2016 at 2:05:15 PM UTC+12, Doug Hoffman wrote: > > > A good OOP package gives you more than just inheritance, polyporphism, > > dynamic binding, open recursion, and data namespace protection. > > A good language will give you more than just OOP. Functions as first-class objects can be rather useful, too. Hasn't Forth always had this? So long as you can obtain the xt with FIND or tick then you have a function as a first-class object. I relied on this in LowDraw.4th (my first-ever ANS-Forth program) to allow the user to write functions for various drawing strategies and then run the program with those strategies being used, without needing to recompile the program or rerun the table-building word.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-12 23:39 -0700 |
| Message-ID | <1f719a0d-3e81-48d3-8a49-ae06b189babe@googlegroups.com> |
| In reply to | #50014 |
On Saturday, August 13, 2016 at 5:15:08 PM UTC+12, hughag...@gmail.com wrote:
> On Friday, August 12, 2016 at 9:05:53 PM UTC-7, Lawrence D’Oliveiro wrote:
>> Functions as first-class objects can be rather useful, too.
>
> Hasn't Forth always had this? So long as you can obtain the xt with FIND or
> tick then you have a function as a first-class object.
In order for this to work properly, call frames need to be allocated on the heap. This way an inner function can continue to refer to the outer environment even after the outer function has exited. Consider the following Python snippet:
def make_counter(prefix) :
count = 0
def counter() :
nonlocal count
count += 1
print("%s count = %d" % (prefix, count))
#end counter
#begin make_counter
return counter
#end make_counter
counter1 = make_counter("counter1")
counter2 = make_counter("counter2")
counter1()
counter2()
counter1()
counter2()
which produces this output:
counter1 count = 1
counter2 count = 1
counter1 count = 2
counter2 count = 2
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-13 00:03 -0700 |
| Message-ID | <f6bf0a6c-0c3f-4520-8e34-ee3c9f89a3a1@googlegroups.com> |
| In reply to | #50019 |
On Saturday, August 13, 2016 at 1:39:10 AM UTC-5, lawren...@gmail.com wrote:
> In order for this to work properly, call frames need to be allocated on the heap. This way an inner function can continue to refer to the outer environment even after the outer function has exited. Consider the following Python snippet:
You're talking about closures. Normal Forth definitions don't
enclosure on any variables either. First-class definitions are just
as powerful as the normal kind. 'First-class function' also
doesn't imply closures.
>
> def make_counter(prefix) :
> count = 0
> def counter() :
> nonlocal count
> count += 1
> print("%s count = %d" % (prefix, count))
> #end counter
> #begin make_counter
> return counter
> #end make_counter
>
> counter1 = make_counter("counter1")
> counter2 = make_counter("counter2")
> counter1()
> counter2()
> counter1()
> counter2()
>
> which produces this output:
>
> counter1 count = 1
> counter2 count = 1
> counter1 count = 2
> counter2 count = 2
Yeah, Paul Graham's thing. He has Forth submissions but didn't list
them because it depends on bignums and loadable bignum libraries don't
make Forth a bignum language.
This can be accomplished in Forth by doing, explicitly, what other
languages do implicitly with closures: attach some memory to a
function. Shared variables, like in the banking example, are also
possible, but at that point people start wondering if you haven't
heard of OO.
: counter ( n-init "name" -- )
create , does> 1 over +! ;
cr
5 counter blah
blah ?
blah ?
blah ?
: counter ( n-init -- xt )
here >r , :noname r>
]] literal 1 over +! ; [[ ;
100 counter
dup execute ?
dup execute ?
dup execute ?
drop
Output:
6 7 8 101 102 103
Obviously, returning an integer isntead of an address is no problem.
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-13 00:07 -0700 |
| Message-ID | <878tw1xi2y.fsf@jester.gateway.pace.com> |
| In reply to | #50019 |
lawrencedo99@gmail.com writes: > In order for this to work properly, call frames need to be allocated > on the heap. This way an inner function can continue to refer to the > outer environment even after the outer function has exited. In Forth without garbage collection, the best I see as feasible is to allocate those closures on the locals or return stack, so they go away when the outer function cleans up and returns. C++ allocates closures on the stack, and has a way to copy them to the heap (std::function), where those copied closures (IIUC) are freed automatically when their surrounding scope exits. I think there are some mechanisms for transferring their ownership from one scope to another if they have to last beyond the current scope, but I don't completely understand this feature at the moment. I think it wouldn't be practical to use the std::function approach in Forth, since it relies on C++'s concept of scopes and running object destructors when a scope exits. You could free them manually, but overall if you want to program in Scheme then you should download one of the many fine Scheme implementations and use it ;-). I find that extensive use of closures and HOFs gets confusing in Scheme or Python even though their automatic gc takes care of reclaiming storage. It's easy to lose track of how many levels of nested calls you are in, In Haskell, the compile-time type system tracks that for you, so the compiler squawks at you if you make a mistake. In Scheme or Python the runtime checks will usually give you an error condition with a stack dump as soon as the erroneous code is executed. But in Forth you're likely to get garbage results that take effort to debug.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-13 07:35 -0400 |
| Message-ID | <57af05e8$0$303$14726298@news.sunsite.dk> |
| In reply to | #50022 |
On 8/13/16 3:07 AM, Paul Rubin wrote: > But in Forth you're > likely to get garbage results that take effort to debug. Often manual de-allocation is not difficult for me. But you've a valid point for certain situations. Lately I've implemented a simple region based scheme (with RESIZE support) when the going gets too complex. It works well. Downside is it takes more memory than a GC, I believe though I've no measurements to quantify. -Doug
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-13 17:17 -0700 |
| Message-ID | <e979fad1-5227-41bb-9313-f31932f96bd3@googlegroups.com> |
| In reply to | #50031 |
On Saturday, August 13, 2016 at 11:35:06 PM UTC+12, Doug Hoffman wrote: > Downside is it takes more memory than a GC... Python, like Perl, does both reference-counting and garbage collection. Reference-counting takes care of all the cases where there are no reference cycles. Then, for the stubborn cases, it resorts to garbage collection. Best of both worlds--speed and convenience.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-13 20:04 -0700 |
| Message-ID | <43c75549-01ee-4b62-bad5-21596ff0ad95@googlegroups.com> |
| In reply to | #50071 |
On Saturday, August 13, 2016 at 7:17:11 PM UTC-5, lawren...@gmail.com wrote: > On Saturday, August 13, 2016 at 11:35:06 PM UTC+12, Doug Hoffman wrote: > > Downside is it takes more memory than a GC... > > Python, like Perl, does both reference-counting and garbage collection. Perl uses reference counting for the lifetime of the program, except on exit. Which means it only uses referencing counting as far as you'll ever care. > Reference-counting takes care of all the cases where there are no reference cycles. Then, for the stubborn cases, it resorts to garbage collection. > > Best of both worlds--speed and convenience. I suspect - just based on usage by different programming languages, for example, anything used by Python is suspect - that reference counting isn't great for performance, in addition to its other problems, but I didn't look hard for sources on that. I did find this post: http://codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html You can find a conservative GC for Forth at: http://www.complang.tuwien.ac.at/projects/forth.html From which: > However, gc.fs needs to know if there is a reference to the object > (if there is none, the object is certainly dead, and its storage can > be recycled). You have to follow some rules to make sure gc.fs > notices the reference: > > * The reference must reside on the data stack, in a memory location > specified with root-address (see below), or in a naturally aligned > cell in a referenced alloced object (naturally aligned cell means > that its address is divisible by 1 cells). I would have liked to add > the return and locals stack, but unfortunately there is no standard > way to access them, so they are out. > > * The reference is the address where the object starts (i.e., the > address returned by alloc). I.e., you cannot use addresses pointing > into the middle of an object (e.g., a pointer walking an array), > unless you also keep a pointer to the start in a place where gc.fs > will find it.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-13 20:38 -0700 |
| Message-ID | <71bcc18e-1002-4538-a69b-db771723bb95@googlegroups.com> |
| In reply to | #50073 |
On Sunday, August 14, 2016 at 3:04:13 PM UTC+12, Julian Fondren wrote: > ... reference counting isn't great for performance ... Let me offer a high-performance counterexample to that: the Linux kernel. Which uses reference-counting heavily for managing its internal objects. Can you point to a kernel which uses garbage collection instead? No, because nobody would seriously use one.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-13 20:46 -0700 |
| Message-ID | <c6877d6b-3d72-4077-bb19-b71af2164028@googlegroups.com> |
| In reply to | #50075 |
On Saturday, August 13, 2016 at 10:38:46 PM UTC-5, lawren...@gmail.com wrote: > On Sunday, August 14, 2016 at 3:04:13 PM UTC+12, Julian Fondren wrote: > > > ... reference counting isn't great for performance ... > > Let me offer a high-performance counterexample to that: the Linux kernel. Which uses reference-counting heavily for managing its internal objects. > > Can you point to a kernel which uses garbage collection instead? No, because nobody would seriously use one. If you don't know anything about GC performance either, there's nothing to discuss. On Saturday, August 13, 2016 at 10:39:44 PM UTC-5, lawren...@gmail.com wrote: > That was just a toy example. See the anim_framework examples I linked to previously for more non-trivial instances. I glanced through that and saw nothing of interest. Why don't you excerpt from it and say why the excerpt is interesting? -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 06:02 -0700 |
| Message-ID | <062187a4-59a8-40aa-8992-9806677c4146@googlegroups.com> |
| In reply to | #50075 |
On Saturday, August 13, 2016 at 8:38:46 PM UTC-7, lawren...@gmail.com wrote: > On Sunday, August 14, 2016 at 3:04:13 PM UTC+12, Julian Fondren wrote: > > > ... reference counting isn't great for performance ... > > Let me offer a high-performance counterexample to that: the Linux kernel. Which uses reference-counting heavily for managing its internal objects. > > Can you point to a kernel which uses garbage collection instead? No, because nobody would seriously use one. In my string-stack.4th I use a technique different from either GC or reference-counting. I have unique and derivative strings. When a unique gets dropped or modified, I first call FIX-DERIVATIVES --- this searches the entire string-stack for any derivatives of this unique and, if found, converts them into uniques --- it doesn't take long to do this, as there are generally only a handful of items on the string-stack. The user can assume that every string on the string-stack is unique and there are no dependencies --- in practice, most of the strings on the string-stack are derivatives --- making a derivative with DUP$ etc. is much faster than making a unique because ALLOCATE doesn't have to be called and the string doesn't have to be copied, but only the address of the string has to be copied. P.S. I agree with Lawrence that reference-counting is more efficient than other GC methods (although I'm not an expert on any of these methods as I've never implemented any of them in any language) --- I skimmed through that "reference-counted-smart-pointers-are-for-retards" article that Julien Fondren provide the link for and it was grossly arrogant and smarmy (just like Julien Fondren himself) --- I don't think that reference-counting or any other GC method is a good idea for Forth however; this is really only for dynamic-OOP systems, which Forth isn't.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-08-14 23:04 +0100 |
| Message-ID | <noqpu1$a8m$1@dont-email.me> |
| In reply to | #50082 |
On 14/08/2016 14:02, hughaguilar96@gmail.com wrote: > In my string-stack.4th I use a technique different from either GC or reference-counting. I have unique and derivative strings. When a unique gets dropped or modified, I first call FIX-DERIVATIVES --- this searches the entire string-stack for any derivatives of this unique and, if found, converts them into uniques --- it doesn't take long to do this, as there are generally only a handful of items on the string-stack. > > The user can assume that every string on the string-stack is unique and there are no dependencies --- in practice, most of the strings on the string-stack are derivatives --- making a derivative with DUP$ etc. is much faster than making a unique because ALLOCATE doesn't have to be called and the string doesn't have to be copied, but only the address of the string has to be copied. String packages with string stacks and garbage collection have been around for some time e.g. see http://www-personal.umich.edu/~williams/archive/forth/strings/smodel.html -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 16:01 -0700 |
| Message-ID | <941a6f46-959c-41e6-ac94-873e2440cb63@googlegroups.com> |
| In reply to | #50107 |
On Sunday, August 14, 2016 at 3:04:52 PM UTC-7, Gerry wrote: > On 14/08/2016 14:02, hughaguilar96@gmail.com wrote: > > In my string-stack.4th I use a technique different from either GC or reference-counting. I have unique and derivative strings. When a unique gets dropped or modified, I first call FIX-DERIVATIVES --- this searches the entire string-stack for any derivatives of this unique and, if found, converts them into uniques --- it doesn't take long to do this, as there are generally only a handful of items on the string-stack. > > > > The user can assume that every string on the string-stack is unique and there are no dependencies --- in practice, most of the strings on the string-stack are derivatives --- making a derivative with DUP$ etc. is much faster than making a unique because ALLOCATE doesn't have to be called and the string doesn't have to be copied, but only the address of the string has to be copied. > > String packages with string stacks and garbage collection have been > around for some time e.g. see > http://www-personal.umich.edu/~williams/archive/forth/strings/smodel.html I skimmed through that article. I found this paragraph: ---------------------------------------------------------------------------- A more likely problem is the transfer of a bound string to the data stack for some manipulation. The MSA on the data stack may become invalid if a dynamic string operation is performed in the meantime which causes garbage collection. The simplest rule is to avoid dynamic string operations while manipulating bound strings on the data stack. But we do include a locking mechanism by which the user can explicitly disallow or repermit garbage collection. ---------------------------------------------------------------------------- That is no good! In my documentation I say this: ---------------------------------------------------------------------------- $> ( -- adr len ) \ string: a -- This is how strings get removed from the string-stack. These strings are in the heap so the address needs to be given to DEALLOC eventually or there will be a memory leak. This function is only used if the string needs to be stored in a data-structure of some kind. The user should not use $> and then consume the string with TYPE or whatever. The user should consume the string on the string-stack, with .$ instead of TYPE for example, so the string is automatically freed from the heap. ---------------------------------------------------------------------------- $> is similar to DROP$ in that it does FIX-DERIVATIVES first. I expect all strings to remain on the string-stack at all times. You don't copy them to the data-stack and do operations on them there, and expect them to still be valid on the string-stack. You don't use TYPE as mentioned above --- there is .$ available for typing out a string. The reason why my memory-management scheme is efficient is because all the strings are on the string-stack --- you don't have strings scattered all over --- everything is contained in one place, so it is easy to manage. Of course, you sometimes need to store a string in a data-structure of some kind, in which case you need to use $> to first put it on the data-stack --- now memory-management is your responsibility and you have to use DEALLOC explicitly to get rid of it or you will have a memory leak.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-13 21:53 -0700 |
| Message-ID | <87k2fkvtmv.fsf@jester.gateway.pace.com> |
| In reply to | #50073 |
Julian Fondren <julian.fondren@gmail.com> writes: > I suspect - just based on usage by different programming languages, > for example, anything used by Python is suspect - that reference > counting isn't great for performance, in addition to its other > problems, but I didn't look hard for sources on that. Refcounting in single threaded CPython works ok. It has caused a lot of pain with multi-threading because have to put locks around the refcounts (killing performance in the single threaded case), or lock the whole interpreter (the infamous Global Interpreter Lock or GIL) when executing bytecodes. One "advantage" of refcounts was that objects are freed as soon as the last reference disappeared, so people relied on that for timely release of stuff like file descriptors, a lame style imho. Later the "with" statement was added to Python which explicitly releases stuff at the end of its scope, which is preferable. Micropython uses pure gc instead of refcounts, if that matters. > http://codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html That article is pretty unpersuasive. C++ smart pointers work pretty well if you remember that C++ is a totally different language than C and don't use legacy C stuff in your program. The refcounted pointers are useful when they are needed, but unique_ptr is good enough most of the time, and has almost no overhead. unique_ptr means the pointer has a single owner, so the object is freed when the owner goes out of scope, unless you transfer the ownership to another unique_ptr first. C++ std::shared_ptr (the ref counted ones) do have locks around the refcounts, which must be expensive. I believe Seastar has its own version of shared_ptr that can't be shared across threads, so that would get rid of the need for locks. There's some hooks in C++ for a real GC but I don't know of any implementations or what the obstacles to them are. But, part of the idea of C++ is to control your program's memory resources. If you want a GC'd language you might as well use one designed for GC from the start. > You can find a conservative GC for Forth at: > http://www.complang.tuwien.ac.at/projects/forth.html Yes, that's way cool. >> * The reference must reside on the data stack,.... I would have liked >> to add the return and locals stack, but unfortunately there is no >> standard way to access them, so they are out. I think it's worth supporting the return and locals stack in specific implementations using carnal knowledge of those implementations.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 07:45 -0700 |
| Message-ID | <e816a2c2-173c-450a-9b38-227411a64972@googlegroups.com> |
| In reply to | #50079 |
On Saturday, August 13, 2016 at 9:53:17 PM UTC-7, Paul Rubin wrote: > That article is pretty unpersuasive. C++ smart pointers work pretty > well if you remember that C++ is a totally different language than C and > don't use legacy C stuff in your program. The refcounted pointers are > useful when they are needed, but unique_ptr is good enough most of the > time, and has almost no overhead. unique_ptr means the pointer has a > single owner, so the object is freed when the owner goes out of scope, > unless you transfer the ownership to another unique_ptr first. > > C++ std::shared_ptr (the ref counted ones) do have locks around the > refcounts, which must be expensive. I believe Seastar has its own > version of shared_ptr that can't be shared across threads, so that would > get rid of the need for locks. I skimmed through that article but I was turned off by the writer's arrogant and smarmy attitude (calls people "retards" if they use reference-counting). I'm not surprised that Julien Fondren posted the link, because he is arrogant and smarmy too. I agree with you and Lawrence that reference-counting is a valid GC technique --- this is what I would most likely use if I were ever to implement GC --- I don't think that GC is a good idea in Forth though; if you want this, then program in C++ with its "smart pointers." Franck seems to be pretty knowledgeable on programming. I would be interested in finding out how he does GC in his Oforth, but he hasn't yet posted anything in this thread --- he may have posted something about GC in Oforth in some other thread, but I missed it. Earlier, Franck said this about my string-stack.4th package: On Thursday, March 10, 2016 at 11:42:43 AM UTC-7, franck....@gmail.com wrote: > Le lundi 7 mars 2016 04:09:14 UTC+1, hughag...@gmail.com a écrit : > > > 1.) JUGGLERS --- These include SWAP$ etc. and they just move items around on the string-stack. > > > > 2.) DUPLICATORS --- These include DUP$ etc. and they make a derivative item. > > > > 3.) CONSUMERS --- These include .$ etc. and they consume an item. If the item is a derivative it is just dropped. If the item is a unique, then FIX-DERIVATIVES is called first (this searches the string-stack for derivatives that are inside of this unique and changes them into uniques) and then it is dropped. > > > > 4.) MUTATORS --- These include UCASE$ etc. and they modify an item. If the item is a derivative it gets changed into a unique first, and if the item is a unique then FIX-DERIVATIVES gets called first, then the item is modified. > > > > This is an interesting memory management. I wonder how this compare to > a memory management using a garbage collector. Whenever a unique string gets dropped or modified, FIX-DERIVATIVES gets called first --- FIX-DERIVATIVES searches the entire string-stack for any derivatives of this unique and, if found, converts them into uniques --- this is pretty fast because there are typically only a handful of strings on the string-stack. The user can assume that all strings on the string-stack are unique and his code will work fine. In actuality, most of the strings are derivatives. When a new derivative is made with DUP$ or whatever, all that needs to be copied is the address of the string --- if a new unique were made, than ALLOCATE would need to be called and the string would need to be copied, which would be very slow.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-08-15 06:44 -0700 |
| Message-ID | <075c35f2-257a-43b4-856b-cf4dacc3009e@googlegroups.com> |
| In reply to | #50088 |
Le dimanche 14 août 2016 16:45:16 UTC+2, hughag...@gmail.com a écrit : > I would be interested in finding out how he does GC in his Oforth, but he hasn't yet posted anything in this thread --- he may have posted something about GC in Oforth in some other thread, but I missed it. > Oforth implements a mark and sweep incremental GC. Incremental means that, when the GC is running, it runs by steps. After each step, the GC stops, the programm runs again a little, then the GC restarts again, and so on until the end of the GC phase. This allows to not have a "stop the world" GC. If you are interested, you can read how Oforth handles memory and how GC works here : http://www.oforth.com/memory.html As for a reference counting GC, I am not fond of it. It is a good choice for a mono-thread programs, but when you use it in a multi-thread context, things are getting more complex. I much prefer a mark and sweep incremental GC. As for the Point class, here is an Oforth implementation : Object Class new: Point ( x, y ) Point method: << // ( aStream aPoint -- aStream ) "X:" << @x << " Y:" << @y << ; Point method: initialize // ( x y -- ) := y := x ; : my-test // ( -- ) 5 8 Point new . // intialize is called by #new and #. uses #<< ; #my-test see 6a: 4:c7:47 : 0 : push 4 c7:47:fc: 5 : 2 : mov c0000005, -4(edi) c7:47:f8: 8 : 9 : mov c0000008, -8(edi) bd:ac:de:69 : 10 : mov 69deac, ebp 83:ef: 8:e8 : 15 : sub 8, edi e8:c7:2b:d8 : 18 : call 401A40 e8:3a:62:ff : 1D : call 6750B8 83:c4: 4:c3 : 22 : add 4, esp c3: 0: 0:b9 : 25 : ret ok About performances, if you want to compare, here is a bench that creates many Point objects : : b-test // ( n -- ) | i | loop: i [ i i Point new drop ] ; On my laptop (core i7), creating (and freeing with GC) 100000000 Points takes about 1,4 seconds. #[ 100000000 b-test ] bench 1420136 ok Franck
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-14 19:57 +0200 |
| Message-ID | <20160814195734.1e0e87d5@maxa-pc> |
| In reply to | #50079 |
On Sat, 13 Aug 2016 21:53:12 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Julian Fondren <julian.fondren@gmail.com> writes: > > I suspect - just based on usage by different programming languages, > > for example, anything used by Python is suspect - that reference > > counting isn't great for performance, in addition to its other > > problems, but I didn't look hard for sources on that. > > Refcounting in single threaded CPython works ok. It has caused a lot > of pain with multi-threading because have to put locks around the > refcounts (killing performance in the single threaded case), or lock > the whole interpreter (the infamous Global Interpreter Lock or GIL) > when executing bytecodes. Classic GC either have to lock whole program or to synchronize on every pointer access as well...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-14 11:17 -0700 |
| Message-ID | <878tvzw6z7.fsf@jester.gateway.pace.com> |
| In reply to | #50091 |
Melzzzzz <mel@zzzzz.com> writes: >> lock the whole interpreter (the infamous Global Interpreter Lock or >> GIL) when executing bytecodes. > > Classic GC either have to lock whole program or to synchronize on every > pointer access as well... Classic GC only has to lock the program -during garbage collection-. The Python GIL has to lock the interpreter essentially -all the time-. That means your program is always running on a single cpu core even if you use multiple threads. That was ok when most cpus were single core, but it's a significant source of frustration now.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-14 13:59 -0700 |
| Message-ID | <aaed3e4a-dabc-4f28-a129-798899e2cb75@googlegroups.com> |
| In reply to | #50092 |
On Monday, August 15, 2016 at 6:17:21 AM UTC+12, Paul Rubin wrote: > The Python GIL has to lock the interpreter essentially -all the time-. > That means your program is always running on a single cpu core even if > you use multiple threads. That was ok when most cpus were single core, > but it's a significant source of frustration now. That may apply to pure Python code, but it doesn’t need to apply to extension modules written in C. In these, you can release the GIL during the CPU-intensive parts, allowing them to be multithreaded, then reacquire it for returning results back to Python. I used this technique here <https://github.com/ldo/grainypy/blob/master/grainyx.c>--look for the sequences bracketed by Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-14 14:09 -0700 |
| Message-ID | <87ziofukfo.fsf@jester.gateway.pace.com> |
| In reply to | #50099 |
lawrencedo99@gmail.com writes: > That may apply to pure Python code, but it doesn’t need to apply to > extension modules written in C. In these, you can release the GIL Yes, I know about that, and it helps some of the time (I think numpy does that). I meant the interpreter has to hold the GIL while running Python code. For occasional CPU-intensive stuff I do in Python, I can usually split up the problem and run multiple Python instances on different cores, but the GIL is still a big wart on Python.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-14 15:48 -0700 |
| Message-ID | <fbe858b7-cbc0-4a04-b7fd-8898656789d0@googlegroups.com> |
| In reply to | #50101 |
On Monday, August 15, 2016 at 9:09:32 AM UTC+12, Paul Rubin wrote: > I meant the interpreter has to hold the GIL while running > Python code. If you want speed, you’re going to recode that bit in C, not Python, anyway. That’s why the GIL hasn’t been seen as a big problem.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web