[squeak-dev] WebClient test fails in trunk
Andreas Raab
Andreas.Raab at gmx.de
Sun Jul 15 16:48:15 UTC 2012
Hi David -
Are these patches needed only for IPv6 or also to support IPv4? If the
latter, this would bother me greatly. I can understand why IPv6 may be
implemented in incompatible ways but I can't see why there should be an
incompatible interface to IPv4 addresses which have been used for eternity
in Squeak. In particular given that (I believe) SocketAddress is a subclass
of ByteArray it strikes me as not particularly hard to have Sockets support
ByteArrays of length 4 as IPv4 socket addresses (and perhaps return
instances of SocketAddress with length 4 or so). In any case, I'm not
looking forward to seeing every last bit of networking code break - there
has to be a better way...
Cheers,
- Andreas
>
> -------- Original-Nachricht --------
> Datum: Sun, 15 Jul 2012 11:46:54 -0400
> Von: "David T. Lewis" <lewis at mail.msen.com>
> An: The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>, andreas.raab at gmx.de
> Betreff: Re: [squeak-dev] WebClient test fails in trunk
>
> On Wed, Jul 04, 2012 at 11:46:58PM +0200, Levente Uzonyi
> 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.
>
> I wanted to check that the recent network updates were not causing
> problems for WebClient. I found that some updates to WebClient are
> needed to account for the fact that network addresses are now being
> represented as SocketAddress rather than ByteArray when running on
> a VM that supports the new network primitives.
>
> Attached is a change set that addresses all the issues that I could
> find. I'm assuming that the testServerDestroy issue discussed above
> has already been addressed, as I had no failures for that test.
>
> From the preamble:
>
> Change Set: WebClient-networkPatches-dtl
> Date: 15 July 2012
> Author: David T Lewis
>
> These patches update WebClient to work with new network code in Squeak
> trunk (all tests green).
>
> Explanation: When using the new network code along with a VM that
> supports the
> IPV6 primitives, socket addresses are instances of SocketAddress rather
> than
> ByteArray. Conversion of a socket address to a string must be
> implemented
> differently for SocketAddress.
>
> Also use String crlf instead of undeclared CrLf in HTTPSocket
> class>>httpPostMultipart:args:accept:request:
>
> Note: Squeak automatically uses SocketAddress if the VM supports it at
> image
> start time. To force use of old style ByteArray addresses, evaluate
> NetNameResolver useOldNetwork: true.
>
> Follow up: The WebClient methods in HTTPSocket are marked as overrides
> (category
> *WebClient-HTTP-override) but are not overrides with respect to Squeak
> trunk.
> The override category prevents these methods from appearing in a change
> set
> fileout. Should these methods just be adopted in trunk?
>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120715/d8556cb9/attachment.htm
More information about the Squeak-dev
mailing list
|