-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17-Oct-06, at 7:48 PM, John MacFarlane wrote:
Thanks for your quick response. Here's what I'm seeing now, after recompiling with the changes you suggested:
% gsi/gsi Gambit Version 4.0 beta 20
(define f (open-input-file "README")) (input-port-byte-position f)
0
(read-char f)
#\R
(input-port-byte-position f)
1024
You are witnessing the effect of the buffering. The "byte-position" is the read/write position of the device (a file in this case). At the first read-char, the system will read 1024 bytes into the read buffer. So if you ask for the byte position you will get 1024. The byte position will change after the 1024 bytes have been consumed by a sufficient number of read-chars (or other input operation). The behavior you expected can be obtained by turning the buffering off:
Gambit Version 4.0 beta 20
(define f (open-input-file (list path: "README" buffering: #f))) (input-port-byte-position f)
0
(read-char f)
#\R
(input-port-byte-position f)
1
(read-char f)
#\E
(input-port-byte-position f)
2
(read-char f)
#\A
(input-port-byte-position f)
3
(input-port-byte-position f 0)
0
(read-char f)
#\R
(input-port-byte-position f)
1
Of course the I/O operations will be significantly slower when buffering is off.
It is still not clear to me if this is the proper way of reporting the "byte-position". Gambit has two levels of buffering, a byte buffer and a character buffer. When the byte buffer is empty, an input operation is performed on the device to fill the byte buffer. When the character buffer is empty, the byte buffer is used to fill the character buffer (and a byte to character conversion is performed). The byte position cannot take into account the position in the character buffer because the decoding of bytes to characters may be many to one in general. However the byte position could take into account the position in the byte buffer, which may be more useful than the byte position of the device. I'd appreciate feedback on this issue.
Marc