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

Reply via email to