Status display in QUIT ?

[dxforth]

I recently began using a forth which did a .S (among other things) in QUIT.
I previously considered such too verbose but have to say it's grown on me
after intensive debugging involving spurious values on the stack. Some
forths simply display DEPTH if non-zero which is akin to this teaser:

"I've just picked up a fault in the AE35 unit. It's going to go 100% failure
in 72 hours."

No worries, Forth. I think I'll just ignore it :)

Curious to know other forthers experiences/preferences?

[S Jack]

On Friday, April 8, 2022 at 11:25:20 PM UTC-5, dxforth wrote:
>
> Curious to know other forthers experiences/preferences?

Since VAL Forth days always show stack status on QUIT but now just
show dots. If want to see the values, I'll do .S myself. The
stack display is an option but I have it on most of the time.
Sometimes I enable a fancy display that has a status line at the
screen bottom and then display the stack there. I also have a
mode (option) that upon command entry before its execution the
screen is cleared and the cursor homed. After execution, the
cursor is placed at the command line (4 lines above the bottom
line). Another display option is split screen with the bottom 4
lines a scroll area for command input and the upper area is
painted with a canvas as a backdrop for boxes. The top line is a
title bar and the bottom line of the upper area is a status bar.
Can also switch the scroll area to the upper screen for lengthy
displays that scroll off the top into a buffer that can be viewed
afterwards.
--
me

[Marcel Hendrix]

I think it's a question of taste.

FORTH> : test begin 123 56 >S PI QUIT AGAIN ; ok
FORTH> test
[1]<1>{1}FORTH> . -s f. 123 3.141593 ok

-marcel

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>Curious to know other forthers experiences/preferences?

The development version of Gforth diplays the stack depth after ok,
and the stack contents in the bottom line (which is erased when
the next line is text-interpreted).

E.g., inputting

s" foo" 1.23e

results in a line

s" foo" 1.23e ok 2 f:1

(2 is the data stack depth, 1 the FP stack depth), and the bottom line shows:

<2> "foo" |F:<1> 1.230000E0 |o:Forth Forth Root Forth

- 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 2021: https://euro.theforth.net/2021

[minf...@arcor.de]

Anton Ertl schrieb am Samstag, 9. April 2022 um 14:02:28 UTC+2:
> dxforth <dxf...@gmail.com> writes:
> >Curious to know other forthers experiences/preferences?
> The development version of Gforth diplays the stack depth after ok,
> and the stack contents in the bottom line (which is erased when
> the next line is text-interpreted).
>
> E.g., inputting
>
> s" foo" 1.23e
>
> results in a line
>
> s" foo" 1.23e ok 2 f:1
>
> (2 is the data stack depth, 1 the FP stack depth), and the bottom line shows:
>
> <2> "foo" |F:<1> 1.230000E0 |o:Forth Forth Root Forth
>

The <2> "foo" is interesting. I guess that it appears only when the 2nd stack element
points to a stack buffer. Otherwise it would show the numbers.

What happens when you input "foo" at the command line?

[P Falth]

I have .OK in QUIT that prints the OK prompt and dots after it depending on the depth
3 items on the stack will look like ok...
the ok prompt is also printed in green. (I use a black background)

As a complement I have : .. .S DEPTH DISCARD ;
This will print the stack items and clear the stack. A very useful tool

BR
Peter

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>The <2> "foo" is interesting. I guess that it appears only when the 2nd stack element
>points to a stack buffer.

This comes out of "...", the smart brother of ".S"
<2019Apr3...@mips.complang.tuwien.ac.at>. It uses some heuritics
to try to guess what the stack items mean. Often it is right,
sometimes it is wrong. I would have to look at the code to find out
what the exact heuristics are, but it's probably something like: the
length part must be not too big, all bytes inside accessible, and they
must not be control characters.

>What happens when you input "foo" at the command line?

"foo" type \ foo ok

The stuff behind \ is the output.

The general principle is that ... outputs stuff in a way that you can
also input. So we have recognizers for these things. E.g.:

create a 10 allot
a 1 + ... \ <1> <a+$1> ok 1
<a+$1> = . \ -1 ok

[S Jack]

On Saturday, April 9, 2022 at 9:44:28 AM UTC-5, P Falth wrote:
> This will print the stack items and clear the stack. A very useful tool

In Fig days and before Linux it was common and convenient to hit dot twice for an illegal command
to clear the stack. That quickly evolved to the word ".." that would clear the stack without an
error message. But in Linux a double dot is for the parent directory. Although it has no meaning in
my Forth I changed it to double-x, "xx", to avoid confusion.
--
me

[Paul Rubin]

S Jack <sdwj...@gmail.com> writes:
> In Fig days and before Linux it was common and convenient to hit dot
> twice for an illegal command to clear the stack. That quickly evolved
> to the word ".." that would clear the stack without an error message.

