<br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 11:32 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06.06.2012, at 02:41, David T. Lewis wrote:<br>
<div><div class="h5"><br>
> On Tue, Jun 05, 2012 at 05:11:53PM +0200, Bert Freudenberg wrote:<br>
>><br>
>> On 05.06.2012, at 16:44, David T. Lewis wrote:<br>
>><br>
>>> On Tue, Jun 05, 2012 at 03:13:20PM +0200, Bert Freudenberg wrote:<br>
>>>><br>
>>>> On 05.06.2012, at 04:31, David T. Lewis wrote:<br>
>>>><br>
>>>>> On Wed, Jun 22, 2011 at 08:29:29PM -0500, Chris Muller wrote:<br>
>>>>>> Just an FYI, the Magma test suite is pretty heavy on networking<br>
>>>>>> activity, but I didn't encounter any problems with this loaded.<br>
>>>>>><br>
>>>>>> So what needs to happen for us as a community to make a decision on<br>
>>>>>> whether to accept or reject this? I assume we will accept it, but<br>
>>>>>> maybe some of those more familiar with it can make some comments..?<br>
>>>>>> Who is our best networking expert who might want to review it and<br>
>>>>>> discuss?<br>
>>>>><br>
>>>>> I have merged Levente's Network-ul.100 updates into the current Squeak<br>
>>>>> trunk, and made some additional changes to get unit tests working.<br>
>>>>><br>
>>>>> The updates are in the inbox in Network-dtl.123 and NetworkTests-dtl.28.<br>
>>>>> I would appreciate if a couple of folks could load these updates,<br>
>>>>> run the network tests, and let us know if any problems arise.<br>
>>>>><br>
>>>>> If there are no objections after a few days, I'll move the updates<br>
>>>>> to trunk and we can sort out any remaining issues there.<br>
>>>>><br>
>>>>> Dave<br>
>>>><br>
>>>> I committed a small fix to inbox as Network-bf.124. This is needed if you run on a VM that has only the old primitives (like, the Cog VM I'm using).<br>
>>>><br>
>>>> With that fix the fallback code appears to work fine (at least I can use Monticello).<br>
>>>><br>
>>>> A similar fix might be needed for Etoys, but we never ran into it, because we had the new plugin for ages.<br>
>>>><br>
>>>> Btw, shouldn't asSocketAddress rather be an extension of the Network package?<br>
>>>><br>
>>><br>
>>> D'oh! Yes, asSocketAddress should be a Network package extension. Sorry.<br>
>>><br>
>>> Dave<br>
>><br>
>><br>
>> After loading your tests package I get these failures (again, old SocketPlugin):<br>
>><br>
>> HttpUrlTest>>#testHttps<br>
>> SocketTest>>#testLocalAddress<br>
>> SocketTest>>#testRemoteAddress<br>
>> SocketTestOldNetwork>>#testLocalAddress<br>
>> SocketTestOldNetwork>>#testRemoteAddress<br>
>><br>
>> - Bert -<br>
><br>
</div></div>> I get different results on Linux, see attached.<br>
><br>
> I suspect we will need some way to set UseOldNetwork at image startup time<br>
> in order to accomodate VMs that do not have the new network primitives.<br>
><br>
> I believe that the testSendTimeout and testSocketReuse failures that I<br>
> am seeing are Linux specific, and not related to the new network changes<br>
> we are discussing here.<br>
><br>
> I don't understand where the testHttps, testLocalAddress, and testRemoteAddress<br>
> failures are coming from. Can you double check and see if these failures<br>
> existed on your platform prior to the updates we are discussing? In other<br>
> words, are they Mac related, or are they caused by the network updates in<br>
> the inbox?<br>
><br>
> Thanks!<br>
> Dave<br>
<br>
<br>
<br>
The testHttps failure was something local to my image. The other two fail in the same way, wether or not the new code is loaded:<br>
<br>
On Mac OS using the current Network code and a Cog VM (not your new package):<br>
137 run, 135 passes, 0 expected failures, 2 failures, 0 errors, 0 unexpected passes<br>
SocketTest>>#testLocalAddress<br>
SocketTest>>#testRemoteAddress<br>
<br>
Same VM and the new Network code today:<br>
142 run, 140 passes, 0 expected failures, 2 failures, 0 errors, 0 unexpected passes<br>
SocketTest>>#testLocalAddress<br>
SocketTest>>#testRemoteAddress<br>
<br>
<br>
testLocalAddress:<br>
listenerSocket localAddress ==> #[0 0 0 0]<br>
clientSocket localAddress ==> #[127 0 0 1]<br>
serverSocket localAddress ==> #[127 0 0 1]<br>
self listenerAddress ==> #[0 0 0 0]<br>
<br>
testRemoteAddress:<br>
listenerSocket remoteAddress ==> #[0 0 0 0]<br>
clientSocket remoteAddress ==> #[127 0 0 1]<br>
serverSocket remoteAddress ==> #[127 0 0 1]<br>
self listenerAddress ==> #[0 0 0 0]<br></blockquote><div><br></div><div>I fixed the localAddress failures on MacOS X. I'm committing now. One needs to change platforms/unix/plugins/SocketPlugin/sqUnixSocket.c::sqResolverLocalAddress to read, e.g.</div>
<div><br></div><div><div>sqInt sqResolverLocalAddress(void)</div><div>{ sqInt localaddr = nameToAddr(localHostName);</div><div> if (!localaddr)</div><div> localaddr = nameToAddr("localhost");</div><div>
return localaddr;</div><div>}</div></div><div><br></div><div>I'm pretty sure this occurs when one has a hostname set (e.g. my machine McStalker) on a laptop and you change the network configuration (e.g. drop a VPN connexion) that invalidates the hostname's ip. Then nameToAddr returns 0 and one needs to fallback on localhost/<a href="http://127.0.0.1">127.0.0.1</a>.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Bert -<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>