i'm not sure this email came through whilst the list was down sunday/monday so i am reposting by request. i will add some further content at the end ===================================================== I have dug around the network problem (OS X) in Pharo 1.0. I am convinced #useOldNetwork = true does not work. Looking through old core images, it never worked; at least with my current OS and VM choice. i have been using Magma as a test case. Indeed it is broken on 10508 rc2, however if I set NetNameResolver classPool at: #UseOldNetwork put: false and hack #initializeNetwork to make the reference false as well (since it can change its value once set)... I can run the first 10mins of the Magma test suite which is heavy on network use. I only can't complete the magma test case due to unrelated issues. I've asked Chris to see if these changes work for him. i propose in Pharo Core 1.0 -set UseOldNetwork := false, and change all references that try and set it to true -now we are only using the new network infrastructure, -gather fresh test cases from the community where networking fails and fix them with a final push. -do not try and fix the UseOldNetwork := true branches If we can not get this approach above to work then as a fallback I propose to remove all the new network code and revert it all back to the point where it was simpler where socket addresses were just byte arrays...We then spend more time in 1.1 trying to get it to work properly. Does anyone care at this point how the infrastructure looks in 1.0? The fact that our rc2 network layer is totally bust is enough to do something drastic to finish the cycle. I propose in Pharo 1.1 -strip out all useOldNetwork = true branches. it does not work, and it is a mess to have these two branches side by side, especially when the value of useOldNetwork can change on its own (this happened a number of times to me) I guess due to all the attempts to check and initialize the network. somewhere it flips. obviously we need some focus on testing a final set of changes, but please consider the direction I outline. thanks, Mike ==================================================== I spent some time after writing this above looking at the magma test case more deeply and chatting to Chris offline. After fixing a quoting issue with magma image launching i managed to get the magma test suite to run for about 30 mins (until it stopped...). So in principle the networking does work... Then to my astonishment i could not get it to run again at all for another few hours, i got no where... it was like it was a dream. I suspect the problem is the exact network interfaces that the server and client try to connect/bind to. In the old ipv4 world it was fairly simple. i suspect in the ipv6 world, different parts of magma are binding to different interfaces and i find it impenetrable to work out which. i have lots of interfaces on my machine (wifi, ethernet, parallels virtual, etc) and when you do NetNameResolver localHostAddress (or whatever the message is) you get back only the first one. I think this could be the cause of issues. Adrian mentions to me John thought they came back randomly. So now my conclusion is firmly we have to take a step back and simplify. for pharo 1.0 unless we have someone with a lot of time i do not feel we can untangle the resolver and socket code. We should revert it back to the original #[192 168 0 10] style code when it used to be simple. This assumes the primitives still support this. Then what I would like to see in Pharo 1.1 or 1.2, is that we separate out classes for ip4 and ip6 support, and make them work cleanly and transparently together. Just because we have ip6 support i don't want to be forced to use it. we should have a clearer interface to enumerate all the network interfaces on the machine, and we should really document this heavily. I think the new help system would be great for this. I started to have to write my own scripts just to document the change in API across images. these can go straight into a help system... cheers, Mike