Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52738 > unrolled thread
| Started by | humptydumpty <ouatubi@gmail.com> |
|---|---|
| First post | 2016-11-19 13:34 -0800 |
| Last post | 2017-04-11 06:41 -0700 |
| Articles | 20 on this page of 159 — 26 participants |
Back to article view | Back to comp.lang.forth
Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-19 13:34 -0800
Re: Yet another draw of rectangle "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-20 00:53 +0000
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 14:46 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-19 20:01 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 20:10 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 01:18 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 01:36 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 02:16 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 02:36 -0800
Re: Yet another draw of rectangle Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-20 07:48 -0500
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-22 23:36 -0500
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 02:03 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 21:49 +1100
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 03:33 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 08:52 -0800
Re: Yet another draw of rectangle Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-20 12:05 -0600
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-21 10:43 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 16:25 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-21 15:20 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 00:02 -0800
Re: Yet another draw of rectangle Mark Wills <markwills1970@gmail.com> - 2016-11-22 01:00 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 01:13 -0800
Re: Yet another draw of rectangle "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-22 20:54 +0000
Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-27 13:32 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-26 18:52 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-28 15:00 +1100
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 18:32 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-27 20:44 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-29 15:22 +1100
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-29 00:42 -0500
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-28 22:20 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-29 17:18 -0800
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-29 23:15 -0500
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-11-30 07:08 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-29 21:51 -1000
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-11-30 12:09 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 09:43 -1000
Re: Yet another language ( was Yet another draw of rectangle) Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 17:36 -0600
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:31 -1000
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-12-01 07:02 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-01 08:58 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-01 16:44 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-05 21:28 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 07:41 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-06 18:13 +1100
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-05 21:36 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 00:05 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-08 10:09 +1100
Re: Yet another language ( was Yet another draw of rectangle) Paul Rubin <no.email@nospam.invalid> - 2016-12-07 15:27 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-08 04:22 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-08 17:05 -0800
Re: Yet another language ( was Yet another draw of rectangle) Mark Wills <markwills1970@gmail.com> - 2016-12-09 01:47 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-09 04:01 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 06:49 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-10 10:15 +1100
Re: Yet another language ( was Yet another draw of rectangle) josv@planet.nl - 2017-04-12 04:47 -0700
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-07 14:34 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-07 18:39 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-10 09:38 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 16:25 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 00:14 -0800
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-12-06 12:01 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 10:21 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 16:27 -0800
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-08 21:05 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-08 18:57 -0700
Re: Yet another language ( was Yet another draw of rectangle) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-09 05:28 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-09 06:45 -0700
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-10 16:54 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-10 17:21 -0700
Re: Yet another language ( was Yet another draw of rectangle) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-11 08:03 +0100
Re: Yet another language ( was Yet another draw of rectangle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-11 07:50 +0000
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-11 11:43 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-11 10:16 -0700
Re: Yet another language ( was Yet another draw of rectangle) Paul Rubin <no.email@nospam.invalid> - 2017-04-11 10:21 -0700
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-11 10:48 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-11 23:58 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 03:07 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 00:29 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 00:55 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 04:07 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 13:29 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 16:51 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 03:50 -0700
Re: Yet another language ( was Yet another draw of rectangle) Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:55 +0200
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 04:17 -0700
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 06:03 -0500
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 04:30 -0700
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 08:44 -0500
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:01 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 13:33 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 12:59 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 17:05 -0400
Re: Yet another language ( was Yet another draw of rectangle) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 10:27 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-11 14:02 -0400
Re: Yet another language ( was Yet another draw of rectangle) Julian Fondren <julian.fondren@gmail.com> - 2017-04-08 20:10 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-13 13:16 -0400
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-05 12:01 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 10:39 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-12-05 18:53 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 11:33 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-12-05 22:22 +0000
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-06 04:29 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 11:32 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-07 19:06 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-06 04:27 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 10:24 -0800
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-30 13:41 +0000
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-11-30 15:15 +0000
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-12-01 09:54 +0000
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-01 04:42 -0600
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:09 -0400
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:14 -0400
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 08:32 -1000
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 12:42 -0700
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 10:36 -1000
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 16:41 -0400
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:25 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 14:13 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 17:45 -0400
Re: Yet another language ( was Yet another draw of rectangle) Mark Wills <markwills1970@gmail.com> - 2017-04-13 05:53 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-13 13:34 -0400
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-29 11:48 +0000
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-11-29 14:24 +0000
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-29 21:27 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-29 18:15 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-11-30 10:03 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-01 16:14 -0800
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-29 12:22 -1000
Re: Yet another language ( was Yet another draw of rectangle) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-29 14:31 +0100
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-02 23:05 +1100
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-03 22:00 +1100
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-23 10:11 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 00:01 -0800
Re: Yet another draw of rectangle albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-23 13:49 +0100
Re: Yet another draw of rectangle foxaudioresearch@gmail.com - 2016-11-23 10:51 -0800
Re: Yet another draw of rectangle "Elizabeth D. Rather" <erather@forth.com> - 2016-11-24 09:26 -1000
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 12:28 -0800
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-24 16:54 -0800
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-25 02:20 -0500
Re: Yet another draw of rectangle albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-25 10:39 +0100
Re: Yet another draw of rectangle Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-22 04:17 -0600
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 10:38 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-23 13:05 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-29 15:23 -0800
Re: Yet another draw of rectangle Ron Aaron <rambamist@gmail.com> - 2016-11-24 07:46 +0200
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 21:59 -0800
Re: Yet another draw of rectangle Ron Aaron <rambamist@gmail.com> - 2016-11-24 08:12 +0200
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-23 22:22 -0500
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-23 21:14 -0800
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-24 01:06 -0500
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-25 11:56 +1100
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-19 23:14 -0800
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-24 18:11 -0800
Re: Yet another draw of rectangle luser droog <mijoryx@yahoo.com> - 2016-11-24 18:58 -0800
Re: Yet another draw of rectangle luser droog <mijoryx@yahoo.com> - 2016-11-24 20:01 -0800
Re: Yet another draw of rectangle Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-20 14:08 -0800
Re: Yet another draw of rectangle lehs <skydda.barnen@gmail.com> - 2017-04-11 06:41 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-05 11:33 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <6ff1822a-f229-45f4-83f0-84cb8c2f2a10@googlegroups.com> |
| In reply to | #53092 |
On Monday, December 5, 2016 at 11:53:13 AM UTC-7, Alex wrote: > On 12/5/2016 18:39, hughaguilar96@gmail.com wrote: > > > Andrew Haley is an > > employee of Elizabeth Rather > > Really? > > -- > Alex Yes, of course. Why else would he have been appointed to the Forth-200x committee? He says this: On Saturday, June 25, 2016 at 3:09:53 AM UTC-7, Andrew Haley wrote: > Brad Eckert <hwfwguy@gmail.com> wrote: > > > > Forth is a language best taught by experts. You can teach yourself, > > but it's going to take a while if you're learning by doing. Using a > > commercial Forth is a good way to learn from an expert. > > I was fortunate enough to work for COMSOL and attend (and later teach) > some training courses and then even do some things with Forth, Inc. > I'm not sure that I would ever have really got the idea of Forth > without being taught by experts. This is the COMSOL he is referring to: http://www.computer-solutions.co.uk/chipdev/forth.htm
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-05 22:22 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o24p80$hrm$1@dont-email.me> |
| In reply to | #53095 |
On 12/5/2016 19:33, hughaguilar96@gmail.com wrote: > On Monday, December 5, 2016 at 11:53:13 AM UTC-7, Alex wrote: >> On 12/5/2016 18:39, hughaguilar96@gmail.com wrote: >> >>> Andrew Haley is an >>> employee of Elizabeth Rather >> >> Really? >> >> -- >> Alex > > Yes, of course. Why else would he have been appointed to the Forth-200x committee? He says this: > > On Saturday, June 25, 2016 at 3:09:53 AM UTC-7, Andrew Haley wrote: >> Brad Eckert <hwfwguy@gmail.com> wrote: >>> >>> Forth is a language best taught by experts. You can teach yourself, >>> but it's going to take a while if you're learning by doing. Using a >>> commercial Forth is a good way to learn from an expert. >> >> I was fortunate enough to work for COMSOL and attend (and later teach) >> some training courses and then even do some things with Forth, Inc. >> I'm not sure that I would ever have really got the idea of Forth >> without being taught by experts. > > This is the COMSOL he is referring to: > http://www.computer-solutions.co.uk/chipdev/forth.htm > Ah, so he knows what he's talking about. That's why you're jealous. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-06 04:29 -0600 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <AZCdnU4XNM1zD9vFnZ2dnUU7-a-dnZ2d@supernews.com> |
| In reply to | #53098 |
Alex <alex@rivadpm.com> wrote: > > Ah, so he knows what he's talking about. That's why you're jealous. Yep. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-06 11:32 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <c269987a-c28c-4ccc-a317-890ab264ac52@googlegroups.com> |
| In reply to | #53116 |
On Tuesday, December 6, 2016 at 3:29:07 AM UTC-7, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: > > > > Ah, so he knows what he's talking about. That's why you're jealous. > > Yep. > > Andrew. A bit arrogant, aren't you Andrew? Has your appointment to the Forth-200x committee gone to your head? Does everybody that Elizabeth Rather appoints to the Forth-200x committee need to buy a new hat one size larger? Alex McDonald is already at the maximum hat size due to the prodigious quantity of b.s. that he packs in his head --- if he gets promoted to be a voting member of the Forth-200x committee, which I expect to happen soon, there won't be any hat that will fit him --- he'll need to overturn a five-gallon bucket and use that for his hat, which will be the only thing that will fit! Remember this thead? https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B1-25%5D Here we have an example of Andrew Haley completely failing to understand what a quotation is. And, btw, whatever happened to that issue? Have the Paysan-faked quotations been accepted into Forth-200x yet? This was another example of when I wrote code that worked (the rquotations) and the Forth-200x committee remained focused on a fantasy that doesn't work in the sense that there is no working code, and also doesn't work in the sense that it fails to provide the features that my code provides. On Saturday, July 9, 2016 at 11:24:11 AM UTC-7, hughag...@gmail.com wrote: > On Saturday, July 9, 2016 at 10:27:31 AM UTC-7, Andrew Haley wrote: > > JennyB <jennybrien@googlemail.com> wrote: > > > Outside its parent, the quotation could only be meaningfully be > > > executed from within another definition that provided a suitable > > > local frame. How you would manage that, or why you would want to, I > > > leave up to you. > > > > Quite. I think that idea isn't going to fly. > > > > Andrew. > > LOL! Jennifer Brien has already figured out that this statement of her's is nonsense --- Andrew Haley (employee of Forth Inc.) had to go back to a post where she still didn't understand how quotations worked so he could agree with that. Quite (funny). > > The HOF doesn't have to "provide a suitable local frame" --- this was Jennifer's confused idea that the HOF had to have a look-alike local-frame as the parent function's --- actually, the HOF just has to have a local-frame so that its local-frame pointer can be held aside by REX (on the return-stack), but it doesn't matter to the quotation what the HOF's local-frame looks like because it is going to be ignored.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-07 19:06 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ff5328cf-5e7d-4f24-9e12-f034d67373ac@googlegroups.com> |
| In reply to | #53116 |
On Tuesday, December 6, 2016 at 3:29:07 AM UTC-7, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: > > > > Ah, so he knows what he's talking about. That's why you're jealous. > > Yep. > > Andrew. This was actually the funniest exchange that I've seen on comp.lang.forth in quite some time --- we haven't had such comedy since John Passaniti left --- this is actually funnier though because one of the people claiming that I'm jealous is a Forth-200x committee member. Andrew Haley's array definer worked only with cell-sized elements, so it was limited to being used to define an array of single-precision integers or an array of pointers to something else. What if a student needs an array of floats? This would be pretty common in numerical programing. Using Andrew Haley's array definer, he would have to define an array of pointers to floats. This is a hassle because, there is an extra level of indirection needed to access the floats. Given the address of an array element, he needs to do @ F@ to get the float, rather than just F@ directly. Where are all of those floats going to be stored? The obvious answer is that they are stored in the heap. This grossly increases the complexity of the program though, because the student now needs to use ALLOCATE and FREE to obtain and release the memory for each floating point number that his program uses. This complication is not only a big hassle, but it will also significantly slow down his program because ALLOCATE and FREE are notoriously slow functions. By comparison, my <ARY> and ARY allow the array elements to be any size, so the array element can contain a float --- or it can contain a double-precision integer or a struct, or whatever --- my <ARY> and ARY are a general-purpose array definer. I consider ANS-Forth and Forth-200x to be a cult. The code quality is abysmal. Instead of learning more about computer-science and improving their code quality, the committee members say that people such as myself are jealous of their awesome programming skill, and that we are utterly incompetent ourselves (Alex McDonals says that I "have a serious misunderstanding of how pointers work" and that I "really don't know how CREATE DOES> works") --- if I were really that stupid, then it would be impossible for me to write even the simplest Forth code --- I do write quite a lot of Forth code though. I wrote the entire novice-package, but nobody has ever used it, and afaik nobody has ever looked at it. I post code such as this too: https://groups.google.com/forum/#!topic/comp.lang.forth/TYuy2hPpi7U There is no response. The cult members turn a blind eye to working Forth code because working Forth code doesn't have any place in their world-view. Even if nobody ever responds to that post above, it is still worthwhile to me because it makes the ANS-Forth cult look stupid --- working Forth code is what they hate and fear the most!
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-06 04:27 -0600 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <AZCdnU8XNM0VD9vFnZ2dnUU7-a-dnZ2d@supernews.com> |
| In reply to | #53092 |
Alex <alex@rivadpm.com> wrote: > On 12/5/2016 18:39, hughaguilar96@gmail.com wrote: > >> Andrew Haley is an employee of Elizabeth Rather > > Really? No, of course not. I am Java Platform Engineering Lead at Red Hat. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-06 10:24 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <08a655d2-c96d-4355-84ec-4ab9c746d5ab@googlegroups.com> |
| In reply to | #53115 |
On Tuesday, December 6, 2016 at 3:27:26 AM UTC-7, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: > > On 12/5/2016 18:39, hughaguilar96@gmail.com wrote: > > > >> Andrew Haley is an employee of Elizabeth Rather > > > > Really? > > No, of course not. I am Java Platform Engineering Lead at Red Hat. > > Andrew. You have worked for Forth Inc. in the past --- this stain can never be washed off --- she appointed you to the Forth-200x committee because she still considers you to be her tool, and you are.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-11-30 13:41 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <MPG.32a8e779a9548589896d2@news.virginmedia.com> |
| In reply to | #52981 |
> In article <VMadnb2EDIODGKPFnZ2dnUU7-KvNnZ2d@supernews.com>, erather@forth.com says... > > I suggest that the real reason Forth libraries haven't caught > on is that it's easier to write the words than to search the internet > for versions someone else wrote that don't do exactly what you want. > > Cheers, > Elizabeth > > -- Trust me Elizabeth - that's not the case. as an example - If I wanted an FFT I couldn't just sit down and code it today (some years ago maybe but not these days - hence jim) . I might still know what an FFT is (or a sobel edge detector or whatever is) and have a need for it without having the time to re-acquaint myself fully to recreate one. A proven library or package or whatever you call it is ideal in such cases. It happens at all levels. To keep it practical how about making it a function of the standards committe to review and approve a list of packages based for example on the repeated use and refinement from a single source such as Geralds library or another if he was unable or unwilling to do that side of things. Forth users would be encouraged to use the packages and report back any issue to the author and when a concensus arises that one is a stable item that resolves a problem or provides a "product" the standards comittee marks it as the authorised solution. Anyone can then "include" it in applications the same as any C library or whatever. The mechanisms are there without too much work provided there are enough actual users of forth to drive it. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-30 15:15 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <583ee1a8.1767856775@news.eternal-september.org> |
| In reply to | #52985 |
On Wed, 30 Nov 2016 13:41:50 -0000, john <anon@example.com> wrote: >Trust me Elizabeth - that's not the case. >as an example - If I wanted an FFT I couldn't just sit down and code >it today (some years ago maybe but not these days - hence jim) . I might still >know what an FFT is (or a sobel edge detector or whatever is) and have >a need for it without having the time to re-acquaint myself fully to recreate one. >A proven library or package or whatever you call it is ideal in such cases. >It happens at all levels. Libraries appeal as application complexity increases. Especially for desktop apps, consideration of application size is increasingly irrelevant. Running a 32 Mb Forth app on a PC with 4Gb (base) of RAM is using less than 1% of RAM for the application. Embedded apps are also much larger than they used to be. Memory constraints don't get any easier. There may be more memory but it's still in demand - especially RAM. I have been banging on about libraries for years. FLAG is a personal project hosted by MPE. http://soton.mpeforth.com/flag/ Successful library repositories need to be supplier-neutral and appeal to modernists as well as us old farts. Gerald's site succeeds in both ways. >To keep it practical how about making it a function of the standards >committe to review and approve a list of packages based for example >on the repeated use and refinement from a single source such as Geralds >library or another if he was unable or unwilling to do that side of things. See http://forth-standard.org/ At the last standard meeting in September, the topic was discussed. Currently libraries are on http://theforth.net but after some evaluation process has been defined and set up, some will emerge on the standard site. Would you like to volunteer to help? 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 | john <anon@example.com> |
|---|---|
| Date | 2016-12-01 09:54 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <MPG.32aa03a522ca602f9896d4@news.virginmedia.com> |
| In reply to | #52987 |
> In article <583ee1a8.1767856775@news.eternal-september.org>, stephen@mpeforth.com says... > > See > http://forth-standard.org/ > > At the last standard meeting in September, the topic was discussed. > Currently libraries are on > http://theforth.net > but after some evaluation process has been defined and set up, some > will emerge on the standard site. > > Would you like to volunteer to help? > > Stephen What I would like is is about another 20 hours in a day. There's only so much 2 men and a dog can do. I'm just suprised all this stuff wasn't done long ago. I've offered space on the web site to contribute what I can but time is the enemy as always. My real interest in forth at the moment is to prototype my OS and processor design but all I need for that is a minimal kernel and it wont look at all like forth very soon after anyway. I think this is something worth doing - especially as Intel have just signalled the beginning of the end of the X86 family... If you get specific issues you need help with by all means poke me with a sharp stick at any time -- that's where I live. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-01 04:42 -0600 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <aOSdnbI9P_jlY6LFnZ2dnUU7-eXNnZ2d@supernews.com> |
| In reply to | #52985 |
john <anon@example.com> wrote: >> In article <VMadnb2EDIODGKPFnZ2dnUU7-KvNnZ2d@supernews.com>, erather@forth.com says... >> >> I suggest that the real reason Forth libraries haven't caught >> on is that it's easier to write the words than to search the internet >> for versions someone else wrote that don't do exactly what you want. > > Trust me Elizabeth - that's not the case. :-) > as an example - If I wanted an FFT I couldn't just sit down and code > it today (some years ago maybe but not these days - hence jim) . I > might still know what an FFT is (or a sobel edge detector or > whatever is) and have a need for it without having the time to > re-acquaint myself fully to recreate one. Wee-eell, yabbut. I've coded FFTs a few times, and they were different. Sure, if you happen to have a fast floating-point unit then you don't have to worry much about scaling and whatnot, and if you can use double precision you probably don't have to worry much about rounding errors. But there's still the matter of whether your data just happens to fit in an array a power of two in length, and whether it's convenient to use DIT or DIF. Sure, if you need something *now* and your CPU is significantly more capable than the problem actually requires, a library routine will suffice. And if your cost is domintated by developer time, then a library routine is indeed optimal. > A proven library or package or whatever you call it is ideal in such > cases. It happens at all levels. Not necessarily ideal: adequate. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-12 13:09 -0400 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <oclmr0$jsp$1@dont-email.me> |
| In reply to | #52985 |
On 11/30/2016 8:41 AM, john wrote: >> In article <VMadnb2EDIODGKPFnZ2dnUU7-KvNnZ2d@supernews.com>, erather@forth.com says... >> >> I suggest that the real reason Forth libraries haven't caught >> on is that it's easier to write the words than to search the internet >> for versions someone else wrote that don't do exactly what you want. >> >> Cheers, >> Elizabeth >> >> -- > > Trust me Elizabeth - that's not the case. > as an example - If I wanted an FFT I couldn't just sit down and code > it today (some years ago maybe but not these days - hence jim) . I might still > know what an FFT is (or a sobel edge detector or whatever is) and have > a need for it without having the time to re-acquaint myself fully to recreate one. > A proven library or package or whatever you call it is ideal in such cases. > It happens at all levels. Signal processing is always a great area for a library. Even using library functions signal processing is complicated and *no one* has time to write the basic signal processing code if they don't have to. The only limiting factor in a signal processing library is that relatively speaking, there would be few users. It's no every day you need signal processing for code you are writing. > To keep it practical how about making it a function of the standards > committe to review and approve a list of packages based for example > on the repeated use and refinement from a single source such as Geralds > library or another if he was unable or unwilling to do that side of things. > > Forth users would be encouraged to use the packages and report back any > issue to the author and when a concensus arises that one is a stable > item that resolves a problem or provides a "product" > the standards comittee marks it as the authorised solution. > > Anyone can then "include" it in applications the same as any C library or > whatever. > > The mechanisms are there without too much work provided there > are enough actual users of forth to drive it. I agree a bit with Hugh in that I've always wondered why there aren't basic array defining words. I ended up with my own library which posters here helped me develop. Writing that was a useful exercise and I learned a few things, but I don't see why that library isn't out there already. I expect apps that don't need arrays are few and far between. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-12 13:14 -0400 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ocln41$kpa$1@dont-email.me> |
| In reply to | #57163 |
On 4/12/2017 1:09 PM, rickman wrote: > On 11/30/2016 8:41 AM, john wrote: >>> In article <VMadnb2EDIODGKPFnZ2dnUU7-KvNnZ2d@supernews.com>, >>> erather@forth.com says... >>> >>> I suggest that the real reason Forth libraries haven't caught >>> on is that it's easier to write the words than to search the internet >>> for versions someone else wrote that don't do exactly what you want. >>> >>> Cheers, >>> Elizabeth >>> >>> -- >> >> Trust me Elizabeth - that's not the case. >> as an example - If I wanted an FFT I couldn't just sit down and code >> it today (some years ago maybe but not these days - hence jim) . I >> might still >> know what an FFT is (or a sobel edge detector or whatever is) and have >> a need for it without having the time to re-acquaint myself fully to >> recreate one. >> A proven library or package or whatever you call it is ideal in such >> cases. >> It happens at all levels. > > Signal processing is always a great area for a library. Even using > library functions signal processing is complicated and *no one* has time > to write the basic signal processing code if they don't have to. The > only limiting factor in a signal processing library is that relatively > speaking, there would be few users. It's no every day you need signal > processing for code you are writing. > > >> To keep it practical how about making it a function of the standards >> committe to review and approve a list of packages based for example >> on the repeated use and refinement from a single source such as Geralds >> library or another if he was unable or unwilling to do that side of >> things. >> >> Forth users would be encouraged to use the packages and report back any >> issue to the author and when a concensus arises that one is a stable >> item that resolves a problem or provides a "product" >> the standards comittee marks it as the authorised solution. >> >> Anyone can then "include" it in applications the same as any C library or >> whatever. >> >> The mechanisms are there without too much work provided there >> are enough actual users of forth to drive it. > > I agree a bit with Hugh in that I've always wondered why there aren't > basic array defining words. I ended up with my own library which > posters here helped me develop. Writing that was a useful exercise and > I learned a few things, but I don't see why that library isn't out there > already. I expect apps that don't need arrays are few and far between. Opps, I see I replied to a rather old post. Sorry. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-12 08:32 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <tr-dnQpDHcpY73PFnZ2dnUU7-UnNnZ2d@supernews.com> |
| In reply to | #57163 |
On 4/12/17 7:09 AM, rickman wrote: > On 11/30/2016 8:41 AM, john wrote: >>> In article <VMadnb2EDIODGKPFnZ2dnUU7-KvNnZ2d@supernews.com>, >>> erather@forth.com says... >>> >>> I suggest that the real reason Forth libraries haven't caught >>> on is that it's easier to write the words than to search the internet >>> for versions someone else wrote that don't do exactly what you want. >>> >>> Cheers, >>> Elizabeth >>> >>> -- >> >> Trust me Elizabeth - that's not the case. >> as an example - If I wanted an FFT I couldn't just sit down and code >> it today (some years ago maybe but not these days - hence jim) . I >> might still >> know what an FFT is (or a sobel edge detector or whatever is) and have >> a need for it without having the time to re-acquaint myself fully to >> recreate one. >> A proven library or package or whatever you call it is ideal in such >> cases. >> It happens at all levels. > > Signal processing is always a great area for a library. Even using > library functions signal processing is complicated and *no one* has time > to write the basic signal processing code if they don't have to. The > only limiting factor in a signal processing library is that relatively > speaking, there would be few users. It's no every day you need signal > processing for code you are writing. Chuck Moore had a math library, consisting of functions that he developed in the course of application writing. It included lots of fixed-point fraction arithmetic and trig and an FFT. In the 70's, he kept it on microfiche. When he had occasion to use one of those functions, he'd type it in, and then completely re-write it because the needs of *this* application were different, or he could think of a better way to factor it, or something. Contrary to popular rumor, I'm a great fan of Forth libraries. FORTH, Inc. has supported math, database, and graphics libraries for many years; polyFORTH included all these. When we developed SwiftForth, however, we found that most of our users preferred to be able to call external code, which was much more extensive, so we made that easy. We do still distribute the Forth math library, although I don't know of any of our customers who are using it. Whenever the complaint about the lack of Forth libraries arises, I encourage people to make and release some. If people put as much effort into public libraries as they do in private Forth implementations that complaint would be largely mitigated. >> To keep it practical how about making it a function of the standards >> committe to review and approve a list of packages based for example >> on the repeated use and refinement from a single source such as Geralds >> library or another if he was unable or unwilling to do that side of >> things. >> >> Forth users would be encouraged to use the packages and report back any >> issue to the author and when a concensus arises that one is a stable >> item that resolves a problem or provides a "product" >> the standards comittee marks it as the authorised solution. >> >> Anyone can then "include" it in applications the same as any C library or >> whatever. >> >> The mechanisms are there without too much work provided there >> are enough actual users of forth to drive it. > > I agree a bit with Hugh in that I've always wondered why there aren't > basic array defining words. I ended up with my own library which > posters here helped me develop. Writing that was a useful exercise and > I learned a few things, but I don't see why that library isn't out there > already. I expect apps that don't need arrays are few and far between. All of the applications that I've worked on needed arrays, but they've all had slightly different properties: size of elements, dimensions, degrees of error checking, etc. One of the standard problem sets in Forth Application Techniques is defining a 2-dimension cell-wise array with basic limit checking. When I used it in my classes, it usually took students in their 3rd day of a 5-day beginning Forth class about half an hour to get it working. Thereafter, it will be a matter of how long it takes to type two or three lines, except that as you gain experience you'll have the arrays you've found useful already in your "back pocket". But if you want to publish the code for the arrays you've found useful, no one is stopping you. Where are they? Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-04-12 12:42 -0700 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <66622702-7c8d-4dd2-b863-58f77ab3ff43@googlegroups.com> |
| In reply to | #57165 |
How does c-libraries works? Are there standard names, parameters, actions? That makes the libraries enough adequate? Or is the explanation that the c-Unix-world is so much larger than the Forth-world and that the most skillfull Forth programmers rather make Forth variants and hardware than libraries? Also, it is very interesting to take someones code and modify it in Forth. The possibilities to make the "perfect thing" is a temptation. Somehow all c-programs looks the same, unlike the case with Forth. https://github.com/Lehs/ANS-Forth-libraries https://forthmath.blogspot.se
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-12 10:36 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ZMmdnYGXfIt2EnPFnZ2dnUU7-b_NnZ2d@supernews.com> |
| In reply to | #57167 |
On 4/12/17 9:42 AM, lehs wrote: > How does c-libraries works? Are there standard names, parameters, actions? That makes the libraries enough adequate? > Or is the explanation that the c-Unix-world is so much larger than the Forth-world and that the most skillfull Forth programmers rather make Forth variants and hardware than libraries? Also, it is very interesting to take someones code and modify it in Forth. The possibilities to make the "perfect thing" is a temptation. Somehow all c-programs looks the same, unlike the case with Forth. > > https://github.com/Lehs/ANS-Forth-libraries > https://forthmath.blogspot.se > From time to time discussions have broken out here about how to formally package libraries, but no consensus is reached and nothing gets done. IMO the important thing is simply for someone to put together a collection of related functions that he/she thinks is useful, one or more files as indicated, and publish it somewhere, making announcements here and elsewhere. It's essential to include documentation for how to use the stuff, as well as notes on any dependencies or non-standard items. Don't argue about it, just do it. If it's well written, well documented and useful in many places, that will be great and maybe more will follow. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-12 16:41 -0400 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ocm37r$1q0$1@dont-email.me> |
| In reply to | #57165 |
On 4/12/2017 2:32 PM, Elizabeth D. Rather wrote: > On 4/12/17 7:09 AM, rickman wrote: >> >> Signal processing is always a great area for a library. Even using >> library functions signal processing is complicated and *no one* has time >> to write the basic signal processing code if they don't have to. The >> only limiting factor in a signal processing library is that relatively >> speaking, there would be few users. It's no every day you need signal >> processing for code you are writing. > > Chuck Moore had a math library, consisting of functions that he > developed in the course of application writing. It included lots of > fixed-point fraction arithmetic and trig and an FFT. In the 70's, he > kept it on microfiche. When he had occasion to use one of those > functions, he'd type it in, and then completely re-write it because the > needs of *this* application were different, or he could think of a > better way to factor it, or something. > > Contrary to popular rumor, I'm a great fan of Forth libraries. FORTH, > Inc. has supported math, database, and graphics libraries for many > years; polyFORTH included all these. When we developed SwiftForth, > however, we found that most of our users preferred to be able to call > external code, which was much more extensive, so we made that easy. We > do still distribute the Forth math library, although I don't know of any > of our customers who are using it. > > Whenever the complaint about the lack of Forth libraries arises, I > encourage people to make and release some. If people put as much effort > into public libraries as they do in private Forth implementations that > complaint would be largely mitigated. I may be in the minority of being interested in using Forth but never having any desire to write my own. I would be happy to work on a Forth library, but Hugh is right about me in that I am not a skilled Forth programmer. I wouldn't even post my few personal libraries because they will be total crap next to what many here write. I prefer to contribute by helping to document Forth that I find useful. I am currently working to document Mecrisp on the TMS430. I would have more interest in documenting Mecrisp on the ARM, but someone is already working on that and isn't interested in combining our work. I may still help with some of the ARM documentation as he prefers the STmicro devices and the ARM units I have are TI launchpads. We'll see. >> I agree a bit with Hugh in that I've always wondered why there aren't >> basic array defining words. I ended up with my own library which >> posters here helped me develop. Writing that was a useful exercise and >> I learned a few things, but I don't see why that library isn't out there >> already. I expect apps that don't need arrays are few and far between. > > All of the applications that I've worked on needed arrays, but they've > all had slightly different properties: size of elements, dimensions, > degrees of error checking, etc. Uh, how many element sizes would there be? 1 character elements, 1 cell elements and then "many". I think the first two groups would be sufficiently useful and general that they wouldn't need rewriting every time you want one. When I wrote my array library I added some minimal run time error checking and then added words with more run time error checking. That's what makes it a library, that it has more than one word to cover different applications. > One of the standard problem sets in > Forth Application Techniques is defining a 2-dimension cell-wise array > with basic limit checking. When I used it in my classes, it usually took > students in their 3rd day of a 5-day beginning Forth class about half an > hour to get it working. Thereafter, it will be a matter of how long it > takes to type two or three lines, except that as you gain experience > you'll have the arrays you've found useful already in your "back > pocket". But if you want to publish the code for the arrays you've found > useful, no one is stopping you. Where are they? What is a library if not a "back pocket"? What exactly is your idea of a "back pocket"? Being some thousands of times more experienced than myself, you likely have the code for arrays stored in your finger muscle memory. I don't. I have to go back to the Forth standard document every time I write a new program because it is often six months or more apart. No muscle memory there. So I find arrays to be very useful as long as they are documented well. Documentation is the big downfall of most open source projects. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-12 13:25 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <4_-dnbv_icXHKnPFnZ2dnUU7-dvNnZ2d@supernews.com> |
| In reply to | #57172 |
On 4/12/17 10:41 AM, rickman wrote: > On 4/12/2017 2:32 PM, Elizabeth D. Rather wrote: >> On 4/12/17 7:09 AM, rickman wrote: >>> >>> Signal processing is always a great area for a library. Even using >>> library functions signal processing is complicated and *no one* has time >>> to write the basic signal processing code if they don't have to. The >>> only limiting factor in a signal processing library is that relatively >>> speaking, there would be few users. It's no every day you need signal >>> processing for code you are writing. >> >> Chuck Moore had a math library, consisting of functions that he >> developed in the course of application writing. It included lots of >> fixed-point fraction arithmetic and trig and an FFT. In the 70's, he >> kept it on microfiche. When he had occasion to use one of those >> functions, he'd type it in, and then completely re-write it because the >> needs of *this* application were different, or he could think of a >> better way to factor it, or something. >> >> Contrary to popular rumor, I'm a great fan of Forth libraries. FORTH, >> Inc. has supported math, database, and graphics libraries for many >> years; polyFORTH included all these. When we developed SwiftForth, >> however, we found that most of our users preferred to be able to call >> external code, which was much more extensive, so we made that easy. We >> do still distribute the Forth math library, although I don't know of any >> of our customers who are using it. >> >> Whenever the complaint about the lack of Forth libraries arises, I >> encourage people to make and release some. If people put as much effort >> into public libraries as they do in private Forth implementations that >> complaint would be largely mitigated. > > I may be in the minority of being interested in using Forth but never > having any desire to write my own. I would be happy to work on a Forth > library, but Hugh is right about me in that I am not a skilled Forth > programmer. I wouldn't even post my few personal libraries because they > will be total crap next to what many here write. > > I prefer to contribute by helping to document Forth that I find useful. > I am currently working to document Mecrisp on the TMS430. I would have > more interest in documenting Mecrisp on the ARM, but someone is already > working on that and isn't interested in combining our work. I may still > help with some of the ARM documentation as he prefers the STmicro > devices and the ARM units I have are TI launchpads. We'll see. That's incredibly helpful! Many too many good programmers are terrible at documenting their code. Helping document code for publication is a great contribution. >>> I agree a bit with Hugh in that I've always wondered why there aren't >>> basic array defining words. I ended up with my own library which >>> posters here helped me develop. Writing that was a useful exercise and >>> I learned a few things, but I don't see why that library isn't out there >>> already. I expect apps that don't need arrays are few and far between. >> >> All of the applications that I've worked on needed arrays, but they've >> all had slightly different properties: size of elements, dimensions, >> degrees of error checking, etc. > > Uh, how many element sizes would there be? 1 character elements, 1 cell > elements and then "many". I think the first two groups would be > sufficiently useful and general that they wouldn't need rewriting every > time you want one. Single byte, [n]-byte strings, cells, double cells, floats of various sizes, etc. Some specialized arrays exist in hardware, such as rows on an imaging device. > When I wrote my array library I added some minimal run time error > checking and then added words with more run time error checking. That's > what makes it a library, that it has more than one word to cover > different applications. The amount of error checking needed also depends on the application. If an array is used in very well-defined circumstances such that it can never be accessed inappropriately (e.g., there is strong error checking higher up in the program) than error checking can be omitted from the array code, for improved performance. There's a virtually unlimited set of options. Of course, as you write more applications you add to your repertoire of arrays for different purposes >> One of the standard problem sets in >> Forth Application Techniques is defining a 2-dimension cell-wise array >> with basic limit checking. When I used it in my classes, it usually took >> students in their 3rd day of a 5-day beginning Forth class about half an >> hour to get it working. Thereafter, it will be a matter of how long it >> takes to type two or three lines, except that as you gain experience >> you'll have the arrays you've found useful already in your "back >> pocket". But if you want to publish the code for the arrays you've found >> useful, no one is stopping you. Where are they? > > What is a library if not a "back pocket"? What exactly is your idea of > a "back pocket"? Being some thousands of times more experienced than > myself, you likely have the code for arrays stored in your finger muscle > memory. I don't. I have to go back to the Forth standard document > every time I write a new program because it is often six months or more > apart. No muscle memory there. So I find arrays to be very useful as > long as they are documented well. Documentation is the big downfall of > most open source projects. Exactly, a library *is* a "back pocket" from which you can select the code most appropriate to the application you're working on. As you gain more experience, your back pocket grows. And there's always the option of publishing it somewhere for others. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-12 14:13 -0700 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <1531dfb2-9bdc-4608-88c1-7825ba659fdb@googlegroups.com> |
| In reply to | #57165 |
On Wednesday, April 12, 2017 at 11:32:43 AM UTC-7, Elizabeth D. Rather wrote:
> Chuck Moore had a math library, consisting of functions that he
> developed in the course of application writing. It included lots of
> fixed-point fraction arithmetic and trig and an FFT. In the 70's, he
> kept it on microfiche. When he had occasion to use one of those
> functions, he'd type it in, and then completely re-write it because the
> needs of *this* application were different, or he could think of a
> better way to factor it, or something.
>
> Contrary to popular rumor, I'm a great fan of Forth libraries. FORTH,
> Inc. has supported math, database, and graphics libraries for many
> years; polyFORTH included all these. When we developed SwiftForth,
> however, we found that most of our users preferred to be able to call
> external code, which was much more extensive, so we made that easy. We
> do still distribute the Forth math library, although I don't know of any
> of our customers who are using it.
This thread was my first contact with you. This was at a time when I was very new to comp.lang.forth:
https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D
On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> ...
> > The problem is the ANS-Forth standard. Really, how obvious was the
> > need for double-precision arithmetic? This could have been an
> > extension to the language similar to floating-point. Compiler-writers
> > working on small microprocessors could decline to implement it if they
> > didn't want to.
> >
> > I am frustrated with the ANS-Forth standard because I believe that the
> > bad design of the standard is the #1 reason for the failure of Forth
> > to become an important language. Forth was doing pretty well in the
> > 1980s, but we needed a standard. What we got was Forth-83, and then
> > ANS-Forth-94, both of which were badly designed. With some more
> > thoughtful leadership we could have succeeded.
>
> There are D+, D-, M*, M/, and M*/ (and the unsigned operators). These
> were adequate in a very wide variety of projects over a 30 year period,
> many of which were extremely computation-intensive and running on slow
> 16-bit processors.
>
> Forth's design is pragmatic: it has functions that have been needed and
> that have proven their usefulness *in Forth*, not necessarily those that
> have been required in other languages. Generally speaking, Forth has
> the most flexible set of *integer* arithmetic operators of any language.
> In particular, M*/ was one of Chuck's most brilliant innovations. I'm
> sure if Chuck were trying to do your continued fractions that is what he
> would rely on. Yes, that sometimes requires thinking differently, like
> many other things in Forth.
>
> Cheers,
> Elizabeth
My interpretation of this post is that you are saying that I am not a Forth programmer, and I never can be a Forth programmer, because this "requires thinking differently." Differently from what? Reality? I obviously am not capable of thinking differently from reality, so I can't be a Forth programmer!
Shortly afterward, John Passaniti began hinting heavily that he was homosexual. I had not had much contact with him previously, except to note that he was a troll who spent all of his time calling people stupid. I was not aware that he was a homosexual, and I wasn't clear if I was interpreting his hints correctly, so I just asked if that was what he was trying to tell us.
It was a trap! Your trick for driving Forth programmers away is the old liberal trick of presuming the moral high-ground:
On Sunday, November 22, 2009 at 10:21:35 PM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> ...
> > BTW, you said that your "partner" is "Phillip." Are you trying to tell
> > us that you're a faggot?
>
> That is an extremely offensive remark that has no place in this
> newsgroup. You owe all of us an apology.
>
> Elizabeth
On Monday, November 23, 2009 at 4:00:59 AM UTC-7, Stephen Pelc wrote:
> On Sun, 22 Nov 2009 20:23:23 -0800 (PST), Hugh Aguilar
> <hugoaguilar@rosycrew.com> wrote:
>
> >Are you trying to tell us that you're a faggot?
>
> My tolerance level has been exceeded. Please apologise and/or
> go away.
>
> Stephen
You don't actually care about homosexuality and bestiality and all that other stuff. You and Stephen Pelc are mad because I said that D/ was needed in ANS-Forth, so you are using the homosexuality issue as a club to beat me over the head and drive me away.
You and Stephen Pelc are telling me that I'm not a Forth programmer and never can be. If I have to start out at the sub-faggot level, how many years of study will be required for me to progress to the faggot level? How many decades of study will be required for me to progress to the novice level? How many centuries of study will be required for me to progress to your exulted level? Obviously, if I have to start out at the sub-faggot level then I can never become a Forth programmer.
Now John Passaniti is gone, but you have Julien Fondren instead. Julien Fondren routinely makes death threats against people who program in Forth. Where is your "tolerance level" now? The silence from you and Stephen Pelc is deafening! You tolerate Julien Fondren, and encourage him, because he is driving Forth programmers away. You are afraid of Forth programmers because you consider Forth programmers to be competition for Forth Inc. and MPE, so you want to drive Forth programmers away. You want to only have sycophants. You want Rickman to call me "insane" and you want Alex McDonald to say that I have a "serious misunderstanding of how pointers work" --- they aren't a threat to you because they are dumb as a box of hammers and incapable of writing Forth code --- they are not competing against Forth Inc. and MPE, but they are just brown-nosing which is what you want.
> Whenever the complaint about the lack of Forth libraries arises, I
> encourage people to make and release some. If people put as much effort
> into public libraries as they do in private Forth implementations that
> complaint would be largely mitigated.
This is what you said about my novice-package:
---------------------------------------------------------------------------
Does "*every* application" you write use exactly the same kind of data
arranged in the same way? If so, having written it once you can
reuse it often. If not, you either have to rearrange your data to make it
work or modify your "general-purpose" structure.
---------------------------------------------------------------------------
Here is a more recent remark:
https://groups.google.com/forum/#!topic/comp.lang.forth/N5B1AbXqPfQ%5B26-50%5D
On Monday, April 3, 2017 at 1:06:30 AM UTC-7, Elizabeth D. Rather wrote:
> On 4/2/17 6:58 AM, rickman wrote:
> > Hugh may seem at times as mad as a hatter, but he *is* very
> > knowledgeable in Forth. He has written a "novice" package which would
> > be good material for you to go through after you have finished your
> > books. You may not want to use every feature in his library, but from
> > what he says it seems like it shows many useful features and can show
> > you how real code is written, not just teaching examples. Just a thought.
>
> From what I've seen of it, it seems to be attempting to generalize
> imaginary application requirements, none of which have been relevant in
> any of the applications I've worked on in the last 40 years.
You are so slow on the uptake that you didn't realize that Rickman was just being sarcastic. You thought he was serious, and that you needed to refute him and speak out against the novice package.
> > I agree a bit with Hugh in that I've always wondered why there aren't
> > basic array defining words. I ended up with my own library which
> > posters here helped me develop. Writing that was a useful exercise and
> > I learned a few things, but I don't see why that library isn't out there
> > already. I expect apps that don't need arrays are few and far between.
>
> All of the applications that I've worked on needed arrays, but they've
> all had slightly different properties: size of elements, dimensions,
> degrees of error checking, etc. One of the standard problem sets in
> Forth Application Techniques is defining a 2-dimension cell-wise array
> with basic limit checking. When I used it in my classes, it usually took
> students in their 3rd day of a 5-day beginning Forth class about half an
> hour to get it working. Thereafter, it will be a matter of how long it
> takes to type two or three lines, except that as you gain experience
> you'll have the arrays you've found useful already in your "back
> pocket".
What you are describing here is cut-and-paste programming. You don't know what a general-purpose data-structure is. You think that it is necessary to rewrite your array definer when the size of the elements is different, or the number of dimensions is different, etc.. This is not true. This is, actually, stupid.
> But if you want to publish the code for the arrays you've found
> useful, no one is stopping you. Where are they?
I've had arrays in the novice-package since 2010:
--------------------------------------------------------------------------
\ ******
\ ****** These are an alternate definition of arrays using Iliffe arrays (http://en.wikipedia.org/wiki/Iliffe_vector).
\ ****** This code was originally written by Andrew Haley using CREATE DOES> and was limited to word elements.
\ ****** I upgraded the code to allow for user-specified element sizes.
\ ******
: [] ( adr index - element-adr ) \ not a MACRO: because it might be used interactively
cells + ;
: -> ( adr index -- element ) \ not a MACRO: because it might be used interactively
[] @ ;
: ,rows ( size 0 dims... -- size 0 dims... ) \ size is the size of the element; all elements get zero'd out
here locals| array dim | \ ARRAY is the adr and DIM is the largest dimension
dup if w else over then \ -- element-size \ all but the last level are pointers (size W)
dim * allot
dup if
dim 0 do here array I [] ! dup >r recurse r> loop
then ;
\ Any alignment to the dictionary pointer should be done *before* ,ROWS is called.
\ This is in <ARY> prior to the DIMENSIONS.
\ This isn't necessary in ,ROWS prior to the RECURSE because we have only been compiling words.
\ Don't align the HERE at the beginning of ,ROWS as this has to be the same HERE that was obtained prior to calling ,ROWS.
: dimensions ( size 0 dims... size ) \ size is the size of the element
,rows
begin 0= until ; \ discard the dimensions and the zero terminator
: <ary> ( size 0 dims... name -- )
>r
non-zeros >r r@ 0 = abort" *** ARY needs some dimensions ***"
align here >r dimensions >r
r> r> r> r> { siz adr cnt name -- }
name get-current :name \ runtime: indices... -- element-adr
adr lit,
cnt 1 ?do swap, postpone -> loop
swap, siz lit*, +, ;,
c" <" name get-current :2name \ runtime: -- base-adr
adr lit, ;,
name c" >" get-current :2name \ runtime: adr index -- element-adr
siz lit*, +, ;,
;
: ary ( size 0 dims... -- )
bl word hstr dup >r <ary> r> dealloc ;
\ You can define a two-dimensional array of words in either of these ways:
\ W 0 3 5 C" TEST" <ARY>
\ W 0 3 5 ARY TEST
\ Assuming that I and J are indexes, an element can be accessed like this:
\ I J TEST \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the same order as the dimensions were.
\ It is also possible to access the element like this:
\ <TEST J -> I TEST> \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the opposite order as the dimensions were.
\ The [] only works for word-sized elements.
\ You should always use the xxx> word (even for words) because it takes into account the size of the element.
\ Arrays of dimensions other than two are defined the same --- you can have as many dimensions as you want.
\ <ARY> figures out how many dimensions there are by looking for the 0 under the non-zero dimensions.
\ This is a classic example of the problem with CREATE DOES> words being limited to *one* action per data type.
\ The CREATE DOES> version of the Iliff vectors relied on [] for resolving the final level, which had to be word elements.
\ There is no way to do this with CREATE DOES> because you can't have a type-specific version of [] (such as my xxx> word).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-12 17:45 -0400 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ocm6vo$ekr$1@dont-email.me> |
| In reply to | #57178 |
On 4/12/2017 5:13 PM, hughaguilar96@gmail.com wrote: > > This thread was my first contact with you. This was at a time when I > was very new to comp.lang.forth: > https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D > > On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D > Rather wrote: >> Hugh Aguilar wrote: ... >>> The problem is the ANS-Forth standard. Really, how obvious was >>> the need for double-precision arithmetic? This could have been >>> an extension to the language similar to floating-point. >>> Compiler-writers working on small microprocessors could decline >>> to implement it if they didn't want to. >>> >>> I am frustrated with the ANS-Forth standard because I believe >>> that the bad design of the standard is the #1 reason for the >>> failure of Forth to become an important language. Forth was doing >>> pretty well in the 1980s, but we needed a standard. What we got >>> was Forth-83, and then ANS-Forth-94, both of which were badly >>> designed. With some more thoughtful leadership we could have >>> succeeded. >> >> There are D+, D-, M*, M/, and M*/ (and the unsigned operators). >> These were adequate in a very wide variety of projects over a 30 >> year period, many of which were extremely computation-intensive and >> running on slow 16-bit processors. >> >> Forth's design is pragmatic: it has functions that have been needed >> and that have proven their usefulness *in Forth*, not necessarily >> those that have been required in other languages. Generally >> speaking, Forth has the most flexible set of *integer* arithmetic >> operators of any language. In particular, M*/ was one of Chuck's >> most brilliant innovations. I'm sure if Chuck were trying to do >> your continued fractions that is what he would rely on. Yes, that >> sometimes requires thinking differently, like many other things in >> Forth. >> >> Cheers, Elizabeth > > My interpretation of this post is that you are saying that I am not a > Forth programmer, and I never can be a Forth programmer, because this > "requires thinking differently." I think this supports an open and shut case regarding Hugh's level of paranoia. Nowhere in her post does she say anything about Hugh's competency as a Forth programmer. > Shortly afterward, John Passaniti began hinting heavily that he was > homosexual. I had not had much contact with him previously, except to > note that he was a troll who spent all of his time calling people > stupid. I was not aware that he was a homosexual, and I wasn't clear > if I was interpreting his hints correctly, so I just asked if that > was what he was trying to tell us. OMG! Hugh calling someone a troll because they say someone is "stupid" is so kettle and pot! > It was a trap! Your trick for driving Forth programmers away is the > old liberal trick of presuming the moral high-ground: I'm just going to snip all the lunatic ravings. I guess Hugh is having a bad day or is out of his meds or something. The full moon was a couple of days ago I believe, maybe that is still having an effect. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web