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:

http://code.google.com/p/pharo/issues/detail?id=1853

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.

Ok thanks for the analysis. We should really be able to collect such information and build regression tests. Right now we have test checking for simple behavior but I would like to capture the regression you spotted. I do not know what was the "avoids fixing the plugin bug" but I would like to know that too. Stef

Just bench it:

Before change:

[ NetNameResolver localHostAddress ] bench " '34,000 per second.' "

After change:

[ NetNameResolver localHostAddress ] bench " '31 per second.' "

In just looking at the reason given for making the change, it says this is to satisfy an _exceptional_ case; e.g., the case where "no network connection is available."

Then I look at the new code called by #localHostAddress and becomes obvious why:

isConnected "Dirty, but avoids fixing the plugin bug" [NetNameResolver addressForName: 'www.esug.org'.] on: NameLookupFailure do: [:ex| ^false]. ^true

A hard-coded nslookup to 'www.esug.org' wrapped in an exception-handler? Wow!

If this isn't enough, you can run the Magma test-suite to see the effect on a real-world networking application.

I recommend Pharo crew revert this change and consider a different approach.

- Chris

On Tue, Apr 19, 2011 at 2:27 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

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:

http://code.google.com/p/pharo/issues/detail?id=1853

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.