transcoded-port relies on port-position/set-port-position!

[weinholt]

The get-line procedure behaves strangely with custom binary input ports and also raises a condition.

There are three different types of errors:

• If both get-position and set-position! are provided then all data is read by the first get-line but the second get-line call crashes.
• If only get-position is provided then every sixth character is returned in the first get-line, followed by a crash in get-line.
• If neither position procedure is provided then get-line crashes the first time.

The following program demonstrates the problems:

(import (rnrs))

(define (open-test)
  (define pos 0)
  (define data
    (string->utf8 "    0     1     2     3     4     5"))
  (define (read! bv start count)
    (let* ((bytes-read (fxmin count
                              (fx- (bytevector-length data) pos))))
      (bytevector-copy! data pos bv start bytes-read)
      (write `(bytevector-copy! data ,pos bv ,start ,bytes-read))
      (newline)
      (set! pos (+ pos bytes-read))
      bytes-read))
  (define (get-position) pos)
  ;; (define get-position #f)
  ;; (define (set-position! x) (set! pos x))
  (define set-position! #f)
  (make-custom-binary-input-port "test" read! get-position set-position! #f))

(call-with-port (transcoded-port (open-test) (native-transcoder))
  (lambda (p)
    (let lp ()
      (let ((line (get-line p)))
        (write line)
        (newline)
        (unless (eof-object? line)
          (lp))))))

Example output:

(bytevector-copy! data 0 bv 0 4)
(bytevector-copy! data 4 bv 0 6)
(bytevector-copy! data 10 bv 0 6)
(bytevector-copy! data 16 bv 0 6)
(bytevector-copy! data 22 bv 0 6)
(bytevector-copy! data 28 bv 0 6)
(bytevector-copy! data 34 bv 0 1)
(bytevector-copy! data 35 bv 0 0)
"012345"
(bytevector-copy! data 35 bv 0 0)
&i/o-port: #<textual-input-port>
&who: get-line

(I hope that this access pattern for ports is not the usual one, as it seems quite inefficient).

Tested with IronScheme 1.0.186-31c6aae on Mono 5.18.0.240+dfsg-3 (.NET 4.0 64-bit).

[leppie]

Thanks. Yeah, custom ports are quite badly implemented to keep it compatible with .NET.

The crash issue on the second call was due to not checking for EOF before trying to normalize the EOL chars.

Fixing that, deals with the case where get/set are both supplied, but the other cases are quite broken 🗡

[weinholt]

You mean that .NET code is responsible for reading from the ports and they can be passed around to .NET code? Pretty cool if so, but looks difficult. In any other setting I would expect the ports to have their own buffers and no seeking would be needed.

[leppie]

You mean that .NET code is responsible for reading from the ports and they can be passed around to .NET code? Pretty cool if so, but looks difficult. In any other setting I would expect the ports to have their own buffers and no seeking would be needed.

The idea was to use as much from .NET as possible, but custom ports are a bit of a mess. I could add buffering, but havent really used custom ports, so never had the need.

[leppie]

af28d19 addresses the error with get-line.

I have changed the topic to reflect the correct issue that is remaining(?).

Also @weinholt saw your loko release 🥇 🎉 . Was wondering what scheme that was from circleci. Thought you had something to do with it, but not a whole native implementation :D

[weinholt]

The fs-fatfs tests pass now, but only because I don't check that the output is correct. :)

("README.md") 155
#<textual-input-port>
"sspn6hi e itFepile ,63h"
"s"
#<eof>

[leppie]

This is going to need a proper rework 😿

[leppie]

@weinholt can you try the latest release?

[weinholt]

@leppie Tested with fs-fatfs; verified that the output is now regular English. Looks good.

[weinholt]

I didn't check all the cases from the text of the issue though; busy writing USB hub driver code.

[leppie]

I didn't check all the cases from the text of the issue though; busy writing USB hub driver code.

It's fine. 👍

The issue should be more narrowed down now.