Stef, What was it fixing? There might be a better solution. I found myself trying to swim in Linux, Pharo and machines with multiple interfaces (wired and wireless) almost simultaneously. I still haven't really figured it out, but *if* #localHostAddress makes sense at all (#localHostAddresses might be more meaningful message), it should probably raise an error if there is not a unique result. #localHostAddress:ifNone:ifMany: would put the sender in control. For your problem, #localHostOrLoopBackAddress would be another option; at least the sender would be knowingly accepting the "risk" of getting the loopback address. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Tuesday, April 19, 2011 3:27 AM To: Pharo-project@lists.gforge.inria.fr; ma.chris.m@gmail.com Cc: magma Subject: Re: [Pharo-project] Networking change in Pharo 1.2? yes Now do you have a description how we can reproduce your problem because the fix was fixing something. and it would be good to understand what is the deeper problem. Stef On Apr 19, 2011, at 4:20 AM, Chris Muller wrote:
Thank you too; it was a bruising problem I'm glad to have it identified.
On Mon, Apr 18, 2011 at 12:21 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Apr 18, 2011, at 7:14 PM, Chris Muller wrote:
The only change to NetNameResolver was this:
Reverting this change fixed it.
Thanks! I have opend the issue again for 1.2.2 and 1.3
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.