Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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