[REBOL] Re: pop problems
From: gscottjones:mchsi at: 18-Oct-2002 15:18
From: "Graham Chiu"
> I think Brett has already reported this to feedback. I'll
> give your function a go the next time Rebol hangs on an
> email, but I fear that it will be much slower reading a
> character at a time vs a line at a time.
Hi, Graham,
I sent 4 messages to myself: two of 16000 bytes in a single line and two of
8000 bytes in a line. Unchanged pop protocol, of course, choked. Doing a
pop read (broadband connection) with my revision over three runs:
0:00:12.42
0:00:07.85
0:00:07.8
Then I sent the same lengths of messages, but this time in a more line
friendly 76 characters per line. First, I ran a pop read with unchanged
protocol:
0:00:04.88
0:00:01.32
0:00:01.37
Then with my changed protocol:
0:00:03.96
0:00:03.96
0:00:03.79
I made a few revisions to my version, including the dumping of the final
period, and I changed the "append" to and "insert tail", which doubled its
speed for the 76 char line length trial (it made very little difference in
the "long line" versions).
Newest version, including the proper binding, for others who may wish to
experiment:
system/schemes/pop/handler/read-til-dot: func [port buf] bind [
set-modes port [lines: false]
line: system/words/copy ""
while [line <> ".^M^/"][
insert tail buf line
line: system/words/copy ""
while [not find line "^M^/"][
a: system/words/pick port/sub-port 1
if integer? a [
insert tail line to-char a
]
]
]
set-modes port [lines: true]
replace/all buf "^M^/" newline
buf
] in system/schemes/pop/handler 'self
I certainly agree that "something" needs to be fixed, and I think we would
all prefer the "/lines" buffer to be more robust in the face of less than
courteous tcp programs. I think the robustness of the patch is a reasonable
trade-off until a proper repair is made. Just trying to be helpful. :-)
> Since the problem is not just with pop, hopefully RT will
> address this problem real soon :)
Agreed!
--Scott Jones