flagxor / ueforth

Apache License 2.0
95 stars 26 forks source link

Numerical formating #34

Closed Eszartek closed 1 year ago

Eszartek commented 1 year ago

There is an odd issue while using numerical formating at the console, either serial or webui. I havn't tried telnet.

--> 10 <# #s #> type
10 ok

which is correct. However, if you perform the formatting without the type, leaving the counted string on the stack, then issuing type afterward, you get an incorrect output. This is on an ESP32C3 v7.0.7.4:

--> 10 <# #s #> 
 ok
1070269430 2 --> type
00 ok
-->

Running ueforth v7.0.7.3 on Linux:

-->  10 <# #s #>
 10 <# #s #>
 ok
134494982 2 --> type
type
82 ok

Its different but still incorrect, however it's not a show stopper. It was just driving me nuts when I was working out a simple formatted number at the console and the results were not what I expected. Now that I know, I just always add the type at the end.

Eszartek commented 1 year ago

I think I figured it out. The pad is getting overwritten by the numeric format of the subsequest stack display, which also uses numeric formatting in the sequence of the words ?arrow , raw.s , . , and finally u. or str , which both use numeric formatting, thereby destroying the pad after it runs and just before I get the prompt.

MPETREMANN11 commented 1 year ago

Hello, <# #s #> use it only in a definition.

<# use the same memory space as the terminal buffer

Eszartek commented 1 year ago

Yes, I see now that it works as designed. I fixed it by adding pad offsets to raw.s and httpd response.