In gforth (and maybe it is in ANS) "clearstack" clears the stack, and I
usually alias it to "cs" when testing stuff.

[minf...@arcor.de]

Anton Ertl schrieb am Samstag, 9. April 2022 um 18:01:01 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >The <2> "foo" is interesting. I guess that it appears only when the 2nd stack element
> >points to a stack buffer.
> This comes out of "...", the smart brother of ".S"
> <2019Apr3...@mips.complang.tuwien.ac.at>. It uses some heuritics
> to try to guess what the stack items mean. Often it is right,
> sometimes it is wrong. I would have to look at the code to find out
> what the exact heuristics are, but it's probably something like: the
> length part must be not too big, all bytes inside accessible, and they
> must not be control characters.
> >What happens when you input "foo" at the command line?
> "foo" type \ foo ok
>
> The stuff behind \ is the output.
>
> The general principle is that ... outputs stuff in a way that you can
> also input. So we have recognizers for these things. E.g.:
>
> create a 10 allot
> a 1 + ... \ <1> <a+$1> ok 1
> <a+$1> = . \ -1 ok

So <a+$1> is infix while Forth is postfix ... if it helps debugging, okay.

[Anton Ertl]

Yes, we could also let "..." output "<a> 1 +" instead (or in this
case, even "a 1 +" would be ok, and it would simplify the
implementation of the body recognizer (the thing that recognizes <a>
and would then not recognize <a+$1>).

But OTOH <a+$1> is one space-delimited thing, which makes it easier to
identify as one stack item; I guess that's the advantage that resulted
in everybody from the Gforth team accept the <word+const> syntax. I
certainly did not think about it as an infix expresson.

[dxforth]

It's beneficial to automatically see the results of operations at each step -
much the same way as a calculator or debugger does:

1 2 3 ok 1 2 3 <
+ ok 1 5 <
- ok -4 <
. -4 ok
pi ok 3.141593E0 <f
2e f* ok 6.283186E0 <f

If one makes an error then bad luck it all vanishes. IIRC 8th doesn't empty
the stack on error. The latter might be acceptable in regular forth provided
stack out-of-bounds continues to be monitored in the QUIT loop.

[S Jack]

On Saturday, April 9, 2022 at 1:32:52 PM UTC-5, Paul Rubin wrote:
> In gforth (and maybe it is in ANS) "clearstack" clears the stack, and I
> usually alias it to "cs" when testing stuff.

That's fine. "cs" is a little more awkward than ".." but will do. For sure ".." is for at the terminal
operating and in test scripts. In programs I use "SP!!"; I don't do Cobol:
I-am-clearing-the-data-stack-now
very-good-there-were-no-errors
--
me

[dxforth]

ABORT clears the stack without an error msg. Error msg or not I'm puzzled
why another word is necessary. It's a rare app that needs it and trivial
enough to define when one does.

[minf...@arcor.de]

"clearstack" is only a factor of ABORT.
They are not equivalent.

[dxforth]

I've been unable to make a case for factoring 'clearstack' - other than
for systems where ABORT doesn't clear the stacks. One could point to
forth standards and say they've not seen fit to distinguish them either.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>I've been unable to make a case for factoring 'clearstack'

Checking this in Gforth:

CLEARSTACK (data stack) is only called from CLEARSTACKS (data and FP
stack) CLEARSTACKS is only called from QUIT. I have also looked at
uses of SP! and FP! to see whether there were additional factoring
opportunities, but there are not.

So it's more a conceptual thing: When I want to clear the stacks, I
write CLEARSTACKS. When I want to abort, I write ABORT (but I never
want to do that; instead, I throw).

[minf...@arcor.de]

QUIT empties only the return stack.

ABORT empties the data stack(s) and performs QUIT.

[dxforth]

On 11/04/2022 16:50, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>I've been unable to make a case for factoring 'clearstack'
>
> Checking this in Gforth:
>
> CLEARSTACK (data stack) is only called from CLEARSTACKS (data and FP
> stack) CLEARSTACKS is only called from QUIT. I have also looked at
> uses of SP! and FP! to see whether there were additional factoring
> opportunities, but there are not.
>
> So it's more a conceptual thing: When I want to clear the stacks, I
> write CLEARSTACKS. When I want to abort, I write ABORT (but I never
> want to do that; instead, I throw).

That begs the question of when ABORT wouldn't do. It's less typing.
Besides there's nothing more joyous than typing 'xx' and getting a
reaction from the system - at least I know it's still thinking :)

[none albert]

ciforth (lina wina) is nice and clean and don't bother you with
clutter besides OK.

Unless you want to. Issue
WANT DO-DEBUG
and the stack is printed each time before OK.

(Indirect Threaded Forths allow you to revector everything,
including OK).

Nowaday I could use a decorator:
WANT decorated
' .S 'OK decorated

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Marcel Hendrix]

