Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49278 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2016-07-21 07:09 -0700 |
| Last post | 2016-07-28 05:33 -0700 |
| Articles | 20 on this page of 169 — 25 participants |
Back to article view | Back to comp.lang.forth
Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 07:09 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-21 07:21 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 14:58 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 11:23 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 12:42 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 12:40 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:07 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:32 -0500
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-21 17:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:50 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:53 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:58 +0300
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:54 +0300
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:48 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 00:19 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 02:33 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 10:45 +0300
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 19:41 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:52 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:22 -0400
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 10:49 -0500
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:16 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:11 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:32 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:58 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-21 17:02 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 17:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:11 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 15:57 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-22 13:25 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 20:24 -0700
Re: Dictionary separated from code ... PROS and CONs stephen@mpeforth.com (Stephen Pelc) - 2016-07-22 11:32 +0000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 12:49 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 23:10 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:36 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:58 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 21:56 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:38 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 10:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 14:18 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:55 -1000
Re: Dictionary separated from code ... PROS and CONs "WJ" <w_a_x_man@yahoo.com> - 2016-07-25 11:34 +0000
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:36 -0400
Re: Dictionary separated from code ... PROS and CONs Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-22 11:15 +0200
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:37 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:56 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-24 13:16 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 12:58 -0700
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-25 18:09 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 22:34 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-27 23:08 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 08:58 -1000
CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 09:17 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 00:19 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 14:54 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-07-28 10:00 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 21:47 +1000
Re: CREATE...DOES> etc. and flash Coos Haak <chforth@hccnet.nl> - 2016-07-29 15:04 +0200
Re: CREATE...DOES> etc. and flash "HAA" <someone@microsoft.com> - 2016-07-30 18:42 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 15:05 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 02:21 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-31 13:05 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 21:24 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-31 19:07 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:24 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:14 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-02 10:45 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 06:59 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 00:34 -0700
Re: CREATE...DOES> etc. and flash Coos Haak <htrofhc@gmail.com> - 2016-08-02 13:57 +0200
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 06:19 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 15:28 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:34 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 07:32 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-03 11:51 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 08:21 +0000
Re: CREATE...DOES> etc. and flash stephen@mpeforth.com (Stephen Pelc) - 2016-08-04 13:18 +0000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 14:02 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 12:26 -0500
Re: CREATE...DOES> etc. and flash Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:24 -0700
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 07:36 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:14 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:17 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-06 13:35 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:20 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:43 -0500
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 09:19 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 05:15 +0000
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 21:50 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 08:24 +0000
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 10:08 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 15:06 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-30 06:22 +0000
Re: CREATE...DOES> etc. and flash Paul Rubin <no.email@nospam.invalid> - 2016-07-30 01:07 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 01:30 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-30 10:17 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 00:51 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 05:20 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 13:06 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 08:13 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 14:08 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 15:24 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 20:12 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 17:36 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 21:54 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:03 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:00 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:19 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 20:40 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-23 22:23 +1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:48 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 16:04 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 19:31 -0400
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 17:20 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 17:54 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 21:27 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 19:18 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 22:25 -0400
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-24 20:39 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:32 -0700
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:30 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 21:36 -1000
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:46 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-25 09:19 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:35 -0400
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:32 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 17:48 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:09 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:43 -0400
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-23 06:58 +0000
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-23 04:02 -0500
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-23 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-23 10:48 -0700
Re: Dictionary separated from code ... PROS and CONs humptydumpty <ouatubi@gmail.com> - 2016-07-23 10:53 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-23 11:24 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-24 03:33 -0500
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 08:16 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:28 -0500
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 11:59 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 07:36 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 10:44 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 11:36 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 11:53 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 12:47 -0700
Re: Dictionary separated from code ... PROS and CONs foxaudioresearch@gmail.com - 2016-07-27 13:27 -0700
Re: Dictionary separated from code ... PROS and CONs all2001@spambog.com (Wolfgang Allinger) - 2016-07-27 18:20 -0300
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-27 19:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 19:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-28 00:44 -0400
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 16:14 -0500
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 18:38 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 16:03 -0400
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:09 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:13 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 15:25 +0000
Re: Dictionary separated from code ... PROS and CONs Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:53 -0700
Re: Dictionary separated from code ... PROS and CONs JennyB <jennybrien@googlemail.com> - 2016-07-27 09:44 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 13:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:36 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 12:43 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:53 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:32 -0500
Re: Dictionary separated from code ... PROS and CONs Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-07-23 14:47 +0200
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 12:24 -1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 19:47 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-28 05:33 -0700
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-07-24 20:39 -0700 |
| Message-ID | <d2fd0957-674f-47b8-8478-49d7158e7889@googlegroups.com> |
| In reply to | #49420 |
Hugh, Yes, perhaps other posts are not perfectly on topic, but at least they are not personal attacks. That is where I draw the line. Your rants against Elizabeth seem to be in every thread where Elizabeth posts, and they are very personal and hateful. They inject an element of toxicity into the thread, and I will call it out when it happens in my threads. And if you think I'm a sycophant, then you clearly don't know what a sycophant is. One can be polite and courteous without being a sycophant.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-24 23:32 -0700 |
| Message-ID | <7e595094-99d4-40dd-a754-e3d6abb10f3c@googlegroups.com> |
| In reply to | #49427 |
On Sunday, July 24, 2016 at 8:39:30 PM UTC-7, Chris Curl wrote: > Hugh, > > Yes, perhaps other posts are not perfectly on topic, but at least they are > not personal attacks. That is where I draw the line. > > Your rants against Elizabeth seem to be in every thread where Elizabeth posts, > and they are very personal and hateful. They inject an element of toxicity > into the thread, and I will call it out when it happens in my threads. > > And if you think I'm a sycophant, then you clearly don't know what a > sycophant is. One can be polite and courteous without being a sycophant. If Elizabeth Rather just stuck to selling SwiftForth, then I would be polite and courteous to her. The world is full of sales-people selling low-quality products which they claim is high-quality --- I don't argue with them or point out the flaws in their product --- I just ignore them. When Elizabeth Rather declares that she alone decides what Forth is, I consider that to be a personal attack on me --- why should I be polite and courteous when insulted in such a way? --- I'm going to continue to point out the problems with SwiftForth and ANS-Forth (which are essentially the same thing). If you allow Elizabeth Rather to declare herself to be your "leading expert" and tell you that she alone (not you) has a right to define what Forth is, then you are being a sycophant. I guarantee you that if you come out with a Forth system that does not have all of SwiftForth's bugs, Elizabeth Rather will dismiss your Forth system as being non-standard --- you hope that by being "polite and courteous" to her, you can induce her to be nice to you and say that your Forth system is Forth --- you are deluding yourself; she will say that it is non-standard, and hence not Forth at all (then you'll be the victim of a "personal attack" but it will be too late to complain because you have already supported her in saying that I'm not a Forth programmer). From Elizabeth Rather's point of view, the whole point of having a Standard is so she can tell the competition that they are non-standard. You and your Forth are the competition. What part of this is not obvious???
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-25 00:30 -0700 |
| Message-ID | <e64fc06f-f726-49f4-a105-a7fc06a9e7b5@googlegroups.com> |
| In reply to | #49447 |
On Monday, July 25, 2016 at 1:32:33 AM UTC-5, hughag...@gmail.com wrote: > When Elizabeth Rather declares that she alone decides what Forth is, I consider that to be a personal attack on me The standard is ignored by everybody. ... but the standard's faults are a big problem for Forth ... and it would be devastating for a system to be determined to not be standard. #JustHughThings Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth (would "be polite and courteous" to her) if only she hadn't declared, in some feverish delusion of Hugh's, to be the sole arbiter of Forth. Well, that's water under the bridge. Even if she apologized, somehow, for what the delusion said, probably the delusion would just go on to say more things to justify renewed attacks on her. BTW, Hugh, I don't particularly dislike you. A solid 15% of what you say is worth reading. When I said that you were insane, I only meant that you were insane. I don't use labels only to communicate "bad dog!" or "good dog!", the way leftists use them. These days I'm only annoyed when someone takes your rantings seriously -- and mostly at that person. Like, read the air of the room better. The worst is when such people ask Elizabeth to engage you to resolve the 'dispute'. I say this because you seemed to have been a bit confused by my last on post on this matter. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-24 21:36 -1000 |
| Message-ID | <iJadnUw8EZMdXAjKnZ2dnUU7-UnNnZ2d@supernews.com> |
| In reply to | #49450 |
On 7/24/16 9:30 PM, Julian Fondren wrote: > Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth > (would "be polite and courteous" to her) if only she hadn't > declared, in some feverish delusion of Hugh's, to be the sole > arbiter of Forth. Which, exactly, feverish delusion of Hugh's was that, Julian? There have been so many. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-25 00:46 -0700 |
| Message-ID | <0716fa3d-a460-4858-ac28-0c504c1483f5@googlegroups.com> |
| In reply to | #49451 |
On Monday, July 25, 2016 at 2:36:38 AM UTC-5, Elizabeth D. Rather wrote: > On 7/24/16 9:30 PM, Julian Fondren wrote: > > > Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth > > (would "be polite and courteous" to her) if only she hadn't > > declared, in some feverish delusion of Hugh's, to be the sole > > arbiter of Forth. > > Which, exactly, feverish delusion of Hugh's was that, Julian? There have > been so many. According to pattern, Hugh will link to a thread, or even directly quote from the thread, and then declare victory. There's no actual need for the thread or his quote to support his claims. He'll just say that it does :p > Cheers, > Elizabeth > > -- > ================================================== > Elizabeth D. Rather (US & Canada) 800-55-FORTH > FORTH Inc. +1 310.999.6784 > 5959 West Century Blvd. Suite 700 > Los Angeles, CA 90045 > http://www.forth.com > > "Forth-based products and Services for real-time > applications since 1973." > ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-25 09:19 -0700 |
| Message-ID | <5ee4116f-a349-4b63-bb50-48d8a21651d1@googlegroups.com> |
| In reply to | #49452 |
On Monday, July 25, 2016 at 12:46:18 AM UTC-7, Julian Fondren wrote:
> On Monday, July 25, 2016 at 2:36:38 AM UTC-5, Elizabeth D. Rather wrote:
> > On 7/24/16 9:30 PM, Julian Fondren wrote:
> >
> > > Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth
> > > (would "be polite and courteous" to her) if only she hadn't
> > > declared, in some feverish delusion of Hugh's, to be the sole
> > > arbiter of Forth.
> >
> > Which, exactly, feverish delusion of Hugh's was that, Julian? There have
> > been so many.
>
> According to pattern, Hugh will link to a thread, or even directly
> quote from the thread, and then declare victory. There's no actual
> need for the thread or his quote to support his claims. He'll just
> say that it does :p
Consider this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B76-100%5D
I'll quote directly from the thread:
On Sunday, July 10, 2016 at 9:23:44 PM UTC-7, hughag...@gmail.com wrote:
> As usual, SwiftForth code is grossly over-complicated. I figured it out though. Just as a joke, here is code for both VFX (slightly upgraded to be more efficient) and SwiftForth (not totally trivial, but reasonably easy to write):
>
> \ in the stack-picture comments, R is a continuation (a vector to a quotation)
>
> VFX? SwiftForth? or [if]
>
> \ My code ( VFX or SwiftForth only) requires that the HOF does have local variables.
>
> : rexit ( -- ) rdrop ;
> : (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
> : r[ ( -- r ) postpone (r:) postpone ahead ; immediate
> : ]r ( -- ) postpone rexit postpone then ; immediate
>
> VFX? [if]
>
> code rex ( r -- ) \ HumptyDumpty called this RCALL
> push edi \ this is the HOF's LF which won't be used by the quotation
> mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
> mov eax, ebx
> mov ebx, 0 [ebp] lea ebp, w [ebp]
> call eax
> pop edi \ restore HOF's LF
> next, end-code
>
> [then]
>
> SwiftForth? [if]
>
> 156 constant lf-offset \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)
>
> code rex ( r -- ) \ HumptyDumpty called this RCALL
> lf-offset [esi] edx mov
> edx push \ this is the HOF's LF which won't be used by the quotation
> -4 [edx] eax mov \ this is the old ESP
> 0 [eax] eax mov \ this is the parent's LF which will be used by the quotation
> eax lf-offset [esi] mov
> ebx eax mov [drop]
> eax call
> lf-offset [esi] pop \ restore HOF's LF
> ret end-code
>
> [then]
>
> [else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX
>
> : rexit ( -- ) RDROP ;
> : (r:) ( -- r ) R@ 0 ;
> : r[ ( -- r ) postpone (r:) postpone IF ; immediate
> : ]r ( -- ) postpone REXIT postpone THEN ; immediate
> : rex ( r -- ) >R -1 ; \ HumptyDumpty called this RCALL
>
> \ HumptyDumpty's code requires that the HOF does not have local variables.
>
> [then]
>
> \ char & comment \ this only works for my code (VFX or SwiftForth)
>
> : test-hof { r | y -- }
> 9 to y
> cr ." enter TEST-HOF " y . \ should be 9
> 3 0 do r rex loop
> cr ." leave TEST-HOF " y . \ should be 9
> ;
>
> : test { | x -- }
> 10 to x
> cr ." before: " x . \ should be 10
> r[ 1 +to x ]r test-hof
> cr ." after: " x . \ should be 13
> ;
>
> &
I declare victory in this thread!
The quotations RfD was supposed to be a slam-dunk from a ladder. The code for the Paysan-faked quotations was written by Bernd Paysan (Forth-200x committee member). The RfD was taken word-for-word from an article written by Stephen Pelc (Forth-200x committee member) and endorsed by Anton Ertl (Forth-200x committee chair-person). The RfD was pre-approved by Leon Wagner (boss of the Forth-200x committee). Alex McDonald put his name on the RfD to fake-up a grass-roots aspect to the RfD so it wouldn't appear to have come straight from the Forth-200x committee, but would instead appear to have come from the Forth community. All in all, a slam-dunk from a ladder!
Now the RfD has pretty much died. Over on the Forth-200x mailing list, nobody wants to discuss the RfD anymore. The last post in the mailing-list thread is dated July 7, which is quite some time ago. This is the last post (from Jennifer Brien):
----------------------------------------------------------------------------
On Thu, Jul 7, 2016 at 3:48 PM, Hans Bezemer hansoft@xs4all.nl [forth200x] <forth200x@yahoogroups.com> wrote:
I don't like to write dirty stuff just to please quiche eaters, so IMHO this
one is far more controversial that the "keep access to outer variables". For
what? It has already executed. The thing is dead!
I think we are all agreed on that. I asked because I didn't see any great need for what Hugh was demanding, I still don't, and I can see trying to provide it might result in a lot of gotchas. I'm quite content with what he is pleased to call "Paysan faked quotations."
As far as locals and quotations are concerned, I think it is much more important that they can be passed as parameters to structure-walking words like map-array and traverse-wordlist.
----------------------------------------------------------------------------
The reason why nobody wants to respond, is that what she says is clearly untrue. She is saying that my rquotations can't be passed as parameters to "structure-walking words" (her term for higher-order-functions, commonly called HOFs). This is a pretty disingenuous argument --- roughly comparable to Alex McDonald saying that I have a "serious misunderstanding of how pointers work" or that I "really don't know how CREATE DOES> works" --- just typical Forth-200x insults (Forth-200x is a house founded upon sand, and for mortar they use bullshit).
So, I feel comfortable in declaring victory against the Forth-200x committee in regard to quotations. If anybody disagrees, then they need to get on the Forth-200x mailing list and go back to praising the RfD for the Paysan-faked quotations that Jennifer Brien is "quite content" with. Do it Forth-200x supporters! This is the only way you can declare victory for yourselves! The Forth-200x mailing-list is a "Hugh-free zone" (Jennifer Brien's term) so there is no way for me to stop you from declaring victory --- all that is needed is for you to is to get off your fat asses and declare victory --- but you haven't done so yet, and instead you have let the RfD wither and die (that RfD is almost a year old now, and it has yet to be turned into a CfV and ratified unanimously despite being pre-approved by Leon Wagner).
P.S. I actually do like to eat quiche. I remember way back in Santa Barbara going to parties and the women would bring quiche for the pot-luck. Awesome! Who doesn't like quiche?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-25 12:35 -0400 |
| Message-ID | <nn5f4e$ql$2@dont-email.me> |
| In reply to | #49481 |
On 7/25/2016 12:19 PM, hughaguilar96@gmail.com wrote:
> On Monday, July 25, 2016 at 12:46:18 AM UTC-7, Julian Fondren wrote:
>> On Monday, July 25, 2016 at 2:36:38 AM UTC-5, Elizabeth D. Rather wrote:
>>> On 7/24/16 9:30 PM, Julian Fondren wrote:
>>>
>>>> Bonus: Hugh would avoid his shockingly venomous attacks on Elizabeth
>>>> (would "be polite and courteous" to her) if only she hadn't
>>>> declared, in some feverish delusion of Hugh's, to be the sole
>>>> arbiter of Forth.
>>>
>>> Which, exactly, feverish delusion of Hugh's was that, Julian? There have
>>> been so many.
>>
>> According to pattern, Hugh will link to a thread, or even directly
>> quote from the thread, and then declare victory. There's no actual
>> need for the thread or his quote to support his claims. He'll just
>> say that it does :p
>
> Consider this thread:
> https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B76-100%5D
>
> I'll quote directly from the thread:
>
> On Sunday, July 10, 2016 at 9:23:44 PM UTC-7, hughag...@gmail.com wrote:
>> As usual, SwiftForth code is grossly over-complicated. I figured it out though. Just as a joke, here is code for both VFX (slightly upgraded to be more efficient) and SwiftForth (not totally trivial, but reasonably easy to write):
>>
>> \ in the stack-picture comments, R is a continuation (a vector to a quotation)
>>
>> VFX? SwiftForth? or [if]
>>
>> \ My code ( VFX or SwiftForth only) requires that the HOF does have local variables.
>>
>> : rexit ( -- ) rdrop ;
>> : (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
>> : r[ ( -- r ) postpone (r:) postpone ahead ; immediate
>> : ]r ( -- ) postpone rexit postpone then ; immediate
>>
>> VFX? [if]
>>
>> code rex ( r -- ) \ HumptyDumpty called this RCALL
>> push edi \ this is the HOF's LF which won't be used by the quotation
>> mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
>> mov eax, ebx
>> mov ebx, 0 [ebp] lea ebp, w [ebp]
>> call eax
>> pop edi \ restore HOF's LF
>> next, end-code
>>
>> [then]
>>
>> SwiftForth? [if]
>>
>> 156 constant lf-offset \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)
>>
>> code rex ( r -- ) \ HumptyDumpty called this RCALL
>> lf-offset [esi] edx mov
>> edx push \ this is the HOF's LF which won't be used by the quotation
>> -4 [edx] eax mov \ this is the old ESP
>> 0 [eax] eax mov \ this is the parent's LF which will be used by the quotation
>> eax lf-offset [esi] mov
>> ebx eax mov [drop]
>> eax call
>> lf-offset [esi] pop \ restore HOF's LF
>> ret end-code
>>
>> [then]
>>
>> [else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX
>>
>> : rexit ( -- ) RDROP ;
>> : (r:) ( -- r ) R@ 0 ;
>> : r[ ( -- r ) postpone (r:) postpone IF ; immediate
>> : ]r ( -- ) postpone REXIT postpone THEN ; immediate
>> : rex ( r -- ) >R -1 ; \ HumptyDumpty called this RCALL
>>
>> \ HumptyDumpty's code requires that the HOF does not have local variables.
>>
>> [then]
>>
>> \ char & comment \ this only works for my code (VFX or SwiftForth)
>>
>> : test-hof { r | y -- }
>> 9 to y
>> cr ." enter TEST-HOF " y . \ should be 9
>> 3 0 do r rex loop
>> cr ." leave TEST-HOF " y . \ should be 9
>> ;
>>
>> : test { | x -- }
>> 10 to x
>> cr ." before: " x . \ should be 10
>> r[ 1 +to x ]r test-hof
>> cr ." after: " x . \ should be 13
>> ;
>>
>> &
>
> I declare victory in this thread!
>
> The quotations RfD was supposed to be a slam-dunk from a ladder. The code for the Paysan-faked quotations was written by Bernd Paysan (Forth-200x committee member). The RfD was taken word-for-word from an article written by Stephen Pelc (Forth-200x committee member) and endorsed by Anton Ertl (Forth-200x committee chair-person). The RfD was pre-approved by Leon Wagner (boss of the Forth-200x committee). Alex McDonald put his name on the RfD to fake-up a grass-roots aspect to the RfD so it wouldn't appear to have come straight from the Forth-200x committee, but would instead appear to have come from the Forth community. All in all, a slam-dunk from a ladder!
>
> Now the RfD has pretty much died. Over on the Forth-200x mailing list, nobody wants to discuss the RfD anymore. The last post in the mailing-list thread is dated July 7, which is quite some time ago. This is the last post (from Jennifer Brien):
> ----------------------------------------------------------------------------
> On Thu, Jul 7, 2016 at 3:48 PM, Hans Bezemer hansoft@xs4all.nl [forth200x] <forth200x@yahoogroups.com> wrote:
>
> I don't like to write dirty stuff just to please quiche eaters, so IMHO this
> one is far more controversial that the "keep access to outer variables". For
> what? It has already executed. The thing is dead!
>
>
> I think we are all agreed on that. I asked because I didn't see any great need for what Hugh was demanding, I still don't, and I can see trying to provide it might result in a lot of gotchas. I'm quite content with what he is pleased to call "Paysan faked quotations."
>
> As far as locals and quotations are concerned, I think it is much more important that they can be passed as parameters to structure-walking words like map-array and traverse-wordlist.
> ----------------------------------------------------------------------------
>
> The reason why nobody wants to respond, is that what she says is clearly untrue. She is saying that my rquotations can't be passed as parameters to "structure-walking words" (her term for higher-order-functions, commonly called HOFs). This is a pretty disingenuous argument --- roughly comparable to Alex McDonald saying that I have a "serious misunderstanding of how pointers work" or that I "really don't know how CREATE DOES> works" --- just typical Forth-200x insults (Forth-200x is a house founded upon sand, and for mortar they use bullshit).
>
> So, I feel comfortable in declaring victory against the Forth-200x committee in regard to quotations. If anybody disagrees, then they need to get on the Forth-200x mailing list and go back to praising the RfD for the Paysan-faked quotations that Jennifer Brien is "quite content" with. Do it Forth-200x supporters! This is the only way you can declare victory for yourselves! The Forth-200x mailing-list is a "Hugh-free zone" (Jennifer Brien's term) so there is no way for me to stop you from declaring victory --- all that is needed is for you to is to get off your fat asses and declare victory --- but you haven't done so yet, and instead you have let the RfD wither and die (that RfD is almost a year old now, and it has yet to be turned into a CfV and ratified unanimously despite being pre-approved by Leon Wagner).
>
> P.S. I actually do like to eat quiche. I remember way back in Santa Barbara going to parties and the women would bring quiche for the pot-luck. Awesome! Who doesn't like quiche?
Not sure, but this might qualify as installment 3 in Hugh's manifesto.
How many installments did the Unibomber make? Or was his manifesto
published all in one edition?
--
Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-25 12:32 -0400 |
| Message-ID | <nn5eu2$ql$1@dont-email.me> |
| In reply to | #49450 |
On 7/25/2016 3:30 AM, Julian Fondren wrote: > > When I said that you were insane, I only > meant that you were insane. When I read this I *literally* laughed out loud! I couldn't have said it better myself. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-24 17:48 -1000 |
| Message-ID | <AZGdnd9hDeCJEQjKnZ2dnUU7-QPNnZ2d@supernews.com> |
| In reply to | #49417 |
On 7/24/16 3:27 PM, rickman wrote: > I think this serves as installment 2 of Hugh's manifesto. It really would be a service to the community to avoid quoting all this trash. Many of us have Hugh in the kill file to avoid the unpleasantness. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-24 23:09 -0700 |
| Message-ID | <4c0302eb-9cb8-4f7e-aba8-b3a055569ad3@googlegroups.com> |
| In reply to | #49429 |
On Sunday, July 24, 2016 at 8:48:43 PM UTC-7, Elizabeth D. Rather wrote: > On 7/24/16 3:27 PM, rickman wrote: > > I think this serves as installment 2 of Hugh's manifesto. > > It really would be a service to the community to avoid quoting all this > trash. Many of us have Hugh in the kill file to avoid the unpleasantness. What you snipped was a quote from Stephen Pelc in his VFX manual. Are you saying that Stephen Pelc's words are trash? This is what Stephen Pelc said: "CPUs from the Pentium 3 onwards have serious performance problems when data is close to code, leading to a wide variation in performance depending on data location." By comparison, this is what you said on the subject: On Thursday, July 21, 2016 at 3:40:35 PM UTC-7, Elizabeth D. Rather wrote: > An integrated code/data space dictionary is simpler to create and > maintain, and results in less implementation code and modestly better > compilation performance. On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote: > In a resident system, the advantage of > segregating the headers from the code is unclear to me. I think that SwiftForth has combined code and data because SwiftForth is really just a port of an old Forth system that Charles Moore wrote in the 1970s for the PDP-11 for which separating code and data wasn't an issue. Forth Inc. doesn't employ programmers who are capable of writing new software --- your "programmers" just maintain software written by Charles Moore --- you have been keeping this old code going for about 40 years now. If it was just a matter of SwiftForth being low-quality, I wouldn't care. The problem however is that you want to impose your ignorance on the entire Forth community by declaring that the bugs in SwiftForth are the Standard for Forth and that every Forth system must have the same bugs as SwiftForth or they will be non-standard. ANS-Forth is full of bad design decisions. All of these bad design decisions originated in Forth Inc. systems, but you were the chair-person of the ANS-Forth committee so you required Forth Inc. systems to be ANS-Forth compliant without any modification whatsoever, so all of these bugs got written in stone and imposed on the entire Forth community. Most of these bugs are grossly obvious --- Stephen Pelc is hardly the only assembly-language programmer who knows that code and data need to be separated to avoid cache conflicts --- you are the only person who doesn't know this. People make themselves look foolish by using ANS-Forth because they are required to embrace bugs as their standard --- they come off appearing to be ignorant of even first-year programming concepts --- ANS-Forth is ignored by essentially everybody (including Stephen Pelc) because nobody wants to look dumb.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-25 12:43 -0400 |
| Message-ID | <nn5fjn$594$1@dont-email.me> |
| In reply to | #49444 |
On 7/25/2016 2:09 AM, hughaguilar96@gmail.com wrote: > On Sunday, July 24, 2016 at 8:48:43 PM UTC-7, Elizabeth D. Rather wrote: >> On 7/24/16 3:27 PM, rickman wrote: >>> I think this serves as installment 2 of Hugh's manifesto. >> >> It really would be a service to the community to avoid quoting all this >> trash. Many of us have Hugh in the kill file to avoid the unpleasantness. > > What you snipped was a quote from Stephen Pelc in his VFX manual. Are you saying that Stephen Pelc's words are trash? This is what Stephen Pelc said: > "CPUs from the Pentium 3 onwards have serious performance problems when data is close to code, leading to a wide variation in performance depending on data location." > > By comparison, this is what you said on the subject: > > On Thursday, July 21, 2016 at 3:40:35 PM UTC-7, Elizabeth D. Rather wrote: >> An integrated code/data space dictionary is simpler to create and >> maintain, and results in less implementation code and modestly better >> compilation performance. > > On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote: >> In a resident system, the advantage of >> segregating the headers from the code is unclear to me. > > I think that SwiftForth has combined code and data because SwiftForth is really just a port of an old Forth system that Charles Moore wrote in the 1970s for the PDP-11 for which separating code and data wasn't an issue. Forth Inc. doesn't employ programmers who are capable of writing new software --- your "programmers" just maintain software written by Charles Moore --- you have been keeping this old code going for about 40 years now. > > If it was just a matter of SwiftForth being low-quality, I wouldn't care. The problem however is that you want to impose your ignorance on the entire Forth community by declaring that the bugs in SwiftForth are the Standard for Forth and that every Forth system must have the same bugs as SwiftForth or they will be non-standard. > > ANS-Forth is full of bad design decisions. All of these bad design decisions originated in Forth Inc. systems, but you were the chair-person of the ANS-Forth committee so you required Forth Inc. systems to be ANS-Forth compliant without any modification whatsoever, so all of these bugs got written in stone and imposed on the entire Forth community. Most of these bugs are grossly obvious --- Stephen Pelc is hardly the only assembly-language programmer who knows that code and data need to be separated to avoid cache conflicts --- you are the only person who doesn't know this. > > People make themselves look foolish by using ANS-Forth because they are required to embrace bugs as their standard --- they come off appearing to be ignorant of even first-year programming concepts --- ANS-Forth is ignored by essentially everybody (including Stephen Pelc) because nobody wants to look dumb. I guess Hugh is really off his nut lately. Maybe it's a good idea to try not to bug him. I'll quiet down... -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-23 06:58 +0000 |
| Message-ID | <2016Jul23.085835@mips.complang.tuwien.ac.at> |
| In reply to | #49353 |
Brad Eckert <hwfwguy@gmail.com> writes:
>It's interesting that the biggest ANS opponents were the Forth hardware guy=
>s. It's as if ANS was geared to use all four flags in CPUs designed to run =
>C code: Overflow, Carry, Minus and Zero. Of course all architectures going =
>forward have to support C, so that was the main target of ANS. So, : < - 0<=
> ; is nonstandard in one case that will probably never happen in practice.
C code does not need these flags, and indeed, architectures like Alpha
have been designed for C that do not have these flags. They seem to
be a pretty useful result of common ALU designs, although apparently
not compelling enough to design them into every architecture. Apart
from Alpha, MIPS does not have them, and in particular, at best you
can trap on overflow in Alpha and the original MIPS (recently MIPS has
acquired a way to test for overflow without incurring a trap or
long-winded computations). There is no carry flag at all in these
architectures, but you can work around that relatively cheaply.
Anyway, programming languages, including C and Forth normally don't
make flags explicit, so architectures have quite a lot of freedom in
their design in this area. And given that standard Forth runs on
Alpha, MIPS, PowerPC (which also deviates from the NZCV scheme), and
IA-64 (another deviation), it is obviously not limited to
architectures with these flags. Sure, someone designed +LOOP too
cleverly to make use of the oVerflow flag, and you need a few extra
instructions on Alpha and classical MIPS for that, but that's small
change.
As for the circular comparison
: < - 0< ;
that's not any more efficient than the standard Forth (since Forth-79,
although with 0/1 instead of 0/-1 in Forth-83...2012) pair of < and
U<, on either Alpha, MIPS, PowerPC, or IA-64 (I think it takes an
additional instruction on IA-64). What circular comparison gives us
is having just one less-than instead of two.
As for the difference not happening in practice, I am pretty sure that
it does happen, especially with smaller cell sizes, or they would not
have standardized on two less-than words rather than one in Forth-79
when memory was at a premium. But you can check it yourself, by
defining < and u< to do both the standard and the circular comparison,
and reporting the cases when the results differ.
>But now that the dust has settled, what are the most popular objections to =
>the ANS way of doing things?
1) It's too big for the smallest systems, and includes features that
are not needed for these systems.
2) It does not contain certain features the objector considers important.
3) It's too loosely defined.
4) It's too tightly defined (e.g., : < - 0< ; is not a standard
implementation of < :-)
5) Chuck Moore stopped participating in Forth-94 and does not see much
value in any standard.
The cool thing is that 1 and 2 often come from the same person, as
well as 3 and 4. Moreover, between the objectors, the perceived sets
of missing and superfluous features usually don't have that much
overlap, as well as the areas where the standard is too tightly or too
loosely specified in their opinion. In those cases where many people
agree on such issues, one can standardize them (however,
de-standardizing is something that is not done lightly, and takes a
lot of time).
Concerning reason 5, that's a good reason to do your own thing, just
like Chuck Moore, and the implementors of a number of non-standard
systems. Note that these system implementors generally don't waste
any time objecting to the standard; they don't need it, so they also
don't object to it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-23 04:02 -0500 |
| Message-ID | <e42dndxPyOshrw7KnZ2dnUU78c_NnZ2d@supernews.com> |
| In reply to | #49353 |
Brad Eckert <hwfwguy@gmail.com> wrote: > But now that the dust has settled, what are the most popular > objections to the ANS way of doing things? I don't know about "popular", but from what I can remember: The semantics of DO ... +LOOP are bewildering. This was inherited from Forth-83. The distinction between "immediacy" and "special compilation semantics" still causes confusion, and from time to time there is an effort to sort it out. It seems that words such as S" (in the FILE wordset) and TO can't be implemented in a strictly-correct way as STATE-smart IMMEDIATE words. TO can't be POSTPONEd or COMPILEd, so can't easily be used as a factor. All of this is something of a mess. In hindsight it would have been better if there were no state-smart (more formally, "words with interpretation semantics and non-default compilation semantics") words in the standard system. But I am of the [unpopular] opinion that STATE should not exist at all, or perhaps that if it exists it should be an internal detail of the system. So it's probably just me. It's not entirely clear that a text interpreter can be written in Standard Forth, for reasons discussed at length here. In practice this isn't a problem, so it's perhaps not worth mentioning. The floating-point wordset is lacking some conveniences which many systems supply: there's no floating-point PICK, or LOCAL, or >R. But all of these things are fairly minor. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-23 10:43 -0700 |
| Message-ID | <e26818c6-3806-4ac7-a9b2-6236da5d2cf8@googlegroups.com> |
| In reply to | #49363 |
On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote: > Brad Eckert <hwfwguy@gmail.com> wrote: > > > But now that the dust has settled, what are the most popular > > objections to the ANS way of doing things? > > I don't know about "popular", but from what I can remember: > > The semantics of DO ... +LOOP are bewildering. This was inherited from > Forth-83. That's why I rarely use +LOOP. Inefficiency, and it creates more work the next time I implement it. I use a FOR NEXT structure for simple loops that do something 0 or more times. A quick SEE of my current Forth: : dt_typec ( $a --) countc for countc emit next drop ; see dt_typec 31D COUNTC 1- MBRAN 7 321 >R COUNTC EMIT R> BRAN -A 328 DROP DROP EXIT FOR compiles the "1- MBRAN 7 >R" NEXT compiles the "R> BRAN -A DROP" It's done this way so R@ can get the loop count. All of these are 8-bit tokens for a VM, although they are sometimes Forth CPU instructions. MBRAN is a non-swallowing "branch if <0" instruction. > > But I am of the [unpopular] opinion > that STATE should not exist at all, or perhaps that if it exists it > should be an internal detail of the system. So it's probably just me. Are there any papers on STATEless Forths? I think search order manipulation could handle the different semantics, but has it been tried? I'm not sure colorForth is stateless. The state is specified in each word. Unfortunately, the idea is dependent on having an editor that people like as much as the impressive array of text editors already existing. > It's not entirely clear that a text interpreter can be written in > Standard Forth, for reasons discussed at length here. In practice > this isn't a problem, so it's perhaps not worth mentioning. Come to think of it, modifying the interpreter in a nonstandard way is mostly a cut-n-paste job. Much easier than trying to do it in a standard way.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-23 10:48 -0700 |
| Message-ID | <87h9bgb603.fsf@jester.gateway.pace.com> |
| In reply to | #49369 |
Brad Eckert <hwfwguy@gmail.com> writes: > Are there any papers on STATEless Forths? I think search order > manipulation could handle the different semantics, but has it been > tried? I thought that's what cmForth was.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-07-23 10:53 -0700 |
| Message-ID | <f2864458-87be-405c-9381-1f4edf946ef4@googlegroups.com> |
| In reply to | #49369 |
On Saturday, July 23, 2016 at 8:43:26 PM UTC+3, Brad Eckert wrote: > On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote: > > Brad Eckert wrote: > > > > > But now that the dust has settled, what are the most popular > > > objections to the ANS way of doing things? > > > > I don't know about "popular", but from what I can remember: > > > > The semantics of DO ... +LOOP are bewildering. This was inherited from > > Forth-83. > > That's why I rarely use +LOOP. Inefficiency, and it creates more work the next time I implement it. > > I use a FOR NEXT structure for simple loops that do something 0 or more times. A quick SEE of my current Forth: > > : dt_typec ( $a --) countc for countc emit next drop ; > see dt_typec > 31D COUNTC 1- MBRAN 7 > 321 >R COUNTC EMIT R> BRAN -A > 328 DROP DROP EXIT > > FOR compiles the "1- MBRAN 7 >R" > NEXT compiles the "R> BRAN -A DROP" > It's done this way so R@ can get the loop count. > All of these are 8-bit tokens for a VM, although they are sometimes Forth CPU instructions. MBRAN is a non-swallowing "branch if <0" instruction. > > > > > But I am of the [unpopular] opinion > > that STATE should not exist at all, or perhaps that if it exists it > > should be an internal detail of the system. So it's probably just me. > > Are there any papers on STATEless Forths? I think search order manipulation could handle the different semantics, but has it been tried? > > I'm not sure colorForth is stateless. The state is specified in each word. Unfortunately, the idea is dependent on having an editor that people like as much as the impressive array of text editors already existing. > > > It's not entirely clear that a text interpreter can be written in > > Standard Forth, for reasons discussed at length here. In practice > > this isn't a problem, so it's perhaps not worth mentioning. > > Come to think of it, modifying the interpreter in a nonstandard way is mostly a cut-n-paste job. Much easier than trying to do it in a standard way. Hi! > Are there any papers on STATEless Forths? I think search order manipulation could handle the different semantics, but has it been tried? Maybe FreeForth? http://christophe.lavarenne.free.fr/ff/ Have nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2016-07-23 11:24 -0700 |
| Message-ID | <9fe86af7-4cb7-4ea2-8b49-25f5ad3edd3f@googlegroups.com> |
| In reply to | #49369 |
> I'm not sure colorForth is stateless. The state is specified in each word. Unfortunately, the idea is dependent on having an editor that people like as much as the impressive array of text editors already existing. My forth not have state, not compiling or execution diference, ColorForth have macro word but only for optimization i guess, really not have state too.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-24 03:33 -0500 |
| Message-ID | <L6GdnarFgp704AnKnZ2dnUU78b-dnZ2d@supernews.com> |
| In reply to | #49369 |
Brad Eckert <hwfwguy@gmail.com> wrote: > On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote: >> Brad Eckert <hwfwguy@gmail.com> wrote: >> >> > But now that the dust has settled, what are the most popular >> > objections to the ANS way of doing things? >> >> But I am of the [unpopular] opinion that STATE should not exist at >> all, or perhaps that if it exists it should be an internal detail >> of the system. So it's probably just me. > > Are there any papers on STATEless Forths? I think search order > manipulation could handle the different semantics, but has it been > tried? There's no need to change the search order: the compiler and interpreter are different programs rather than interleaved, so there's no need to maintain any STATE because it's implicit in whichever word is running. IMMEDIATE still exists. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | missycurl@gmail.com |
|---|---|
| Date | 2016-07-24 08:16 -0700 |
| Message-ID | <2e8c89d7-c7fd-4b63-bc93-fd3695297e36@googlegroups.com> |
| In reply to | #49384 |
On Sunday, July 24, 2016 at 4:33:48 AM UTC-4, Andrew Haley wrote: > Brad Eckert <hwf..@gmail.com> wrote: > > On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote: > >> Brad Eckert <hwf...@gmail.com> wrote: > >> > >> > But now that the dust has settled, what are the most popular > >> > objections to the ANS way of doing things? > >> > >> But I am of the [unpopular] opinion that STATE should not exist at > >> all, or perhaps that if it exists it should be an internal detail > >> of the system. So it's probably just me. > > > > Are there any papers on STATEless Forths? I think search order > > manipulation could handle the different semantics, but has it been > > tried? > > There's no need to change the search order: the compiler and > interpreter are different programs rather than interleaved, so there's > no need to maintain any STATE because it's implicit in whichever word > is running. IMMEDIATE still exists. > > Andrew. I don't follow this statement. In my system, "DUP" is an immediate word. It looks to see if a word is being compile, and if so, it generates the appropriate code into the definition. If not, it actually performs the DUP right then. I suppose this is just how I implemented that optimization, and there are certainly other ways to skin that cat ... : DUP ?COMPILING IF <asm> CPUSH opDUP </asm> C, <asm> RET </asm> ELSE <asm> opDUP </asm> THEN ; IMMEDIATE
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-25 04:28 -0500 |
| Message-ID | <scydnQzy_OZNRgjKnZ2dnUU78LnNnZ2d@supernews.com> |
| In reply to | #49390 |
missycurl@gmail.com wrote: > On Sunday, July 24, 2016 at 4:33:48 AM UTC-4, Andrew Haley wrote: >> Brad Eckert <hwf..@gmail.com> wrote: >> > On Saturday, July 23, 2016 at 2:02:54 AM UTC-7, Andrew Haley wrote: >> >> Brad Eckert <hwf...@gmail.com> wrote: >> >> >> >> > But now that the dust has settled, what are the most popular >> >> > objections to the ANS way of doing things? >> >> >> >> But I am of the [unpopular] opinion that STATE should not exist at >> >> all, or perhaps that if it exists it should be an internal detail >> >> of the system. So it's probably just me. >> > >> > Are there any papers on STATEless Forths? I think search order >> > manipulation could handle the different semantics, but has it been >> > tried? >> >> There's no need to change the search order: the compiler and >> interpreter are different programs rather than interleaved, so there's >> no need to maintain any STATE because it's implicit in whichever word >> is running. IMMEDIATE still exists. > > I don't follow this statement. In my system, "DUP" is an immediate word. So, DUP has to be STATE-smart in your system. Let me be absolutely clear what I mean by STATEless Forth: there is no word which has non-default compilation semantics and interpretation semantics. > It looks to see if a word is being compile, and if so, it generates > the appropriate code into the definition. If not, it actually > performs the DUP right then. I suppose this is just how I > implemented that optimization, and there are certainly other ways to > skin that cat ... There are many. You don't have to do it that way: you could have a smart COMPILE, which performs the appropriate optimizations on primitives without needing STATE-smartness. Or you could tokenize the whole word, processing IMMEDIATE words etc along the way, and then make a pass over it to do any optimization. Or arrange the compiler as a pipeline which passes tokens to an optimizer. Or use dual-cfa words, but that has its own problems. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web