On 3 July 2012 17:42, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 3 July 2012 17:38, Levente Uzonyi <leves at elte.hu> wrote:
>> On Tue, 3 Jul 2012, Frank Shearar wrote:
>>
>>> Hi,
>>>
>>> I took WebClient for a spin in a trunk image, and found a failing
>>> test: WebClientServerTest >> #testServerDestroy throws a
>>> "ConnectionClosed: Connection closed while waiting for data". That
>>> sounds familiar - I think this was introduced in a recent Network
>>> change.
>>>
>>> Still, it means WebClient needs fixing. I'll try fix it on my evening
>>> commute, but if anyone feels like racing me, I'll be happy!
>>
>>
>> Interesting, I had no issue with it on windows, except for some extension
>> methods trying to use the CrLf class variable in HTTPSocket (or some other
>> class), but that variable doesn't exist.
>
> Which reminds me of an important fact I should mention: I'm testing
> this on an Ubuntu Lynx box.

Peek tries to read data, which waits for data, which raises the
ConnectionClosed. If peek must return nil when the socket's closed,
I'd expect to see the receiveData wrapped appropriately. Something
like

peek
	"Return next byte, if inBuffer is empty
	we recieve some more data and try again.
	Do not consume the byte."

	self atEnd ifTrue: [^nil].
	self isInBufferEmpty ifTrue:
		[[self receiveData] on: ConnectionClosed do: [^nil] "<--"
		self atEnd ifTrue: [^nil]].
	^inBuffer at: lastRead+1

That's a random hack that makes the test pass (and doesn't break any
others); I don't know if it has any negative consequences elsewhere. I
guess the method as above means "return the next thing in the stream,
unless we're at the end of the stream, or there's no data", which
doesn't seem entirely unreasonable.

frank

> frank
>
>> Levente
>>
>>>
>>> frank
>>>
>>>
>>