Re: Does SRFI 205 cover serial port?
hga@xxxxxx 18 Oct 2020 15:48 UTC
> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, October 18, 2020 10:04 AM
>
>> Not exactly, if by terminals you mean a real physical or virtual terminal
>> at the other end of the serial line
>
> Yes.
>
>> that falls under retrocomputing.
>>
>> Complete support of serial ports for embedded and the like programming is
>> officially in its remit.
>
> Classical embedded development can be quite similar to retrocomputing :)
You have a point. So far, I've partly been distinguishing it in my
mind as who makes requests and who fulfills them. But an operating
device might well be set into a mode where it pushes information,
alerts, whatever, and perhaps demands a response. And I think I'd be
hard pressed to *prevent* using 205 to directly support terminals, not
that I would try.
And if one or a very few additional constants need to be exposed to
completely support them, that would be fine. Not sure about this one:
> [...]
>
> One thing currently missing from 205 is TIOCGWINSZ (window size):
>
> struct winsize ws;
> if (ioctl(fd, TIOCGWINSZ, &ws) == -1) error();
> width = ws.ws_col;
> height = ws.ws_row;
But it looks simple, just added that to the official TODO.txt file in
my GitHub repo for consideration in due course.
>> All part of the plan, but delayed for now due to Real Life issues, which
>> are hopefully getting resolved soon.
>
> Great.
Errr, one of the problems is an RSI flareup, and I can tell from this
morning's computer activities it's going to take a lot longer than I'd
like to resolve. But keeping this SRFI on the shelf is not the end of
the world, it was first created to capture the with-* and without-echo
procedures after they were removed from SRFI 170, while all that was
still fresh in my mind. Except for the new from scsh procedures which
John says belong in it, which have not been examined by myself or
anyone else, the way forward is clear, it just needs time and effort
it can't be given for now.
- Harold