Well, since microcom and screen can both read the data fine, logically
it must be a fault either in my picolisp programming, or the way
picolisp handles input. At home I've been playing around with coding it
different to try to capture more in a single read, such us using 'rd,
and introducing delays at various points, but no luck so far. I'm going
to try to strace microcom and see what it does differently. Maybe it all
has something to do with the ioctl params...?

Incidentally, is the a way in picoLisp to pull all available data from a
file (not just a line) in one call, but without evaluating said data?
There's load, but that always evaluates the file data. I guess I could
do a character at a time and poll for eof...?

On 04/24/2017 09:49 PM, Alexander Burger wrote:
> On Mon, Apr 24, 2017 at 07:56:32PM -0800, Christopher Howard wrote:
>> The lines...
>> write(3, "ver\n", 4)                    = 4
>> read(3, "ver\n", 8192)                  = 4
>> ..are where I have prinl'd "ver" to the dev file and got it echoed back.
> Yes, as observed.
>> I do not know what...
>> read(3, 0x9f0148, 8192)                 = ? ERESTARTSYS (To be restarted
> Here it hangs in the next read. The first read returned only 4 bytes (as seen
> from the "= 4" return value) despite 8 KiB were requested, but then no more 
> data
> arrive.
> Perhaps the opposing side doesn't flush() after writing? Or some tty or USB
> driver doesn't? In any case, this seems not under the control of this PicoLisp
> process.
> ♪♫ Alex

Christopher Howard, Computer Assistant
Alaska Satellite Internet
3239 La Ree Way, Fairbanks, AK 99709
907-451-0088 or 888-396-5623 (toll free)
fax: 888-260-3584

UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to