I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
I always worry about using PAD, but it seems ok in this case. The string is being handed to another word and is used right away. It is the prompt in a user control point in the program. "Hit any key for this and any other key for that", sort of thing.
I should just put it off until tomorrow, but I sleep better knowing a thing is done.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
2) If it works why are you bothered by usage?
NN <novembe...@gmail.com> writes:
2) If it works why are you bothered by usage?If you try something and it works when you try it, that only means that
it worked the time you tried it. I.e. that it works at least some of
the time.
It is preferable to write code that always works. For that, you have to
know what it is actually doing, not just what it appears to do.
On Friday, 27 May 2022 at 06:20:57 UTC+1, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
I always worry about using PAD, but it seems ok in this case. The string is being handed to another word and is used right away. It is the prompt in a user control point in the program. "Hit any key for this and any other key for that", sort of thing.
I should just put it off until tomorrow, but I sleep better knowing a thing is done.
--
Rick C.
- Get 1,000 miles of free Supercharging1) What does writing to a S" mean?
- Tesla referral code - https://ts.la/richard11209
2) If it works why are you bothered by usage?
3) What's a proper buffer ?
NN <novembe...@gmail.com> writes:
2) If it works why are you bothered by usage?If you try something and it works when you try it, that only means that
it worked the time you tried it. I.e. that it works at least some of
the time.
It is preferable to write code that always works. For that, you have to
know what it is actually doing, not just what it appears to do.
On Friday, May 27, 2022 at 4:21:15 AM UTC-4, NN wrote:thing.
On Friday, 27 May 2022 at 06:20:57 UTC+1, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
I always worry about using PAD, but it seems ok in this case. The string is being handed to another word and is used right away. It is the prompt in a user control point in the program. "Hit any key for this and any other key for that", sort of
I should just put it off until tomorrow, but I sleep better knowing a thing is done.
--
Rick C.
S" Channel 0 audio test has ERRORS, Repeating test"- Get 1,000 miles of free Supercharging1) What does writing to a S" mean?
- Tesla referral code - https://ts.la/richard11209
3DUP DROP 8 CHARS + SWAP '0' + C! UserPrompt
UserPrompt is a word that handles the prompt to the user and the response. This string is in RAM in a PC and appears to not be protected from writing, but I think this is not valid and may not work in all cases.
2) If it works why are you bothered by usage?The same reason why I don't drive on bald tires. Yeah, they work ok until something else happens...
3) What's a proper buffer ?If you don't know what a buffer is, then we don't need to continue the conversation. Are you being facetious?
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
On Friday, 27 May 2022 at 18:43:38 UTC+1, gnuarm.del...@gmail.com wrote:thing.
On Friday, May 27, 2022 at 4:21:15 AM UTC-4, NN wrote:
On Friday, 27 May 2022 at 06:20:57 UTC+1, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
I always worry about using PAD, but it seems ok in this case. The string is being handed to another word and is used right away. It is the prompt in a user control point in the program. "Hit any key for this and any other key for that", sort of
I should just put it off until tomorrow, but I sleep better knowing a thing is done.
--
Rick C.
S" Channel 0 audio test has ERRORS, Repeating test"- Get 1,000 miles of free Supercharging1) What does writing to a S" mean?
- Tesla referral code - https://ts.la/richard11209
3DUP DROP 8 CHARS + SWAP '0' + C! UserPrompt
UserPrompt is a word that handles the prompt to the user and the response. This string is in RAM in a PC and appears to not be protected from writing, but I think this is not valid and may not work in all cases.Why do you believe its not valid and can you expand further as to under what conditions it may not work
Stick to forth unless you are trolling2) If it works why are you bothered by usage?The same reason why I don't drive on bald tires. Yeah, they work ok until something else happens...
Its your terminology .3) What's a proper buffer ?If you don't know what a buffer is, then we don't need to continue the conversation. Are you being facetious?
If you need to ask the answer is obviously NO !
3) What's a proper buffer ?
On Friday, May 27, 2022 at 12:55:11 PM UTC-4, Paul Rubin wrote:
NN <novembe...@gmail.com> writes:
2) If it works why are you bothered by usage?If you try something and it works when you try it, that only means that
it worked the time you tried it. I.e. that it works at least some of
the time.
It is preferable to write code that always works. For that, you have to
know what it is actually doing, not just what it appears to do.
I probably wrote the original code that way because manipulating such strings is
a bit of a PITA.
On 28/05/2022 03:48, Rick C wrote:
On Friday, May 27, 2022 at 12:55:11 PM UTC-4, Paul Rubin wrote:
NN <novembe...@gmail.com> writes:
2) If it works why are you bothered by usage?If you try something and it works when you try it, that only means that
it worked the time you tried it. I.e. that it works at least some of
the time.
It is preferable to write code that always works. For that, you have to
know what it is actually doing, not just what it appears to do.
I probably wrote the original code that way because manipulating such strings isManipulating strings is so common that it's worth having the tools
a bit of a PITA.
\ Resident functions in DX-Forth
: (D.) ( d -- a u ) tuck dabs <# #s rot sign #> ;
: (.) ( n -- a u ) s>d (d.) ;
: +STRING ( a1 u1 a2 u2 -- a2 u1+u2 ) 2swap swap 2over + 2 pick move + ;
: >PAD ( a u -- a2 u ) pad 0 +string ;
: ChanErr$ ( chan# -- a u )
(.) s" Channel " >pad +string
s" audio test has ERRORS, Repeating test" 2swap +string ;
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
On Friday, May 27, 2022 at 12:20:57 AM UTC-5, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
If you are over writing an existing string, you had better check that you
do not overflow the existing string's buffer. Buffer overflows are nasty because their corruptions may not show up until much later leaving no clue
as to the problem.
For a string that needs to change use a string variable which has a maximum size with which to test before writing into the string buffer.
I have some old code that is writing to a S" string on a PC under Windows.
It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote: >> I have some old code that is writing to a S" string on a PC under Windows. >> It seems to work, but it appears to be a not so valid usage. Should I do this
using a proper buffer?
Technically, an implementer may do with S" whatever they want:
"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall >be no less than 80 characters. Subsequent uses of S" may overwrite the >temporary buffer. At least one such buffer shall be provided".
So - you may assume that whatever is there is both limited in time and
space. My suggestion would be: if you want to do anything fancy with it and want
it to run on as many platforms as possible, copy it ASAP to a buffer of your own.
That's what I suggest to the users of my own compiler anyway: >https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/
Hans Bezemer
In article <251f2cc0-c7a3-4e3b-b1f1-abd83b7fa432n@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote: >>> I have some old code that is writing to a S" string on a PC under Windows. >>> It seems to work, but it appears to be a not so valid usage. Should I do this
using a proper buffer?
Technically, an implementer may do with S" whatever they want:
"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall >>be no less than 80 characters. Subsequent uses of S" may overwrite the >>temporary buffer. At least one such buffer shall be provided".
Actually, they don't. I store the content of S" in the dictionary not
in a temporary buffer. This is more or less illegal.
I have yet to come accross a program that relies on the fact that HERE
is not changed by S" .
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do thisTechnically, an implementer may do with S" whatever they want:
using a proper buffer?
"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall be no less than 80 characters. Subsequent uses of S" may overwrite the temporary buffer. At least one such buffer shall be provided".
So - you may assume that whatever is there is both limited in time and
space. My suggestion would be: if you want to do anything fancy with it and want
it to run on as many platforms as possible, copy it ASAP to a buffer of your own.
That's what I suggest to the users of my own compiler anyway: https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/
On Tuesday, June 7, 2022 at 7:14:46 AM UTC-4, the.bee...@gmail.com wrote:
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows.Technically, an implementer may do with S" whatever they want:
It seems to work, but it appears to be a not so valid usage. Should I do this
using a proper buffer?
"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall
be no less than 80 characters. Subsequent uses of S" may overwrite the temporary buffer. At least one such buffer shall be provided".
So - you may assume that whatever is there is both limited in time and space. My suggestion would be: if you want to do anything fancy with it and want
it to run on as many platforms as possible, copy it ASAP to a buffer of your own.
That's what I suggest to the users of my own compiler anyway: https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
Instead it says,
3.3.3.4
Text-literal regions
The text-literal regions, specified by strings compiled with S", S\" and C" may be read-only.
A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only
system variable or read-only transient regions.
On 8/06/2022 02:10, albert wrote:
In article <251f2cc0-c7a3-4e3b...@googlegroups.com>,
Hans Bezemer <the.bee...@gmail.com> wrote:
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows.
It seems to work, but it appears to be a not so valid usage. Should I do this
using a proper buffer?
Technically, an implementer may do with S" whatever they want:
"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall
be no less than 80 characters. Subsequent uses of S" may overwrite the >>temporary buffer. At least one such buffer shall be provided".
Actually, they don't. I store the content of S" in the dictionary notIs that a challenge? :)
in a temporary buffer. This is more or less illegal.
I have yet to come accross a program that relies on the fact that HERE
is not changed by S" .
Funny because after 40 years of Forth Inc using the same variable for
two [presumed] mutually exclusive functions, an ANS programmer came up
with a code snippet that broke it. Long story short, Forth Inc caved
in. God's in his heaven. All's right with the world once again!
I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
Instead it says,
3.3.3.4
Text-literal regions
The text-literal regions, specified by strings compiled with S", S\" and C" may be read-only.
A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only
system variable or read-only transient regions.
On Wednesday, June 8, 2022 at 5:31:10 AM UTC+2, gnuarm.del...@gmail.com wrote:
I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
Instead it says,
3.3.3.4That may be because I quote the ANS-94 version. AFAIK every other incarnation of any Forth standard
Text-literal regions
The text-literal regions, specified by strings compiled with S", S\" and C" may be read-only.
A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only
system variable or read-only transient regions.
is *not* ANS.
I've seen some people claim FIG was a standard, simply by example.It may have been a "de facto standard" if you want. But it wasn't backed by
Ok, I'm not going to argue that, even if I feel it is disingenuous.Since when is simply stating mere facts "disingenuous"?!
On Wednesday, June 8, 2022 at 2:56:26 PM UTC+2, gnuarm.del...@gmail.com wrote:
I've seen some people claim FIG was a standard, simply by example.It may have been a "de facto standard" if you want. But it wasn't backed by any international standards body.
And "claims" by "some people" is not only "weasel speak", it's also quite possible
that some people DON'T consider it a standard - which evens it out and makes the statement kind of superfluous.
Ok, I'm not going to argue that, even if I feel it is disingenuous.Since when is simply stating mere facts "disingenuous"?!
And it's an ambivalent statement as well. Is implied here that
the act of stating it is "disingenuous" or is the person stating it "disingenuous". Be careful! You might hurt someones feelings.
gnuarm.del...@gmail.com schrieb am Mittwoch, 8. Juni 2022 um 05:31:10 UTC+2: >> On Tuesday, June 7, 2022 at 7:14:46 AM UTC-4, the.bee...@gmail.com wrote:wn.
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
I have some old code that is writing to a S" string on a PC under Windows.Technically, an implementer may do with S" whatever they want:
It seems to work, but it appears to be a not so valid usage. Should I do this
using a proper buffer?
"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall
be no less than 80 characters. Subsequent uses of S" may overwrite the
temporary buffer. At least one such buffer shall be provided".
So - you may assume that whatever is there is both limited in time and
space. My suggestion would be: if you want to do anything fancy with it and want
it to run on as many platforms as possible, copy it ASAP to a buffer of your o
I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
That's what I suggest to the users of my own compiler anyway:
https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/
Instead it says,
3.3.3.4
Text-literal regions
The text-literal regions, specified by strings compiled with S", S\" and C" may be read-only.
A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only
system variable or read-only transient regions.
Avoiding wordsmithing:
Since interpretation and compilation of S\" can become mixed (and appear within strings
for EVALUATE, even nested EVALUATEs or macros) I would not be happy to use HERE
for buffering.
Sorry,, what Forth standards are there which are not ANS?
As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?
On 8/06/2022 21:22, Gerry Jackson wrote:
As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?
Not a bug.
You got them on an ANS technicality - namely there's nothing
in ANS which explicitly prevents a programmer from mixing number input
and output.
That Forth Inc had no such need - indeed their systems were
designed on that basis
- with apparently no complaints for over 40 years,
was irrelevant to you.
"Sorry,, what Forth standards are there which are not ANS?"
It seems this one was accepted by ANSI: https://webstore.ansi.org/Standards/INCITS/ansix32151994Sorry,, what Forth standards are there which are not ANS?Within the limits of a definition of "standard",
FIG, Forth-79, Forth-83, ANS-94, Forth-2012
Why do you quibble about totally unimportant points while ignoring the purpose of my post?I don't. If you choose to use a pejorative term for me stating a simple fact you'll be called out.
"Sorry,, what Forth standards are there which are not ANS?"I found only one: ANS-94 - technically: ANSI X3215-1994.
On Wednesday, June 8, 2022 at 8:32:04 AM UTC-4, the.bee...@gmail.com wrote:
On Wednesday, June 8, 2022 at 5:31:10 AM UTC+2, gnuarm.del...@gmail.com wrote:
I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
Sorry,, what Forth standards are there which are not ANS?
Within the limits of a definition of "standard",
FIG, Forth-79, Forth-83, ANS-94, Forth-2012
Note that from Forth-2012 onwards, the latest document supersedes previous >documents.
On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:
On 8/06/2022 21:22, Gerry Jackson wrote:
Not a bug.
As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?
If some valid Forth code causes a standard Forth system to crash, that's a bug in my book and no amount of weasel wording will change my mind. [...]
On 8/06/2022 22:56, Rick C wrote:
On Wednesday, June 8, 2022 at 8:32:04 AM UTC-4, the.bee...@gmail.com wrote: >>> On Wednesday, June 8, 2022 at 5:31:10 AM UTC+2, gnuarm.del...@gmail.com wrote:
I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
It was in Forth-94 (ANS) 11.6.1.2165 but has since been incorporated into 6.1.2165
Details of the "transient buffer" seem to have gone AWOL
There's a newer 'Draft'
http://www.forth200x.org/documents/forth19-1.pdf
not that it helps
Sorry,, what Forth standards are there which are not ANS?Within the limits of a definition of "standard",
FIG, Forth-79, Forth-83, ANS-94, Forth-2012
Note that from Forth-2012 onwards, the latest document supersedes previous documents.
On Wednesday, June 8, 2022 at 3:57:58 PM UTC+2, gnuarm.del...@gmail.com wrote:
Why do you quibble about totally unimportant points while ignoring the purpose of my post?I don't. If you choose to use a pejorative term for me stating a simple fact you'll be called out.
On 8/06/2022 23:57, Rick C wrote:
"Sorry,, what Forth standards are there which are not ANS?"Easier to ask which ones are.
"American National Standards Institute, Inc."
on the title page
On 9/06/2022 16:17, Rick C wrote:
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.'Google it, mate'
https://youtu.be/QxO8aF8SEYM
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.
On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:bug where valid Forth code crashed their system?
On 8/06/2022 21:22, Gerry Jackson wrote:
As for the nonsense about Forth Inc caving in - as the code above >crashed SwiftForth why would a reputable Forth system supplier not fix a
that's a bug in my book and no amount of weasel wording will change myNot a bug.
If some valid Forth code causes a standard Forth system to crash,
mind. [...]
To me it looks like a failure of ANS to recognize 40 years of practice
by a vendor.
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.
Rick C.
On Wednesday, June 8, 2022 at 10:57:32 AM UTC-4, Stephen Pelc wrote:
Within the limits of a definition of "standard",
Sorry,, what Forth standards are there which are not ANS?
FIG, Forth-79, Forth-83, ANS-94, Forth-2012
Note that from Forth-2012 onwards, the latest document supersedes previous >> documents.
I am perhaps more confused now. "ANS-94" is not ANS?
On Wednesday, June 8, 2022 at 1:47:33 PM UTC-4, the.bee...@gmail.com wrote:I don't think it's a language problem:
On Wednesday, June 8, 2022 at 3:57:58 PM UTC+2, gnuarm.del...@gmail.com wrote:Maybe this is a language problem, but I have no idea what you are talking about.
Why do you quibble about totally unimportant points while ignoring the purpose of my post?I don't. If you choose to use a pejorative term for me stating a simple fact
you'll be called out.
I also don't care so much to have any discussion that involves being "called out".Frankly, I couldn't care less about your opinions. If you don't even have the facts at hand - or take the trouble to READ stuff to get the required information -
This sounds so grade school like.
In article <812f8214-42c3-4af0...@googlegroups.com>,
Rick C <gnuarm.del...@gmail.com> wrote:
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.I hate to say this, but has this been promoted to an ISO standard?
Why refer to an "American" standard, if it is International?
ciforth means "close to ISO" because I don't want to deter
Chinese users.
In article <t7rm8t$bcd$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 9/06/2022 03:02, Gerry Jackson wrote:
On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:crashed SwiftForth why would a reputable Forth system supplier not fix a
On 8/06/2022 21:22, Gerry Jackson wrote:
As for the nonsense about Forth Inc caving in - as the code above
bug where valid Forth code crashed their system?
that's a bug in my book and no amount of weasel wording will change myNot a bug.
If some valid Forth code causes a standard Forth system to crash,
mind. [...]
Okay. Let's see. Is `` @ '' valid source code?
It certainly is. Can it crash a system? It certainly does!
To me it looks like a failure of ANS to recognize 40 years of practice
by a vendor.
If anything matters for a compiler that is stability.
There is a cost involved in fixing bugs.
Any bug fix risks to introduce other bugs.
There is a reason why ciforth went from 4.6.0 to 5.3.0 to 5.4.0
with years stability in between. And known bugs, be it a few.
On 09/06/2022 09:29, albert wrote:
In article <t7rm8t$bcd$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 9/06/2022 03:02, Gerry Jackson wrote:
On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:crashed SwiftForth why would a reputable Forth system supplier not fix a >>> bug where valid Forth code crashed their system?
On 8/06/2022 21:22, Gerry Jackson wrote:
As for the nonsense about Forth Inc caving in - as the code above
that's a bug in my book and no amount of weasel wording will change myNot a bug.
If some valid Forth code causes a standard Forth system to crash,
mind. [...]
Okay. Let's see. Is `` @ '' valid source code?
It certainly is. Can it crash a system? It certainly does!
That's a different case. If an application or user feeds an invalid
address to @ that is a program error not a system bug.
On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
In article <812f8214-42c3-4af0...@googlegroups.com>,
Rick C <gnuarm.del...@gmail.com> wrote:
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.I hate to say this, but has this been promoted to an ISO standard?
Why refer to an "American" standard, if it is International?
ciforth means "close to ISO" because I don't want to deterNot sure what that means. Does being ISO compliant offend Chinese in some way?
Chinese users.
On Thursday, June 9, 2022 at 3:18:57 AM UTC-4, dxforth wrote:
On 9/06/2022 16:17, Rick C wrote:
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:'Google it, mate'
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.
https://youtu.be/QxO8aF8SEYM
Please take your stupidity elsewhere. Thank you.
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?
In article <66d40070-80f7-469a-9fbd-b88ac8e56862n@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:
On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
In article <812f8214-42c3-4af0...@googlegroups.com>,
Rick C <gnuarm.del...@gmail.com> wrote:
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:I hate to say this, but has this been promoted to an ISO standard?
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.
Why refer to an "American" standard, if it is International?
ciforth means "close to ISO" because I don't want to deter
Chinese users.
Not sure what that means. Does being ISO compliant offend Chinese in
some way?
American Standard Compliant could. I forget the smiley.
I'm chauvinist here. I prefer to replace standards set by USA
to international standards.
--Rick C.
Groetjes Albert
On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
In article <812f8214-42c3-4af0...@googlegroups.com>,
Rick C <gnuarm.del...@gmail.com> wrote:
On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:I hate to say this, but has this been promoted to an ISO standard?
On 8/06/2022 23:57, Rick C wrote:
Easier to ask which ones are.
"Sorry,, what Forth standards are there which are not ANS?"
"American National Standards Institute, Inc."
on the title page
Except that would not answer the question at all.
Why refer to an "American" standard, if it is International?
ciforth means "close to ISO" because I don't want to deter
Chinese users.
Not sure what that means. Does being ISO compliant offend Chinese in
some way?
--
Rick C.
On 10.06.2022 03:52, Rick C wrote:
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?
https://www.iso.org/standard/26479.html
On 10.06.2022 03:52, Rick C wrote:is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there
https://www.iso.org/standard/26479.html
"THIS STANDARD WAS LAST REVIEWED AND CONFIRMED IN 2021. THEREFORE THIS
VERSION REMAINS CURRENT."
Raises more questions. Do standards ever die? :)
In article <t7v5om$hf4$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 10/06/2022 18:14, Bernd Linsel wrote:
On 10.06.2022 03:52, Rick C wrote:is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there
https://www.iso.org/standard/26479.html
"THIS STANDARD WAS LAST REVIEWED AND CONFIRMED IN 2021. THEREFORE THIS
VERSION REMAINS CURRENT."
Raises more questions. Do standards ever die? :)
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.
On 10/06/2022 21:01, albert wrote:
In article <t7v5om$hf4$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
Raises more questions. Do standards ever die? :)
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.
The ANSI/ISO one referenced above?
On 10.06.2022 03:52, Rick C wrote:
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?https://www.iso.org/standard/26479.html
On Friday, June 10, 2022 at 4:14:57 AM UTC-4, Bernd Linsel wrote:
On 10.06.2022 03:52, Rick C wrote:
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?https://www.iso.org/standard/26479.html
It's not very often that a standard has separate versions ANS and ISO for something that is truly world wide. Can someone explain what is going on? Is the standard created under ANS and then also listed with ISO?
On 11/06/2022 06:30, Rick C wrote:
On Friday, June 10, 2022 at 4:14:57 AM UTC-4, Bernd Linsel wrote:
On 10.06.2022 03:52, Rick C wrote:
Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?https://www.iso.org/standard/26479.html
It's not very often that a standard has separate versions ANS and ISO for something that is truly world wide. Can someone explain what is going on? Is the standard created under ANS and then also listed with ISO?
Forth-94 made its appearance under the ISO imprimatur in 1996 some
two years after ANSI. How and by whom is as much a mystery to me
as who reviewed and approved it in 2021. According to ISO, reviews
are conducted each 5 years with the involvement of stakeholders.
If there's an ISO standard and an ANS standard, are they the same standard
kept in sync?
Why not just have one?
Rick C <gnuarm.deletethisbit@gmail.com> writes:
If there's an ISO standard and an ANS standard, are they the same standard
Apart from the title page and such, they are the same in this case,
and that's how it should be and AFAIK usually is the case.
kept in sync?
That's an interesting question. C89/C90 was developed under the ANSI auspices ("ANSI C"), then fast-tracked as ISO standard ("ISO C"), like
ANS Forth. AFAIK they then continued on directly under ISO auspices,
and no longer under ANSI. But since ANSI is a member of ISO, any ISO standard is also valid in the USA.
Why not just have one?
If a nationally developed standard is elevated to an international
standard, as in the case of C and Forth, this by necessity means that
that standard is both.
Rick C <gnuarm.del...@gmail.com> writes:
If there's an ISO standard and an ANS standard, are they the same standard Apart from the title page and such, they are the same in this case,and that's how it should be and AFAIK usually is the case.
kept in sync?
That's an interesting question. C89/C90 was developed under the ANSI auspices ("ANSI C"), then fast-tracked as ISO standard ("ISO C"), like
ANS Forth. AFAIK they then continued on directly under ISO auspices,
and no longer under ANSI. But since ANSI is a member of ISO, any ISO standard is also valid in the USA.
Why not just have one?If a nationally developed standard is elevated to an international
standard, as in the case of C and Forth, this by necessity means that
that standard is both.
I'm chauvinist here. I prefer to replace standards set by USA
to international standards.
On Saturday, June 11, 2022 at 2:52:29 AM UTC-4, Anton Ertl wrote:
Rick C <gnuarm.del...@gmail.com> writes:
If there's an ISO standard and an ANS standard, are they the same standard >> Apart from the title page and such, they are the same in this case,and that's how it should be and AFAIK usually is the case.
kept in sync?
That's an interesting question. C89/C90 was developed under the ANSI
auspices ("ANSI C"), then fast-tracked as ISO standard ("ISO C"), like
ANS Forth. AFAIK they then continued on directly under ISO auspices,
and no longer under ANSI. But since ANSI is a member of ISO, any ISO
standard is also valid in the USA.
Why not just have one?If a nationally developed standard is elevated to an international
standard, as in the case of C and Forth, this by necessity means that
that standard is both.
Sorry, maybe that's not the question. Why continue to develop the
standard under ANS? Why not discontinue the ANS standard and only
develop the ISO standard. [...]
Why continue to develop the standard=
under ANS?
Why not discontinue the ANS standard and only develop the ISO =
standard.
Is there actually some advantage of having the ANS Forth standard in additi= >on to the ISO Forth standard?=20
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.
This suggests, that the standards become „obsolete”; actually why the need(?)
for a new standard for Forth every few years? Anything wrong with using, say, fig-Forth in 2022? Anything that needs an update — like block system prepared
for 8" drives — can be modified by the users themselves.
This suggests, that the standards become =E2=80=9Eobsolete=E2=80=9D; actual= >ly why the need(?)
for a new standard for Forth every few years?
Anything wrong with using, sa=
y,
fig-Forth in 2022?
...
Of course, you probably won't be able to run your code on a system
like Gforth, iForth, SwiftForth, or VFX, but maybe you don't care for
that.
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.
This suggests, that the standards become „obsolete”; actually why the need(?)
for a new standard for Forth every few years? Anything wrong with using, say, fig-Forth in 2022? Anything that needs an update — like block system prepared
for 8" drives — can be modified by the users themselves.
Zbig <zbigniew2011@gmail.com> writes:
This suggests, that the standards become =E2=80=9Eobsolete=E2=80=9D; actual= >>ly why the need(?)
for a new standard for Forth every few years?
The following reasons:
1) Requirements change. Around 1990 people where thinking that the
future would be 16-bit Unicode, and Forth-94 has CHARS and CHAR+ for
dealing with fixed-size characters larger than a byte (actually an
address unit). Then came Unicode 2.0, which does not fit in 16 bits;
it also turned out that converting existing software (including Forth >software) to wider fixed-size characters is not going to happen, so
UTF-8 won. As a result, Forth-2012 has the Extended Character wordset
that allows to deal with variable-width encodings like UTF-8. And
after Forth-2012, we standardized the common practice that 1 CHARS
gives 1.
2) Some things were not common practice in earlier times, but now are,
the committee could not find a consensus on the topic, but now it can,
or nobody made a proposal on the topic, but now has, so a later
standard can standardize things that were left open earlier. As an
example, Forth-2012 has standardized dealing with cursor keys, which
Forth-94 left to system implementors.
Anything wrong with using, sa=
y,
fig-Forth in 2022?
Not if you don't miss anything, just like there is nothing wrong with
using cmForth, colorForth, retroForth, or any other non-standard
system.
Of course, you probably won't be able to run your code on a system
like Gforth, iForth, SwiftForth, or VFX, but maybe you don't care for
that.
- anton
On 14 Jun 2022 at 01:22:09 CEST, "Zbig" <zbigniew2011@gmail.com> wrote:
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.
This suggests, that the standards become „obsolete”; actually why the need(?)
for a new standard for Forth every few years? Anything wrong with using, say,
fig-Forth in 2022? Anything that needs an update — like block system prepared
for 8" drives — can be modified by the users themselves.
Standards may be obsolete if they are inadequate. Forth-200x has developed new wordsets because people regularly needed support for wordsets not addressed by older versions.
Unfortunately there are still naysayers who believe that a system must support
all words and wordsets.
Forth doesn't have a standard in 200x. It's got a double standard.I think you effectively might be right. I think that nobody questions the authority of ANS-94 anymore. There may be criticism on parts - some of
I still feel that's not quite true of the Forth-200x "standard"
There hasn't been (AFAIK) been a release stating: "This is Forth
2010 and this is how it is. Moving on.." IMHO that's quite confusing to >implementers, because they can't say "This is Forth 2010 compliant" as
you can do with ANS-94, Forth-83 (yuk!) or Forth-79.
IMHO that's quite confusing to
implementers, because they can't say "This is Forth 2010 compliant"
But actually... what is "Forth 2010 compliance" good for?
As for Forth-2012 compliance: if you write a Forth-2012 program that
uses the extensions x, y, and z, it will run on Forth-2012 systems
that provide the extensions x, y, and z.
Maybe I see the things simplified way -- but in case of need there (in most cases)
shouldn't be a big problem to add/modify respective words to make the Forth >program compile properly using about any Forth compiler?
It of course depends on how much time you are willing to spend. I
have no patience for incompatibility when people could just have used standard features, and little time in other cases. But sure, if you
have enough time for porting, say, a colorForth program to retroForth
or vice versa, then you don't need standards.
Hans Bezemer <the.bee...@gmail.com> writes:Yeah, my bad. It may have been though that it still says Forth-200x,
There has been no 2010 release, but there has been the Forth-2012
release. You can find it on:
http://www.forth200x.org/documents/forth-2012.pdf https://forth-standard.org/standard/words
It surprises me that you missed that. I alone have mentioned
"Forth-2012" 550 times in comp.lang.forth.
It of course depends on how much time you are willing to spend. I
have no patience for incompatibility when people could just have used standard features, and little time in other cases. But sure, if you
have enough time for porting, say, a colorForth program to retroForth
or vice versa, then you don't need standards.
Zbig <zbigniew2011@gmail.com> writes:
Maybe I see the things simplified way -- but in case of need there (in most cases)
shouldn't be a big problem to add/modify respective words to make the Forth >>program compile properly using about any Forth compiler?
It of course depends on how much time you are willing to spend. I
have no patience for incompatibility when people could just have used standard features, and little time in other cases. But sure, if you
have enough time for porting, say, a colorForth program to retroForth
or vice versa, then you don't need standards.
On 18/06/2022 03:11, Anton Ertl wrote:
Zbig <zbigni...@gmail.com> writes:
Maybe I see the things simplified way -- but in case of need there (in most cases)
shouldn't be a big problem to add/modify respective words to make the Forth
program compile properly using about any Forth compiler?
It of course depends on how much time you are willing to spend. IExcept Forth has never had a Standard. It's not a Standard when one can
have no patience for incompatibility when people could just have used standard features, and little time in other cases. But sure, if you
have enough time for porting, say, a colorForth program to retroForth
or vice versa, then you don't need standards.
pick and choose. At most Forth has had corporate sanctioned 'common practice' which it calls a Standard because that's what [some] forthers
and ROW want to hear. It makes Forth appear respectable.
It of course depends on how much time you are willing to spend. II see the "standard" rather as set of proposals and recommendations rather than something "mandatory"; in general: "what you may want to use and how". That's why I see rather unusual the anxiety of sort "oh, boy -- if my compiler
have no patience for incompatibility when people could just have used standard features, and little time in other cases. But sure, if you
have enough time for porting, say, a colorForth program to retroForth
or vice versa, then you don't need standards.
won't conform to the newest XYZ standard it'll be considered obsolete'!" (or the like).
Any user of such "obsolescent version" is able rather easily make it (if not 100%, then
at least 99%) "compliant" to any (past, present or future) standard by adding new
words by himself; it's Forth, not C.
As for Forth-2012 compliance: if you write a Forth-2012 program thatMaybe I see the things simplified way -- but in case of need there (in most cases)
uses the extensions x, y, and z, it will run on Forth-2012 systems
that provide the extensions x, y, and z.
shouldn't be a big problem to add/modify respective words to make the Forth program compile properly using about any Forth compiler?
That's why I see rather unusual the anxiety of sort "oh, boy -- if my compiler >won't conform to the newest XYZ standard it'll be considered obsolete'!" (or the like).
Any user of such "obsolescent version" is able rather easily make it (if not 100%, then
at least 99%) "compliant" to any (past, present or future) standard by adding new
words by himself; it's Forth, not C.
Yeah, my bad. It may have been though that it still says Forth-200x,
so I think my interpretation of Forth-2012 must have been "well, they'll
bump it up again next year" :-)
It of course depends on how much time you are willing to spend. I
have no patience for incompatibility when people could just have used
standard features, and little time in other cases. But sure, if you
have enough time for porting, say, a colorForth program to retroForth
or vice versa, then you don't need standards.
I see the "standard" rather as set of proposals and recommendations rather >than something "mandatory"; in general: "what you may want to use and how". >That's why I see rather unusual the anxiety of sort "oh, boy -- if my compiler >won't conform to the newest XYZ standard it'll be considered obsolete'!" (or the like).
Any user of such "obsolescent version" is able rather easily make it (if not 100%, then
at least 99%) "compliant" to any (past, present or future) standard by adding new
words by himself; it's Forth, not C.
We are not as fast as the C++ people. They have regularly scheduledI'm not in C++ (never have) since it's a language that makes it SO EASY for programmers that nobody actually understands what's happening anymore.
releases every three years (train station model), which means that a
feature that does not make it in one standard does not lose a lot of
time. They also have many more additions to the standard, a much
bigger standardization group, and more people interested in advancing
their standard.
Anyway, Forth standardization strolls at a much more leisurely pace,I can understand that, because issues are different. E.g.
and this seems to suit many Forthers just fine. Of course, there are
those who damn the standard for not standardizing this or that
feature, and those who damn the standard as a straitjacket for
implementors and programmers; sometimes the same people damn the
standard for both.
Ad a:
I think you shouldn't meddle with the underlying architecture, just
BECAUSE we saw in Forth-83 what happens ("words are two address
units").
Ad b:
There are plenty of COMUS words like PLACE, +PLACE and BOUNDS which
should finally be included. Most implementations support them.
I used the SUBSTITUTE wordset only
once (and then I was happy it was there, but still.. only once).
What are you writing about? "address unit" does not occur inYeah, that's teach me to answer a message on my tablet, where it
Forth-83, and "word" is defined as "A sequence of characters
terminated by one blank [...]".
Forth-83 did not change that part of the Forth-79 in effect: it hasAnd it ALSO talks about "minimum field" - implying that it could be larger.
8-bit bytes and 16-bit cells. The terminology has changed, however:
Where Forth-79 talks about cells (and defines them as 16-bit memory locations), Forth-83 does not mention cells at all (except in anBeating around the bush: "When values exist within a larger field, the most- significant bits are zero. 16-bit numbers are represented
uncotrolled reference word), and instead uses "16-bit" and "16b" in a
lot of places.
Well, you've just given the reason why they are not. The "how to store a string"There are plenty of COMUS words like PLACE, +PLACE and BOUNDS whichNobody has proposed them yet; and for PLACE and +PLACE, that's the way
should finally be included. Most implementations support them.
it should be.
So SUBSTITUTE is more useful than I expected. After discovering >STRING-EXECUTE, I did not expect that anybody outside the MPE bubbleWell, it proved to be a lifesaver when designing a tiny localization lib ;-) Never throw away potentially useful code.
would ever use SUBSTITUTE.
On Saturday, June 18, 2022 at 4:14:56 PM UTC+2, Anton Ertl wrote:...
Forth-83 did not change that part of the Forth-79 in effect: it has
8-bit bytes and 16-bit cells.
Beating around the bush: "When values exist within a larger field, the most- >significant bits are zero. 16-bit numbers are represented
in memory by addressing the first of two bytes at
consecutive addresses. The byte order is unspecified by
this Standard. Double numbers are represented on the stack
with the most-significant 16 bits (with sign) most
accessible. Double numbers are represented in memory by two
consecutive 16-bit numbers. The address of the least
significant 16 bits is two greater than the address of the
most significant 16 bits. The byte order within each 16-bit
field is unspecified".
That's so specific, it doesn't leave much room for anything else.
Well, you've just given the reason why they are not. The "how to store a string"There are plenty of COMUS words like PLACE, +PLACE and BOUNDS whichNobody has proposed them yet; and for PLACE and +PLACE, that's the way
should finally be included. Most implementations support them.
it should be.
discussion has been going on for eternity and is ALWAYS stopped because
(1) We want to get rid of counted strings;
(2) We don't have an alternative,
And that's why people don't submit any COMUS words for inclusion -
such RfD's are put aside WITHOUT any discussion and effectively buried.
I don't have the habit of repeating myself. I already pointed out that Forth-79 gave more latitude to implementers than Forth-83 in this regard.That's so specific, it doesn't leave much room for anything else.Yes, it obviously was not intended to. Neither was Forth-79. So why
complain about Forth-83?
What about this one? https://forth-standard.org/proposals/place-place#contribution-206And that's why people don't submit any COMUS words for inclusion -without any discussion?
such RfD's are put aside WITHOUT any discussion and effectively buried. Bullshit! Can you give an example of any RfD that was put aside
On Sunday, June 19, 2022 at 5:34:40 PM UTC+2, Anton Ertl wrote:
I don't have the habit of repeating myself. I already pointed out that Forth-79That's so specific, it doesn't leave much room for anything else.Yes, it obviously was not intended to. Neither was Forth-79. So why
complain about Forth-83?
gave more latitude to implementers than Forth-83 in this regard.
What about this one? https://forth-standard.org/proposals/place-place#contribution-206And that's why people don't submit any COMUS words for inclusion -Bullshit! Can you give an example of any RfD that was put aside
such RfD's are put aside WITHOUT any discussion and effectively buried.
without any discussion?
It's been sitting there for only two years.
On Sunday, June 19, 2022 at 5:34:40 PM UTC+2, Anton Ertl wrote:
I don't have the habit of repeating myself. I already pointed out that Forth-79That's so specific, it doesn't leave much room for anything else.Yes, it obviously was not intended to. Neither was Forth-79. So why
complain about Forth-83?
gave more latitude to implementers than Forth-83 in this regard.
What about this one? https://forth-standard.org/proposals/place-place#contribution-206And that's why people don't submit any COMUS words for inclusion -Bullshit! Can you give an example of any RfD that was put aside
such RfD's are put aside WITHOUT any discussion and effectively buried.
without any discussion?
It's been sitting there for only two years.
Forth has standards. As part of those standards, users have choices. The same is true for most standards. You are not required to use every one of the 25 pins on an RS-232 interface. The USB standard allows several different modes and speeds. Youget choices with most standards.
Rick C.
choices with most standards.Forth has standards. As part of those standards, users have choices. The same is true for most standards. You are not required to use every one of the 25 pins on an RS-232 interface. The USB standard allows several different modes and speeds. You get
Thanks, I was looking for a good illustration for this.
Forth has standards. As part of those standards, users have choices. The same is true for most standards. You are not required to use every one of the 25 pins on an RS-232 interface.
On 22/06/2022 14:09, Zbig wrote:completely out-of-any-standard Machine Forth, as a better tool to complete some particular task, than „standard” ANS-Forth, right?
The most obvious example is Chuck Moore himself, who doesn't care that much about any official „standard” of Forth. It was discussed here not that long ago, I mean that story by Jeff Fox, when Moore recommended to some employees use of his
Well he would, wouldn't he?
The most obvious example is Chuck Moore himself, who doesn't care that much about any official „standard” of Forth. It was discussed here not that long ago, I mean that story by Jeff Fox, when Moore recommended to some employees use of hiscompletely out-of-any-standard Machine Forth, as a better tool to complete some particular task, than „standard” ANS-Forth, right?
completely out-of-any-standard Machine Forth, as a better tool to complete some particular task, than „standard” ANS-Forth, right?The most obvious example is Chuck Moore himself, who doesn't care that much about any official „standard” of Forth. It was discussed here not that long ago, I mean that story by Jeff Fox, when Moore recommended to some employees use of his
Well he would, wouldn't he?My impression is that he does not give recommendations. He does talk
about what he does and did.
#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would argue that Machine
The standard fulfills a need for vendors and some contractors who have
to maintain much software on many processors.
Mr. Moore was just doing
is own one thing; he didn't have the same need so of course it didn't
appeal to him.
#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would argue that Machine
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
On 22/06/2022 23:09, Zbig wrote:
Forth has standards. As part of those standards, users have choices. The same is true for most standards. You are not required to use every one of the 25 pins on an RS-232 interface.
I'm still looking for the 9 pins on the Forth Standard's 25 that will run 99.99%
of applications.
Except it wasn't second-hand. What got you try Forth if not someone
touting their opinion? Surely what matters is why you stayed.
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
On 23/06/2022 09:45, S Jack wrote:[Zbig wrote, reporting on a story by Jeff Fox]
#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would argue that Machine
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
Except it wasn't second-hand.
On Thursday, June 23, 2022 at 1:45:21 AM UTC+2, S Jack wrote:
[..]
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
It's been a long time since anybody dared to express this conjecture
about pastor Jeff.
dxforth <dxforth@gmail.com> writes:
On 23/06/2022 09:45, S Jack wrote:[Zbig wrote, reporting on a story by Jeff Fox]
#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would argue that Machine
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
Except it wasn't second-hand.
True, it's third hand. Zbig claims that Jeff Fox claimed that Chuck
Moore recommended Machine Forth. Then Zbig tries to support his claim
by something that may be a quote of Jeff Fox, but is given without
reference. Even if it is a genuine Jeff Fox quote, it's not a
first-hand recommendation from Chuck Moore. Having looked at and
heard first-hand material from Chuck Moore, and on what Jeff Fox
claimed about him, my impression is that the claims contained much
more Jeff Fox than Chuck Moore.
dxforth <dxforth@gmail.com> writes:
On 23/06/2022 09:45, S Jack wrote:[Zbig wrote, reporting on a story by Jeff Fox]
#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would >>>> argue that Machine
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
Except it wasn't second-hand.
True, it's third hand. Zbig claims that Jeff Fox claimed that Chuck
Moore recommended Machine Forth. Then Zbig tries to support his claim
by something that may be a quote of Jeff Fox, but is given without
reference. Even if it is a genuine Jeff Fox quote, it's not a
first-hand recommendation from Chuck Moore. Having looked at and
heard first-hand material from Chuck Moore, and on what Jeff Fox
claimed about him, my impression is that the claims contained much
more Jeff Fox than Chuck Moore.
Have a reference then; no problem:#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would argue that Machine
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
Except it wasn't second-hand.True, it's third hand. Zbig claims that Jeff Fox claimed that Chuck
Moore recommended Machine Forth. Then Zbig tries to support his claim
by something that may be a quote of Jeff Fox, but is given without
reference.
Dealing with Jeff was always difficult. It's problematic being a
disciple and acolyte.
Stephen--
In article <t91eht$dnj$1@dont-email.me>,
Stephen Pelc <stephen@vfxforth.com> wrote:
Dealing with Jeff was always difficult. It's problematic being a
disciple and acolyte.
Image that I had the utmost respect for colorforth but it
simple didn't run on the three machines I tried.
Then I wrote ciasdis in an ultimate effort to restore the source
to at least have a chance to debug it.
Jeff Fox was furious about this, for me incomprehensible, and
he was hostile to me ever since.
In article <t91eht$dnj$1...@dont-email.me>,
Stephen Pelc <ste...@vfxforth.com> wrote:
Dealing with Jeff was always difficult. It's problematic being aImage that I had the utmost respect for colorforth but it
disciple and acolyte.
simple didn't run on the three machines I tried.
Then I wrote ciasdis in an ultimate effort to restore the source
to at least have a chance to debug it.
Jeff Fox was furious about this, for me incomprehensible, and
he was hostile to me ever since.
Getting up noses is something of an occupational hazard in forth.Let's face it - Forth was created by a rebel who discarded just about every dogma in the CS textbook. That only rebels are attracted to it is just the logical consequence. That they rebel against the rebellion is no wonder as
Why we mostly end up doing our own thing.
In many countries/states the decompilation of software can be illegal,Well, not in the EU. If Albert BOUGHT ColorForth, it would have been crystal clear - as the legal purchaser he MAY decompile the code in order to make
as well as public discussions about "discoveries". Both activities can
be regarded as creating damage to the business of the software owner.
So Jeff's reaction might have been corrrect, particularly under US laws.
dxforth <dxf...@gmail.com> writes:Oh, I guess that's a matter of opinion - what does one consider "nice"?
And how do you explain the significant number of nice people in the
Forth community?
It may explain why some advocate practices that make it hard to workLots of "weasel words" here. No comment. However, there are some people
with others.
Getting up noses is something of an occupational hazard in forth.
Why we mostly end up doing our own thing.
Well, not in the EU. If Albert BOUGHT ColorForth,
I had thought ColorForth was distriubted for free, and that its source
code was released. It was written in 8086 assembler iiuc.
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
As for the source code of colorForth, does it not come with
colorForth? I saw some demos of it, where the demonstrator changed
some internal aspect of it, so the demonstrator obviously had the
source code.
- anton
Hans Bezemer <the.beez.speaks@gmail.com> writes:
Well, not in the EU. If Albert BOUGHT ColorForth,
I had thought ColorForth was distriubted for free, and that its source
code was released. It was written in 8086 assembler iiuc. So the idea
of disassembling it confused me. I figured maybe it meant Albert
suspected some discrepancy between the released binary and the released >source.
You severely misunderstand Chunk Moore. The point of colorforth
is that there is no distinction between source code and object code.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
Ah ok. I remembered it running under MSDOS
Paul Rubin <no.email@nospam.invalid> writes:
I had thought ColorForth was distriubted for free, and that its source
code was released. It was written in 8086 assembler iiuc.
Seems unlikely.
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
2) Chuck Moore writes his stuff in Forth (most stuff) or machine code
(e.g., OKAD); why should he write ColorForth in assembly language?
The result would not be portable between the PC and the GA144 version
of ColorForth, it would be harder to write, and it barely helps with
the code generation aspects of the colorForth compiler, because
assemblers tend not to include an equivalent to POSTPONE. So for code generation he likely just commas the machine code for the primitives
(like he does in cmForth); there are only ~32 primitives, so that's
not a big effort.
As for the source code of colorForth, does it not come with
colorForth? I saw some demos of it, where the demonstrator changed
some internal aspect of it, so the demonstrator obviously had the
source code.
- anton
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
Ah ok. I remembered it running under MSDOS and associated that with
8086, but it was used with the 386 as well. I do remember seeing or
hearing of some x86 assember code, but maybe it was a disassembly.
On 23 Jun 2022 at 10:16:48 CEST, "Anton Ertl" <Anton Ertl> wrote:
dxforth <dxf...@gmail.com> writes:
On 23/06/2022 09:45, S Jack wrote:[Zbig wrote, reporting on a story by Jeff Fox]
#v+
trying to pull teeth from an angry pit bull by hand. Chuck and I would >>>> argue that Machine
I'm always leery of second hand info. It could very well be someone
touting his opinion and using his God's name in vain to bolster his
position. Boring.
Except it wasn't second-hand.
True, it's third hand. Zbig claims that Jeff Fox claimed that ChuckI have worked in the same building as Chuck and Jeff, and met
Moore recommended Machine Forth. Then Zbig tries to support his claim
by something that may be a quote of Jeff Fox, but is given without reference. Even if it is a genuine Jeff Fox quote, it's not a
first-hand recommendation from Chuck Moore. Having looked at and
heard first-hand material from Chuck Moore, and on what Jeff Fox
claimed about him, my impression is that the claims contained much
more Jeff Fox than Chuck Moore.
them many times over the years.
I have the utmost respect for Chuck - he's a genius. Some of his
opinions about Forth are (I suspect) due to his oddball eyesight.
MPE and Forth Inc have to deal with different problems, so our
opinions are not the same as Chuck's.
Dealing with Jeff was always difficult. It's problematic being a
disciple and acolyte.
As to Forth chip design, the successful (by some measure)
stack machine chips have all been designed using industry
standard tools. This has enabled them to move from one
process generation to the next. As Chuck found out at great
expense, the foundry models do not reflect reality, they enable
the standard tools to produce working chips.
Stephen
--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974 http://www.mpeforth.com - free VFX Forth downloads
Paul Rubin <no.email@nospam.invalid> writes:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
Ah ok. I remembered it running under MSDOS
My memory is that it is a native Forth, and therefore ran only on
certain PC hardware, supported little of the PC hardware (e.g., only
floppy drives, already pretty outdated at the time). Other people
have then worked at making it more accessible by providing versions
running under DOS, Linux, or, e.g., Bochs.
On 25/06/2022 20:14, Anton Ertl wrote:
Paul Rubin <no.e...@nospam.invalid> writes:
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
Ah ok. I remembered it running under MSDOS
My memory is that it is a native Forth, and therefore ran only onIt was in asm format (with near zero comments AFAIR)
certain PC hardware, supported little of the PC hardware (e.g., only floppy drives, already pretty outdated at the time). Other people
have then worked at making it more accessible by providing versions running under DOS, Linux, or, e.g., Bochs.
https://colorforth.github.io/install.htm
The ftp links no longer work but I probably have a copy somewhere.
On Sunday, June 26, 2022 at 2:11:29 PM UTC+10, dxforth wrote:be copies to be found to restore history.
On 25/06/2022 20:14, Anton Ertl wrote:
Paul Rubin <no.e...@nospam.invalid> writes:It was in asm format (with near zero comments AFAIR)
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1) What I saw of the PC version of Machine Forth used 386
instructions; I don't think that Chuck Moore is into retrocomputing,
so why should he use 8086?
Ah ok. I remembered it running under MSDOS
My memory is that it is a native Forth, and therefore ran only on
certain PC hardware, supported little of the PC hardware (e.g., only
floppy drives, already pretty outdated at the time). Other people
have then worked at making it more accessible by providing versions
running under DOS, Linux, or, e.g., Bochs.
https://colorforth.github.io/install.htm
The ftp links no longer work but I probably have a copy somewhere.
archive.org would be one place to keep it.
Here's a thought. A forth vault that everybody can download from Archivd.org, and archive themselves, so there will be copies around to restart going into the future, incase archive.org version goes down. So, when we are all dead, there might still
dxforth <dxforth@gmail.com> writes:
Getting up noses is something of an occupational hazard in forth.
What in Forth would cause that?
And how do you explain the significant number of nice people in the
Forth community?
Why we mostly end up doing our own thing.
It may explain why some advocate practices that make it hard to work
with others.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 36:02:52 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,431 |