SocketReadStream nextLine usage?

How does one use this?

I've tried

result := ''.
crLf := Character cr asString, Character lf asString.
socket := Socket port: 80 host: 'www.apple.com'.
socket connect.
readStream := socket readStream.
socket sendByteArray: 'GET /',crLf,crLf.
result := readStream nextLine.
readStream close.
socket close.

After a executing this, result is '' and I get a socket closed error.

Jerome Chan <[hidden email]> wrote in news:eviltofu-
[hidden email]:

> result := ''.
> crLf := Character cr asString, Character lf asString.
> socket := Socket port: 80 host: 'www.apple.com'.
> socket connect.
> readStream := socket readStream.
> socket sendByteArray: 'GET /',crLf,crLf.
> result := readStream nextLine.
> readStream close.
> socket close.

sockets return ints (and ByteArrays). nextLine is expecting
characters. So it never finds the end of line character and so
just reads and reads and reads....

So, you need your own kind of nextLine. In my newsreader, I
have:

readLine
        | result |
        result := (socket readStream upTo: ##(String
lineDelimiter last asInteger)) asString.
        ^(result notEmpty and: [result last = ##(String
lineDelimiter first)]) ifTrue: [result allButLast] ifFalse:
[result]

(borrowed from the definition of nextLine). I think this is a
bug; methods on streams shouldn't make assumptions that they're
reading characters. Not sure how easy this is to fix, though
(there needs to be a CharacterStream class?)

P.

Paul,

> (borrowed from the definition of nextLine). I think this is a
> bug; methods on streams shouldn't make assumptions that they're
> reading characters. Not sure how easy this is to fix, though
> (there needs to be a CharacterStream class?)

I'm not sure I'd go as far as to call it a bug - there are also variants on
whether you require a cr and lf, or just one of them.  What about #upToAll:?
It looks like one could pass it a string or byte array with the required
terminator(s) - or does #skipToAll: choke for some kinds of streams?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]