Carlos, No worries. I **agree** with you about 'localhost' - that should resolve to the standard value if at all possible. When one gets "the" local IP number and asks for the name of that, then the (first) fully qualified DNS entry would be the natural choice.
My point is simply that it is easy to say "change your network configuration," but what if one is lucky to get enough IT support to make a DNS entry, let alone investigate subtle points of the network configuration to make it work. I had huge problems with this, much of which came from Windows itself, and probably some from other sources to remain nameless. There is weirdness here that goes beyond my failure to send the (anachronistic IMHO) #initializeNetwork before doing the lookup on a LINUX MACHINE. Another bug, I know, but it's easy to blame the network; it's harder to fix it sometimes, especially when it's not at fault. Bill ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 6:37 PM To: [email protected] Subject: Re: [Pharo-project] #remoteHostAddress Bill, I dont see a problem if Pharo features some alternate mechanism that may change the result of resolving localhost to another address. I would not insist, localhost is something I associate to a reserved word - perhaps is too much saying localhost comes from a standard Carlos -----Mensaje original----- De: [email protected] [mailto:[email protected]]en nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 03:13 p.m. Para: [email protected] Asunto: Re: [Pharo-project] #remoteHostAddress Carlos, What if one cannot (admin rights) or simply does not wish to be bothered tweaking configurations? I found a goofy sequence of operations that correctly resolved local names, at least on Windows, and will eventually replicate that in Pharo. Bill ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: [email protected] Subject: Re: [Pharo-project] #remoteHostAddress I agree. localhost bound to the loop address is the ip atandard, and based on the stack implementation you run on, you may wish to define localhost to resolve different, you haev the configuration files to change that -----Mensaje original----- De: [email protected] [mailto:[email protected]]en nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 02:13 p.m. Para: [email protected] Asunto: Re: [Pharo-project] #remoteHostAddress For 'localhost', sure, 127.0.0.1 is probably the correct response. However, one can also run into situations of needing to find "the" current IP number/name. There are also servers with multiple addresses, and numbers with multiple names. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: [email protected]; [email protected] Subject: Re: [Pharo-project] #remoteHostAddress Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <[email protected]<mailto:[email protected]>> wrote: Well that does ^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat > <[email protected]<mailto:[email protected]> > > wrote: > I am trying to port Magma to Pharo, and I have run across the > following issue. > > Ini Pharo, the method: > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mir 6/17/2007 20:10) > > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , self remoteHostAddress hostNumber , ':' , port asString] > > > #remoteHostAddress has no implementors in Pharo. > > The implementation of this method in Squeak uses NetNameResolver > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mu 8/14/2003 15:15) > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port > asString] > > Who is maintaining Socket now in Pharo? > Has anyone got some advice on how to solve this? > Cheers > > r. > > > > _______________________________________________ > Pharo-project mailing list > [email protected]<mailto:[email protected]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <[email protected]<mailto:[email protected]>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [email protected]<mailto:[email protected]> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
