Show stopper network bug on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Show stopper network bug on Windows

Damien Cassou
http://code.google.com/p/pharo/issues/detail?id=961


--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Stéphane Ducasse
Indeed.
Mike is moving just right now but it is important that this bug gets  
addressed.

Stef

On Jul 21, 2009, at 10:41 AM, Damien Cassou wrote:

> http://code.google.com/p/pharo/issues/detail?id=961
>
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Adrian Lienhard
If this bug also exists in Squeak (which I expect since it seems a VM  
problem), I suggest to report it there too (and create a Mantis entry).

Adrian

On Jul 21, 2009, at 13:49 , Stéphane Ducasse wrote:

> Indeed.
> Mike is moving just right now but it is important that this bug gets
> addressed.
>
> Stef
>
> On Jul 21, 2009, at 10:41 AM, Damien Cassou wrote:
>
>> http://code.google.com/p/pharo/issues/detail?id=961
>>
>>
>> --
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>>
>> "Lambdas are relegated to relative obscurity until Java makes them
>> popular by not having them." James Iry
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Damien Cassou
On Tue, Jul 21, 2009 at 12:56 PM, Adrian Lienhard<[hidden email]> wrote:
> If this bug also exists in Squeak (which I expect since it seems a VM
> problem), I suggest to report it there too (and create a Mantis entry).

No, it's only Pharo.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
Again, I *think* the problem is too much code removed, and failure to protect with #useOldNetwork.  It blows up on IPv4; it happens both on Windows and Linux.  If anyone has counter examples or can otherwise show me wrong, please set me straight.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Damien Cassou
Sent: Tuesday, July 21, 2009 11:29 AM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

On Tue, Jul 21, 2009 at 12:56 PM, Adrian Lienhard<[hidden email]> wrote:
> If this bug also exists in Squeak (which I expect since it seems a VM
> problem), I suggest to report it there too (and create a Mantis entry).

No, it's only Pharo.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Adrian Lienhard
In this case the first step woud be to identify which update  
introduced the problem.

Suppose that a core #10200 image still works, you could do:

10200 to: 10384 do: [ :i |
        Utilities updateFromServerThroughUpdateNumber: i.
        NetNameResolver localHostAddress ]

And then see after which update number the first exception is thrown.  
I did not test this, but it should work.

Adrian


On Jul 21, 2009, at 18:47 , Schwab,Wilhelm K wrote:

> Again, I *think* the problem is too much code removed, and failure  
> to protect with #useOldNetwork.  It blows up on IPv4; it happens  
> both on Windows and Linux.  If anyone has counter examples or can  
> otherwise show me wrong, please set me straight.
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> ] On Behalf Of Damien Cassou
> Sent: Tuesday, July 21, 2009 11:29 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Show stopper network bug on Windows
>
> On Tue, Jul 21, 2009 at 12:56 PM, Adrian Lienhard<[hidden email]>  
> wrote:
>> If this bug also exists in Squeak (which I expect since it seems a VM
>> problem), I suggest to report it there too (and create a Mantis  
>> entry).
>
> No, it's only Pharo.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them  
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Stéphane Ducasse
Yes we do not have a windows at hand.
can you let us know from which update the problem is related.


> In this case the first step woud be to identify which update
> introduced the problem.
>
> Suppose that a core #10200 image still works, you could do:
>
> 10200 to: 10384 do: [ :i |
> Utilities updateFromServerThroughUpdateNumber: i.
> NetNameResolver localHostAddress ]
>
> And then see after which update number the first exception is thrown.
> I did not test this, but it should work.
>
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
It's trying to run on a win2k3 box.  I say trying because it insists on telling me (modally) how many updates it processed - every time.  Is there a way to gag that?

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, July 21, 2009 1:36 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

Yes we do not have a windows at hand.
can you let us know from which update the problem is related.


> In this case the first step woud be to identify which update
> introduced the problem.
>
> Suppose that a core #10200 image still works, you could do:
>
> 10200 to: 10384 do: [ :i |
> Utilities updateFromServerThroughUpdateNumber: i.
> NetNameResolver localHostAddress ]
>
> And then see after which update number the first exception is thrown.
> I did not test this, but it should work.
>
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
I think I have it willing to keep running now.  I looked for the #inform: in the process browser, and missed it the first time - I needed to ask for the full stack, and there it was, a good long way down the list :)  It is now sending text to the transcript, so cross your fingers.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
Sent: Tuesday, July 21, 2009 2:22 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

It's trying to run on a win2k3 box.  I say trying because it insists on telling me (modally) how many updates it processed - every time.  Is there a way to gag that?

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, July 21, 2009 1:36 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

Yes we do not have a windows at hand.
can you let us know from which update the problem is related.


> In this case the first step woud be to identify which update
> introduced the problem.
>
> Suppose that a core #10200 image still works, you could do:
>
> 10200 to: 10384 do: [ :i |
> Utilities updateFromServerThroughUpdateNumber: i.
> NetNameResolver localHostAddress ]
>
> And then see after which update number the first exception is thrown.
> I did not test this, but it should work.
>
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
Rats!!! Spoke too soon - "You are about to load a package that has unsaved changes..."




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
Sent: Tuesday, July 21, 2009 2:44 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

I think I have it willing to keep running now.  I looked for the #inform: in the process browser, and missed it the first time - I needed to ask for the full stack, and there it was, a good long way down the list :)  It is now sending text to the transcript, so cross your fingers.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
Sent: Tuesday, July 21, 2009 2:22 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

It's trying to run on a win2k3 box.  I say trying because it insists on telling me (modally) how many updates it processed - every time.  Is there a way to gag that?

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, July 21, 2009 1:36 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