On Sunday, April 10, 2022 at 6:12:21 AM UTC+2, dxforth wrote:
> On 9/04/2022 21:06, Marcel Hendrix wrote:
> > On Saturday, April 9, 2022 at 6:25:20 AM UTC+2, dxforth wrote:

[..]

> It's beneficial to automatically see the results of operations at each step -
> much the same way as a calculator or debugger does:

FORTH> : ok .S ; ok
FORTH> 1 2 3 ok
Data: 1 2 3 ---
System: ---
Float: --- ok
[3]FORTH> + ok
Data: 1 5 ---
System: ---
Float: --- ok
[2]FORTH> - ok
Data: -4 ---
System: ---
Float: --- ok
[1]FORTH> . -4 ok
FORTH> pi ok
Data: ---
System: ---
Float: 3.1415926535897932385 --- ok
{1}FORTH> 2e f* ok
Data: ---
System: ---
Float: 6.2831853071795864770 --- ok
{1}FORTH> f. 6.283185 ok

Like this?

-marcel

[none albert]

In article <87lewe9...@nightsong.com>,

cs is a little bit to terse.
I would like to see CLS make into the standard.
Every Forth is defining a new word with this functionality.
I ought to be in the standard.

[none albert]

You must be kidding. Teach a Forth novice to clear the stack by invoking
a scary word like ABORT ? . Better declare ABORT obsolescent because
it lacks clear intent, and the suggestion that it may be equivalent
to a throw makes my head spin.
Also ABORT doesn't work in a definition to clear the stack.

[none albert]

In article <2022Apr1...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>dxforth <dxf...@gmail.com> writes:
>>I've been unable to make a case for factoring 'clearstack'
>
>Checking this in Gforth:
>
>CLEARSTACK (data stack) is only called from CLEARSTACKS (data and FP
>stack) CLEARSTACKS is only called from QUIT. I have also looked at
>uses of SP! and FP! to see whether there were additional factoring
>opportunities, but there are not.
>
>So it's more a conceptual thing: When I want to clear the stacks, I
>write CLEARSTACKS. When I want to abort, I write ABORT (but I never
>want to do that; instead, I throw).

Also it is useful to revector CLS ( CLEARSTACKS ) to a NOOP.
I don't like it that if I make a mistake the bodies are cremated
in a blink.

>
>- anton

[minf...@arcor.de]

none albert schrieb am Montag, 11. April 2022 um 12:15:50 UTC+2:
> In article <87lewe9...@nightsong.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
> >S Jack <sdwj...@gmail.com> writes:
> >> In Fig days and before Linux it was common and convenient to hit dot
> >> twice for an illegal command to clear the stack. That quickly evolved
> >> to the word ".." that would clear the stack without an error message.
> >
> >In gforth (and maybe it is in ANS) "clearstack" clears the stack, and I
> >usually alias it to "cs" when testing stuff.
> cs is a little bit to terse.
> I would like to see CLS make into the standard.
> Every Forth is defining a new word with this functionality.
> I ought to be in the standard.

For my taste CLS is too close to that old CLearScreen.

I use .. quite often and like it because it is just a quick double-tap
on the keyboard adjacent to the space bar.

[Doug Hoffman]

On 4/10/22 12:12 AM, dxforth wrote:

> It's beneficial to automatically see the results of operations at each step -
> much the same way as a calculator or debugger does:
>
> 1 2 3 ok 1 2 3 <
> + ok 1 5 <
> - ok -4 <
> . -4 ok
> pi ok 3.141593E0 <f
> 2e f* ok 6.283186E0 <f

Agreed. MacForthonVFX with judicious use of traceon and traceoff:

-Doug


traceon debug off
: test begin 1 2 3 + - . pi 2e f* quit again ;
traceoff

debug on
test
begin ( 0 )
1 ( 1 ) \ 1
2 ( 2 ) \ 1 \ 2
3 ( 3 ) \ 1 \ 2 \ 3
+ ( 2 ) \ 1 \ 5
- ( 1 ) \ -4
. -4 ( 0 )
pi ( 0 ) ( 1 ) \ 3.141593
2e ( 0 ) ( 2 ) \ 3.141593 \ 2.
f* ( 0 ) ( 1 ) \ 6.283186
quit

[Andy Valencia]

"minf...@arcor.de" <minf...@arcor.de> writes:
> For my taste CLS is too close to that old CLearScreen.
> I use .. quite often and like it because it is just a quick double-tap
> on the keyboard adjacent to the space bar.

Me too, until I added input line editing to ForthOS.
Now ^L (control-L) has taken over.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[dxforth]

If you've patched the system such that it automatically displays stack content,
then well and good. I would suggest there's nothing to be gained displaying
stacks that are empty.

[dxforth]

