Tcl Source Code

See attached script. Output from script:

bschwarz@mythbox:~$ /usr/local/bin/tclsh8.5 tst_chan.tcl 
tcl_platform(byteOrder)   = littleEndian
tcl_platform(machine)     = x86_64
tcl_platform(os)          = Linux
tcl_platform(osVersion)   = 2.6.22-14-generic
tcl_platform(platform)    = unix
tcl_platform(pointerSize) = 8
tcl_platform(threaded)    = 1
tcl_platform(user)        = bschwarz
tcl_platform(wordSize)    = 8
Tcl patch: 8.5.1
expected integer but got ""
    invoked from within
"chan seek $fid 0 start"
    (file "tst_chan.tcl" line 96)

This occurs even with the work around fix for bug #1904907.

Logged In: YES 
user_id=75003
Originator: NO

Ok. Your 'write' command is still not returning the number of bytes written, but incorrectly an empty string.
This causes an error to be stashed into the tip 219 areas, when 'write' is invoked.

Why is this returned for seek, but not for puts?

In your example the 'puts' is not invoking the 'write' procedure. 'write' is invoked when the channel is flushed, and your [puts] doesn't cause that. Tcl's IO system buffers things up, default is to flush when a buffer is full, or, on interactive stuff, when a full line is written.

However, for [seek] to work properly it the I/O core has to flush outstanding writes, so it does.
At that point the 'write' is invoked, causes the error, which is then returned by [seek].
If you don't do the seek the flush happens on [close], and [close] returns the error.

What you are seeing now is how Tcl I/O core can defer stuff until it is has to be done.
It allows for errors to appear in places which seem to be odd at first glance.
I.e. with reflected channel you can get a very deep peek into the internals of Tcl's IO system.

Logged In: YES 
user_id=80530
Originator: NO


The common cause of the error from both
seek and close is a failed flush.
Investigating further...

Logged In: YES 
user_id=75003
Originator: NO

Question: Does the Tcl you are using pass the testsuite? Because I have lots of test cases for the reflected channel code in ioCmd.test (starting at iocmd-20.0).

File Added - 270416: refchan_example.tcl

Logged In: YES 
user_id=75003
Originator: NO

Ok, an error even with corrected return sounds more like a bug. Given the other data points I wonder if the error happens earlier and is simple reported late and/or not cleared.

I have an example refchan, which I never got around to actually testing for correctness.
I am attaching it now, however it may be bad as well.


File Added: refchan_example.tcl

Logged In: YES 
user_id=159778
Originator: YES

Yes, that is wrong (return [return $idx($chan)]. However, even when I correct that, I still get the error. In fact, even if I have the seek proc only do one thing, return 1, i.e. proc seek {chan offset {base start}} {return 1}, I still get the same error. Also worth noting, is in the tst_chan.tcl file, if you take the chan close out of the [catch], you get the same error there (and commenting out the [chan seek]. So, I'm not sure what's going on...I don't think it is in the implementation. Is there another example script around that I can try out?

Logged In: YES 
user_id=75003
Originator: NO

The reflection layer got an empty string from the Tcl handler you wrote where it expected an integer, so it returned that as an error, and our hackery with the core channel driver code (tip 219 error handling) ensures that you see this error as an err or of 'seek' itself.

So, what does the implementation of 'seek' look like?

Hm ... The last command in the implementation of seek, "return [return $idx($chan)]", looks very very wrong to me. I believe you meant "return $idx($chan)" instead, yes?

File Added - 270332: tst_chan.tcl