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) _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
