Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56164 > unrolled thread
| Started by | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| First post | 2017-03-23 02:17 -0500 |
| Last post | 2017-05-11 20:59 -0700 |
| Articles | 20 on this page of 184 — 31 participants |
Back to article view | Back to comp.lang.forth
comp.lang.forth is THE PROBLEM Richard Owlett <rowlett@cloud85.net> - 2017-03-23 02:17 -0500
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 00:27 -0700
Re: comp.lang.forth is THE PROBLEM anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 11:50 +0000
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-03-23 12:34 -0500
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 10:56 -0700
Re: comp.lang.forth is THE PROBLEM mentificium@gmail.com - 2017-03-24 05:25 -0700
Re: comp.lang.forth is THE PROBLEM rickman <gnuarm@gmail.com> - 2017-03-24 19:23 -0400
Re: comp.lang.forth is THE PROBLEM john <anon@example.com> - 2017-05-03 10:54 +0100
Re: comp.lang.forth is THE PROBLEM mentificium@gmail.com - 2017-05-04 05:28 -0700
Re: comp.lang.forth is THE PROBLEM Dennis Ruffer <daruffer@gmail.com> - 2017-03-24 17:46 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-24 18:49 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-03-24 22:09 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-03-24 20:47 -0700
Re: comp.lang.forth is THE PROBLEM krishna.myneni@ccreweb.org - 2017-03-25 10:49 -0700
Re: comp.lang.forth is THE PROBLEM Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:39 -0700
Re: comp.lang.forth is THE PROBLEM The Beez <the.beez.speaks@gmail.com> - 2017-05-10 02:07 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 11:23 +0200
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-10 16:29 -1000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-11 13:39 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 16:01 -0500
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 21:41 -1000
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-12 03:18 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-12 19:12 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-12 19:15 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:01 -0700
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-16 17:59 -0400
Re: comp.lang.forth is THE PROBLEM rickman <gnuarm@gmail.com> - 2017-05-24 16:57 -0400
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-26 02:28 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-12 17:44 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-13 00:21 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:15 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-13 00:30 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-13 04:43 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-13 12:51 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-13 08:47 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-13 09:57 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-13 18:26 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-13 10:59 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:36 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 00:33 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 12:04 -0500
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 11:45 -0700
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-14 12:02 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:22 -0500
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 23:08 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:12 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-14 12:25 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:48 -0500
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-15 00:24 -0400
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:14 -0500
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:17 -0500
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:30 -0500
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-15 09:54 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-15 02:27 -0700
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-15 00:24 -0400
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-15 09:53 +0100
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-15 16:31 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 11:43 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-15 15:47 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 20:06 -0700
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 12:05 +0100
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-16 15:00 +0000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-16 10:52 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-16 19:33 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-16 21:11 +0200
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-16 21:25 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-17 07:48 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 10:50 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 19:27 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 11:42 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 20:22 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 12:57 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 13:01 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 13:01 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 14:09 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 07:00 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-18 22:15 -0700
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 22:21 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 08:04 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 23:10 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 08:19 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 23:29 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 08:44 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-18 01:13 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 10:02 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 01:29 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 11:34 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 03:56 -0700
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:44 +0000
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:42 +0000
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 03:59 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 13:01 +0200
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-18 08:26 +0100
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:37 +0000
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-18 08:16 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:04 -0500
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 19:41 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-16 21:05 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-16 11:21 -0700
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 20:32 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-16 19:35 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 11:06 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 19:30 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 12:02 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 20:41 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-17 19:17 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 20:58 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 10:46 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 08:43 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 16:00 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 01:47 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:03 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 17:51 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 07:51 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 00:11 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 17:46 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 10:34 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 20:57 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:08 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 10:51 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 05:15 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 14:51 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 09:18 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 21:15 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 19:49 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-19 07:10 +0200
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-19 07:42 -0500
Re: comp.lang.forth is THE PROBLEM Coos Haak <htrofhc@gmail.com> - 2017-05-19 09:59 +0200
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 18:48 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-19 12:40 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 20:57 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-20 03:42 -0500
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-20 02:00 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 10:15 +0100
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:34 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 02:01 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:18 +0100
Re: comp.lang.forth is THE PROBLEM albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-19 17:06 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 08:31 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-19 17:02 +0100
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 09:18 -0700
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 09:34 -0700
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-18 16:40 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-18 08:12 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-19 02:30 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 18:57 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-20 14:01 -0700
Re: comp.lang.forth is THE PROBLEM albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-21 19:55 +0200
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 11:57 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-05-21 12:41 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 13:02 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 14:43 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 16:32 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 18:46 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-22 07:05 +0100
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-23 13:45 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-23 22:02 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-24 01:00 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-24 14:07 +0100
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-18 22:14 -0700
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-16 18:48 -1000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 15:06 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:16 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 12:18 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:58 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-12 03:32 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-12 19:29 -0500
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-13 08:25 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-13 13:25 -0500
Re: comp.lang.forth is THE PROBLEM "Robert L." <No_spamming@noWhere_7073.org> - 2017-05-15 05:45 +0000
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-15 06:54 -0700
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-15 16:30 +0200
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-16 00:32 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-16 19:25 -0700
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-16 21:15 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-05-16 21:34 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-15 08:39 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 12:38 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 17:32 -0500
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-16 10:06 +0200
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:51 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:50 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:47 -0700
Re: comp.lang.forth is THE PROBLEM Bill Zimmerly <billzimmerly@gmail.com> - 2017-05-11 20:59 -0700
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-18 08:19 +0200 |
| Message-ID | <86d1b6lma3.fsf@molnjunk.nocrew.org> |
| In reply to | #59460 |
Raimond Dragomir wrote: >> Obviously, there are two different philosophies regarding this. Some >> don't allow target words to execute at compile time. Some do. [...] >> if I had paying customers that requested this feature, I wouldn't be >> inclined to tell them "don't do that". > > I agree. But the question here is: how you would do that if you were > to do that? Mr Pelc repeately told us that one way is to execute the target instructions by way of emulation/simulation. Another way might be to generate two words: one target word, and another word that runs in the host and emulates the behaviour of the target word.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-17 23:29 -0700 |
| Message-ID | <ee490e95-bb4d-48b2-9092-c6340d66cf5c@googlegroups.com> |
| In reply to | #59461 |
joi, 18 mai 2017, 09:19:33 UTC+3, Lars Brinkhoff a scris: > Raimond Dragomir wrote: > >> Obviously, there are two different philosophies regarding this. Some > >> don't allow target words to execute at compile time. Some do. [...] > >> if I had paying customers that requested this feature, I wouldn't be > >> inclined to tell them "don't do that". > > > > I agree. But the question here is: how you would do that if you were > > to do that? > > Mr Pelc repeately told us that one way is to execute the target > instructions by way of emulation/simulation. > > Another way might be to generate two words: one target word, and another > word that runs in the host and emulates the behaviour of the target > word. The example was: variable x 10 x ! If you execute the 10 x ! part on the host, that works on the host. But will not work on the target! At the host TIME, the host will put 10 in a target image location. That's RAM in the target. At target TIME, nothing will happen. x variable will not get 10.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 08:44 +0100 |
| Message-ID | <ofjj77$4ch$1@dont-email.me> |
| In reply to | #59462 |
On 5/18/2017 07:29, Raimond Dragomir wrote: > joi, 18 mai 2017, 09:19:33 UTC+3, Lars Brinkhoff a scris: >> Raimond Dragomir wrote: >>>> Obviously, there are two different philosophies regarding this. Some >>>> don't allow target words to execute at compile time. Some do. [...] >>>> if I had paying customers that requested this feature, I wouldn't be >>>> inclined to tell them "don't do that". >>> >>> I agree. But the question here is: how you would do that if you were >>> to do that? >> >> Mr Pelc repeately told us that one way is to execute the target >> instructions by way of emulation/simulation. >> >> Another way might be to generate two words: one target word, and another >> word that runs in the host and emulates the behaviour of the target >> word. > > The example was: > variable x > 10 x ! > > If you execute the 10 x ! part on the host, that works on the host. > But will not work on the target! > > At the host TIME, the host will put 10 in a target image location. > That's RAM in the target. At target TIME, nothing will happen. > x variable will not get 10. > If you look at the metacompiled kernel in WF32, you'll see that this works OK. X will be set to 10 in the target. defer x ' noop is x variable y 10 y ! create a 10 , 20 , 30 , 0 value z here 200 allot to z begin-structure %st cell +field: field1 end-structure All work just fine and as you would expect. It also supports undeclared forward declarations, since it's hard to write metacompiled code that doesn't require one or two. The alternative is to use DEFERs but then you need to support IS in interpreted metacompilation, or have some form of initialization code. Hugh (and possibly others here) are proposing metacompiling a very restricted subset of Forth; and not providing an interpreted metacompile capability at all. https://github.com/alextangent/wf32/releases The kernel is src/kernel/gkernel32.fs The metacompiler (see gmeta.fs) includes some really unpleasant code with some pretty weird & wonderful incantations, and it really needs a major overhaul. Recognizers are a very promising approach for this. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-18 01:13 -0700 |
| Message-ID | <f20cdb9f-5839-4e5a-bf7e-1020888292f7@googlegroups.com> |
| In reply to | #59468 |
On Thursday, 18 May 2017 08:44:51 UTC+1, Alex wrote: > On 5/18/2017 07:29, Raimond Dragomir wrote: > > joi, 18 mai 2017, 09:19:33 UTC+3, Lars Brinkhoff a scris: > >> Raimond Dragomir wrote: > >>>> Obviously, there are two different philosophies regarding this. Some > >>>> don't allow target words to execute at compile time. Some do. [...] > >>>> if I had paying customers that requested this feature, I wouldn't be > >>>> inclined to tell them "don't do that". > >>> > >>> I agree. But the question here is: how you would do that if you were > >>> to do that? > >> > >> Mr Pelc repeately told us that one way is to execute the target > >> instructions by way of emulation/simulation. > >> > >> Another way might be to generate two words: one target word, and another > >> word that runs in the host and emulates the behaviour of the target > >> word. > > > > The example was: > > variable x > > 10 x ! > > > > If you execute the 10 x ! part on the host, that works on the host. > > But will not work on the target! > > > > At the host TIME, the host will put 10 in a target image location. > > That's RAM in the target. At target TIME, nothing will happen. > > x variable will not get 10. > > > > If you look at the metacompiled kernel in WF32, you'll see that this > works OK. X will be set to 10 in the target. > > defer x ' noop is x > variable y 10 y ! > create a 10 , 20 , 30 , > 0 value z > here 200 allot to z > > begin-structure %st > cell +field: field1 > end-structure > > All work just fine and as you would expect. It also supports undeclared > forward declarations, since it's hard to write metacompiled code that > doesn't require one or two. The alternative is to use DEFERs but then > you need to support IS in interpreted metacompilation, or have some form > of initialization code. > > Hugh (and possibly others here) are proposing metacompiling a very > restricted subset of Forth; and not providing an interpreted metacompile > capability at all. > > https://github.com/alextangent/wf32/releases > The kernel is src/kernel/gkernel32.fs > > The metacompiler (see gmeta.fs) includes some really unpleasant code > with some pretty weird & wonderful incantations, and it really needs a > major overhaul. Recognizers are a very promising approach for this. > > -- > Alex If I'm interpreting the discussion correctly, Hugh is discussing a kind of "static" meta-compilation technique, and you (Alex) are discussing a kind of "dynamic" meta-compilation technique.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-18 10:02 +0200 |
| Message-ID | <868tlulhig.fsf@molnjunk.nocrew.org> |
| In reply to | #59462 |
Raimond Dragomir wrote: >> Another way might be to generate two words: one target word, and >> another word that runs in the host and emulates the behaviour of the >> target word. > > The example was: > variable x > 10 x ! > > At the host TIME, the host will put 10 in a target image location. > That's RAM in the target. At target TIME, nothing will happen. > x variable will not get 10. There would be two different "x". The host version pushes its pfa to the stack. The target version compiles itself into the current definition. Likewise there would be two different "!".
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-18 01:29 -0700 |
| Message-ID | <7404a3c4-c94b-420d-a5da-c8ddc6bdea6f@googlegroups.com> |
| In reply to | #59470 |
joi, 18 mai 2017, 11:02:32 UTC+3, Lars Brinkhoff a scris: > Raimond Dragomir wrote: > >> Another way might be to generate two words: one target word, and > >> another word that runs in the host and emulates the behaviour of the > >> target word. > > > > The example was: > > variable x > > 10 x ! > > > > At the host TIME, the host will put 10 in a target image location. > > That's RAM in the target. At target TIME, nothing will happen. > > x variable will not get 10. > > There would be two different "x". The host version pushes its pfa to > the stack. The target version compiles itself into the current > definition. Likewise there would be two different "!". There is no current definition.... variable x 10 x ! all are outside any definition, in interpreter mode.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-18 11:34 +0200 |
| Message-ID | <86vaoyjypg.fsf@molnjunk.nocrew.org> |
| In reply to | #59473 |
Sending this to comp.lang.forth. Raimond Dragomir wrote: > \ Push 10 and the target pfa of x > 10 x > \ This version of ! uses the target address to store into the > target > \ image > ! > > Yes, this works in the host. But when the target image gets executed > on the target nothing gets executed (from 10 x !). Ah, now I see what you mean. No, the interpreted "10 x !" wouldn't be compiled into the target image. I'm not sure what cross compilers out there do. Do they support this use case? I haven't considered this before. It seems to me it might be strange if all interpreted code were executed twice: first during compilation, then when the target starts. I see the compilation/loading of a Forth source file as running a program. The side effect of this program is that it leaves another program in memory. In this model, interpreting code during compilation only happens at compile time. > The thing is: TARGET INTERPRETER mode can easily run in the host, but > it should also run in the target! Should it run twice? How about this? create x 0 , 1 x +! Should x be set to 1 or 2 when the target code runs?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-18 03:56 -0700 |
| Message-ID | <71a9fbb6-6838-4099-9f32-956957ebdaae@googlegroups.com> |
| In reply to | #59479 |
joi, 18 mai 2017, 12:34:04 UTC+3, Lars Brinkhoff a scris: > Sending this to comp.lang.forth. > > Raimond Dragomir wrote: > > \ Push 10 and the target pfa of x > > 10 x > > \ This version of ! uses the target address to store into the > > target > > \ image > > ! > > > > Yes, this works in the host. But when the target image gets executed > > on the target nothing gets executed (from 10 x !). > > Ah, now I see what you mean. > > No, the interpreted "10 x !" wouldn't be compiled into the target image. > I'm not sure what cross compilers out there do. Do they support this > use case? > > I haven't considered this before. It seems to me it might be strange if > all interpreted code were executed twice: first during compilation, then > when the target starts. > > I see the compilation/loading of a Forth source file as running a > program. The side effect of this program is that it leaves another > program in memory. In this model, interpreting code during compilation > only happens at compile time. > > > The thing is: TARGET INTERPRETER mode can easily run in the host, but > > it should also run in the target! > > Should it run twice? How about this? > > create x 0 , > 1 x +! > > Should x be set to 1 or 2 when the target code runs? 1 There is no "twice". The fact that the host emulates/simulates this is for its usaage in the first place, and also helps for a kind of debugging with simulation (I don't know hot to say it different, debugging without a real target). Think of this: its target code. What do you expect from it? All this discussion is on a very simple case. Usually the ram initialization can be done more efficient than this. There is a more complicated case when you want to have a kind of more complex initialization. For example init a table with powers of two, programatically. Or even more complicated, just run a definition just after it is compiled. All this in a pure compiled language is not allowed. You can only compile run-time things. But this is forth, and one may want to write a cross-compiled application in the same manner as he writes on a host (in a "scripting" way).
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-18 09:44 +0000 |
| Message-ID | <591d6c7e.681532191@news.eternal-september.org> |
| In reply to | #59462 |
On Wed, 17 May 2017 23:29:47 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >The example was: >variable x >10 x ! > >If you execute the 10 x ! part on the host, that works on the host. >But will not work on the target! > >At the host TIME, the host will put 10 in a target image location. >That's RAM in the target. At target TIME, nothing will happen. >x variable will not get 10. With the MPE compiler and the default target start-up code, target X will be set to 10. It's been that way since version 1.0. 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-18 09:42 +0000 |
| Message-ID | <591d6b9e.681308423@news.eternal-september.org> |
| In reply to | #59461 |
On Thu, 18 May 2017 08:19:32 +0200, Lars Brinkhoff <lars.spam@nocrew.org> wrote: >Raimond Dragomir wrote: >>> Obviously, there are two different philosophies regarding this. Some >>> don't allow target words to execute at compile time. Some do. [...] >>> if I had paying customers that requested this feature, I wouldn't be >>> inclined to tell them "don't do that". >> >> I agree. But the question here is: how you would do that if you were >> to do that? > >Mr Pelc repeately told us that one way is to execute the target >instructions by way of emulation/simulation. > >Another way might be to generate two words: one target word, and another >word that runs in the host and emulates the behaviour of the target >word. I have never said that a register-level CPU simulator is needed. That assumption was made by one of our resident shouty people. However, the behaviour of target memory needs to be simulated. Sure, the MPE compiler has a raft of target memory access words which have to be set up for the target. 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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-18 03:59 -0700 |
| Message-ID | <8500c6f0-e73a-4829-b183-2c018d27fae7@googlegroups.com> |
| In reply to | #59481 |
joi, 18 mai 2017, 12:41:52 UTC+3, Stephen Pelc a scris: > On Thu, 18 May 2017 08:19:32 +0200, Lars Brinkhoff > <lars.spam@nocrew.org> wrote: > > >Raimond Dragomir wrote: > >>> Obviously, there are two different philosophies regarding this. Some > >>> don't allow target words to execute at compile time. Some do. [...] > >>> if I had paying customers that requested this feature, I wouldn't be > >>> inclined to tell them "don't do that". > >> > >> I agree. But the question here is: how you would do that if you were > >> to do that? > > > >Mr Pelc repeately told us that one way is to execute the target > >instructions by way of emulation/simulation. > > > >Another way might be to generate two words: one target word, and another > >word that runs in the host and emulates the behaviour of the target > >word. > > I have never said that a register-level CPU simulator is needed. > That assumption was made by one of our resident shouty people. > However, the behaviour of target memory needs to be simulated. > > Sure, the MPE compiler has a raft of target memory access words > which have to be set up for the target. > > 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 Fair enough. Probably it's a simulation/emulation wording here. I'm thinking of simulation when you replicate the very low level functionality of a processor (at registers and instructions level).
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-18 13:01 +0200 |
| Message-ID | <86lgpujumy.fsf@molnjunk.nocrew.org> |
| In reply to | #59481 |
Stephen Pelc wrote: > I have never said that a register-level CPU simulator is needed. My apologies!
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-18 08:26 +0100 |
| Message-ID | <ofji5h$1eu$1@dont-email.me> |
| In reply to | #59458 |
On 18/05/2017 06:21, Raimond Dragomir wrote:
>> variable x
>> 10 x !
> Normally, in a cross-compiled application this should be impossible.
> The application is first compiled, the run.
>
> I can ask you: WHEN the 10 x ! is executed?
>
> A solution may exist: to emulate/simulate the behavior of the host
> forth (or just a "scripting" forth system - the traditional aproach)
> one would implement the following strategy: compile all this code
> which is normally interpreted in a hidden definition which is run
> just at the start (like compiling a hidden main() in C) and install
> this main to run at the boot. This way the interpreted code like
> 10 x ! will get executed at the target at its time.
>
I handle this by having a target-interpret mode where a target-interpret
wordlist is searched first. In that wordlist words like ! are defined to
save the data in the target variable. Similarly definitions like
create xyz
are handled by a definition of CREATE in the target-interpret wordlist.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-18 09:37 +0000 |
| Message-ID | <591d67eb.680361045@news.eternal-september.org> |
| In reply to | #59458 |
On Wed, 17 May 2017 22:21:04 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >> variable x >> 10 x ! > >Normally, in a cross-compiled application this should be impossible. >The application is first compiled, the run. > >I can ask you: WHEN the 10 x ! is executed? Assume the following in the cross-compiled code: variable x 10 x ! ... x @ . However you cut it, during cross-compilation there needs to be an X which can be stored to and fetched from. Such behaviour is useful for creating linked lists and anchors for these lists. How RAM is later initialised is a separate cross-compiler and target issue. You also need to consider such issues as the haviour (at cross-compile time) of + @ and ! for a 24 bit cell-addressed Harvard DSP. To say that the INTERPRETER @ is just the HOST @ is to completely miss the point. My objective when designing a cross-compiler is 'code transparency'. I want the code to be cross-compiled to be as close as possible to normal Forth code. This includes handling defining words without having to define a separate host analogue. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-18 08:16 -0700 |
| Message-ID | <87r2zm6vr7.fsf@nightsong.com> |
| In reply to | #59442 |
Alex <alex@rivadpm.com> writes: > Here we need to execute the CREATE part of the definition *as though > it is running on the target system*. I still don't understand the need for emulating the target architecture, beyond basics like the word size and byte order. The host needs an interpreter environment that represents the target, but that's less of a big deal.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 11:04 -0500 |
| Message-ID | <mtOdnV-BI56_W4DEnZ2dnUU7-RWdnZ2d@supernews.com> |
| In reply to | #59506 |
Paul Rubin <no.email@nospam.invalid> wrote: > Alex <alex@rivadpm.com> writes: >> Here we need to execute the CREATE part of the definition *as though >> it is running on the target system*. > > I still don't understand the need for emulating the target architecture, > beyond basics like the word size and byte order. That's basically it, as long as you have the words you need. I've even seen a cross-compiler from a 16-bit x86 system to 32-bit 68000, but I have to admit that was quite hairy. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-16 19:41 +0100 |
| Message-ID | <offgva$8ke$1@dont-email.me> |
| In reply to | #59376 |
On 16/05/2017 16:00, Stephen Pelc wrote: > On Tue, 16 May 2017 12:05:28 +0100, Gerry Jackson > <gerry@jackson9000.fsnet.co.uk> wrote: > >>> On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: >>>> There are three types of compilation involved >>>> 1) Host compilation >>>> 2) Clone compilation (target CPU same as host and memory matches) >>>> 3) Cross compilation (target CPU is not host CPU) >>>> >>>> In the third case you have to simulate *everything* when dealing >>>> with both the definition and execution of defining words. It's not >>>> easy. You also have to extend the normal Forth compiler by at least >>>> two time frames. Forth cross compilers are much more complicated >>>> and much more subtle than they appear to be. > > I stand by this post and refer you to > https://english.stackexchange.com/questions/111787/what-is-the-difference-between-simulate-and-emulate Funnily enough I had looked at that very post before replying to Hugh but prefer the explanation given at the start of a linked post at http://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference/1584701#1584701. Neither helped explain what you wrote. > >> 2) to execute the CREATE part of CREATE ... DOES> words to build target >> data structures. This is unnecessary as the host can simply emulate the >> behaviour of the target system which is much simpler. > > You will hit this problem when you want the cross-compiler to execute > a user-written defining word correctly. > I realise that is the case which is why I raised it, but my question was why one would need to do so. I think I've just realised the answer. I (and presumably Hugh) was assuming that the writer of the cross compiler was also writing the target source code in which case the behaviour of the target can easily be emulated. Presumably as a cross compiler vendor your customers can write the target source code themselves and may wish to execute user-written defining words - in which case the target has to be simulated. Is that what you meant? I think my attitude would be to not allow that and provide some facility instead to enable the user to emulate the target - if that is indeed possible. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-16 21:05 +0200 |
| Message-ID | <86lgpwmxkj.fsf@molnjunk.nocrew.org> |
| In reply to | #59392 |
Gerry Jackson wrote:
>> You will hit this problem when you want the cross-compiler to execute
>> a user-written defining word correctly.
>
> I realise that is the case which is why I raised it, but my question
> was why one would need to do so. I think I've just realised the
> answer. I (and presumably Hugh) was assuming that the writer of the
> cross compiler was also writing the target source code in which case
> the behaviour of the target can easily be emulated. Presumably as a
> cross compiler vendor your customers can write the target source code
> themselves and may wish to execute user-written defining words - in
> which case the target has to be simulated. Is that what you meant? I
> think my attitude would be to not allow that and provide some facility
> instead to enable the user to emulate the target - if that is indeed
> possible.
Right, I went this route.
For example, my cross-compiling version of VARIABLE is a plain host
definition (runs in the host) but writes to the target image:
h: variable create cell allot ;
This word is defined with H: (which is an alias for the host :) so that
it doesn't clash with the cross-compiling :. In this context, CREATE,
CELL and ALLOT all refer to the target.
Then there's a second version of VARIABLE in the target Forth:
: variable create cell allot ;
I'm guessing that in Stephen Pelc's compiler, there's only the target
definition, which would be why he has to emulate the target processor to
run it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-16 11:21 -0700 |
| Message-ID | <968f53b6-7851-4ab4-91ce-52ae292bc00f@googlegroups.com> |
| In reply to | #59364 |
On Tuesday, May 16, 2017 at 4:05:27 AM UTC-7, Gerry wrote: > On 15/05/2017 19:43, hughaguilar96@gmail.com wrote: > > What I am saying, is that if they are going to describe themselves as leaders of the Forth community, they should first write useful Forth code-libraries --- this would be a good start toward gaining the respect of Forthers such as myself --- this is actually the only way to gain credence as leaders. > > > > Evidently they don't agree. I don't think they "declare themselves to be > the rulers of the world" - only the world of ANS Forth and Forth 2012 > and following standards. And as the Forth 200X Standard Committee that > is their right and responsibility. Obviously, I meant the world of Forth --- the Forth-200x committee also mean the world of Forth --- they use the terms "Forth" and "ANS-Forth" as synonyms, despite the fact that Charles Moore said that ANS-Forth is not Forth but is a Forth-like language at best. Your use of the word "right" is interesting --- is this a God-given right? --- this sounds a lot like the monarchies of the Middle Ages when the royal families claimed to have a divine right to rule over the peasants. > > I am extremely offended by Elizabeth Rather who declares herself to be the "leading expert" of Forth, > > I just look on claims like that as marketing hype indulged in by all > commercial organisations. British English has a phrase 'blowing your own > trumpet' that covers such claims. Just ignore it and move on. You are just telling me to become one of Elizabeth Rather's brown-nosers --- you are telling me that this is the only way to move on as a Forth programmer --- this is not going to happen. > > Stephen Pelc has admitted on comp.lang.forth that he doesn't know how to write a cross-compiler: > > > > On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: > >> There are three types of compilation involved > >> 1) Host compilation > >> 2) Clone compilation (target CPU same as host and memory matches) > >> 3) Cross compilation (target CPU is not host CPU) > >> > >> In the third case you have to simulate *everything* when dealing > >> with both the definition and execution of defining words. It's not > >> easy. You also have to extend the normal Forth compiler by at least > >> two time frames. Forth cross compilers are much more complicated > >> and much more subtle than they appear to be. > > I don't think you can draw the conclusion that "he doesn't know how to > write a cross-compiler" from the above, after all he has been > successfully selling them for a long time. But I do agree that the > paragraph about the third case seems odd. ISTM that simulation of the > target processor is only necessary if the cross compiler needs to > actually execute target code - and why would you want to do that? The > only reasons I can think of are: > 1) to plug a software simulation into a target board because the target > processor isn't available. I wouldn't regard that as part of the cross > compiler itself. Or > 2) to execute the CREATE part of CREATE ... DOES> words to build target > data structures. This is unnecessary as the host can simply emulate the > behaviour of the target system which is much simpler. > > Perhaps I'm missing something? You're not missing anything. It is easy and obvious. Stephen Pelc has been selling cross-compilers for a long time, but that doesn't mean that he knows how to write a cross-compiler. His target processors are presumably pretty easy targets, so he gets away with using this goofy scheme of simulating the target processor at compile-time. He would have failed badly on the MiniForth with its Harvard Architecture and out-of-order assembler that parallelizes up to 5 instructions in a single opcode. > > Writing code-libraries does take time --- this fact I know from experience! --- you know it too! > > Yes, and probably the members of the Forth 200X committee don't have > that time. Forth experts who don't have the time to write Forth code-libraries??? So, how exactly are these "experts" qualified to be on the standard committee and rule over Forth code-monkeys such as myself? Well, the answer is that they were appointed to the Forth-200x committee by Elizabeth Rather --- their position as rulers of the Forth world is not God given --- it comes from the "leading expert" in marketing department at Forth Inc.. I was being generous before when I said that Stephen Pelc, Leon Wagner, Bernd Paysan, and Anton Ertl were capable of writing STRING-STACK.4TH, but they didn't do so because they wanted to prevent Forth programmers from writing programs that work with strings --- there isn't actually any supporting evidence of them having this capability --- a simple explanation for why they have never provided any support for strings is that they just don't know how.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-16 20:32 +0100 |
| Message-ID | <offjtu$jj4$1@dont-email.me> |
| In reply to | #59388 |
On 16/05/2017 19:21, hughaguilar96@gmail.com wrote: > On Tuesday, May 16, 2017 at 4:05:27 AM UTC-7, Gerry wrote: >> On 15/05/2017 19:43, hughaguilar96@gmail.com wrote: >>> What I am saying, is that if they are going to describe themselves as leaders of the Forth community, they should first write useful Forth code-libraries --- this would be a good start toward gaining the respect of Forthers such as myself --- this is actually the only way to gain credence as leaders. >>> >> >> Evidently they don't agree. I don't think they "declare themselves to be >> the rulers of the world" - only the world of ANS Forth and Forth 2012 >> and following standards. And as the Forth 200X Standard Committee that >> is their right and responsibility. > > Obviously, I meant the world of Forth --- the Forth-200x committee also mean the world of Forth --- they use the terms "Forth" and "ANS-Forth" as synonyms, despite the fact that Charles Moore said that ANS-Forth is not Forth but is a Forth-like language at best. > > Your use of the word "right" is interesting --- is this a God-given right? --- this sounds a lot like the monarchies of the Middle Ages when the royal families claimed to have a divine right to rule over the peasants. People who thought that ANS Forth needed to be extended/rationalised/updated etc got together and formed the Forth200X committee. As such it is their creation and therefore their right to make decisions about the way it is extended etc. Similarly it is your 'right' to make decisions about Straight Forth. > >>> I am extremely offended by Elizabeth Rather who declares herself to be the "leading expert" of Forth, >> >> I just look on claims like that as marketing hype indulged in by all >> commercial organisations. British English has a phrase 'blowing your own >> trumpet' that covers such claims. Just ignore it and move on. > > You are just telling me to become one of Elizabeth Rather's brown-nosers No I'm not, ignoring something doesn't mean you agree with it. I would guess that most readers ignore your diatribes but don't agree with you, they've just given trying to dissuade you. Given your posts over the last few years it's highly unlikely that any regular reader of c.l.f. thinks that you 'brown nose' Elizabeth Rather. --- you are telling me that this is the only way to move on as a Forth programmer No. --- this is not going to happen. That's a pity. > Stephen Pelc has been selling cross-compilers for a long time, but that doesn't mean that he knows how to write a cross-compiler. His target processors are presumably pretty easy targets, so he gets away with using this goofy scheme of simulating the target processor at compile-time. He would have failed badly on the MiniForth with its Harvard Architecture and out-of-order assembler that parallelizes up to 5 instructions in a single opcode. See my reply to him about simulating a target processor for a possible explanation of where he's coming from. > >>> Writing code-libraries does take time --- this fact I know from experience! --- you know it too! >> >> Yes, and probably the members of the Forth 200X committee don't have >> that time. > > Forth experts who don't have the time to write Forth code-libraries??? Well at least some of them are holding down full time jobs and probably have families and other responsibilities. > I was being generous before when I said that Stephen Pelc, Leon Wagner, Bernd Paysan, and Anton Ertl were capable of writing STRING-STACK.4TH, but they didn't do so because they wanted to prevent Forth programmers from writing programs that work with strings --- there isn't actually any supporting evidence of them having this capability --- a simple explanation for why they have never provided any support for strings is that they just don't know how. That's too simple an explanation as well as being offensive. For example I don't think that someone capable of writing the Gray parser generator in ANS Forth is incapable of writing Forth libraries. -- Gerry
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web