bugGforth - Bugs: bug #59674, Stack on Status Bar Does Not...

 
 

bug #59674: Stack on Status Bar Does Not Change Radix

Submitted by:  Jason Smith <jasonsmith>
Submitted on:  Sun 13 Dec 2020 05:59:53 PM UTC  
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  In Progress
Privacy:  Public Assigned to:  Bernd Paysan <paysan>
Open/Closed:  Open

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 14 Dec 2020 04:45:28 PM UTC, comment #4: 

Yes, we should do it in "smart.".  ~~ calls ..., and it should not matter whether the run-time happens to be in hex or decimal.  Yes, we do not know what it is, and therefore guess it, but making the guess on BASE does not appear to be a good idea (certainly for ~~).  For interactive use, if the user wants hex output when using hex, there is always ".S".

Anton Ertl <anton>
Project Administrator
Mon 14 Dec 2020 01:14:46 PM UTC, comment #3: 

We don't know what kind of number something we didn't identify actually is (ASCII code? Bitmask? Count of something?).  Therefore, smart. falls back to . if it doesn't know.  . is printed in the current base.  The user probably knows.

I think the status-line should invoke ... as is, and if we decide that decimal . with "#" prefixed is the right fallback, we should do it in smart., not in the status-line code.

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Mon 14 Dec 2020 10:00:58 AM UTC, comment #2: 

The status line (like ...) displays numbers that are (accessible) addresses outside the dictionary in hex with $ prefix (or as strings), and non-address numbers in decimal, by design.  It also displays the base unless it is decimal.  I agree that it can be confusing.

To avoid the confusion, we could add the prefix "#" to the number if the base is not decimal.

I don't think we should display non-address numbers as hex in the status line or in ...

Anton Ertl <anton>
Project Administrator
Mon 14 Dec 2020 09:47:09 AM UTC, comment #1: 

At the moment, this is by design so (we do a ['] ... #10 base-execute), but I understand why this is confusing. Changing it is easy, I want to get some opinions from the other developers.

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Sun 13 Dec 2020 05:59:53 PM UTC, original submission:  

Ubuntu 20.04
snap
gforth 0.7.9_20201105 amd64

EXAMPLE SESSION:

~$ gforth
Gforth 0.7.9_20201105
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type `authors'
Copyright © 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
decimal  ok
13 14 15 16  ok 4
hex  ok 4
.s <4> D E F 10  ok 4

base=16|<4> 13 14 15 16 

Note the status shows base 16, but the stack still displays decimal.

Jason Smith <jasonsmith>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by anton (Posted a comment)
  • -email is unavailable- added by paysan (Posted a comment)
  • -email is unavailable- added by jasonsmith (Submitted the item)
  • -email is unavailable- added by jasonsmith (Changes from 1.7.3 are AWESOME! Thank you!)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-14 paysan StatusNone => In Progress
        Assigned toNone => paysan
    2020-12-13 jasonsmith Carbon-Copy- => Added jasonsmith

    Back to the top


    Powered by Savane 3.5