[racket] regexp-match-evt and file-position
The `port-commit-peeked' function (used by `regexp-match-evt') was
deeply broken with respect to `file-position' and `port-next-location'.
I see no workaround for old versions, but the problem is now fixed in
the current development version (in the git repo).
At Sat, 11 Jun 2011 07:19:03 -0700, Matthew Flatt wrote:
> Thanks for the report!
>
> I think the bug is more specifically in the implementation of
> `port-commit-peeked' for some kinds of ports, since the following
> program also has the wrong result:
>
> #lang racket/base
> (define-values (in out) (make-pipe))
> (display "12345" out)
> (peek-bytes 3 0 in)
> (port-commit-peeked 3 (port-progress-evt in) always-evt in)
> (file-position in)
>
> Offhand, I don't see why pipe ports are broken while string and file
> ports work. I should be able to fix it soon in the source repo, though,
> and maybe I can find a workaround for v5.1.1.
>
> At Sat, 11 Jun 2011 06:53:37 +0100, Milo Arvidsson wrote:
> >
> >
> > In the following program, (sync (regexp-match-evt #rx"^..." in)) returns
> > '(#"123") but (file-position in) returns 0 instead of 3:
> >
> >
> > #lang racket/base
> > (require racket/port)
> > (define-values (in out) (make-pipe))
> > (display "12345" out)
> > (sync (regexp-match-evt #rx"^..." in))
> > (file-position in)
> >
> >
> >
> > That means there's a problem with regexp-match-evt, right? It means
> > regexp-match-evt is not updating the input port's position following a
> > successful match.
> >
> >
> > If you append (read-char in) (file-position in) to this program, read-char
> will
> > return #\4 and file-position will return 1.
> >
> >
> > Anyway, regexp-match-evt introduces this problem when used with input ports
> > returned by make-pipe, tcp-connect and tcp-accept, but it works fine with the
> > input port returned by open-input-string. I looked at the definition of
> > regexp-match-evt in collects/mzlib/ports.rkt but I can't identify the
> problem.
> > (I'm using Racket v5.1.1 on Windows)