Okay, then i think it is better to move this thread on vm-dev list (to notify VM devs about this bug), because it seems a VM bug, not image-side bug.
I just tested it on my WinXP + VM (dated 27 march 2009 - not sure what version is) and it indeed failing if i do NetNameResolver localHostName and not do: NetNameResolver initializeNetwork before. But once i did initialization, all subsequent requests is ok. 2009/7/22 Schwab,Wilhelm K <[email protected]>: > Sig, > > Respectfully, I do not agree that the current situation is elegant. There > are other ways to cope with a disabled plugin (see #useOldNetwork), and > littering code with #initializeNetwork is error prone and wasteful in its own > way, no matter how lean the method might be. > > This looks to me like an anachronism. There was no better mechanism, so a > workaround had to suffice. Now with weak collections and events, it should > be possible to do better. If those things do not work well, then they need > to be challenged and fixed as appropriate. > > The lack of fully qualified names could easily be a windows stupidity. My > Dolphin code for lookups has long been a little complicated: look up this, > clear that, do it again, and it always seemed that I was fighting lack of > imagination from the general direction of Redmond WA - who would have thought > that possible? :) My favorite was win2k from (IIRC) pre-sp3: the only > machine one could not find by name was the local host! > > Bill > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Igor > Stasenko > Sent: Tuesday, July 21, 2009 11:02 PM > To: [email protected] > Subject: Re: [Pharo-project] Show stopper network bug on Windows > > 2009/7/22 Schwab,Wilhelm K <[email protected]>: >> Sig, >> >> Queue veryLoudHeadSlap.wav - however, that is not a fix for it on Linux. >> Also, on Windows, I am not getting the fully qualified name, which is >> another problem. It also helps make the case for formalized session >> management, as the image should know when it has had its first cup of coffee >> (the vm can inform it). >> > Usually, all code , working with sockets , sending #initializeNetwork, to be > sure it is initialized: > > Socket>>newTCP: family > "Create a socket and initialise it for TCP" > self initializeNetwork. > ^[ super new initialize: TCPSocketType family: family ] > repeatWithGCIf: [ :socket | socket isValid not ] > > --------- > Socket>>initializeNetwork > "Initialize the network drivers and the NetNameResolver. Do nothing if > the network is already initialized." > "Note: The network must be re-initialized every time Squeak starts up, > so applications that persist across snapshots should be prepared to > re-initialize the network as needed. Such applications should call 'Socket > initializeNetwork' before every network transaction. " > > NetNameResolver initializeNetwork > ---------- > another way could be just add the #startUp method and initialize network > there. > But i think that current solution is more elegant, because if your image > never using the network, it will never initialize the plugin and in this way, > preserve some resources. > And , of course , there could be the cases, where VMs built without network > support, or running with disabled networking security setting (for > sandboxing). In these cases this primitive (as well as rest of socket prims) > will fail. > > As for retreiving a fully qualified name - can't give you answer right now. I > think it can be answered by Andreas, who added the ipv6 support recently to > Windoze VM platform code. > >> Bill >> >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Igor >> Stasenko >> Sent: Tuesday, July 21, 2009 6:53 PM >> To: [email protected] >> Subject: Re: [Pharo-project] Show stopper network bug on Windows >> >> Guys, see my comment on that issue.: >> #localHostName should not be used before #initializeNetwork. >> >> Hope it helps. >> >> _______________________________________________ >> Pharo-project mailing list >> [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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
