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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-06 09:55 -0800 |
| Message-ID | <a6438ec4-7b51-447f-8afd-a6569e678df9@googlegroups.com> |
| In reply to | #55463 |
I never write about trolls. It's a bad thing do do. Trolling people often like when discussions has come that way off. But everybody that is dishonnest in a discussion is trolling. And that is real bad, isn't it? Trolling in discussions about something you belive in! You may say I'm a dreamer, but I'm not the only one...
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-03-06 11:04 -0600 |
| Message-ID | <o9k4m9$uf5$1@dont-email.me> |
| In reply to | #55454 |
On 3/6/2017 7:22 AM, hughaguilar96@gmail.com wrote: > On Monday, March 6, 2017 at 2:28:37 AM UTC-7, Alex wrote: >> On 3/6/2017 02:45, hughaguilar96@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 >> >> Why? On a modern system 64bit system, saving memory (which is scalable) >> & sacrificing CPU (where we're nearly at limit, hence not scalable) is >> the absolute reverse of what you should be pursuing. > > Data structures can be huge, so storing a string in one cell rather than two could save a lot of memory --- data-cache thrashing is a major speed sink, so saving memory is the same as improving speed. > > Straight Forth is a standard, so it describes behavior rather than implementation. > > As a practical matter though, it is worthwhile to design it in such a manner that implementation will be efficient on modern desktop-computers. My own implementation is ITC, and I expect that most implementations will be ITC for a while, although STC is possible. > > In an ITC system, it is worthwhile to make the string-stack be part of the standard. This allows all of the string-stack words to be primitives written in assembly-language. By comparison, ANS-Forth doesn't have a string-stack as part of the standard. I wrote STRING-STACK.4TH which is ANS-Forth --- in order for it to be ANS-Forth however, then it has to be written in Forth, and hence it has to depend upon the compiler's optimizer in order to be efficient (it is pretty efficient in VFX and is much less efficient in SwiftForth). > > Such a low-level and fundamental aspect of Forth as the string-stack should be part of the standard so it can be written in assembly-language for efficiency. Also, a lot of the Forth language (such as <# etc.) rely on having a string-stack, so if these words are going to be standard then the string-stack has to be standard also. > I have quite a few systems in my house, the smaller CPUs are Quad Core with 16 GB of RAM. The exception is this PC, it has 16GB of RAM but it can't be used because it is running Windows 7 32 bit OS for compatibility with very old software, everyone else is running 64 bit Windows 10. You mentioned before you want Straight Forth for CNC applications, what company would buy a PC for that purpose and saddle it with small amounts of RAM? But I will say this, I have worked on the CNC industry designing hardware and writing software and it does not take a whole lot resources except good software to run a CNC or have a PC to program a CNC controller, specially programming is a very simple straight forward application. Forth would do exceedingly well at such a task. I would not design a system based on the premise that the user is going to be cheap and not have an adequate amount of RAM. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-07 07:44 -0800 |
| Message-ID | <0e6901e4-6a3a-46f2-a188-1e63d3306376@googlegroups.com> |
| In reply to | #55466 |
On Monday, March 6, 2017 at 10:04:50 AM UTC-7, Cecil - k5nwa wrote: > On 3/6/2017 7:22 AM, hughaguilar96@gmail.com wrote: > > On Monday, March 6, 2017 at 2:28:37 AM UTC-7, Alex wrote: > >> On 3/6/2017 02:45, hughaguilar96@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 > >> > >> Why? On a modern system 64bit system, saving memory (which is scalable) > >> & sacrificing CPU (where we're nearly at limit, hence not scalable) is > >> the absolute reverse of what you should be pursuing. > > > > Data structures can be huge, so storing a string in one cell rather than two could save a lot of memory --- data-cache thrashing is a major speed sink, so saving memory is the same as improving speed. > > > > Straight Forth is a standard, so it describes behavior rather than implementation. > > > > As a practical matter though, it is worthwhile to design it in such a manner that implementation will be efficient on modern desktop-computers. My own implementation is ITC, and I expect that most implementations will be ITC for a while, although STC is possible. > > > > In an ITC system, it is worthwhile to make the string-stack be part of the standard. This allows all of the string-stack words to be primitives written in assembly-language. By comparison, ANS-Forth doesn't have a string-stack as part of the standard. I wrote STRING-STACK.4TH which is ANS-Forth --- in order for it to be ANS-Forth however, then it has to be written in Forth, and hence it has to depend upon the compiler's optimizer in order to be efficient (it is pretty efficient in VFX and is much less efficient in SwiftForth). > > > > Such a low-level and fundamental aspect of Forth as the string-stack should be part of the standard so it can be written in assembly-language for efficiency. Also, a lot of the Forth language (such as <# etc.) rely on having a string-stack, so if these words are going to be standard then the string-stack has to be standard also. > > > > I have quite a few systems in my house, the smaller CPUs are Quad Core > with 16 GB of RAM. The exception is this PC, it has 16GB of RAM but it > can't be used because it is running Windows 7 32 bit OS for > compatibility with very old software, everyone else is running 64 bit > Windows 10. > > You mentioned before you want Straight Forth for CNC applications, what > company would buy a PC for that purpose and saddle it with small amounts > of RAM? But I will say this, I have worked on the CNC industry designing > hardware and writing software and it does not take a whole lot resources > except good software to run a CNC or have a PC to program a CNC > controller, specially programming is a very simple straight forward > application. Forth would do exceedingly well at such a task. > > I would not design a system based on the premise that the user is going > to be cheap and not have an adequate amount of RAM. Adequate for what? My point was that I couldn't think of any application that needed more than 4GB of RAM --- first-person shoot-em-up games and browsers are the only programs that I can think of that need more than 4GB of RAM, but I'm not interested in writing either with Straight Forth --- maybe "big data" programs too, which is something I'm interested in, so that would be a reason to support the full 64-bit address.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-03-07 10:50 -0600 |
| Message-ID | <o9mo8a$i5f$1@dont-email.me> |
| In reply to | #55499 |
On 3/7/2017 9:44 AM, hughaguilar96@gmail.com wrote: > On Monday, March 6, 2017 at 10:04:50 AM UTC-7, Cecil - k5nwa wrote: >> On 3/6/2017 7:22 AM, hughaguilar96@gmail.com wrote: >>> On Monday, March 6, 2017 at 2:28:37 AM UTC-7, Alex wrote: >>>> On 3/6/2017 02:45, hughaguilar96@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 >>>> >>>> Why? On a modern system 64bit system, saving memory (which is scalable) >>>> & sacrificing CPU (where we're nearly at limit, hence not scalable) is >>>> the absolute reverse of what you should be pursuing. >>> >>> Data structures can be huge, so storing a string in one cell rather than two could save a lot of memory --- data-cache thrashing is a major speed sink, so saving memory is the same as improving speed. >>> >>> Straight Forth is a standard, so it describes behavior rather than implementation. >>> >>> As a practical matter though, it is worthwhile to design it in such a manner that implementation will be efficient on modern desktop-computers. My own implementation is ITC, and I expect that most implementations will be ITC for a while, although STC is possible. >>> >>> In an ITC system, it is worthwhile to make the string-stack be part of the standard. This allows all of the string-stack words to be primitives written in assembly-language. By comparison, ANS-Forth doesn't have a string-stack as part of the standard. I wrote STRING-STACK.4TH which is ANS-Forth --- in order for it to be ANS-Forth however, then it has to be written in Forth, and hence it has to depend upon the compiler's optimizer in order to be efficient (it is pretty efficient in VFX and is much less efficient in SwiftForth). >>> >>> Such a low-level and fundamental aspect of Forth as the string-stack should be part of the standard so it can be written in assembly-language for efficiency. Also, a lot of the Forth language (such as <# etc.) rely on having a string-stack, so if these words are going to be standard then the string-stack has to be standard also. >>> >> >> I have quite a few systems in my house, the smaller CPUs are Quad Core >> with 16 GB of RAM. The exception is this PC, it has 16GB of RAM but it >> can't be used because it is running Windows 7 32 bit OS for >> compatibility with very old software, everyone else is running 64 bit >> Windows 10. >> >> You mentioned before you want Straight Forth for CNC applications, what >> company would buy a PC for that purpose and saddle it with small amounts >> of RAM? But I will say this, I have worked on the CNC industry designing >> hardware and writing software and it does not take a whole lot resources >> except good software to run a CNC or have a PC to program a CNC >> controller, specially programming is a very simple straight forward >> application. Forth would do exceedingly well at such a task. >> >> I would not design a system based on the premise that the user is going >> to be cheap and not have an adequate amount of RAM. > > Adequate for what? > > My point was that I couldn't think of any application that needed more than 4GB of RAM --- first-person shoot-em-up games and browsers are the only programs that I can think of that need more than 4GB of RAM, but I'm not interested in writing either with Straight Forth --- maybe "big data" programs too, which is something I'm interested in, so that would be a reason to support the full 64-bit address. > Adequate to run the OS, tools, and applications, with 64 bit OS I would think of 8GB as a minimum. The OS runs better when it has a lot of RAM available to it. Still for most applications 8GB is plenty, I run Virtualization a lot so in that case one can't get enough RAM, my five main PCs have 24GB of RAM, everyone else has 16GB both those limits are due to the motherboard otherwise they would have more RAM, virtualization eats a lot of RAM, 24 GB seems to be plenty. Granted that while using Forth 4 GB is lots of room for programs, Windows will eat at least 1.5GB leaving 2.5GB which is still a lot unless there is tons of data. Linux uses less resources so more RAM is available for programs. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-03-08 11:30 +0000 |
| Message-ID | <MPG.3329fbb4d5f222969896f7@news.virginmedia.com> |
| In reply to | #55506 |
In article <o9mo8a$i5f$1@dont-email.me>, cbayona@cbayona.com says... > > Adequate to run the OS, tools, and applications, with 64 bit OS I would > think of 8GB as a minimum. > > My windows-7 64 development system reports 675Mb with 1MB reserved for hardware on boot. That includes some extra drivers and other stuff I have plugged in.. Only applications need more - video editing is another popular memory eater. I've never needed more than 4GB myself. I suspect that system ram usage could fall when the new high speed system buses are developed to break through the current irritating bottleneck (system bus to SSD) With memory paging on such a bus core memory becomes mostly a secondary concern for the majority of users I'd think. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-08 13:37 +0000 |
| Message-ID | <2017Mar8.143732@mips.complang.tuwien.ac.at> |
| In reply to | #55539 |
john <anon@example.com> writes:
>I suspect that system ram usage could fall when the new high speed system
>buses are developed to break through the current irritating bottleneck (system
>bus to SSD)
>
>With memory paging on such a bus core memory becomes mostly a secondary
>concern for the majority of users I'd think.
Core memory <https://en.wikipedia.org/wiki/Magnetic-core_memory> died
out in the 1970s.
Great advances in non-volatile memory have been predicted in the last
few years. E.g., Intel's Kaby Lake has support "Optane Memory" as one
of its flagship features (but Optane Memory did not show up in time).
Anyway, if these memory technologies replace DRAM, the programming
model will still have a large random-access address space (that the
system you imagine would access with paging); indeed, the addressable
memory will be even larger than with DRAM, because the cost per bit
will be lower (otherwise, there is no way that this memory can replace
DRAM). And while you don't need more than 640KB of RAM for every
application, there are applications where you need more than 640KB,
and others where you can do more with more than 640KB; and the same is
true for the 4GB boundary.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-08 14:14 +0000 |
| Message-ID | <o9p3e4$dm3$1@dont-email.me> |
| In reply to | #55542 |
On 3/8/2017 13:37, Anton Ertl wrote: > john <anon@example.com> writes: >> I suspect that system ram usage could fall when the new high speed system >> buses are developed to break through the current irritating bottleneck (system >> bus to SSD) NVMe; see http://www.nvmexpress.org/ >> >> With memory paging on such a bus core memory becomes mostly a secondary >> concern for the majority of users I'd think. > > Core memory <https://en.wikipedia.org/wiki/Magnetic-core_memory> died > out in the 1970s. > > Great advances in non-volatile memory have been predicted in the last > few years. E.g., Intel's Kaby Lake has support "Optane Memory" as one > of its flagship features (but Optane Memory did not show up in time). 3D Xpoint. It's a joint venture between Micron & Intel. > > Anyway, if these memory technologies replace DRAM, the programming > model will still have a large random-access address space (that the > system you imagine would access with paging); indeed, the addressable > memory will be even larger than with DRAM, because the cost per bit > will be lower (otherwise, there is no way that this memory can replace > DRAM). And while you don't need more than 640KB of RAM for every > application, there are applications where you need more than 640KB, > and others where you can do more with more than 640KB; and the same is > true for the 4GB boundary. The early proposals are for memory mapped functionality see http://pmem.io -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-03-08 15:16 +0100 |
| Message-ID | <o9p3oh$up3$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55542 |
In article <2017Mar8.143732@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >john <anon@example.com> writes: >>I suspect that system ram usage could fall when the new high speed system >>buses are developed to break through the current irritating bottleneck (system >>bus to SSD) >> >>With memory paging on such a bus core memory becomes mostly a secondary >>concern for the majority of users I'd think. > >Core memory <https://en.wikipedia.org/wiki/Magnetic-core_memory> died >out in the 1970s. In fact it is back in the new MSP430 FRAM chips, available now. They behave exactly like core memory. The memory remains if the chip is turned off. Writing to memory is magnetizing a small thingy probably more a plating around a wire then a core It is not substantially slower than writing to RAM, at least in the realm of MSP430 microcontrollers. Willem Ouwerkerk is adapting Noforth to have an even simpler Forth development environment. Facilities to allow erasure of flash memory and compilation to flash are replaced by facilities to protect parts of the fram. in order not to loose the Forth itself. This will probably be presented at the Forth Tagung in Germany in april. <SNIP> >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-03-08 16:14 +0000 |
| Message-ID | <MPG.332a3e278f3770f39896fa@news.virginmedia.com> |
| In reply to | #55545 |
In article <o9p3oh$up3$1@cherry.spenarnc.xs4all.nl>, albert@cherry.spenarnc.xs4all.nl says... > > Willem Ouwerkerk is adapting Noforth to have an even simpler > Forth development environment. Facilities to allow erasure of flash > memory and compilation to flash are replaced by facilities to > protect parts of the fram. in order not to loose the Forth itself. > This will probably be presented at the Forth Tagung in Germany > in april. > > <SNIP> > Sounds interesting. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-03-08 14:49 +0000 |
| Message-ID | <MPG.332a2a51259791669896f9@news.virginmedia.com> |
| In reply to | #55542 |
In article <2017Mar8.143732@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at says... > > john <anon@example.com> writes: > >I suspect that system ram usage could fall when the new high speed system > >buses are developed to break through the current irritating bottleneck (system > >bus to SSD) > > > >With memory paging on such a bus core memory becomes mostly a secondary > >concern for the majority of users I'd think. > > Core memory <https://en.wikipedia.org/wiki/Magnetic-core_memory> died > out in the 1970s. > I know - I suspect I was one of the last to use it. Poor choice of word on my part perhaps. But I think you missunderstood what I was trying to suggest. The main system bottleneck is now as always the I/O - and with the advent of SSD's we find the system bus itself cannot keep up with the speed. Hence all SSD's today are operating significantly slower than they could. This is now being addressed by manufacturers. Once that issue is corrected the paging in and out of ram will be suficiently fast enough that vast quantities of main system (working) ram (DRAM if you like) will not be required in addition to SSD (disk) space. I could be wrong but I dont see why right now. (Unless someone has any other ideas) -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-09 10:57 -0500 |
| Message-ID | <o9rtrq$bqf$1@dont-email.me> |
| In reply to | #55454 |
On 3/6/2017 8:22 AM, hughaguilar96@gmail.com wrote: > On Monday, March 6, 2017 at 2:28:37 AM UTC-7, Alex wrote: >> On 3/6/2017 02:45, hughaguilar96@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 >> >> Why? On a modern system 64bit system, saving memory (which is >> scalable) & sacrificing CPU (where we're nearly at limit, hence >> not scalable) is the absolute reverse of what you should be >> pursuing. > > Data structures can be huge, so storing a string in one cell rather > than two could save a lot of memory --- data-cache thrashing is a > major speed sink, so saving memory is the same as improving speed. The funny part is you aren't saving memory on any but the largest of machines, the 64 bit processors. Even the mobile 64 bit processors have GB of data these days. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-05 18:22 -0800 |
| Message-ID | <134d5e2e-bd26-436e-8c61-2072e6b283b1@googlegroups.com> |
| In reply to | #55396 |
On Friday, March 3, 2017 at 5:02:10 PM UTC-7, Cecil - k5nwa 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. Because the cfa is 32-bit rather than 64-bit, the threaded code is half the size --- this reduces data-cache thrashing --- note that an xt is 64-bit though; it contains a 32-bit cfa and a 32-bit pointer to the local-frame (for a quotation, or zero for a colon word). All of the addresses are relative to a base register --- the heap is in the negative half and the dictionary is in the positive half. I might change this to a 64-bit address --- if I think of some kind of program that needs more than 4GB --- games, especially first-person shoot-em-ups, need a lot memory because they have a lot of images, but this isn't anything that I'm interested in.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-04 10:48 -0800 |
| Message-ID | <0135542f-445f-474d-9948-ecbb0f41d0e4@googlegroups.com> |
| In reply to | #55394 |
> > 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. > Rick C I'm not a novice, I'm just ignorant. I have used Forth since 1983 for hobby programming. And even had an article in 4th dimension vol IX number 4. But I will never be (or claim to be) a Forth authority as some of you here on clf. But in this case I'm right. It's obvious what KEY and EKEY should do and saying that it's nothing Forth can do about how KEY and EKEY works doesn't harmonize at all with the proud motto: ANYTHING IS POSSIBLE IN FORTH! Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. It's sad that so much talent on clf is dedicated to stupid fights and rivalry. You all, and Forth, deserve a better destiny. But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. Hit me with your knowledge, but skip the bullshit.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-04 21:00 -0500 |
| Message-ID | <o9frba$3ue$2@dont-email.me> |
| In reply to | #55410 |
On 3/4/2017 1:48 PM, lehs wrote: >>> 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. > >> Rick C > > I'm not a novice, I'm just ignorant. I have used Forth since 1983 for hobby programming. And even had an article in 4th dimension vol IX number 4. But I will never be (or claim to be) a Forth authority as some of you here on clf. > > But in this case I'm right. It's obvious what KEY and EKEY should do and saying that it's nothing Forth can do about how KEY and EKEY works doesn't harmonize at all with the proud motto: > > ANYTHING IS POSSIBLE IN FORTH! > > Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. > > It's sad that so much talent on clf is dedicated to stupid fights and rivalry. You all, and Forth, deserve a better destiny. > > But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. > > Hit me with your knowledge, but skip the bullshit. Many people here have already explained to you how the OS gets in the way of Forth receiving keystrokes. What part of that do you not get? Why don't you show us how Forth should do it? Which code would you change and how? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-05 02:24 -0800 |
| Message-ID | <efa30b1d-476b-4318-8eb3-f5ac471aa978@googlegroups.com> |
| In reply to | #55411 |
Den söndag 5 mars 2017 kl. 03:00:02 UTC+1 skrev rickman: > On 3/4/2017 1:48 PM, lehs wrote: > >>> 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. > > > >> Rick C > > > > I'm not a novice, I'm just ignorant. I have used Forth since 1983 for hobby programming. And even had an article in 4th dimension vol IX number 4. But I will never be (or claim to be) a Forth authority as some of you here on clf. > > > > But in this case I'm right. It's obvious what KEY and EKEY should do and saying that it's nothing Forth can do about how KEY and EKEY works doesn't harmonize at all with the proud motto: > > > > ANYTHING IS POSSIBLE IN FORTH! > > > > Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. > > > > It's sad that so much talent on clf is dedicated to stupid fights and rivalry. You all, and Forth, deserve a better destiny. > > > > But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. > > > > Hit me with your knowledge, but skip the bullshit. > > Many people here have already explained to you how the OS gets in the > way of Forth receiving keystrokes. What part of that do you not get? > Why don't you show us how Forth should do it? Which code would you > change and how? > > -- > > Rick C How Forth should do it is explained in the document http://lars.nocrew.org/dpans/dpansa10.htm#A.10.6.2.1305 and implemented in Rufigs SP-Forth that gives raw data for all keys (press key/release key).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-05 16:44 -0500 |
| Message-ID | <o9i0m2$tp0$4@dont-email.me> |
| In reply to | #55425 |
On 3/5/2017 5:24 AM, lehs wrote: > Den söndag 5 mars 2017 kl. 03:00:02 UTC+1 skrev rickman: >> On 3/4/2017 1:48 PM, lehs wrote: >>>>> 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. >>> >>>> Rick C >>> >>> I'm not a novice, I'm just ignorant. I have used Forth since 1983 for hobby programming. And even had an article in 4th dimension vol IX number 4. But I will never be (or claim to be) a Forth authority as some of you here on clf. >>> >>> But in this case I'm right. It's obvious what KEY and EKEY should do and saying that it's nothing Forth can do about how KEY and EKEY works doesn't harmonize at all with the proud motto: >>> >>> ANYTHING IS POSSIBLE IN FORTH! >>> >>> Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. >>> >>> It's sad that so much talent on clf is dedicated to stupid fights and rivalry. You all, and Forth, deserve a better destiny. >>> >>> But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. >>> >>> Hit me with your knowledge, but skip the bullshit. >> >> Many people here have already explained to you how the OS gets in the >> way of Forth receiving keystrokes. What part of that do you not get? >> Why don't you show us how Forth should do it? Which code would you >> change and how? >> >> -- >> >> Rick C > > How Forth should do it is explained in the document > > http://lars.nocrew.org/dpans/dpansa10.htm#A.10.6.2.1305 > > and implemented in Rufigs SP-Forth that gives raw data for all keys (press key/release key). And why would that be portable? Do you think every computer reports keys the same way? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-04 20:02 -0800 |
| Message-ID | <2c39bae0-c9e8-4f4c-8f8d-b9ec3097d612@googlegroups.com> |
| In reply to | #55410 |
On Saturday, March 4, 2017 at 12:48:24 PM UTC-6, lehs wrote: > > ANYTHING IS POSSIBLE IN FORTH! > > Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. > The pertinent thing that is impossible is "eating your cake and having it too". You can't do two individually possible things that contradict each other. You can only have one of them. Here, you want 1. an EKEY that returns a single code for all of the reasonable key-chords that modern keyboards are capable of, and also 2. for your EKEY -using program to be immediately portable to hosted Forths But the point of using a gforth instead of Enth/Flux or something like that (a native Forth that runs without an OS), is precisely that gforth runs under an OS and can interact with the OS or other applications under it. And OSes intercept common keychords for their own purposes. Ctrl-C in a unix terminal, but also 'print screen' or 'ctrl-alt-del' in windowed environments. If you were only concerned about portability to a bunch of native ANS Forths, you wouldn't worry at all about EKEY - it would *definitely* do what you want. But you might then be annoyed by other matters, like a common way to get the dimensions of the screen, or to set foreground and background colors, or like how clear-and-redraw-from-scratch is blindingly fast in some environments and yet under others so slow as to make your editor unusable (OK not that likely in a native Forth.) > > But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. You say this, and at other times you say "But skip the bullshit" or "You don't like me or my postings" or you start a thread with a post that's one-third apology for having made the post. Nobody actually ever speaks ill of you or your work. There's a lot of venomous posting on clf, but doesn't that make it more obvious that the posts to you *aren't* as venomous? I imagine a fellow walking into a bar where a massive fight has broken out. Man (nervously): can I get a drink? Just a beer! Bartender: *takes out shotgun, shouts that a drunk wielding a broken bottle needs to take that outside* Bartender: sure! Here's your beer. Man (to neighbor): do you have the time? Neighbor (response interrupted by his head getting smashed into the bar): it's Neighbor: almost Neighbor: ten Man (to neighbor): thank you And so on. Later this man reports: the people at that bar are so mean! The bartender pulled out a shotgun when I asked him for a beer! When I asked a guy for the time he replied by spraying blood all over me!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-04 23:34 -0500 |
| Message-ID | <o9g4dh$j5v$2@dont-email.me> |
| In reply to | #55414 |
On 3/4/2017 11:02 PM, Julian Fondren wrote: > On Saturday, March 4, 2017 at 12:48:24 PM UTC-6, lehs wrote: >> >> ANYTHING IS POSSIBLE IN FORTH! >> >> Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. >> > > The pertinent thing that is impossible is "eating your cake and having > it too". You can't do two individually possible things that contradict > each other. You can only have one of them. Here, you want > > 1. an EKEY that returns a single code for all of the reasonable > key-chords that modern keyboards are capable of, and also > > 2. for your EKEY -using program to be immediately portable to hosted > Forths > > But the point of using a gforth instead of Enth/Flux or something like > that (a native Forth that runs without an OS), is precisely that > gforth runs under an OS and can interact with the OS or other > applications under it. And OSes intercept common keychords for their > own purposes. Ctrl-C in a unix terminal, but also 'print screen' or > 'ctrl-alt-del' in windowed environments. > > If you were only concerned about portability to a bunch of native ANS > Forths, you wouldn't worry at all about EKEY - it would *definitely* > do what you want. > > But you might then be annoyed by other matters, like a common way to > get the dimensions of the screen, or to set foreground and background > colors, or like how clear-and-redraw-from-scratch is blindingly fast > in some environments and yet under others so slow as to make your > editor unusable (OK not that likely in a native Forth.) > >> >> But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. > > You say this, and at other times you say "But skip the bullshit" or > "You don't like me or my postings" or you start a thread with a post > that's one-third apology for having made the post. Nobody actually > ever speaks ill of you or your work. There's a lot of venomous posting > on clf, but doesn't that make it more obvious that the posts to you > *aren't* as venomous? > > I imagine a fellow walking into a bar where a massive fight has broken > out. > > Man (nervously): can I get a drink? Just a beer! > > Bartender: *takes out shotgun, shouts that a drunk wielding a broken > bottle needs to take that outside* > > Bartender: sure! Here's your beer. > > Man (to neighbor): do you have the time? > > Neighbor (response interrupted by his head getting smashed into the > bar): it's > > Neighbor: almost > > Neighbor: ten > > Man (to neighbor): thank you > > And so on. Later this man reports: the people at that bar are so mean! > The bartender pulled out a shotgun when I asked him for a beer! When I > asked a guy for the time he replied by spraying blood all over me! lol clf is certainly home to some crazies. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-03-05 02:38 -0800 |
| Message-ID | <d9f4a4fe-cfbf-4c3b-ab9f-94cb19ec579d@googlegroups.com> |
| In reply to | #55414 |
Den söndag 5 mars 2017 kl. 05:02:13 UTC+1 skrev Julian Fondren: > On Saturday, March 4, 2017 at 12:48:24 PM UTC-6, lehs wrote: > > > > ANYTHING IS POSSIBLE IN FORTH! > > > > Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. > > > > The pertinent thing that is impossible is "eating your cake and having > it too". You can't do two individually possible things that contradict > each other. You can only have one of them. Here, you want > > 1. an EKEY that returns a single code for all of the reasonable > key-chords that modern keyboards are capable of, and also > > 2. for your EKEY -using program to be immediately portable to hosted > Forths > > But the point of using a gforth instead of Enth/Flux or something like > that (a native Forth that runs without an OS), is precisely that > gforth runs under an OS and can interact with the OS or other > applications under it. And OSes intercept common keychords for their > own purposes. Ctrl-C in a unix terminal, but also 'print screen' or > 'ctrl-alt-del' in windowed environments. > > If you were only concerned about portability to a bunch of native ANS > Forths, you wouldn't worry at all about EKEY - it would *definitely* > do what you want. > > But you might then be annoyed by other matters, like a common way to > get the dimensions of the screen, or to set foreground and background > colors, or like how clear-and-redraw-from-scratch is blindingly fast > in some environments and yet under others so slow as to make your > editor unusable (OK not that likely in a native Forth.) > > > > > But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. > > You say this, and at other times you say "But skip the bullshit" or > "You don't like me or my postings" or you start a thread with a post > that's one-third apology for having made the post. Nobody actually > ever speaks ill of you or your work. There's a lot of venomous posting > on clf, but doesn't that make it more obvious that the posts to you > *aren't* as venomous? > (snip) To skip the venomous part: obviously an ANS Forth implementation of EKEY should circumvent all operating systems and act according to the standard. And that works fine enough. If different systems give different press or release codes, just use several different codes for the same editor actions.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-05 16:55 -0500 |
| Message-ID | <o9i1bt$5oh$1@dont-email.me> |
| In reply to | #55426 |
On 3/5/2017 5:38 AM, lehs wrote: > Den söndag 5 mars 2017 kl. 05:02:13 UTC+1 skrev Julian Fondren: >> On Saturday, March 4, 2017 at 12:48:24 PM UTC-6, lehs wrote: >>> >>> ANYTHING IS POSSIBLE IN FORTH! >>> >>> Since anything IS possible in Forth those debacles doesn't stop me from doing an editor, it just stop me from doing a simple unsophisticated portable editor. >>> >> >> The pertinent thing that is impossible is "eating your cake and having >> it too". You can't do two individually possible things that contradict >> each other. You can only have one of them. Here, you want >> >> 1. an EKEY that returns a single code for all of the reasonable >> key-chords that modern keyboards are capable of, and also >> >> 2. for your EKEY -using program to be immediately portable to hosted >> Forths >> >> But the point of using a gforth instead of Enth/Flux or something like >> that (a native Forth that runs without an OS), is precisely that >> gforth runs under an OS and can interact with the OS or other >> applications under it. And OSes intercept common keychords for their >> own purposes. Ctrl-C in a unix terminal, but also 'print screen' or >> 'ctrl-alt-del' in windowed environments. >> >> If you were only concerned about portability to a bunch of native ANS >> Forths, you wouldn't worry at all about EKEY - it would *definitely* >> do what you want. >> >> But you might then be annoyed by other matters, like a common way to >> get the dimensions of the screen, or to set foreground and background >> colors, or like how clear-and-redraw-from-scratch is blindingly fast >> in some environments and yet under others so slow as to make your >> editor unusable (OK not that likely in a native Forth.) >> >>> >>> But please, beat me up! Then I learn something. As when you criticized my big integers and sets on separate stacks. Your criticism was very constructive and my code become about ten times faster. >> >> You say this, and at other times you say "But skip the bullshit" or >> "You don't like me or my postings" or you start a thread with a post >> that's one-third apology for having made the post. Nobody actually >> ever speaks ill of you or your work. There's a lot of venomous posting >> on clf, but doesn't that make it more obvious that the posts to you >> *aren't* as venomous? >> (snip) > > To skip the venomous part: obviously an ANS Forth implementation of > EKEY should circumvent all operating systems and act according to the > standard. And that works fine enough. If different systems give > different press or release codes, just use several different codes > for the same editor actions. That would work great if *all* codes were unique. What happens if system A reports 0x0008 for the pressing backspace key and system B reports a 0x0008 for pressing the cntl-H key? Then each keypress would need to have a system identifier attached to the keycode making them all unique. All this does in the end is push the logic of translating keys to the application program rather than the OS or the Forth. How would such an approach work with an attached serial port device, if you were connected to your application via telnet, for example? I don't believe there is any practical way to get raw key codes from a remote device or to know when a key is released as opposed to being pressed. What are the use cases for your editor? Will it only be used on PCs? Obviously it won't be used on tablets or with any remote terminal interface, no? It just makes no sense that you are blaming Forth for all the issues of UI on modern computers. If you want a universal interface, you need to design to the common subset of keys found on the universally found interfaces. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web