Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31555 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2014-06-15 07:06 -0700 |
| Last post | 2014-08-12 03:51 -0700 |
| Articles | 20 on this page of 143 — 27 participants |
Back to article view | Back to comp.lang.forth
FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 07:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 08:48 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-15 23:43 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX rickman <gnuarm@gmail.com> - 2014-06-15 19:44 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-16 02:21 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-16 09:26 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-17 04:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX rickman <gnuarm@gmail.com> - 2014-06-15 19:39 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 09:27 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-17 20:12 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 21:15 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-17 22:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 23:11 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-18 16:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-20 05:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-20 14:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-20 17:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-20 17:53 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 10:57 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 13:30 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:58 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 14:22 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-21 20:13 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 21:54 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX bruce.mcfarling@gmail.com - 2014-06-21 22:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-22 05:31 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:04 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 18:02 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-23 02:53 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 20:29 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-22 13:40 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 12:08 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX november.nihal@gmail.com - 2014-06-22 16:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 20:30 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-26 15:17 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-26 15:51 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-26 22:49 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-27 07:32 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-27 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-28 06:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-28 08:07 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-28 08:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-28 07:23 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-28 22:46 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-27 02:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-28 07:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-28 11:23 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-07-28 19:21 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-28 20:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX visualforth@rocketmail.com - 2014-07-29 11:10 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-29 09:45 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 07:44 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-29 17:48 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-29 11:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-07-29 12:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-29 18:36 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 20:38 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-29 21:43 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 23:05 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-30 22:20 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-31 00:19 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-07-30 01:41 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-30 21:42 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-07-31 01:08 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-31 20:25 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-08-01 02:23 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Lars Brinkhoff <lars.spam@nocrew.org> - 2014-08-01 12:54 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-01 19:57 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-02 04:18 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-27 02:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX bruce.mcfarling@gmail.com - 2014-06-21 21:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-21 22:36 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 22:44 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-22 02:26 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:41 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:43 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-22 19:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-24 21:04 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-24 15:21 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:21 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-25 03:16 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 12:08 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 14:08 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 19:13 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:14 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 21:03 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-26 12:13 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-25 16:14 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:27 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:24 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-26 03:27 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:50 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-27 03:13 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-27 12:30 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-06-25 03:46 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-25 16:15 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 13:19 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:52 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-26 10:45 +0400
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-26 09:56 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-26 11:30 +0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:38 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-25 20:49 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:54 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX David Thompson <dave.thompson2@verizon.net> - 2014-07-26 21:53 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <ayrnieu@gmail.com> - 2014-06-22 22:22 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-24 17:05 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-24 20:55 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-24 19:52 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 13:09 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-23 00:17 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-23 00:27 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:45 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:54 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-24 00:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-27 03:33 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 18:20 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-25 18:50 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 20:00 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-25 23:02 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-26 10:28 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-26 07:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-26 07:59 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:33 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:26 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:22 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-18 22:07 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-18 19:28 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-06-18 23:09 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-18 20:02 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-19 18:28 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-17 21:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-06-17 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX jyf <jyf1987@gmail.com> - 2014-06-19 22:13 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-19 22:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX brelliott18@hotmail.com - 2014-08-10 09:15 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-11 14:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-11 23:51 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX brelliott18@hotmail.com - 2014-08-12 03:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-12 03:51 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-06-26 10:45 +0400 |
| Message-ID | <m2oaxgyxs1.fsf@gmail.com> |
| In reply to | #31852 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes: > On Wed, 25 Jun 2014 16:19:56 -0400, <hughaguilar96@yahoo.com> wrote: > >> In my language, I will not have any limit on the size of the strings, > > Just how do you intend to do that? ... > > You said you're not going to use nul-terminated strings (below), but > integers have a limited range. So, if you use counted strings, your > strings will be limited to the maximum representable value for the > integer used to store the strings' length. I.e., 65535 for unsigned > 16-bit, 4294967295 for unsigned 32-bit, etc. 32-bits is huge, but > it's still a fixed size, not unlimited as you've claimed. As soon as your strings can keep more characters than can fit in the memory you can say that your strings have no limit on the size. I suppose that can be done by using a count of variable size. For example, we can store the length of count in 2 high bits of it: 00 - count is 1 byte and maximum length is 2^6-1 = 63 01 - count is 2 bytes and maximum length is 2^6 * 256 + 255 = 16383 10 - count is 4 bytes and maximum length is 1073741823 11 - count is 8 bytes and maximum length is 9223372036854775807
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2014-06-26 09:56 +0300 |
| Message-ID | <logg6v$qno$1@dont-email.me> |
| In reply to | #31863 |
On 06/26/2014 09:45 AM, Alexander Skobelev wrote: > I suppose that can be done by using a count of variable size. For > example, we can store the length of count in 2 high bits of it: > > 00 - count is 1 byte and maximum length is 2^6-1 = 63 > 01 - count is 2 bytes and maximum length is 2^6 * 256 + 255 = 16383 ... I had considered doing that in Reva, but figured the extra complexity of decoding a count byte did not justify the small space savings per string. Instead I went with 'short' and 'long' strings. My latest efforts are all 'long' strings...
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-06-26 11:30 +0400 |
| Message-ID | <m2k384yvpe.fsf@gmail.com> |
| In reply to | #31865 |
Ron Aaron <rambamist@gmail.com> writes: > On 06/26/2014 09:45 AM, Alexander Skobelev wrote: > >> I suppose that can be done by using a count of variable size. For >> example, we can store the length of count in 2 high bits of it: >> >> 00 - count is 1 byte and maximum length is 2^6-1 = 63 >> 01 - count is 2 bytes and maximum length is 2^6 * 256 + 255 = 16383 > ... > > I had considered doing that in Reva, but figured the extra complexity of > decoding a count byte did not justify the small space savings per > string. Instead I went with 'short' and 'long' strings. My latest > efforts are all 'long' strings... Well I'd rather also leave one bit to mark a count to be one byte's length or in a cell size. In this case I would have 127 bytes or whatever limited by cell size. And decoding is seems not to be very complex: you always read the whole cell and (on big-endian architecture) just shift the count to get one byte value if the flag is not set of just mask the high byte if it's set . For little endian architecture it seems better to store the flag in lower bit in the first byte of counter. Then always rshift the count by 1.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-25 18:38 -0400 |
| Message-ID | <op.xh07u6ls6zenlw@localhost> |
| In reply to | #31812 |
On Wed, 25 Jun 2014 06:46:13 -0400, Mark Wills <markwills1970@gmail.com> wrote: > On Wednesday, 25 June 2014 02:04:05 UTC+1, Rod Pemberton wrote: >> NUL-TERMINATED STRINGS >> > Bullshit. What? So that COUNT has to walk a string looking for a 0, > like C? No thanks. > How often do you use COUNT? ... It's in my dictionary only four times, on words I'm guessing are low use, except for WORD which is higher use. As Ms. Rather noted, most strings are going to be short, i.e., less than 255 characters. So, there is not much overhead counting them. Most of the time COUNT is going to be used once, then the 'c-addr u' string form will be used thereafter. In some cases, the 'c-addr u' form will be generated directly by other words. > What if I want a 0 in my string? Not all strings are displayable > ASCII you know! I'll bite. Under what circumstances would you want to emit a 0 in a string? Or, under what circumstances would you want to embed a 0 in a string? I can only think of one situation, but I don't recall ever seeing it used on IBM PC clones. > A length cell is only sensible way (note, CELL, not byte). A larger length cell would require a change to COUNT too. How is that really any different from what I proposed? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-25 20:49 -1000 |
| Message-ID | <ELadnZyCKqQLXzbOnZ2dnUVZ_rednZ2d@supernews.com> |
| In reply to | #31850 |
On 6/25/14 12:38 PM, Rod Pemberton wrote: > On Wed, 25 Jun 2014 06:46:13 -0400, Mark Wills <markwills1970@gmail.com> > wrote: >> On Wednesday, 25 June 2014 02:04:05 UTC+1, Rod Pemberton wrote: > >>> NUL-TERMINATED STRINGS >>> >> Bullshit. What? So that COUNT has to walk a string looking for a 0, >> like C? No thanks. >> > > How often do you use COUNT? ... > > It's in my dictionary only four times, on words I'm guessing are low use, > except for WORD which is higher use. As Ms. Rather noted, most strings > are going to be short, i.e., less than 255 characters. So, there is not > much overhead counting them. None is preferable to "not much". As for how often it's used, it's a matter of style. Some people and some programs use it a good deal. > Most of the time COUNT is going to be used once, then the 'c-addr u' > string form will be used thereafter. In some cases, the 'c-addr u' > form will be generated directly by other words. It will probably be used once in a particular sequence of operations on a particular string, but there may be many such instances. The fact that you don't use it doesn't mean other people don't. >> What if I want a 0 in my string? Not all strings are displayable >> ASCII you know! > > I'll bite. > > Under what circumstances would you want to emit a 0 in a string? > Or, under what circumstances would you want to embed a 0 in a string? > > I can only think of one situation, but I don't recall ever seeing > it used on IBM PC clones. Ah, but PCs are only a subset of the systems Forth runs on. "Strings" don't have to be made up of graphic characters. Treating arrays of binary data as strings can be a useful strategy, so you can move them around using string operators, for example. >> A length cell is only sensible way (note, CELL, not byte). > > A larger length cell would require a change to COUNT too. > How is that really any different from what I proposed? No one is talking about changing COUNT to take a cell count. If you want a cell count word, you will call it something else. It is very bad form to make a significant change in the function of a standard word without changing its name. That is why, for instance, that Forth94's improved version of EXPECT is called ACCEPT. 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-26 17:54 -0400 |
| Message-ID | <op.xh20gsok6zenlw@localhost> |
| In reply to | #31864 |
On Thu, 26 Jun 2014 02:49:57 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > Treating arrays of binary data as strings can be a useful strategy, > so you can move them around using string operators, for example. Yes, I agree. That's how C works. > No one is talking about changing COUNT to take a cell count. If you want > a cell count word, you will call it something else. It is very bad form > to make a significant change in the function of a standard word without > changing its name. That is why, for instance, that Forth94's improved > version of EXPECT is called ACCEPT. Isn't it worse form to preserve the mistakes of the past for compatibility's sake? EXPECT ACCEPT QUERY ... NOT NEGATE INVERT ... How many versions of the same thing do you need before you fix the original mistake? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2014-07-26 21:53 -0400 |
| Message-ID | <cqm8t99u1d2tnauiggmlpqkk147hdt8i3s@4ax.com> |
| In reply to | #31812 |
On Wed, 25 Jun 2014 03:46:13 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: > On Wednesday, 25 June 2014 02:04:05 UTC+1, Rod Pemberton wrote: > > > > NUL-TERMINATED STRINGS > > > Bullshit. What? So that COUNT has to walk a string looking for a 0, like C? No thanks. > > What if I want a 0 in my string? Not all strings are displayable ASCII you know! > > A length cell is only sensible way (note, CELL, not byte). Null terminated strings are a retarded throw-back to the COBOL universe. > COBOL strings are fixed-length and not terminated. Although group containing 1char occurs depending can reasonably simulate counted. I don't recall any HLL that used terminated other than C's immediate ancestors (B and BCPL) and at least one of them (BCPL) used a character other than NUL as the terminator (I think 0/4 EOT). OTOH it was definitely common in *assembler* on most DEC systems, and in their OSes which were both written and called in assembler.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2014-06-22 22:22 -0700 |
| Message-ID | <50a9b02d-716d-4165-aed7-65acfce36bcb@googlegroups.com> |
| In reply to | #31744 |
On Sunday, June 22, 2014 9:41:58 AM UTC-5, Roger Levy wrote:
> >
> > Here it is: https://gist.github.com/demonview/d7f90f60e8f03bc09a40
> > Which of your standards do you reckon it meets?
>
> I'd say none of them. What's interesting is at the bottom it states it used to be regular Forth code and then it was (probably) complexified to be fast and "reentrant".
That comment refers to the sort. The <#array> definitions sprawl on as they
each create six definitions with GET-CURRENT :NAME and friends.
> Peeking at the code ALLOCATION seems to exist solely for distinguishing between dynamic and static objects.
The sign of the returned size does that, sure. Other purposes of the word
include the size that it returns. Hugh's justification is strewn across
clf in disjointed rants.
> What about using objects?
They also solve the problem of dealing with members of heterogenous data
structures, wanting to know how large things are, and so on. More about
this below.
> Is the xt you pass to $TMP a way for it to control allocation, by executing your string-constructor? That seems awkward, I'd prefer a [STR ... STR] style thing.
The XT produces the output that's collected into the returned string.
: [STR ]] [: [[ ; immediate compile-only
: STR] ]] ;] $TMP [[ ; immediate compile-only
: x [STR 1 . 2 . STR] type ;
x \ 1 2
: x [STR true abort" abort reverts to normal" STR] type ;
x \ :36: error: output reverts to normal, etc. Instead of nothing.
But sometimes you already have a perfectly good output-producing word that you
can pass to $TMP :
2014 ' CALENDAR $TMP
On Sunday, June 22, 2014 9:57:55 PM UTC-5, hughag...@yahoo.com wrote:
> ALLOCATION exists primarily to support CLONE-NODE. When cloning a node in a data-structure, it is necessary to know how big the node is --- the size will vary if the nodes in the data-structure are of various data types (typically all in the same parent-child chain).
If you have a cloneable object, the object can manage not just its
immediate data, but also any separately allocated data that it 'owns'.
It can also take care to manage reference counts of network sockets,
for example, to determine when to close them when the object is
disposed of.
> I don't program in Gforth because it is too slow executing. It is also hugely bloated, and I don't really have time to learn all that stuff. So I don't know what $TMP is --- maybe I'll learn about that some other time --- it is not on my list of priorities.
Hugh doesn't have time to learn one word, but he reckons that newbies
have time to learn a dozen words that poorly substitute for it.
Of gforth, I imagine that there roughly two kinds of 'novices':
1. Those who could burn out on Forth for want of pre-supplied general
data structures, and who are also legitimately *amazed* by how fast and
lightweight gforth is.
2. Those who note that BUFFER: is a substantial improvement on the
standard, vs. CREATE .. ALLOT , and who don't care about gforth as
they they anyway don't want the operating system needed to host it.
> None of these trolls ever write any code of their own.
Have some code.
This is from novice.4th:
: lg ( u -- val|-1 ) \ -1 if not a power of 2
dup 0= if drop -1 exit then
0 begin \ -- u val
over 1 and 0= while 1+ >r 1 rshift r> repeat
over 1 xor if 2drop -1 exit then \ not a power of 2
nip ;
This uses the very first example in Hacker's Delight, and the second
1bit-counting word from forth.sf.net:
: disable-rightmost-bit ( u -- u' ) \ u' is 0 if u is a power of 2
dup 1- and ;
octal
: ones ( uint32 -- bits )
dup 1 rshift 33333333333 and
dup 1 rshift 33333333333 and + -
dup 3 rshift + 30707070707 and 77 mod ;
decimal
: lg ( u -- log2(u)|-1 )
dup 0= over disable-rightmost-bit or if drop -1 exit then
1- ones ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-23 07:31 -0700 |
| Message-ID | <b0fadf48-ef7b-4744-a519-c9dd5436681e@googlegroups.com> |
| In reply to | #31760 |
> That comment refers to the sort. The <#array> definitions sprawl on as they > each create six definitions with GET-CURRENT :NAME and friends. Right. > > What about using objects? > They also solve the problem of dealing with members of heterogenous data > structures, wanting to know how large things are, and so on. More about > this below. Oh, this is what you meant. I know, I used to have my own OOP for this, then I downgraded it to a slightly simpler system where objects have no idea what class they are unless you manage it yourself, which has been working out. I have one heterogenous list, the list (really a pool, which I generalized) of game actors on the "stage" in my game engine. They occupy slots, each /ENTSLOT size, they have to all be based on the %entity class. Could probably add a truly heterogenous list for whatever purpose I can't imagine right now, haven't had a need yet. Can you think of any good uses for one? (You said you don't really use them anyway, but just for conjecture, why *would* a person need one, hypothetically?) > 2014 ' CALENDAR $TMP This is weird, but maybe it works, I dunno. What's an advantage of this over something like " abc" <$ " blahblah" $+ OTHERSTUFF $+ $> ? (that's my string-constructing wordset) > If you have a cloneable object, the object can manage not just its > immediate data, but also any separately allocated data that it 'owns'. > It can also take care to manage reference counts of network sockets, > for example, to determine when to close them when the object is > disposed of. Sounds like overkill for most uses! Those cases could be taken care of with separate systems, yeah? You don't want to complicate things. > Hugh doesn't have time to learn one word, but he reckons that newbies > have time to learn a dozen words that poorly substitute for it. What word? ALLOCATION? I've never heard of it, is it standard? > Of gforth, I imagine that there roughly two kinds of 'novices': > 1. Those who could burn out on Forth for want of pre-supplied general > data structures, and who are also legitimately *amazed* by how fast and > lightweight gforth is. > 2. Those who note that BUFFER: is a substantial improvement on the > standard, vs. CREATE .. ALLOT , and who don't care about gforth as > they they anyway don't want the operating system needed to host it. I don't follow, could you explain?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-24 17:05 -0700 |
| Message-ID | <5dda43e1-0d96-40b7-8432-3274276ecc3f@googlegroups.com> |
| In reply to | #31733 |
On Saturday, June 21, 2014 10:44:09 PM UTC-7, Roger Levy wrote: > > \ We have 1ARRAY and its ilk > ... > > \ We also have 2ARRAY, 3ARRAY, 4ARRAY, 5ARRAY and 6ARRAY for higher-dimensioned arrays. > > > ... which might strike some as solving problems in general that many people will never encounter in particular. > > To me only the 4ARRAY and up are unnecessary, and but they strike me as innocent indulgences. When I was 17 I read a book that provided a program simulating a predator/prey environment. Each critter's knowledge of the world was represented by a 6-dimensional array. Each axis was one attribute of its environment that it could measure, and each index range represented all the possible configurations for that attribute. The value stored at that element of the array was either 0 (if that circumstance had never been encountered before), or it was the direction that the critter moved last time it encountered that circumstance. If the critter hadn't encountered a circumstance previously, then it moved randomly, but if it had, then it did what it had done previously (which must be a good idea, as the critter is still alive) so long as this was possible, otherwise it moved randomly. This was a very primitive AI, but it worked remarkably well --- the critters behavior appeared to be intelligent. The program was in BASIC, I think for the TRS-80, so I ported it over to Vic-20 BASIC. It was unbearably slow however, so I ported it over to Vic-Forth (I was 18 by then) and obtained 3 or 4 times speed improvement. This was a non-trivial program, and it predated the master-key program, but I don't consider it to be my first non-trivial program because I was just porting over another guy's program. By comparison, the master-key program was my own design, plus it did something useful in the real-world (the two non-trivial programs I had previously written were the predator/prey simulation, and a break-out game). That predator/prey program was my very first program in Vic-Forth (which was my first experience with Forth), and it used a 6-dimensional array --- so I don't think it is true that people won't encounter the need for multi-dimensional arrays. There is a balance. If the array has too many dimensions and/or the indices have too large of a range, then the array will take too long to fill up, and the critters will not start behaving intelligently soon enough --- also, they won't be able to deal with a changing environment. On the other hand, if the array is too small, it fills up too soon and the information isn't meaningful. I suspect that most of the time, the number of dimensions will be 6 to 10, and the total size of the array will be 1000 to 4000 elements I think this technique would work well in arcade games. The predators would be the enemy characters, and the prey would be the human player. The enemies would develop distinct personalities, as each one of them will have its own array and will learn different things about the prey's behavior. Also, the attributes can include information about what fellow enemy characters are in the vicinity. This should result in what appears to be teamwork among the enemy characters, despite the fact that they are not actually communicating with each other. So, the enemies not only learn about the prey's behavior, but they also learn about their fellows' behavior. The game would be different for every player, assuming that the players have different styles of play and use different tactics. You are a professional game developer --- you have never heard of this AI technique?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-24 20:55 -0400 |
| Message-ID | <op.xhzjiagx6zenlw@localhost> |
| In reply to | #31799 |
On Tue, 24 Jun 2014 20:05:09 -0400, <hughaguilar96@yahoo.com> wrote: > I think this [AI] technique would work well in arcade games. It did: (or they used similar techniques) Pac Man Ms. Pac Man Robotron Wizard of War Doom etc etc. > When I was 17 I read a book that provided a program simulating > a predator/prey environment. Each critter's knowledge of the > world was represented by a 6-dimensional array. It sound likes a 3-dimensional version of Conway's Game of Life. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-24 19:52 -0700 |
| Message-ID | <830b38c4-61ed-426a-9072-c97b1d74abba@googlegroups.com> |
| In reply to | #31799 |
> I think this technique would work well in arcade games. The predators would be the enemy characters, and the prey would be the human player. The enemies would develop distinct personalities, as each one of them will have its own array and will learn different things about the prey's behavior. Also, the attributes can include information about what fellow enemy characters are in the vicinity. This should result in what appears to be teamwork among the enemy characters, despite the fact that they are not actually communicating with each other. So, the enemies not only learn about the prey's behavior, but they also learn about their fellows' behavior. The game would be different for every player, assuming that the players have different styles of play and use different tactics. > > > > You are a professional game developer --- you have never heard of this AI technique? Not until now. I haven't coded AI this sophisticated yet. I find the way of doing things you describe really fascinating. Not sure I've quite got it yet, but it sounds way cool. As for 6-dimensional arrays, just look at it from the novice's perspective. Do the majority of people need to have that on their plate *just yet*? All I was saying was, the less there is and the clearer things are with that kind of thing, the better. 6-dimensional arrays could go in a separate file, I wasn't saying nobody would *ever* need them. ;)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-25 13:09 -0700 |
| Message-ID | <caf676bb-ae06-4414-ab93-b5fd556d56a1@googlegroups.com> |
| In reply to | #31804 |
On Tuesday, June 24, 2014 7:52:20 PM UTC-7, Roger Levy wrote: > > You are a professional game developer --- you have never heard of this AI technique? > > Not until now. I haven't coded AI this sophisticated yet. I find the way of doing things you describe really fascinating. Not sure I've quite got it yet, but it sounds way cool. This isn't "sophisticated" --- this is super-simple entry-level stuff. It is not all that great, because the enemy characters can become somewhat predictable. Also, if the user knows about this, he can switch up his style of periodically and always stay one step ahead because there is a learning delay. If you want something even yet simpler, check out BIAS in the novice package. This generates random numbers with a triangular distribution. There is no way to generate random numbers with a normal distribution, but a triangular distribution is pretty similar, and good enough for games. > As for 6-dimensional arrays, just look at it from the novice's perspective. Do the majority of people need to have that on their plate *just yet*? All I was saying was, the less there is and the clearer things are with that kind of thing, the better. 6-dimensional arrays could go in a separate file, I wasn't saying nobody would *ever* need them. ;) When I wrote 2ARRAY etc., I didn't have ARY. Now it is somewhat redundant to have two ways of defining arrays. So I'll do what you suggest and put 2ARRAY etc. in a separate file so they can be used optionally, but ARY will be the primary way to define arrays. ARY allows any number of dimensions --- it is not necessary to manually write 7ARRAY or 20ARRAY or whatever is necessary. 6ARRAY already uses 15 local variables, so I don't know that it is even possible to write a 7ARRAY on some ANS-Forth systems (ANS-Forth only requires 8 local variables supported) --- besides that, the xARRAY definers get progressively more complicated, so 20ARRAY would be a monster. I rarely use arrays anyway. The only example program that I have with an array in it, is the LowDraw poker simulator --- the hand of cards is a 5 element array.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2014-06-23 00:17 -0700 |
| Message-ID | <b61f0427-2300-4978-8552-4df513ff2ff2@googlegroups.com> |
| In reply to | #31705 |
On Saturday, June 21, 2014 3:53:29 AM UTC+3, Roger Levy wrote: > > To a large extent, this is a loyalty test. If you want to prove that you are loyal to Elizabeth Rather (and you obviously do!), then you are expected to agree with Elizabeth Rather's critique of my data-structures in my novice package. Don't be shy! State clearly that you agree with her! > > > > I know you're talking about Elizabeth again but I must say I agree that defining general purpose arrays is not a bad thing if you're doing a lot of stuff that requires them. Then again, sometimes I implement custom arrays or other data structures. I don't try to shoehorn every problem into my arrays and that's what makes Forth great; doing either is no big deal, you don't need to lean on any set of structures all the time, but sometimes you come up with an idea with nearly universal use. (Oh god, I'm channeling Chuck) > > > > I think that the REAL danger is being afraid of either extreme. I think people should do whatever is practical for them and try to control complexity by either compartmentalizing complexity, and encapsulating/grouping things that could change. > > > > But yeah Elizabeth's statement was pretty... frustrating. It's not an all-or-nothing thing. Hi! A "universal purpose array" could be obtained by discarding code not by adding: : array CREATE allot DOES> + ; Uses: 100 array string 50 mychars 100 cells something 50 cells something \ /letter is size of a letter : letters S" /letter *" evaluate ; immediate \ macro 100 letters array mybox 9 letters mybox So, if I see 'letters mybox' I know is about mailboxes :) Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2014-06-23 00:27 -0700 |
| Message-ID | <a326621b-adaf-4437-a034-2de4347725c5@googlegroups.com> |
| In reply to | #31762 |
On Monday, June 23, 2014 10:17:58 AM UTC+3, humptydumpty wrote: > On Saturday, June 21, 2014 3:53:29 AM UTC+3, Roger Levy wrote: > > > > To a large extent, this is a loyalty test. If you want to prove that you are loyal to Elizabeth Rather (and you obviously do!), then you are expected to agree with Elizabeth Rather's critique of my data-structures in my novice package. Don't be shy! State clearly that you agree with her! > > > > > > > > > > > > I know you're talking about Elizabeth again but I must say I agree that defining general purpose arrays is not a bad thing if you're doing a lot of stuff that requires them. Then again, sometimes I implement custom arrays or other data structures. I don't try to shoehorn every problem into my arrays and that's what makes Forth great; doing either is no big deal, you don't need to lean on any set of structures all the time, but sometimes you come up with an idea with nearly universal use. (Oh god, I'm channeling Chuck) > > > > > > > > > > > > I think that the REAL danger is being afraid of either extreme. I think people should do whatever is practical for them and try to control complexity by either compartmentalizing complexity, and encapsulating/grouping things that could change. > > > > > > > > > > > > But yeah Elizabeth's statement was pretty... frustrating. It's not an all-or-nothing thing. > > > > Hi! > > A "universal purpose array" could be obtained by discarding code not by adding: > > > > : array CREATE allot DOES> + ; > > > > Uses: > > > > 100 array string 50 mychars > > 100 cells something 50 cells something > > > > \ /letter is size of a letter > > : letters S" /letter *" evaluate ; immediate \ macro > > 100 letters array mybox 9 letters mybox > > > > So, if I see 'letters mybox' I know is about mailboxes :) > > > > Have a nice day, > > humptydumpty Oops there should be: 100 array string 50 string 100 cells array something 50 cells something \ /letter is size of a letter : letters S" /letter *" evaluate ; immediate \ macro 100 letters array mybox 9 letters mybox So, if I see 'letters mybox' I know that 'mybox' is a mailbox :) Sorry for typos, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-23 07:45 -0700 |
| Message-ID | <dcfeb1cb-8df1-4ae8-88b9-4c7b81dee1cd@googlegroups.com> |
| In reply to | #31763 |
> Oops there should be: > 100 array string 50 string > 100 cells array something 50 cells something > > \ /letter is size of a letter > : letters S" /letter *" evaluate ; immediate \ macro > 100 letters array mybox 9 letters mybox > > So, if I see 'letters mybox' I know that 'mybox' is a mailbox :) Your ARRAY has weak encapsulation, and I know it's a mere mental exercise - so yeah, try writing an app that way. If you're goin' to do things that way, might as well ditch the ARRAY: create mybox 10 letters allot 9 letters mybox + At least here you know what's really going on with not much more code - actually, this is the way I do it if I'm trying to write ANS compliant code. (I'm not really doing it anymore though, because my arrays are handy and I decided to make my toolbelt available with the next thing I distribute...)
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-23 07:54 -0700 |
| Message-ID | <4a1ea23a-3de6-470f-9641-0b16bdb87a9c@googlegroups.com> |
| In reply to | #31771 |
>I decided to make my toolbelt available with the next thing I distribute... By which I mean, make my toolbelt available while discussing ways to let different toolbelts coexist in applications harmoniously, for the purpose of promoting more code distribution... ...So that we can stop diddling around and not worry about "one array to rule them all" ;) It'll probably make discussion more focused on *education* about different arrays rather than *consensus*. I've been thinking, Forth has an amazingly flexible set of common data structures to rely on - the data stack, the dictionary, words, and in ANS, wordlists. We already have a standardized data width, the cell. Interoperability should be much easier for us than Microsoft. My attitude regarding data structures and the different ways you can go about things rides on the pretext that this *will* eventually happen. If we can get the toolbelt problem out of the way, arguing over who has the best array will become less incendiary, hopefully. ;)
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2014-06-24 00:56 -0700 |
| Message-ID | <76b82fb3-d49a-472b-a0e7-acdc73bb51c5@googlegroups.com> |
| In reply to | #31774 |
On Monday, June 23, 2014 5:54:26 PM UTC+3, Roger Levy wrote: > >I decided to make my toolbelt available with the next thing I distribute... > > > > By which I mean, make my toolbelt available while discussing ways to let different toolbelts coexist in applications harmoniously, for the purpose of promoting more code distribution... > Hi! > ...So that we can stop diddling around and not worry about "one array to rule them all" ;) Of course! :) > It'll probably make discussion more focused on *education* about different arrays rather than *consensus*. I've been thinking, Forth has an amazingly flexible set of common data structures to rely on - the data stack, the dictionary, words, and in ANS, wordlists. We already have a standardized data width, the cell. Interoperability should be much easier for us than Microsoft. > > > > My attitude regarding data structures and the different ways you can go about things rides on the pretext that this *will* eventually happen. If we can get the toolbelt problem out of the way, arguing over who has the best array will become less incendiary, hopefully. ;) Of course is childish to argue which array implementation is the best. Context will suggest what is better to use or push use from execute-time time to compile-time or maybe not use at all ;) Have nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-06-27 03:33 +0200 |
| Message-ID | <lojm4i$p5d$1@online.de> |
| In reply to | #31705 |
Andrew Haley wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> C++ has, very sensibly, moved to strings with a separate count. As
> far as I know most programming language designers since C have looked
> at C strings and decided not to do what it does.
You might also look at Ken Thompson's and Rob Pike's Go. It's notation for
arrays and subsets of arrays ("slices") also follows the addr len principle
(slices are even more, because they still contain the information how big
the array was they were part of). Of course that includes strings, which
are in Go just an arbitrary addr len byte array (may or may not be UTF-8
compatible, but certainly can contain zeros) - same as in Forth.
That means that even the people who were deeply involved in C's history
changed their mind in the meantime.
Both Forth and C did it wrong 44 years ago. Forth's strings were counted
strings, i.e. the first byte was the length, and passed by address only; C's
strings were zero-terminated strings, also passed by address only.
Forth changed to addr len strings during ANS Forth, C did never change, but
C's library calls got additional addr len versions for many string words,
though "addr len" here means "either zero-terminated or len, whatever is
shorter". Specifying the length twice and requiring a "whatever is shorter"
condition is evil, as redundancy leads to bugs where someone doesn't
correctly follow the rules (that's e.g. when strncat produces strings which
aren't zero-terminated, and therefore the next zero-terminate use may leak
information beyond the original string). In other words: C's strings are
broken beyond repair. Forth did successful repair its broken strings, and
other programming languages did follow that model (or independently reinvent
the same thing - I have no problem with independent reinvention; my
experience is that people often come to the same conclusions if they start
from the same facts).
Go has some other Forth-like features where C is broken, like multiple
return values (C's multiple return values through pointers are *the* second
big source of exploitable bugs - addr-only arrays being the first). Even
the notation of those multiple-return-value functions is more Forth-like, as
the return values are now specified *after* the input values.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-25 18:20 -0700 |
| Message-ID | <f7323774-390a-433c-a80e-43f3081e3021@googlegroups.com> |
| In reply to | #31627 |
On Tuesday, June 17, 2014 10:34:22 PM UTC-7, hughag...@yahoo.com wrote: > On Tuesday, June 17, 2014 9:15:15 PM UTC-7, Roger Levy wrote: > > So Forth is still a dark art and the smartest people who get to use it in their day jobs know how to use it but don't talk about it. Myself, I'm trying to buck that trend, though I'm aware my perception could be out-of-date. AFAIK there are people still using it in the professional world to do serious programs, but correct me if I'm wrong. I know I haven't even properly defined "serious program", but let's just say that that means programs with at least 500 definitions. > > My definition of a "serious program" is one with commercial application. The world has changed a lot since 1984. In those days, there was a lot of talk about the "computer revolution" --- my expectation was that in the future everybody would own a computer, and everybody would know how to program. Programming would be taught in high school like algebra or trigonometry, and everybody would have at least a modicum of ability. I expected that most software people used, they would write themselves, and that commercial software would be a rarity. When I wrote that master-key program, this was a "serious program" in the sense that I expected that this kind of programming would be common in the future --- although it was over an order of magnitude smaller than your definition of a "serious program." My vision of the future didn't work out. People were too dumb; almost nobody learned how to program. Today, at least 95% of locksmiths design master-key systems with pencil-and-paper. They do a terrible job. For one thing, they should randomly have the master-key cut above or below the user-key cut. Instead, they make all of the master-key cuts low, and all of the user-key cuts high. The result is that the master-key is almost perfectly flat, making the lock easy to pick. My Vic-20 program ensured that both master-key and user-key were quite ragged, making the lock more difficult to pick. Also, many of these locksmiths have about a dozen master-key systems that they cycle through, so every 12th customer has an identical system. Considering that there are hundreds of possible master-keys, and hundreds of user-keys for each master-key, that is pretty pathetic. Many of these locksmith companies are owned by a 73-year-old fool who has been doing this since the 1970s, and isn't going to listen to any whippersnapper talking up these new-fangled computer thingamajigs. The few locksmiths that are using computers to generate master-key systems, bought the software rather than write it themselves. They don't know how it works --- they just have faith that the programmer who wrote it knew what he was doing --- making business plans based on faith, is actually worse than doing it yourself with paper-and-pencil and doing it badly, because at least with paper-and-pencil you have the possibility of improving your quality. But the program is easy to write! It was my first-ever non-trivial program in a language other than line-number BASIC. Why did people fail to learn how to do this kind of programming for themselves? So Juergen is trying to teach people how to program in Forth with his tutorial. I wish him good luck! Maybe after he teaches people how to program, he can teach pigs to sing and dogs to drive... Actually, with this language that I'm designing, I am hoping to make it simple enough that people who have never programmed before will be able to pick it up. I am mostly aiming at machinists who want to generate gcode for CNC machines, but it could be used by almost anybody for almost anything. P.S. When I was in high school I also assumed that essentially all adults knew algebra and trigonometry. Now I know that most college graduates have a level of math knowledge comparable to what I had in junior high-school. I over-estimated people on that subject too...
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web