If I run NetNameResolver localHostAddress in a 5.2 image on my iMac it returns #[0 0 0 0]. On a Pi it returns the more appropriate #[192 168 1 42] sort of answer. On an 86 linux it also gives the wrong answer; so it doesn't seem like a purely Mac vm bug. The image says useOldNetwork is true (which seems like something we've been fudging for a long while now) in all cases. If I set the preference to use the ipv6/new network stuff I get a less bad answer on the Mac of 192.168.1.65(192.168.1.65),0(0) - but I don't think it is quite what the rest of the system wants since trying (from PersonalSqueakSource) (NetNameResolver nameForAddress: (NetNameResolver localHostAddress) timeout: 5) ifNil: [NetNameResolver localAddressString] results in a prim failure in NetNameResolver class>>#nameForAddress:timeout: Sigh.
Anybody got any brilliant ideas on what is going wrong here?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A sad tale that brings a lump to the eye and a tear to the throat.
Perhaps you would like to read this thread. I think the upshot is that you are expecting consistency where none is possible.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-May/159797.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-May/159797.html
Chris
Nina Hagen - New York, New York https://www.youtube.com/watch?v=4Cj7mxxEv3Q
On Nov 27, 2019, at 8:48 PM, tim Rowledge tim@rowledge.org wrote:
If I run NetNameResolver localHostAddress in a 5.2 image on my iMac it returns #[0 0 0 0]. On a Pi it returns the more appropriate #[192 168 1 42] sort of answer. On an 86 linux it also gives the wrong answer; so it doesn't seem like a purely Mac vm bug. The image says useOldNetwork is true (which seems like something we've been fudging for a long while now) in all cases. If I set the preference to use the ipv6/new network stuff I get a less bad answer on the Mac of 192.168.1.65(192.168.1.65),0(0) - but I don't think it is quite what the rest of the system wants since trying (from PersonalSqueakSource) (NetNameResolver nameForAddress: (NetNameResolver localHostAddress) timeout: 5) ifNil: [NetNameResolver localAddressString] results in a prim failure in NetNameResolver class>>#nameForAddress:timeout: Sigh.
Anybody got any brilliant ideas on what is going wrong here?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A sad tale that brings a lump to the eye and a tear to the throat.
Yeah, I know about the occasional issue there and perhaps it's the problem here. The interesting question is why my Pi has no problem whatsoever (maybe it has just the one ethernet thing?) but the mac & linuxX86 machines do.
Then the question for more practical purposes is how one can get any sort of meaningful IP number to satisfy the needs of a squeaksource server running on said linuxX86 machine. Setting it explicitly is terribly unsatisfying and of course unstable in the face of dhcp setups.
Also, if we can't have workable solution then we should probably remove the code that appears to provide one!
On 2019-11-27, at 6:24 PM, Chris Cunnington brasspen@gmail.com wrote:
Perhaps you would like to read this thread. I think the upshot is that you are expecting consistency where none is possible.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- COGITO EGGO SUM - I think; therefore, I am a waffle
See if something like this might help:
((NetNameResolver addressesForName: 'squeak.org') detect: [ :info | #inet4 = info addressFamilyName ]) socketAddress hostNumber
Calling a resolver can be slow, so you'll want to remember the result, and maybe put it in a #startUp: method.
We should revisit the networking stuff after the 5.3 release. Ian wrote the primitive support ages ago, and at some point I mashed it into the trunk. But there were concerns about performance of the resolver (at least on Windows) so we ended up leaving "Enable IPv6 and new network support" as a preference. Maybe it's time to turn the preference on, work through the issues, and get rid of the old networking stuff.
Dave
i On Thu, Nov 28, 2019 at 02:04:36PM -0800, tim Rowledge wrote:
Yeah, I know about the occasional issue there and perhaps it's the problem here. The interesting question is why my Pi has no problem whatsoever (maybe it has just the one ethernet thing?) but the mac & linuxX86 machines do.
Then the question for more practical purposes is how one can get any sort of meaningful IP number to satisfy the needs of a squeaksource server running on said linuxX86 machine. Setting it explicitly is terribly unsatisfying and of course unstable in the face of dhcp setups.
Also, if we can't have workable solution then we should probably remove the code that appears to provide one!
On 2019-11-27, at 6:24 PM, Chris Cunnington brasspen@gmail.com wrote:
Perhaps you would like to read this thread. I think the upshot is that you are expecting consistency where none is possible.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- COGITO EGGO SUM - I think; therefore, I am a waffle
On 2019-11-28, at 3:24 PM, David T. Lewis lewis@mail.msen.com wrote:
See if something like this might help:
((NetNameResolver addressesForName: 'squeak.org') detect: [ :info | #inet4 = info addressFamilyName ]) socketAddress hostNumber
Yes, that seems to work on the Mac at least. Nice.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim 999, the number of the Aussie Beast.
squeak-dev@lists.squeakfoundation.org
-
Chris Cunnington -
David T. Lewis -
tim Rowledge