Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55164 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-02-27 01:51 -0800 |
| Last post | 2017-02-27 21:24 +0100 |
| Articles | 20 on this page of 121 — 16 participants |
Back to article view | Back to comp.lang.forth
Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 01:51 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 02:35 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 02:46 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-27 17:38 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 14:12 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 04:42 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 08:58 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 14:15 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 11:51 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 15:17 -0500
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 09:02 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 19:15 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-01 02:23 +0100
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 20:57 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-01 13:24 +0100
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:23 -0500
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-01 08:50 +0000
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 10:04 -0600
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:51 -0500
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-01 13:00 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-02 15:34 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-01 18:09 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:55 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-01 21:28 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-01 22:23 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-02 00:21 -0800
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-02 01:01 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-02 01:30 -0800
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-02 01:46 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-02 02:41 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-02 11:01 +0000
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-01 13:48 -0800
Re: Is GForth KEY really ANS Forth standard? antispam@math.uni.wroc.pl - 2017-03-04 04:02 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:29 +0000
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-02-28 03:24 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 04:14 -0800
Re: Is GForth KEY really ANS Forth standard? Coos Haak <htrofhc@gmail.com> - 2017-02-27 21:50 +0100
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 13:48 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 17:41 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 15:07 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 19:03 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 23:10 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 03:29 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 01:28 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 09:58 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 02:37 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 12:46 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 05:01 -0800
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-28 12:46 +0100
Re: Is GForth KEY really ANS Forth standard? Mikael Nordman <oh2aun@gmail.com> - 2017-02-28 03:52 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 04:10 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 05:48 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 10:07 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 02:42 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-02-28 02:44 -0800
Re: Is GForth KEY really ANS Forth standard? Coos Haak <htrofhc@gmail.com> - 2017-02-28 12:13 +0100
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-02-28 05:10 -0800
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-02-28 12:12 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 13:51 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-27 15:38 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 10:13 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-02-27 11:15 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-03 12:04 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-03 17:30 -0500
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-03 23:13 +0000
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-03 18:02 -0600
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-04 01:12 +0000
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-03 19:12 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-03 19:23 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:45 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:54 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-05 20:47 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 09:20 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 05:04 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 14:07 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 06:36 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 15:04 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:38 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:56 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-07 08:07 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-07 08:37 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:41 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 01:13 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 13:03 +0000
Re: Is GForth KEY really ANS Forth standard? julian.fondren@endurance.com - 2017-03-07 08:36 -0800
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-07 19:02 +0100
Re: Is GForth KEY really ANS Forth standard? alex@rivadpm.com - 2017-03-08 06:08 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 00:46 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 12:39 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 12:42 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 23:13 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 14:34 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:33 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:45 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-08 22:48 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 09:28 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 05:22 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 14:25 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 06:46 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 15:43 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-06 09:55 -0800
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 11:04 -0600
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:44 -0800
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-07 10:50 -0600
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 11:30 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 13:37 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 14:14 +0000
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-08 15:16 +0100
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 16:14 +0000
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 14:49 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-09 10:57 -0500
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:22 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-04 10:48 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-04 21:00 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-05 02:24 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-05 16:44 -0500
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-04 20:02 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-04 23:34 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-05 02:38 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-05 16:55 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 21:24 +0100
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-02-27 10:13 -0800 |
| Message-ID | <bdc03007-f8a8-4661-b7b0-1df51b3fec01@googlegroups.com> |
| In reply to | #55189 |
Den måndag 27 februari 2017 kl. 18:37:49 UTC+1 skrev Anton Ertl: > lehs <skydda.barnen@gmail.com> writes: > >The DPANS document says: > > > >"Receive one character char, a member of the implementation-defined character set. Keyboard events that do not correspond to such characters are discarded until a valid character is received, and those events are subsequently unavailable. > > > >All standard characters can be received. Characters received by KEY are not displayed." > > > >GForth KEY do not discard 'arrow up' but return 27 on the stack and emits '[A'. That might be good but is it really ANS Forth? > > A Forth system that talks to a VT100-compatible terminal has no way to > know whether the user pressed Cursor-Up or the sequence <ESC>[A (well, > Gforth's EKEY tries to differentiate between these cases by timing, > but thanks to network lags and macro keyboards that is not a 100% > reliable way). > > And indeed, looking at Gforth, SwiftForth, VFX Forth, and bigForth for > Linux, when I do > > key . key . key . key . > > and then press Cursor-up and then x, all of them output > > 27 91 65 120 > > I also tried SP-Forth 4.20 for Linux, but its KEY just returns 0 > without waiting for a keypress; and EKEY just gives an error. > > >Words like KEY and EMIT must be exactly the same on any system. > > Apart from SP-Forth, the systems I tried behaved the same way. > > > Else portability is an illusion. > > No, behaving exactly the same is not necessary for portability. E.g., > CELLS does not behave the same way on 32-bit and 64-bit systems, and > yet it is possible to write Forth programs that port between 32-bit > and 64-bit systems, the the different behaviour of CELLS is a key part > in that portability. > > Concerning KEY, it is a word for getting the raw input, and there are > differences based on where the input is coming from (a terminal, a > keyboard, or some serial port). > > For an editor, I would recommend working with EKEY, EKEY>CHAR, > EKEY>FKEY, and the K-... words; and always provide an alternative to > the special keys for cases where the keyboard does not have the > special keys, or they do not work as expected. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard: http://www.forth200x.org/forth200x.html > EuroForth 2016: http://www.euroforth.org/ef16/ Excuse me Anton Ertl but you are not talking about Forth, you are talking about (unix) terminals. The standard is very clear: key should return the ascii value or nothing (if the keystroke doesn't correspond to an ascii value) and nothing should be emitted. That's what would bring true portability! Your counterexample with CELL is ridiculous. I'm really grateful for GForth but if there is no consensus about this simple example then portability is not possible for Forth.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-02-27 11:15 -0800 |
| Message-ID | <2d43feb7-78a0-40c4-a8ed-7cc5c6c920c7@googlegroups.com> |
| In reply to | #55192 |
On Monday, February 27, 2017 at 12:13:10 PM UTC-6, lehs wrote: > Den måndag 27 februari 2017 kl. 18:37:49 UTC+1 skrev Anton Ertl: > > lehs <skydda.barnen@gmail.com> writes: > > >The DPANS document says: > > > > > >"Receive one character char, a member of the implementation-defined character set. Keyboard events that do not correspond to such characters are discarded until a valid character is received, and those events are subsequently unavailable. > > > > > >All standard characters can be received. Characters received by KEY are not displayed." > > > > > >GForth KEY do not discard 'arrow up' but return 27 on the stack and emits '[A'. That might be good but is it really ANS Forth? > > > > A Forth system that talks to a VT100-compatible terminal has no way to > > know whether the user pressed Cursor-Up or the sequence <ESC>[A (well, > > Gforth's EKEY tries to differentiate between these cases by timing, > > but thanks to network lags and macro keyboards that is not a 100% > > reliable way). > > > > And indeed, looking at Gforth, SwiftForth, VFX Forth, and bigForth for > > Linux, when I do > > > > key . key . key . key . > > > > and then press Cursor-up and then x, all of them output > > > > 27 91 65 120 > > > > I also tried SP-Forth 4.20 for Linux, but its KEY just returns 0 > > without waiting for a keypress; and EKEY just gives an error. > > > > >Words like KEY and EMIT must be exactly the same on any system. > > > > Apart from SP-Forth, the systems I tried behaved the same way. > > > > > Else portability is an illusion. > > > > No, behaving exactly the same is not necessary for portability. E.g., > > CELLS does not behave the same way on 32-bit and 64-bit systems, and > > yet it is possible to write Forth programs that port between 32-bit > > and 64-bit systems, the the different behaviour of CELLS is a key part > > in that portability. > > > > Concerning KEY, it is a word for getting the raw input, and there are > > differences based on where the input is coming from (a terminal, a > > keyboard, or some serial port). > > > > For an editor, I would recommend working with EKEY, EKEY>CHAR, > > EKEY>FKEY, and the K-... words; and always provide an alternative to > > the special keys for cases where the keyboard does not have the > > special keys, or they do not work as expected. > > > > - anton > > -- > > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > > New standard: http://www.forth200x.org/forth200x.html > > EuroForth 2016: http://www.euroforth.org/ef16/ > > Excuse me Anton Ertl but you are not talking about Forth, you are talking about (unix) terminals. The standard is very clear: key should return the ascii value or nothing (if the keystroke doesn't correspond to an ascii value) and nothing should be emitted. > > That's what would bring true portability! > > Your counterexample with CELL is ridiculous. I'm really grateful for GForth but if there is no consensus about this simple example then portability is not possible for Forth. OK, have it your way: portability is not possible for Forth. Nor for any other language. 'Portability', we learn early 2017, was always a lie. All languages must deal with the realities of the unix terminal if they're to run under one, but only Forth systems tend to do the extra work required to make KEY or EKEY work the way they do at all. When you even get similar features, in libraries for other languages, it generally comes with an admonition to use ncurses instead. Usually you get "use ncurses" and no KEY at all.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-03 12:04 -0800 |
| Message-ID | <d5192e14-c077-4c20-b001-27bfd4c963b4@googlegroups.com> |
| In reply to | #55192 |
On Monday, February 27, 2017 at 11:13:10 AM UTC-7, lehs wrote: > Den måndag 27 februari 2017 kl. 18:37:49 UTC+1 skrev Anton Ertl: > > lehs <skydda.barnen@gmail.com> writes: > > >The DPANS document says: > > > > > >"Receive one character char, a member of the implementation-defined character set. Keyboard events that do not correspond to such characters are discarded until a valid character is received, and those events are subsequently unavailable. > > > > > >All standard characters can be received. Characters received by KEY are not displayed." > > > > > >GForth KEY do not discard 'arrow up' but return 27 on the stack and emits '[A'. That might be good but is it really ANS Forth? > > > > A Forth system that talks to a VT100-compatible terminal has no way to > > know whether the user pressed Cursor-Up or the sequence <ESC>[A (well, > > Gforth's EKEY tries to differentiate between these cases by timing, > > but thanks to network lags and macro keyboards that is not a 100% > > reliable way). > > > > And indeed, looking at Gforth, SwiftForth, VFX Forth, and bigForth for > > Linux, when I do > > > > key . key . key . key . > > > > and then press Cursor-up and then x, all of them output > > > > 27 91 65 120 > > > > I also tried SP-Forth 4.20 for Linux, but its KEY just returns 0 > > without waiting for a keypress; and EKEY just gives an error. > > > > >Words like KEY and EMIT must be exactly the same on any system. > > > > Apart from SP-Forth, the systems I tried behaved the same way. > > > > > Else portability is an illusion. > > > > No, behaving exactly the same is not necessary for portability. E.g., > > CELLS does not behave the same way on 32-bit and 64-bit systems, and > > yet it is possible to write Forth programs that port between 32-bit > > and 64-bit systems, the the different behaviour of CELLS is a key part > > in that portability. > > > > Concerning KEY, it is a word for getting the raw input, and there are > > differences based on where the input is coming from (a terminal, a > > keyboard, or some serial port). > > > > For an editor, I would recommend working with EKEY, EKEY>CHAR, > > EKEY>FKEY, and the K-... words; and always provide an alternative to > > the special keys for cases where the keyboard does not have the > > special keys, or they do not work as expected. > > > > - anton > > -- > > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > > New standard: http://www.forth200x.org/forth200x.html > > EuroForth 2016: http://www.euroforth.org/ef16/ > > Excuse me Anton Ertl but you are not talking about Forth, you are talking about (unix) terminals. The standard is very clear: key should return the ascii value or nothing (if the keystroke doesn't correspond to an ascii value) and nothing should be emitted. > > That's what would bring true portability! LEHS is right about this. The whole point of ASCII being invented, was to allow portability between OS's. Beating LEHS up because he is a novice at the Unix world is missing the point --- this has nothing to do with Forth. It can be argued that ASCII wasn't a very good standard even at the time that it was invented, and it is worse now. ASCII is the standard though, and ANS-Forth does specify ASCII --- so, KEY and KEY? should work in the same way under any ANS-Forth system running under any OS --- but they don't. > Your counterexample with CELL is ridiculous. I'm really grateful for GForth but if there is no consensus about this simple example then portability is not possible for Forth. Yes, the counter-example with CELL was ridiculous because it was irrelevant. I have seen this a lot, not in regard to Forth, but in the real world. If I ask somebody a question and they don't know the answer and/or they don't want to answer because doing so requires admitting a problem, they will give the answer to a question that they do know the answer to (typically it is obvious, so they are trying to imply that I'm stupid to have asked such an obvious question, although that is not actually the question that I asked). BTW: Straight Forth is not going to have CELL that can be different values in different systems. It is going to assume a 64-bit cell --- this allows numerical programs to be written in standard Straight Forth --- not just numerical programs, but programs working with text too (because the address and count are both 32-bit and can be packed together in a single cell).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-03 17:30 -0500 |
| Message-ID | <o9cqm2$jon$1@dont-email.me> |
| In reply to | #55389 |
On 3/3/2017 3:04 PM, hughaguilar96@gmail.com wrote: > On Monday, February 27, 2017 at 11:13:10 AM UTC-7, lehs wrote: >> Den måndag 27 februari 2017 kl. 18:37:49 UTC+1 skrev Anton Ertl: >>> lehs <skydda.barnen@gmail.com> writes: >>>> The DPANS document says: >>>> >>>> "Receive one character char, a member of the >>>> implementation-defined character set. Keyboard events that do >>>> not correspond to such characters are discarded until a valid >>>> character is received, and those events are subsequently >>>> unavailable. >>>> >>>> All standard characters can be received. Characters received by >>>> KEY are not displayed." >>>> >>>> GForth KEY do not discard 'arrow up' but return 27 on the stack >>>> and emits '[A'. That might be good but is it really ANS Forth? >>> >>> A Forth system that talks to a VT100-compatible terminal has no >>> way to know whether the user pressed Cursor-Up or the sequence >>> <ESC>[A (well, Gforth's EKEY tries to differentiate between these >>> cases by timing, but thanks to network lags and macro keyboards >>> that is not a 100% reliable way). >>> >>> And indeed, looking at Gforth, SwiftForth, VFX Forth, and >>> bigForth for Linux, when I do >>> >>> key . key . key . key . >>> >>> and then press Cursor-up and then x, all of them output >>> >>> 27 91 65 120 >>> >>> I also tried SP-Forth 4.20 for Linux, but its KEY just returns 0 >>> without waiting for a keypress; and EKEY just gives an error. >>> >>>> Words like KEY and EMIT must be exactly the same on any >>>> system. >>> >>> Apart from SP-Forth, the systems I tried behaved the same way. >>> >>>> Else portability is an illusion. >>> >>> No, behaving exactly the same is not necessary for portability. >>> E.g., CELLS does not behave the same way on 32-bit and 64-bit >>> systems, and yet it is possible to write Forth programs that port >>> between 32-bit and 64-bit systems, the the different behaviour of >>> CELLS is a key part in that portability. >>> >>> Concerning KEY, it is a word for getting the raw input, and there >>> are differences based on where the input is coming from (a >>> terminal, a keyboard, or some serial port). >>> >>> For an editor, I would recommend working with EKEY, EKEY>CHAR, >>> EKEY>FKEY, and the K-... words; and always provide an alternative >>> to the special keys for cases where the keyboard does not have >>> the special keys, or they do not work as expected. >>> >>> - anton -- M. Anton Ertl >>> http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth >>> FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html New >>> standard: http://www.forth200x.org/forth200x.html EuroForth 2016: >>> http://www.euroforth.org/ef16/ >> >> Excuse me Anton Ertl but you are not talking about Forth, you are >> talking about (unix) terminals. The standard is very clear: key >> should return the ascii value or nothing (if the keystroke doesn't >> correspond to an ascii value) and nothing should be emitted. >> >> That's what would bring true portability! > > LEHS is right about this. The whole point of ASCII being invented, > was to allow portability between OS's. Beating LEHS up because he is > a novice at the Unix world is missing the point --- this has nothing > to do with Forth. No one is beating up Leh because he is a novice. Leh refuses to look at the full picture and listen to reason. > It can be argued that ASCII wasn't a very good standard even at the > time that it was invented, and it is worse now. ASCII is the standard > though, and ANS-Forth does specify ASCII --- so, KEY and KEY? should > work in the same way under any ANS-Forth system running under any OS > --- but they don't. If the issues have to do with limitations in the OS, then there is nothing Forth can do about it. If the CPU uses 64 bit words and doesn't address bytes, you can't really expect a Forth to change that do you? Why would you expect a Forth to be able to figure out how the keyboard is configured and adapt the key strokes reported? > BTW: Straight Forth is not going to have CELL that can be different > values in different systems. It is going to assume a 64-bit cell --- > this allows numerical programs to be written in standard Straight > Forth --- not just numerical programs, but programs working with text > too (because the address and count are both 32-bit and can be packed > together in a single cell). Whaaaa??? A 64 bit cell but only a 32 bit address? Ok, it's your forth. Doesn't seem very straight to me, seems rather bent. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-03 23:13 +0000 |
| Message-ID | <o9ct80$vsm$1@dont-email.me> |
| In reply to | #55394 |
On 3/3/2017 22:30, rickman wrote: >> (because the address and count are both 32-bit and can be packed >> together in a single cell). > > Whaaaa??? A 64 bit cell but only a 32 bit address? It doesn't match any of the usual 64 bit models; https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-03-03 18:02 -0600 |
| Message-ID | <o9d025$8bt$1@dont-email.me> |
| In reply to | #55395 |
On 3/3/2017 5:13 PM, Alex wrote: > On 3/3/2017 22:30, rickman wrote: >>> (because the address and count are both 32-bit and can be packed >>> together in a single cell). >> >> Whaaaa??? A 64 bit cell but only a 32 bit address? > > It doesn't match any of the usual 64 bit models; > https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models > That is a little strange for a desktop to be in a 64 bit mode but to limit the addressing to 32 bits. It might be done to limit the size of the instruction but a 64 bit desktop should have tons of memory, most of my PC have 24 GB of RAM, and the smaller PCs have 16 GB of RAM. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-04 01:12 +0000 |
| Message-ID | <o9d46a$j2c$1@dont-email.me> |
| In reply to | #55396 |
On 3/4/2017 00:02, Cecil Bayona wrote: > On 3/3/2017 5:13 PM, Alex wrote: >> On 3/3/2017 22:30, rickman wrote: >>>> (because the address and count are both 32-bit and can be packed >>>> together in a single cell). >>> >>> Whaaaa??? A 64 bit cell but only a 32 bit address? >> >> It doesn't match any of the usual 64 bit models; >> https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models >> > That is a little strange for a desktop to be in a 64 bit mode but to > limit the addressing to 32 bits. > > It might be done to limit the size of the instruction but a 64 bit > desktop should have tons of memory, most of my PC have 24 GB of RAM, and > the smaller PCs have 16 GB of RAM. > x86-64 does not support 32 bit addresses and 64 bit operands. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-03 19:12 -0800 |
| Message-ID | <a98c4ff3-2b1c-4958-812b-6756065bf553@googlegroups.com> |
| In reply to | #55398 |
On Friday, March 3, 2017 at 7:12:33 PM UTC-6, Alex wrote:
>
> x86-64 does not support 32 bit addresses and 64 bit operands.
>
So (pre)allocate 4GB of memory and then use relative addressing. Or
ask for a memory location that will let you ignore the top half of the
address and go through some trouble to not have ALLOCATE and other
words break the illusion.
Hugh has this embedded/desktop dichotomy going already, he can just
say that efficiency doesn't matter as much for the desktop since it's
a luxurious super-powered environment anyway. Any extra system cost
will surely be offset by all of the amazing advantages accrued by the
programmer. Consider:
: chomp ( c-addr u -- c-addr u' ) \ "hello\n" -- "hello"
2dup + 1- c@ 10 = + ;
Disgusting. ANS Forth, everybody. Just look at it there, like a dead
animal in the middle of the road.
Meanwhile in Straight Forth:
: count ( $ -- c-addr u )
dup $FFFFFFFF00000000 and 32 rshift swap
$FFFFFFFF and ;
: straighten ( c-addr u -- $ )
swap 32 lshift or ;
: chomp ( $ -- $' ) \ "hello\n" -- "hello"
count 2dup + 1- c@ 10 = + straighten ;
I'm not crying. It's just a little bit of dust that flew into my eye.
What beautiful code! What conspiracy of ANS Forth was it that led to
modern architectures not having direct support for code like this? It
is probably because all the fault of LOCALS|
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-03 19:23 -0800 |
| Message-ID | <47bdc9ae-b31b-4c04-b3c8-2af068372ed6@googlegroups.com> |
| In reply to | #55399 |
On Friday, March 3, 2017 at 9:12:36 PM UTC-6, Julian Fondren wrote: > On Friday, March 3, 2017 at 7:12:33 PM UTC-6, Alex wrote: > > > > x86-64 does not support 32 bit addresses and 64 bit operands. > > > > So (pre)allocate 4GB of memory and then use relative addressing. Or > ask for a memory location that will let you ignore the top half of the > address and go through some trouble to not have ALLOCATE and other > words break the illusion. > > Hugh has this embedded/desktop dichotomy going already, he can just > say that efficiency doesn't matter as much for the desktop since it's > a luxurious super-powered environment anyway. Any extra system cost > will surely be offset by all of the amazing advantages accrued by the > programmer. > Actually, 32-bit Forths tend to have 64-bit floating point numbers, which tend to be on their own stack. This works in SwiftForth for example: s" hello" d>f .s <-Top 21609424000. <-NTop ok f>d type hello ok So, suppose the data stack is actually a floating point stack. Wasn't Straight Forth going to have some feature like that as well?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-05 18:45 -0800 |
| Message-ID | <3688925b-65a3-4e80-8fad-d9191bfaa93c@googlegroups.com> |
| In reply to | #55399 |
On Friday, March 3, 2017 at 8:12:36 PM UTC-7, Julian Fondren wrote: > On Friday, March 3, 2017 at 7:12:33 PM UTC-6, Alex wrote: > > > > x86-64 does not support 32 bit addresses and 64 bit operands. > > > > So (pre)allocate 4GB of memory and then use relative addressing. Or > ask for a memory location that will let you ignore the top half of the > address and go through some trouble to not have ALLOCATE and other > words break the illusion. > > Hugh has this embedded/desktop dichotomy going already, he can just > say that efficiency doesn't matter as much for the desktop since it's > a luxurious super-powered environment anyway. Any extra system cost > will surely be offset by all of the amazing advantages accrued by the > programmer. Consider: > > : chomp ( c-addr u -- c-addr u' ) \ "hello\n" -- "hello" > 2dup + 1- c@ 10 = + ; > > Disgusting. ANS Forth, everybody. Just look at it there, like a dead > animal in the middle of the road. > > > Meanwhile in Straight Forth: > > : count ( $ -- c-addr u ) > dup $FFFFFFFF00000000 and 32 rshift swap > $FFFFFFFF and ; > > : straighten ( c-addr u -- $ ) > swap 32 lshift or ; > > : chomp ( $ -- $' ) \ "hello\n" -- "hello" > count 2dup + 1- c@ 10 = + straighten ; > > I'm not crying. It's just a little bit of dust that flew into my eye. > What beautiful code! What conspiracy of ANS Forth was it that led to > modern architectures not having direct support for code like this? It > is probably because all the fault of LOCALS| Julien Fondren is a liar. In Straight Forth, all work with strings is done on the string-stack --- you never work with address and count on the data-stack like in ANS-Forth --- a packed string (address and count packed into a cell) can be held on the data-stack temporarily, and this is only done for the purpose of storing it in a data-structure (where it takes up only one cell, saving memory). It is never necessary to work with the address and count directly --- if you want to iterate through a string, you pass a quotation to a HOF that iterates through the string and gives the chars to the quotation one at a time --- all iteration in Straight Forth is done inside of HOFs; we do have BEGIN WHILE REPEAT available, but most programmers will never use them (they are only used for writing HOFs, which is advanced-level programming). I support arrays and chains --- most programmers will never use any other data-structures --- there are HOFs available for iterating through these data-structures (most programmers will never need anything else). I have a document that describes Straight Forth --- a few people have read it (none of the comp.lang.forth crowd) --- instead, the comp.lang.forth crowd have Julien Fondren telling a lot of lies...
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-05 18:54 -0800 |
| Message-ID | <6c744c6d-40a0-4130-ab7d-358e4339d1c1@googlegroups.com> |
| In reply to | #55436 |
On Sunday, March 5, 2017 at 7:45:29 PM UTC-7, hughag...@gmail.com wrote: > In Straight Forth, all work with strings is done on the string-stack --- you never work with address and count on the data-stack like in ANS-Forth --- a packed string (address and count packed into a cell) can be held on the data-stack temporarily, and this is only done for the purpose of storing it in a data-structure (where it takes up only one cell, saving memory). I said that wrong --- a string is stored from the string-stack to memory (packing it), or fetched from memory to the string-stack (unpacking it) --- the packed string is never actually held on the data-stack, even temporarily.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-05 20:47 -0800 |
| Message-ID | <411ddba1-8e6b-4f78-8d31-07cc9c0bfa14@googlegroups.com> |
| In reply to | #55436 |
On Sunday, March 5, 2017 at 8:45:29 PM UTC-6, hughag...@gmail.com wrote:
> In Straight Forth, all work with strings is done on the string-stack
I still have no idea why anyone thinks this is clever.
People at least *try* to explain why other features are useful.
> you never work with address and count on the data-stack like in ANS-Forth
OK. How is CHOMP defined in Straight Forth?
> a packed string (address and count packed into a cell) can be held on the data-stack temporarily, and this is only done for the purpose of storing it in a data-structure (where it takes up only one cell, saving memory).
>
1 1024 * 1024 * value interned-length
interned-length allocate throw value interned-strings
0 value interned-index
: pack ( intern-offset u -- packed-string )
4 cells lshift or ;
: unpack ( packed-string -- c-addr u )
dup [ -1 4 cells rshift ] literal and interned-strings +
swap 4 cells rshift ;
: intern ( c-addr u -- packed-string )
interned-index over pack -rot
interned-strings interned-index + swap
dup +to interned-index move ;
> we do have BEGIN WHILE REPEAT available, but most programmers will never use them (they are only used for writing HOFs, which is advanced-level programming).
...
> I support arrays and chains --- most programmers will never use any other data-structures --- there are HOFs available for iterating through these data-structures (most programmers will never need anything else).
Straight Forth aren't to meddle with low level string words... Only
advanced users may use simple looping constructs... arrays and chains
are all that anyone will ever need... And, previously: nobody should
use DO LOOP or double numbers or CELLS... It turns out that Mr. "ANS
Forth is a scheme to cripple Forth programmers." mainly has ideas
about restricting the kind of code that they should write. How odd.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-06 09:20 +0000 |
| Message-ID | <o9j9fk$rje$1@dont-email.me> |
| In reply to | #55438 |
On 3/6/2017 04:47, Julian Fondren wrote: > Straight Forth aren't to meddle with low level string words... Only > advanced users may use simple looping constructs... arrays and chains > are all that anyone will ever need... And, previously: nobody should > use DO LOOP or double numbers or CELLS... It turns out that Mr. "ANS > Forth is a scheme to cripple Forth programmers." mainly has ideas > about restricting the kind of code that they should write. How odd. Velvet handcuffs. Hugh's been reading 50 Shades of Grey and mistaken it for a standard proposal. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-06 05:04 -0800 |
| Message-ID | <e8325920-6724-428f-9e8a-1c4416b8ceed@googlegroups.com> |
| In reply to | #55438 |
On Sunday, March 5, 2017 at 9:47:16 PM UTC-7, Julian Fondren wrote: > Straight Forth aren't to meddle with low level string words... Only > advanced users may use simple looping constructs... arrays and chains > are all that anyone will ever need... And, previously: nobody should > use DO LOOP or double numbers or CELLS... It turns out that Mr. "ANS > Forth is a scheme to cripple Forth programmers." mainly has ideas > about restricting the kind of code that they should write. How odd. Julien Fondren is a liar. I never said that Straight Forth wouldn't have double-precision numbers --- that is a fundamental aspect of Forth --- Julien Fondren is a typical internet troll who tells lies about me continuously in the hope that I won't see his post and respond (but if I do, as above when he was posting crap code and claiming that it was Straight Forth code, then he just posts another lie as he did here when he claimed that I am opposed to double-precision numbers). Ironically, my first-ever contact with Elizabeth Rather came about because I complained that ANS-Forth lacked support for double-precision numbers. Specifically, I needed D/ for my continued-fraction program. The "Starting Forth" book says that rational approximations used with */ are a big feature of Forth (very true!) but it doesn't say how rational approximations are calculated. Obviously, to calculate a single-precision rational approximation, it is necessary to have double-precision arithmetic including D/ etc.. Most likely, Charles Moore had a Fortran program that did continued fractions and calculated his rational approximations with it, then used the ratios in his Forth programs --- that was in the 1970s --- Charles Moore wasn't expecting Forth to be competitive with Fortran at that time, although by the 1980s Forthers were expecting Forth to be used for numerical programming. I had never had any contact with Elizabeth Rather previously. In this thread however, she just came out of the blue and attacked me because I was making the obvious point that ANS-Forth lacks D/ etc.: https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote: > Hugh Aguilar wrote: > ... > > The problem is the ANS-Forth standard. Really, how obvious was the > > need for double-precision arithmetic? This could have been an > > extension to the language similar to floating-point. Compiler-writers > > working on small microprocessors could decline to implement it if they > > didn't want to. > > > > I am frustrated with the ANS-Forth standard because I believe that the > > bad design of the standard is the #1 reason for the failure of Forth > > to become an important language. Forth was doing pretty well in the > > 1980s, but we needed a standard. What we got was Forth-83, and then > > ANS-Forth-94, both of which were badly designed. With some more > > thoughtful leadership we could have succeeded. > > There are D+, D-, M*, M/, and M*/ (and the unsigned operators). These > were adequate in a very wide variety of projects over a 30 year period, > many of which were extremely computation-intensive and running on slow > 16-bit processors. > > Forth's design is pragmatic: it has functions that have been needed and > that have proven their usefulness *in Forth*, not necessarily those that > have been required in other languages. Generally speaking, Forth has > the most flexible set of *integer* arithmetic operators of any language. > In particular, M*/ was one of Chuck's most brilliant innovations. I'm > sure if Chuck were trying to do your continued fractions that is what he > would rely on. Yes, that sometimes requires thinking differently, like > many other things in Forth. > > Cheers, > Elizabeth She says that programming in Forth requires us to think differently? Really? Differently from the real world? That can't be good! This reminds me of how Alex McDonald claimed to: "do standards for a living." When asked to elaborate, he described how he works as a salesman for some corporation that is trying to claim that its product is the standard for the industry. He said that he is helping people to "think in a new way" about mass-storage. LOL All of these sales clowns are the same --- every sales clown claims to be helping people to think in a new way about some particular technology --- every sales clown claims that his or her product is the standard for the entire industry, and that all of the competitors are non-standard wannabees. Realistically, the reason why ANS-Forth doesn't have D/ is because in 1994 none of the employees at Forth Inc. knew assembly-language well enough to write D/ --- so Elizabeth Rather banned it from Forth --- now, over two decades later, D/ continues to be non-standard, and Elizabeth Rather continues to say that I'm not a Forth programmer at all (I don't brown-nose her, which apparently is the only requirement for her to say that somebody is a Forth programmer).
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-06 14:07 +0000 |
| Message-ID | <o9jq93$lv9$1@dont-email.me> |
| In reply to | #55453 |
On 3/6/2017 13:04, hughaguilar96@gmail.com wrote: > > This reminds me of how Alex McDonald claimed to: "do standards for a > living." When asked to elaborate, he described how he works as a > salesman for some corporation that is trying to claim that its > product is the standard for the industry. He said that he is helping > people to "think in a new way" about mass-storage. LOL All of these > sales clowns are the same --- every sales clown claims to be helping > people to think in a new way about some particular technology --- > every sales clown claims that his or her product is the standard for > the entire industry, and that all of the competitors are non-standard > wannabees. You didn't read a single word of what I posted, or the links; but then you're not exactly known round here for reading, comprehending, thinking or considering carefully about much at all. That's the exact opposite of what I would claim. By the way, any progress on your understanding of pointers? Can you for example sort a singly linked list with Wil Baden's sort yet? Or do the same with your inefficent sort? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-06 06:36 -0800 |
| Message-ID | <00ab1ffc-4def-483a-858c-7f3ce7a883a6@googlegroups.com> |
| In reply to | #55455 |
On Monday, March 6, 2017 at 7:07:08 AM UTC-7, Alex wrote: > On 3/6/2017 13:04, hughaguilar96@gmail.com wrote: > > > > This reminds me of how Alex McDonald claimed to: "do standards for a > > living." When asked to elaborate, he described how he works as a > > salesman for some corporation that is trying to claim that its > > product is the standard for the industry. He said that he is helping > > people to "think in a new way" about mass-storage. LOL All of these > > sales clowns are the same --- every sales clown claims to be helping > > people to think in a new way about some particular technology --- > > every sales clown claims that his or her product is the standard for > > the entire industry, and that all of the competitors are non-standard > > wannabees. > > You didn't read a single word of what I posted, or the links; but then > you're not exactly known round here for reading, comprehending, thinking > or considering carefully about much at all. That's the exact opposite of > what I would claim. What you claim is the exact opposite of the truth --- it was obvious that you are a salesman --- you claim to be a programmer, which is obviously not true. > By the way, any progress on your understanding of pointers? Can you for > example sort a singly linked list with Wil Baden's sort yet? Or do the > same with your inefficent sort? You think that you are beating me strong by claiming that I don't understand pointers. This is why I expect ANS-Forth to die --- every time that I write any code, even simple stuff like a SORT function, the ANS-Forth cult respond by making great fools out of themselves --- I don't have to shine a spotlight on the stupidity of ANS-Forth, because the cult members are shining the spotlight in the own eyes, making themselves look stupid and simultaneously blinding themselves to the real world. Anyway, I've never seen Wil Baden's much-touted SORT function. I tried to download it but the webpage was kaput. I don't really care anyway --- way back in high-school I was interested in sort algorithms --- that is a subject that every novice cuts his teeth on... My novice-package (unreleased) has SORT for arrays (uses HeapSort internally) and SORT-LIST (uses MergeSort internally) for LIST structs (my singly linked list which I use for almost all data). I previously had SORT-LIST that did an InsertionSort internally and I also had a way to convert a list into an array and use SORT on the array, then convert back to a list. All of that was inefficient and clunky, so now I just have SORT-LIST that is efficient --- as a practical matter though, the new efficient SORT-LIST (MergeSort) is only about 200 milliseconds faster than the old inefficient SORT-LIST (InsertionSort) for a list of about 4000 elements using a string as a key --- so, it didn't matter from a practical standpoint anyway. I have a version of SORT that uses QuickSort internally, but I found it to be less efficient than the version that uses HeapSort internally --- also, HeapSort has the advantage of a consistent time, whereas QuickSort efficiency varies a lot depending upon whether the data is presorted or not. Anyway, none of this matters --- I was playing around with sort algorithms for fun --- the distinction between HeapSort QuickSort and even InsertionSort is a matter of a few milliseconds and is of no practical importance.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-06 15:04 +0000 |
| Message-ID | <o9jtkr$2bl$1@dont-email.me> |
| In reply to | #55457 |
On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: > On Monday, March 6, 2017 at 7:07:08 AM UTC-7, Alex wrote: > >> By the way, any progress on your understanding of pointers? Can you >> for example sort a singly linked list with Wil Baden's sort yet? Or >> do the same with your inefficent sort? > > You think that you are beating me strong by claiming that I don't > understand pointers. This is why I expect ANS-Forth to die --- every > time that I write any code, even simple stuff like a SORT function, > the ANS-Forth cult respond by making great fools out of themselves > --- I don't have to shine a spotlight on the stupidity of ANS-Forth, > because the cult members are shining the spotlight in the own eyes, > making themselves look stupid and simultaneously blinding themselves > to the real world. > > Anyway, I've never seen Wil Baden's much-touted SORT function. I > tried to download it but the webpage was kaput. http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still confusing the heck out of you. How can it sort anything other than an array of cells? Hmm? How? > I don't really care anyway --- way back in high-school I was > interested in sort algorithms --- that is a subject that every > novice cuts his teeth on... You've obviously graduated straight to dentures. > > My novice-package (unreleased) has SORT for arrays (uses HeapSort > internally) and SORT-LIST (uses MergeSort internally) for LIST > structs (my singly linked list which I use for almost all data). I > previously had SORT-LIST that did an InsertionSort internally and I > also had a way to convert a list into an array and use SORT on the > array, then convert back to a list. This. This last sentence. This is why I keep banging on about your lack of understanding. You don't seem to understand that YOU DON'T NEED TO CONVERT ANYTHING INTO AN ARRAY. NEVER EVER. NOT AT ALL. It is possible to sort the list using HeapSort (or any other exchange sort for that matter) without having to pack & unpack everything in big rectangular boxes. > All of that was inefficient and clunky, so now I just have SORT-LIST > that is efficient --- as a practical matter though, the new efficient > SORT-LIST (MergeSort) is only about 200 milliseconds faster than the > old inefficient SORT-LIST (InsertionSort) for a list of about 4000 > elements using a string as a key --- so, it didn't matter from a > practical standpoint anyway. Unless you're sorting 40,000 items, since most sorts aren't linear-with-N consumers of CPU. But I forgot, you cut your teeth on sort math. > > I have a version of SORT that uses QuickSort internally, but I found > it to be less efficient than the version that uses HeapSort > internally --- also, HeapSort has the advantage of a consistent time, > whereas QuickSort efficiency varies a lot depending upon whether the > data is presorted or not. > > Anyway, none of this matters --- I was playing around with sort > algorithms for fun --- the distinction between HeapSort QuickSort and > even InsertionSort is a matter of a few milliseconds and is of no > practical importance. > You really don't get it. You really, really don't. This is about understanding pointers and sorts, not milliseconds of performance. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-07 07:38 -0800 |
| Message-ID | <07a1c64b-712d-47b9-8d9b-8d4b33dd4bd2@googlegroups.com> |
| In reply to | #55461 |
On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: > On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: > > My novice-package (unreleased) has SORT for arrays (uses HeapSort > > internally) and SORT-LIST (uses MergeSort internally) for LIST > > structs (my singly linked list which I use for almost all data). I > > previously had SORT-LIST that did an InsertionSort internally and I > > also had a way to convert a list into an array and use SORT on the > > array, then convert back to a list. > > This. This last sentence. This is why I keep banging on about your lack > of understanding. You don't seem to understand that YOU DON'T NEED TO > CONVERT ANYTHING INTO AN ARRAY. NEVER EVER. NOT AT ALL. It is possible > to sort the list using HeapSort (or any other exchange sort for that > matter) without having to pack & unpack everything in big rectangular > boxes. > > > All of that was inefficient and clunky, so now I just have SORT-LIST > > that is efficient --- as a practical matter though, the new efficient > > SORT-LIST (MergeSort) is only about 200 milliseconds faster than the > > old inefficient SORT-LIST (InsertionSort) for a list of about 4000 > > elements using a string as a key --- so, it didn't matter from a > > practical standpoint anyway. The novice-package now has SORT-LIST using MergeSort internally --- I was aware that converting into an array to use SORT was "inefficient and clunky" --- I had just done that as an expedient because I had SORT already available, but I don't do it now because I have taken the time to write a new SORT-LIST that uses MergeSort (this took me a full day to write).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-07 07:56 -0800 |
| Message-ID | <d0ce81da-a79d-4405-b3c3-cc98cf2ab11a@googlegroups.com> |
| In reply to | #55461 |
On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: > On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: > > Anyway, I've never seen Wil Baden's much-touted SORT function. I > > tried to download it but the webpage was kaput. > > http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still > confusing the heck out of you. How can it sort anything other than an > array of cells? Hmm? How? Okay, I found it. I glanced over Wil Baden's code and saw that it was very low-quality: 1.) He is limited to working with arrays of cells, but he doesn't support arrays of strcuts. 2.) His code is recursive, so all of those function calls take unneeded time, and duplicating the lo and hi parameters on the data-stack with 2DUP takes time. #2 isn't so bad, because on a modern x86 with CALL/RET prediction CALL and RET are pretty fast, but it was very bad in 1999 when he wrote it. #1 is the big problem. This is a pointless restriction! I am reminded of how Andrew Haley recently wrote a array definer using Iliff arrays, but weirdly he had the pointless restriction of only supporting arrays of cells. I upgraded this to support arrays of structs; this is my ARY in the novice-package. The ANS-Forth cult always fails to support arrays of structs, but instead of just learning how to support arrays of structs, they claim that their failure is a virtue and that supporting arrays of structs is somehow bad. Weird! And stupid!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-07 08:07 -0800 |
| Message-ID | <01ee77d8-1665-4d5a-9605-9838806b1aee@googlegroups.com> |
| In reply to | #55501 |
On Tuesday, 7 March 2017 15:56:36 UTC, hughag...@gmail.com wrote: > On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: > > On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: > > > Anyway, I've never seen Wil Baden's much-touted SORT function. I > > > tried to download it but the webpage was kaput. > > > > http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still > > confusing the heck out of you. How can it sort anything other than an > > array of cells? Hmm? How? > > Okay, I found it. I glanced over Wil Baden's code and saw that it was very low-quality: > 1.) He is limited to working with arrays of cells, but he doesn't support arrays of strcuts. Is that right? I only briefly looked at his code, but it looks like it's built on the concept of a deferred word called PRECEDES that takes two addresses and returns a Boolean. That means that the *implementation* of PRECEDES is free to do anything with those addresses. They might be the addresses of two cells in an array, but they might be the addresses of two structures that PRECEDES (and associated helper words) would examine and compare. Heck, addr_1 could the be address of a structure on one machine, and addr_2 the address of a structure on another machine that is interrogated over a network connection. The sort algorithm doesn't care. It's only interested in the *output* of PRECEDES. Of course, EXCHANGE would have to be changed according to the datum being sorted. I'd argue it should also be a deferred word to make that clearer. It's not in Wil's code. Like I say I only really glanced at the code so I could be making a total idiot of myself here. It wouldn't be the first time ;-)
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web