>Are you reading from a pipe to the logger, or from a disk file which is
>in parallel updated by the logger?

I am reading from a file now, but might end up reading data over USB serial
from a Teensy LC or 3.2 microcontroller.

>Where do you see nonblocking mode in tcllib csv?
>I don't see any 'fconfigure' commands in the module, only
>
> while !eof
> if gets < 0 continue
>
>loops... (tcllib 1.20).

It's the same in tcllib 1.21 too.

My code to read one CSV record included:

while {-1 < [gets $ff line]} { ... }

which works fine reading a file in blocking mode.
In looking for why the library code might be different
I found my code did not work for nonblocking mode,
while the tcllib code works in blocking or nonblocking mode.

In retrospect the operation of [gets] makes sense, however
nothing in the documentation for gets (or fconfigure or open)
appears to explain this.

Dave B

* clt.to.davebr@dfgh.net
| My code to read one CSV record included:
>
| while {-1 < [gets $ff line]} { ... }
>
| which works fine reading a file in blocking mode.
| In looking for why the library code might be different
| I found my code did not work for nonblocking mode,
| while the tcllib code works in blocking or nonblocking mode.

Note that the TCLLIB code is

while !eof
if -1 < gets continue

i.e. in non-blocking mode it busy-waits for EOF.

This is quite different from

while -1 < gets
...

which in non-blocking mode stops at the first no-data-available.

I doubt that the Tcllib CSV code will work on input from a serial line,
blocking or not, since it waits for eof, which will never arrive on the
serial line (unless of course you remove the hardware).

Since the Tcllib code does not change the properties of the channel, it
completely depends on how the channel is configured by the caller. And
since it waits for eof, it implicitely requires a channel which will
ultimately 'send' eof.

| I am reading from a file now, but might end up reading data over USB
| serial from a Teensy LC or 3.2 microcontroller.

I *think* your best bet in this case would be to set up an fileevent
handler for the serial line, and read the data event-based as they come
in. Note however that you would need some indication when no more input
is to be expected from the serial line.

R'

On 11/7/2022 12:57 PM, Ralf Fassel wrote:

>
> | I am reading from a file now, but might end up reading data over USB
> | serial from a Teensy LC or 3.2 microcontroller.
>
> I *think* your best bet in this case would be to set up an fileevent
> handler for the serial line, and read the data event-based as they come
> in. Note however that you would need some indication when no more input
> is to be expected from the serial line.
>
> R'

I think the behavior is more common than serial bus lines. I recall
dealing with output from R and having similar results. IRC, R has
"print" or "cat" and neither prints a newline character by default. So,
when the file closes without doing a newline, the fileevent handler
misses the data that was in the buffer.

* saitology9 <saitology9@gmail.com>
| IRC, R has "print" or "cat" and neither prints a newline character by
| default. So, when the file closes without doing a newline, the
| fileevent handler misses the data that was in the buffer.

Cf 'gets' manpage:

This command reads the next line from channelId, returns everything in
the line up to (but not including) the end-of-line character(s), and
discards the end-of-line character(s).
--<snip-snip>--
If end of file occurs while scanning for an end of line, the command
returns whatever input is available up to the end of file.

If you're reading from a file, gets will return the last line of that
file regardless of whether there is a newline at the end or not:

set fd [open test.txt w]
puts $fd "line one"
puts -nonewline $fd "line two"
close $fd

exec od -tc test.txt
0000000 l i n e o n e \n l i n e t w
0000020 o
0000021

set fd [open test.txt r]
while {[gets $fd line] >= 0} {
puts "READ: {$line}"
}
close $fd
=>
READ: {line one}
READ: {line two}

The crucial part is 'EOF'. If you're reading from a serial line, there
is no EOF, so 'gets' keeps waiting for the newline to arrive (and does
*not* return the bytes which have already arrived). You need to plain
'read' in that case to get at the waiting bytes.

R'