Yes we do not have a windows at hand.
can you let us know from which update the problem is related.


> In this case the first step woud be to identify which update
> introduced the problem.
>
> Suppose that a core #10200 image still works, you could do:
>
> 10200 to: 10384 do: [ :i |
> Utilities updateFromServerThroughUpdateNumber: i.
> NetNameResolver localHostAddress ]
>
> And then see after which update number the first exception is thrown.
> I did not test this, but it should work.
>
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
In reply to this post by Stéphane Ducasse
I am hopefully getting that answer for us. Actually, it just blew up in 10264, but over #next returning nil in Monticello, or so it seems.

More fundamentally than that, are you saying that the code works on a mac, or is it that you have an IPv6-aware network?  Again, I have seen this on both Windows and Linux, and strongly suspect that the problem is that #primHostNameSize blows up on IPv4 or otherwise in connection with trying to accommodate both IP standards.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, July 21, 2009 1:36 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

Yes we do not have a windows at hand.
can you let us know from which update the problem is related.


> In this case the first step woud be to identify which update
> introduced the problem.
>
> Suppose that a core #10200 image still works, you could do:
>
> 10200 to: 10384 do: [ :i |
> Utilities updateFromServerThroughUpdateNumber: i.
> NetNameResolver localHostAddress ]
>
> And then see after which update number the first exception is thrown.
> I did not test this, but it should work.
>
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
This is not quite working, but I suspect this is a defect in primHostNameSize, and will fall by loading VM maker and looking at the socket plugin.  I do not know enough to say whether the primitive needs to be fixed, or simply avoided consistent with #useOldNetwork.




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
Sent: Tuesday, July 21, 2009 2:44 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

I think I have it willing to keep running now.  I looked for the #inform: in the process browser, and missed it the first time - I needed to ask for the full stack, and there it was, a good long way down the list :)  It is now sending text to the transcript, so cross your fingers.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
Sent: Tuesday, July 21, 2009 2:22 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

It's trying to run on a win2k3 box.  I say trying because it insists on telling me (modally) how many updates it processed - every time.  Is there a way to gag that?

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, July 21, 2009 1:36 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

Yes we do not have a windows at hand.
can you let us know from which update the problem is related.


> In this case the first step woud be to identify which update
> introduced the problem.
>
> Suppose that a core #10200 image still works, you could do:
>
> 10200 to: 10384 do: [ :i |
> Utilities updateFromServerThroughUpdateNumber: i.
> NetNameResolver localHostAddress ]
>
> And then see after which update number the first exception is thrown.
> I did not test this, but it should work.
>
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Igor Stasenko
Guys, see my comment on that issue.:
#localHostName should not be used before #initializeNetwork.

Hope it helps.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
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).

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Tuesday, July 21, 2009 6:53 PM
To: [hidden email]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Igor Stasenko
2009/7/22 Schwab,Wilhelm K <[hidden email]>:
> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
> Sent: Tuesday, July 21, 2009 6:53 PM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Damien Cassou
In reply to this post by Igor Stasenko
On Wed, Jul 22, 2009 at 12:53 AM, Igor Stasenko<[hidden email]> wrote:
> Guys, see my comment on that issue.:
> #localHostName should not be used before #initializeNetwork.

#initializeNetwork doesn't prevent the bug from happening.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
Ironically, it did for me on windows, but not on Linux.





-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Damien Cassou
Sent: Wednesday, July 22, 2009 3:36 AM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

On Wed, Jul 22, 2009 at 12:53 AM, Igor Stasenko<[hidden email]> wrote:
> Guys, see my comment on that issue.:
> #localHostName should not be used before #initializeNetwork.

#initializeNetwork doesn't prevent the bug from happening.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Schwab,Wilhelm K
In reply to this post by Igor Stasenko
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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Tuesday, July 21, 2009 11:02 PM
To: [hidden email]
Subject: Re: [Pharo-project] Show stopper network bug on Windows

2009/7/22 Schwab,Wilhelm K <[hidden email]>:
> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Igor
> Stasenko
> Sent: Tuesday, July 21, 2009 6:53 PM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Igor Stasenko
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 <[hidden email]>:

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
> Sent: Tuesday, July 21, 2009 11:02 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Show stopper network bug on Windows
>
> 2009/7/22 Schwab,Wilhelm K <[hidden email]>:
>> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Igor
>> Stasenko
>> Sent: Tuesday, July 21, 2009 6:53 PM
>> To: [hidden email]
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Show stopper network bug on Windows

Igor Stasenko
This is a squeakdebug.log lines:
(again, it fails for me only if i never issue the #initializeNetwork
after image startup before using #localHostName)
-------
Error: a primitive has failed
22 July 2009 10:41:57 pm

VM: Win32 - IX86 - NT - Squeak3.10.2 of '5 June 2008' [latest update: #7179]
Image: Pharo0.1 [Latest update: #10371]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir  ****
Trusted Dir ****
Untrusted Dir ****

NetNameResolver class(Object)>>error:
        Receiver: NetNameResolver
        Arguments and temporary variables:
                aString: 'a primitive has failed'

...
 <snip>
...

NetNameResolver class>>primHostNameSize

--------------

2009/7/22 Igor Stasenko <[hidden email]>:

> 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 <[hidden email]>:
>> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
>> Sent: Tuesday, July 21, 2009 11:02 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Show stopper network bug on Windows
>>
>> 2009/7/22 Schwab,Wilhelm K <[hidden email]>:
>>> 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: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of Igor
>>> Stasenko
>>> Sent: Tuesday, July 21, 2009 6:53 PM
>>> To: [hidden email]
>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12