Under Gforth running on debian 8 on a RPI I ran into the following a
problem for check-read in gforth-0.7.9_20210930/unix/serial.fs

It is defined as:
: check-read ( port -- n ) 0 { w^ io-result }
fileno FIONREAD io-result ioctl ?ior io-result l@ ;

term dbg check-read \ To see the problem
\ term is a value that contains the port I got from open-serial.

Nesting debugger ready!
[ 1 ] 15109056
B681AF28 B67B9630 #0 -> [ 2 ] 15109056 00000
B681AF30 B67BB5C0 >l -> [ 1 ] 15109056
B681AF34 B67BB560 lp- -> [ 1 ] 15109056
B681AF38 B67FEAD8 fileno -> [ 1 ] 00018
B681AF3C B681AD90 FIONREAD -> [ 2 ] 00018 21531
B681AF40 B67BB530 laddr# 4 -> [ 3 ] 00018 21531 3060211700
B681AF48 B6809320 ioctl -> [ 0 ]
B681AF4C B67FF490 ?ior ->
*the terminal*:36:10: error: Stack underflow
term dbg >>>check-read<<<
Backtrace:
/usr/local/share/gforth/0.7.9_20210930/unix/libc.fs:127:8: 0 $B67FF49C =
/usr/local/share/gforth/0.7.9_20210930/unix/serial.fs:137:37: 1 $B681AF50 ?ior
/usr/local/share/gforth/0.7.9_20210930/except.fs:83:2: 2 $B67CD904 execute [catch frame]
/usr/local/share/gforth/0.7.9_20210930/debug.fs:207:28: 3 $B67EDE34 catch
/usr/local/share/gforth/0.7.9_20210930/debug.fs:222:27: 4 $B67EDF50 (debug)

The following also puzzles me a bit:
When I use:
: term-read ( -- addr u ) pad dup 255 term read-file throw ;
then at throw it returns: error: Resource temporarily unavailable

When I change term-read into:
: term-read ( -- addr u ) pad dup 255 term read-file drop ;

then the buffer at pad has been correctly filled.

I hope it can be solved.
Thanks in advance,
Jos

Jos Ven <josv@planet.nl> writes:
>
>Under Gforth running on debian 8 on a RPI I ran into the following a
>problem for check-read in gforth-0.7.9_20210930/unix/serial.fs
>
>It is defined as:
>: check-read ( port -- n ) 0 { w^ io-result }
> fileno FIONREAD io-result ioctl ?ior io-result l@ ;
>
>term dbg check-read \ To see the problem
>\ term is a value that contains the port I got from open-serial.
>
>Nesting debugger ready!
>[ 1 ] 15109056
>B681AF28 B67B9630 #0 -> [ 2 ] 15109056 00000
>B681AF30 B67BB5C0 >l -> [ 1 ] 15109056
>B681AF34 B67BB560 lp- -> [ 1 ] 15109056
>B681AF38 B67FEAD8 fileno -> [ 1 ] 00018
>B681AF3C B681AD90 FIONREAD -> [ 2 ] 00018 21531
>B681AF40 B67BB530 laddr# 4 -> [ 3 ] 00018 21531 3060211700
>B681AF48 B6809320 ioctl -> [ 0 ]

This is wrong. ioctl should take 3 cells and return 1. And it does
on my AMD64 system.

Thanks for the bug report, we will investigate it.

>The following also puzzles me a bit:
>When I use:
>: term-read ( -- addr u ) pad dup 255 term read-file throw ;
>then at throw it returns: error: Resource temporarily unavailable
>
>When I change term-read into:
>: term-read ( -- addr u ) pad dup 255 term read-file drop ;
>
>then the buffer at pad has been correctly filled.

But probably not to 255 characters, right?

READ-FILE returns the ior corresponding to the Unix condition EAGAIN
in this case. Given the widely-used practice of putting THROW after
READ-FILE, it might be better to return ior=0 in that case.

However, looking at the specification of READ-FILE, returning the
actual length and ior=0 indicates that the end of file has been
reached. OTOH, that has been written for reading from a file rather
than from a terminal.

What do people think? Should READ-FILE return ior=0 in this case?

- 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

Op zondag 10 oktober 2021 om 16:20:57 UTC+2 schreef Anton Ertl:
> Jos Ven <jo...nl> writes:
> >
> >Under Gforth running on debian 8 on a RPI I ran into the following a
> >problem for check-read in gforth-0.7.9_20210930/unix/serial.fs
> >
> >It is defined as:
> >: check-read ( port -- n ) 0 { w^ io-result }
> > fileno FIONREAD io-result ioctl ?ior io-result l@ ;
> >
> >term dbg check-read \ To see the problem
> >\ term is a value that contains the port I got from open-serial.
> >
> >Nesting debugger ready!
> >[ 1 ] 15109056
> >B681AF28 B67B9630 #0 -> [ 2 ] 15109056 00000
> >B681AF30 B67BB5C0 >l -> [ 1 ] 15109056
> >B681AF34 B67BB560 lp- -> [ 1 ] 15109056
> >B681AF38 B67FEAD8 fileno -> [ 1 ] 00018
> >B681AF3C B681AD90 FIONREAD -> [ 2 ] 00018 21531
> >B681AF40 B67BB530 laddr# 4 -> [ 3 ] 00018 21531 3060211700
> >B681AF48 B6809320 ioctl -> [ 0 ]
> This is wrong. ioctl should take 3 cells and return 1. And it does
> on my AMD64 system.
>
> Thanks for the bug report, we will investigate it.
> >The following also puzzles me a bit:
> >When I use:
> >: term-read ( -- addr u ) pad dup 255 term read-file throw ;
> >then at throw it returns: error: Resource temporarily unavailable
> >
> >When I change term-read into:
> >: term-read ( -- addr u ) pad dup 255 term read-file drop ;
> >
> >then the buffer at pad has been correctly filled.
> But probably not to 255 characters, right?
>
> READ-FILE returns the ior corresponding to the Unix condition EAGAIN
> in this case. Given the widely-used practice of putting THROW after
> READ-FILE, it might be better to return ior=0 in that case.
>
> However, looking at the specification of READ-FILE, returning the
> actual length and ior=0 indicates that the end of file has been
> reached. OTOH, that has been written for reading from a file rather
> than from a terminal.
>
> What do people think? Should READ-FILE return ior=0 in this case?
>
> - 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

