[Pharo-project] #remoteHostAddress
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.
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 <ramiro@diaztrepat.name>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.
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 <ramiro@diaztrepat.name
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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 < johnmci@smalltalkconsulting.com> 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 < ramiro@diaztrepat.name
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project@lists.gforge.inria.fr; johnmci@smalltalkconsulting.com 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 <johnmci@smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> 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 <ramiro@diaztrepat.name<mailto:ramiro@diaztrepat.name>
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 Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sabado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project@lists.gforge.inria.fr; johnmci@smalltalkconsulting.com 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 <johnmci@smalltalkconsulting.com> 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 <ramiro@diaztrepat.name > > 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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project@lists.gforge.inria.fr; johnmci@smalltalkconsulting.com 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 <johnmci@smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> 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 <ramiro@diaztrepat.name<mailto:ramiro@diaztrepat.name>
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 Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 03:13 p.m. Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project@lists.gforge.inria.fr; johnmci@smalltalkconsulting.com 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 <johnmci@smalltalkconsulting.com> 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 <ramiro@diaztrepat.name > > 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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ====================================================================== == John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ====================================================================== == _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 6:37 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 03:13 p.m. Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sábado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project@lists.gforge.inria.fr; johnmci@smalltalkconsulting.com 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 <johnmci@smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> 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 <ramiro@diaztrepat.name<mailto:ramiro@diaztrepat.name>
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 Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Carlos Crosetti -
John M McIntosh -
Ramiro Diaz Trepat -
Schwab,Wilhelm K