On 11/04/2022 20:26, albert wrote:
> In article <t2v8f0$1h8t$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>>On 10/04/2022 04:32, Paul Rubin wrote:
>>> S Jack <sdwj...@gmail.com> writes:
>>>> In Fig days and before Linux it was common and convenient to hit dot
>>>> twice for an illegal command to clear the stack. That quickly evolved
>>>> to the word ".." that would clear the stack without an error message.
>>>
>>> In gforth (and maybe it is in ANS) "clearstack" clears the stack, and I
>>> usually alias it to "cs" when testing stuff.
>>
>>ABORT clears the stack without an error msg. Error msg or not I'm puzzled
>>why another word is necessary. It's a rare app that needs it and trivial
>>enough to define when one does.
>
> You must be kidding. Teach a Forth novice to clear the stack by invoking
> a scary word like ABORT ? .

Novices have never tried to type in a word that doesn't exist? They must
be well trained :)

> Better declare ABORT obsolescent because
> it lacks clear intent, and the suggestion that it may be equivalent
> to a throw makes my head spin.

ABORT is useful for getting back to a clean state which includes emptying
the stacks; whereas QUIT is useful for debugging because it doesn't empty
the stacks. In my system there's a further distinction:

Like ABORT, QUIT may be used to terminate an application at any
nesting level. Unlike ABORT, QUIT in DX-Forth is not considered
an error condition and cannot be intercepted with CATCH.

> Also ABORT doesn't work in a definition to clear the stack.

It doesn't just clear the stack if that's what you mean. Anyone that chooses
'clearstack' for the name of a function which just clears the stack, clearly
never intended it to get much use. Which aligns with my experience. Novices
are welcome to knock themselves out using it.

[Hans Bezemer]

On Saturday, April 9, 2022 at 6:25:20 AM UTC+2, dxforth wrote:

> I recently began using a forth which did a .S (among other things) in QUIT.
> I previously considered such too verbose but have to say it's grown on me
> after intensive debugging involving spurious values on the stack. Some
> forths simply display DEPTH if non-zero which is akin to this teaser:
>
> "I've just picked up a fault in the AE35 unit. It's going to go 100% failure
> in 72 hours."
>
> No worries, Forth. I think I'll just ignore it :)
>
> Curious to know other forthers experiences/preferences?

Well, given that 4tH has a completely different architecture:

- When I'm testing stuff, I'm always adding either "DEPTH ." or ".S".
The former is a "builtin", so when I remove the "TOOLS" lib, I won't get
a compilation error;
- When writing serious application software (like in professional enviroments)
I'm almost always adding a check on "DEPTH" before leaving. If something is
left, it can have serious repercussions - so I wanna know. For end users, it's called
"system integrity" or "memory leak" - but that's not important right now;
- ABORT is the "get out of here!" command. It can't be caught. If you wanna
catch it, in 4tH you have to throw something. Hence, there is a THROW" as well.

In Gforth, there is now a small indication on what's left on the stack. In its current
form, it doesn't bother me too much. So far, it hasn't been really helpful either, but
that might change with one single occurrence. I do mostly porting work on Gforth,
so when something is wrong, it's usually in the differences between Gforth and
4tH.

When debugging 4tH, yes ".S" is my most intimate and most loyal friend. I only
see him when I invoke him, since 4tH does not have a prompt. But I would think
that even a friend like ".S" would become a nuisance if he dropped by uninvited.
For that, I'd prefer the presence of "DEPTH", I think.

Hans Bezemer

[minf...@arcor.de]

A DEBUG word comes in handy now and then. Here on a stupid word:

# : test 1 2 0 / rot ; ok
# test
? test
^ ?? division by zero
Stacks: r: $0 | 1 2 0 --
Backtrace: / <- test:7
# debug test ok
# test
$4482D0: deb# _[LIT] 1
$4482E0: 1 deb# _[LIT] 2
$4482F0: 1 2 deb# _[LIT] 0
$448300: 1 2 0 deb# /
? test
^ ?? division by zero
Stacks: r: $0 | 1 2 0 --
Backtrace: / <- test:7
#

[dxforth]

On 12/04/2022 23:43, Hans Bezemer wrote:
>
> When debugging 4tH, yes ".S" is my most intimate and most loyal friend. I only
> see him when I invoke him, since 4tH does not have a prompt. But I would think
> that even a friend like ".S" would become a nuisance if he dropped by uninvited.
> For that, I'd prefer the presence of "DEPTH", I think.

I think Marcel's .S would quickly become a nuisance :) 'depth' is no real
replacement for .S Instead of a 'depth' that's a cut-down .S just cut-down
on what .S shows. What this discussion has got me to consider is perhaps
I need to cut-down on some of the verbosity my aborts currently display e.g.
do I need to display "Error:" when it so blatantly is. We can all do with
less clutter :)