Sorry can't test for 255 characters.
The longest string that the connected
hardware returns is only 33 characters long.

> Should READ-FILE return ior=0 in this case?
That would be logical.

Thanks for the investigation.
Kind regards, Jos

Jos Ven <josv@planet.nl> writes:
>Op zondag 10 oktober 2021 om 16:20:57 UTC+2 schreef Anton Ertl:
>> Jos Ven <jo...nl> writes:
>> >
>> >Under Gforth running on debian 8 on a RPI I ran into the following a
>> >problem for check-read in gforth-0.7.9_20210930/unix/serial.fs
>> >
>> >It is defined as:
>> >: check-read ( port -- n ) 0 { w^ io-result }
>> > fileno FIONREAD io-result ioctl ?ior io-result l@ ;
>> >
>> >term dbg check-read \ To see the problem
>> >\ term is a value that contains the port I got from open-serial.
>> >
>> >Nesting debugger ready!
>> >[ 1 ] 15109056
>> >B681AF28 B67B9630 #0 -> [ 2 ] 15109056 00000
>> >B681AF30 B67BB5C0 >l -> [ 1 ] 15109056
>> >B681AF34 B67BB560 lp- -> [ 1 ] 15109056
>> >B681AF38 B67FEAD8 fileno -> [ 1 ] 00018
>> >B681AF3C B681AD90 FIONREAD -> [ 2 ] 00018 21531
>> >B681AF40 B67BB530 laddr# 4 -> [ 3 ] 00018 21531 3060211700
>> >B681AF48 B6809320 ioctl -> [ 0 ]
>> This is wrong. ioctl should take 3 cells and return 1. And it does
>> on my AMD64 system.

We cannot reproduce this bug, even on a Raspi.

>Sorry can't test for 255 characters.

No problem.

>> Should READ-FILE return ior=0 in this case?
>That would be logical.

We have now decided to take the other direction, so that one can still
determine whether you are at the end-of-file or just have temporarily
run out of input:

The patch
<http://git.savannah.gnu.org/cgit/gforth.git/commit/?id=bb6f962bda1fc382348fcf575e716ccdbd82c641> adds:

* a constant EAGAIN-THROW#

* and a word THROW-SERIAL ( throw-code -- ) which ignores EAGAIN-THROW#.

- 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

Op zondag 10 oktober 2021 om 23:32:44 UTC+2 schreef Anton Ertl:
> Jos Ven <jo...nl> writes:
> >Op zondag 10 oktober 2021 om 16:20:57 UTC+2 schreef Anton Ertl:
> >> Jos Ven <jo...nl> writes:
> >> >
> >> >Under Gforth running on debian 8 on a RPI I ran into the following a
> >> >problem for check-read in gforth-0.7.9_20210930/unix/serial.fs
> >> >
> >> >It is defined as:
> >> >: check-read ( port -- n ) 0 { w^ io-result }
> >> > fileno FIONREAD io-result ioctl ?ior io-result l@ ;
> >> >
> >> >term dbg check-read \ To see the problem
> >> >\ term is a value that contains the port I got from open-serial.
> >> >
> >> >Nesting debugger ready!
> >> >[ 1 ] 15109056
> >> >B681AF28 B67B9630 #0 -> [ 2 ] 15109056 00000
> >> >B681AF30 B67BB5C0 >l -> [ 1 ] 15109056
> >> >B681AF34 B67BB560 lp- -> [ 1 ] 15109056
> >> >B681AF38 B67FEAD8 fileno -> [ 1 ] 00018
> >> >B681AF3C B681AD90 FIONREAD -> [ 2 ] 00018 21531
> >> >B681AF40 B67BB530 laddr# 4 -> [ 3 ] 00018 21531 3060211700
> >> >B681AF48 B6809320 ioctl -> [ 0 ]
> >> This is wrong. ioctl should take 3 cells and return 1. And it does
> >> on my AMD64 system.
> We cannot reproduce this bug, even on a Raspi.
> >Sorry can't test for 255 characters.
> No problem.
> >> Should READ-FILE return ior=0 in this case?
> >That would be logical.
> We have now decided to take the other direction, so that one can still
> determine whether you are at the end-of-file or just have temporarily
> run out of input:
>
> The patch
> <http://git.savannah.gnu.org/cgit/gforth.git/commit/?id=bb6f962bda1fc382348fcf575e716ccdbd82c641> adds:
>
> * a constant EAGAIN-THROW#
>
> * and a word THROW-SERIAL ( throw-code -- ) which ignores EAGAIN-THROW#.
> - 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

OK, Thanks for the efforts.
Kind regards, Jos