On 4 July 2012 22:46, Levente Uzonyi <leves at elte.hu> wrote:
> On Tue, 3 Jul 2012, Frank Shearar wrote:
>
>> 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.
>
>
> The VM also matters in this case. I tried it with an older CogVM which
> doesn't have the new socket primitives.
>
>
>>
>> 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.
>
>
> I never really used or looked deeply into SocketStream, so I'm not sure if
> it's okay to catch that exception.

Indeed! I should add that while it's a WebClient test failing, the
above is in the Network package. The WebClient test basically asks
"what do we peek after a socket's been destroyed?" and expects the
answer to be nil. If I understand the Stream protocol correctly (which
I almost certainly don't), returning nil would seem to be the
appropriate return value when you're at the end of the stream. In
Xtreams the answer would be "you get an Incomplete exception".

frank

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