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 9:26

Hi, Graham and Brett,
> On Fri, 18 Oct 2002 14:56:25 +1000 > "Brett Handley" wrote: > >I've asked Graham to check out my theory. In the > > meantime this I what I reckon - the POP scheme > > can't handle a line length greater than 4093. Here's > >a little view program for those interested to test the > >idea: >
From: "Graham Chiu"
> Interestingly although this does not reproduce the problem > for me, it seems Brett does have the same problem in that > read-til-dot gets stuck in a loop returning none. > > The length of the string may be OS dependent. He is using > NT 4, and I'm using XP.
Brett's mutli-x (4094 to be exact :-) -rated email did trip up REBOL on Win98se for me. When I looked at the offending email in your (Graham's) link folder, I am wondering if Brett not be on the right trail, in that the offending email uses HTML with no line breaks. When I experimented, I discovered that it appears to be REBOL's line buffer cannot "absorb" enough characters, at least for NT and Win98. Given the inherent line-oriented nature of POP servers, it is understandable "why" RT used open/lines on the port. But "inconsiderate" email client's that don't offer line breaks seem to break REBOL with its current line buffer. So, I rewrote the pop scheme to switch from line mode to character mode once it begins to read messages. After some fiddling (forgot that newline is not necessarily equivalent to "^M^/" ... whoops there goes an hour of time:-), I got the function to work, so I reintegrated it as the central "read-til-dot" function, and so far it seems to work. It is less than elegant, because I needed to maintain the carriage-return and line-feeds for the port processing logic, but wanted to return the buffer back to the equivalent REBOL newline (hence the replace/all call before the return). If indeed the base problem turns out to be the line buffer, it would be more elegant to improve the native functionality and leave the scheme alone (which was neat in its original form). But my function replacement seems to be more robust for now. Graham, if you decide to try it and it "fixes" the hanging port problem, I would like to report this to feedback, of course. Hope this helps. And thanks to Brett for detecting at least one problem that breaks the pop scheme!! --Scott Jones read-til-dot: func [port buf][ set-modes port [lines: false] line: system/words/copy "" while [line <> ".^M^/"][ line: system/words/copy "" while [not find line "^M^/"][ a: system/words/pick port/sub-port 1 if integer? a [ append line to-char a ] ] insert tail buf line ] set-modes port [lines: true] replace/all buf "^M^/" newline buf ]