[squeak-dev] WebClient test fails in trunk
Levente Uzonyi
leves at elte.hu
Wed Jul 4 21:46:58 UTC 2012
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.
Levente
>
> frank
>
>> frank
>>
>>> Levente
>>>
>>>>
>>>> frank
>>>>
>>>>
>>>
>
>
More information about the Squeak-dev
mailing list
|