NetNameResolver in Pharo 1.1

> In Pharo 1.0 there were some problems with the network stack (namely
> the NetNameResolver) and the IP6 code was reverted shortly before
> release, see the following issue for details:
>
>     http://code.google.com/p/pharo/issues/detail?id=1884
>
> Today I was checking with Stef for the presence of these problems in
> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
> Linux. Does anybody have problems with the following expressions in
> Pharo 1.1?
>
>    NetNameResolver localHostAddress.
>    NetNameResolver addressForName: 'www.yahoo.com'.
>
> Or are we doing the wrong thing to reproduce?
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Mike,
>
> I completely agree that Pharo needs a clear sense of when it starts, and that network inititialization should happen then.  Shutting down and restarting everything on image save is just wrong.  Dolphin does all of this correctly; the key to which is to be willing to save an image that will "wake up" with garbage pointers, but will (because it realizes it is starting) clear all of that and re-initialize (often lazily) so everything is correct in the new session.  Image saves are not relevant to cleanup in that case.  It drove me nuts for a while, but I came to realize that it is the correct approach; one of many in Dolphin's design.
>
> One caveat that we should consider: the weird state of network initialization is perhaps not just due to the absense of session management in Squeak.  It has been explained (Guzdial and Rose??) as being done in deference to some platforms that would react badly to premature network initialization.  Is this just to allow dialup connections on some long-extinct platform?  Is it just an excuse to provide cover for Squeak's lack of session management?  Is it something that made some sense in 1995, but it obsolete in 2010?  Sorry to be so blunt, but there might actually be a good reason for it (perhaps one that is no longer worth the cost) and we won't be able to decide that until we grapple with the truth on both sides.
>
> Another possibility: suppose that to do dialup on your ENIAC, there are problems with #initializeNetwork if it is called before you change the computer's oil.  The problems might be real on some platforms.  Does that mean that broadband-enabled Windows, Mac and Linux users all have to suffer because somebody has a museum piece somewhere?  The answer might be to provide a command line option to defer initialization until the system is ready, but otherwise to do it once on startup.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Roberts
> Sent: Sunday, May 09, 2010 3:21 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1
>
> On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[hidden email]> wrote:
>>> We should run the Magma test suite.
>>
>> Could you do that?
>
> Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more.
>
>>
>>> It was not just related to those NetNameResolver methods IIRC. The
>>> API changed very slightly.  Also, the lazy initialization of
>>> useOldNetwork made it really difficult to see what was going on.
>>
>> In my experiments #useOldNetwork was always 'false' on all platforms
>> (Mac, Linux and Windows). Is this something that depends on the VM?
>
> I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images?
>
>
>> Maybe we should rather remove the old network code and throw an error
>> if somebody is using an old VM that doesn't support the new
>> primitives.
>
> I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths.  Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes.  There are far too many checks for it.  We need to be careful what the old and new API are. this is where documentation would really help.
>
> I ran your methods quickly.  I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order.  There are various threads on it.
> But what changed to cause this? Did we change 1.1 or the VM has a small change?  i didn't track either.
>
> cheers,
> Mike
>
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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

> Mike,
>
> I completely agree that Pharo needs a clear sense of when it starts, and that network inititialization should happen then.  Shutting down and restarting everything on image save is just wrong.  Dolphin does all of this correctly; the key to which is to be willing to save an image that will "wake up" with garbage pointers, but will (because it realizes it is starting) clear all of that and re-initialize (often lazily) so everything is correct in the new session.  Image saves are not relevant to cleanup in that case.  It drove me nuts for a while, but I came to realize that it is the correct approach; one of many in Dolphin's design.
>
> One caveat that we should consider: the weird state of network initialization is perhaps not just due to the absense of session management in Squeak.  It has been explained (Guzdial and Rose??) as being done in deference to some platforms that would react badly to premature network initialization.  Is this just to allow dialup connections on some long-extinct platform?  Is it just an excuse to provide cover for Squeak's lack of session management?  Is it something that made some sense in 1995, but it obsolete in 2010?  Sorry to be so blunt, but there might actually be a good reason for it (perhaps one that is no longer worth the cost) and we won't be able to decide that until we grapple with the truth on both sides.
>
> Another possibility: suppose that to do dialup on your ENIAC, there are problems with #initializeNetwork if it is called before you change the computer's oil.  The problems might be real on some platforms.  Does that mean that broadband-enabled Windows, Mac and Linux users all have to suffer because somebody has a museum piece somewhere?  The answer might be to provide a command line option to defer initialization until the system is ready, but otherwise to do it once on startup.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Michael Roberts
> Sent: Sunday, May 09, 2010 3:21 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1
>
> On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[hidden email]> wrote:
>>> We should run the Magma test suite.
>>
>> Could you do that?
>
> Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more.
>
>>
>>> It was not just related to those NetNameResolver methods IIRC. The
>>> API changed very slightly.  Also, the lazy initialization of
>>> useOldNetwork made it really difficult to see what was going on.
>>
>> In my experiments #useOldNetwork was always 'false' on all platforms
>> (Mac, Linux and Windows). Is this something that depends on the VM?
>
> I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images?
>
>
>> Maybe we should rather remove the old network code and throw an error
>> if somebody is using an old VM that doesn't support the new
>> primitives.
>
> I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths.  Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes.  There are far too many checks for it.  We need to be careful what the old and new API are. this is where documentation would really help.
>
> I ran your methods quickly.  I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order.  There are various threads on it.
> But what changed to cause this? Did we change 1.1 or the VM has a small change?  i didn't track either.
>
> cheers,
> Mike
>
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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

> I have tried to load Magma in Pharo1.1 but have not yet succeeded. I
> don't have a lot of time i'm afraid. the existing Metacello config
> doesn't load the right packages, nor the list on the wiki page (using
> installer) it seems. I am missing an implementation of a method
> maAt:ifPresent:ifAbsent: on Smalltalk.
>
> anyone with a spare moment might like to figure that out. The
> underscores need fixing in dependent packages (write barrier tests)
> as well
>
> so we should maybe do something simpler to test the network.
>
> thanks,
> Mike
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> thanks mike
> indeed we should find a better way to tests network problems.
>
> Stef
>
> On May 13, 2010, at 7:53 PM, Michael Roberts wrote:
>
>> I have tried to load Magma in Pharo1.1 but have not yet succeeded. I
>> don't have a lot of time i'm afraid. the existing Metacello config
>> doesn't load the right packages, nor the list on the wiki page (using
>> installer) it seems. I am missing an implementation of a method
>> maAt:ifPresent:ifAbsent: on Smalltalk.
>>
>> anyone with a spare moment might like to figure that out. The
>> underscores need fixing in dependent packages (write barrier tests)
>> as well
>>
>> so we should maybe do something simpler to test the network.
>>
>> thanks,
>> Mike
>>
>> _______________________________________________
>> 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
>

>
> anyone with a spare moment might like to figure that out. The
> underscores need fixing in dependent packages (write barrier tests)
> as well
>
> so we should maybe do something simpler to test the network.
>
> thanks,
> Mike
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>> installer) it seems. I am missing an implementation of a method
>> maAt:ifPresent:ifAbsent: on Smalltalk.
>
> Hi Mike, this is left-over from when Smalltalk became a
> SmalltalkImage.  But I am confused because I thought I had those all
> cleaned up.  Indeed, I did not find any senders of that to Smalltalk.
>
> Were you just trying to load it or run the test suite?  If you would
> post the stack I would be able to see what you were trying to do and
> would be happy to fix it.
>
>  - Chris
>
>>
>> anyone with a spare moment might like to figure that out. The
>> underscores need fixing in dependent packages (write barrier tests)
>> as well
>>
>> so we should maybe do something simpler to test the network.
>>
>> thanks,
>> Mike
>>
>> _______________________________________________
>> 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
>

> Hi just trying to run the tests via the standard magma test
> expression. So it is looking to see if Display exists. That's the
> point on my mac I recognize that it annoyingly changes my screen
> resolution :-)
>
> anyway it is missing your ma extension to query the namespace.
>
> Cheers
> mike
>
> On Friday, May 14, 2010, Chris Muller <[hidden email]> wrote:
>>> installer) it seems. I am missing an implementation of a method
>>> maAt:ifPresent:ifAbsent: on Smalltalk.
>>
>> Hi Mike, this is left-over from when Smalltalk became a
>> SmalltalkImage.  But I am confused because I thought I had those all
>> cleaned up.  Indeed, I did not find any senders of that to Smalltalk.
>>
>> Were you just trying to load it or run the test suite?  If you would
>> post the stack I would be able to see what you were trying to do and
>> would be happy to fix it.
>>
>>  - Chris
>>
>>>
>>> anyone with a spare moment might like to figure that out. The
>>> underscores need fixing in dependent packages (write barrier tests)
>>> as well
>>>
>>> so we should maybe do something simpler to test the network.
>>>
>>> thanks,
>>> Mike
>>>
>>> _______________________________________________
>>> 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
>>
>

> You have an out-of-date version of "Ma Armored Code" package.  It
> sounds like you are not using instructions on the Magma installation
> page..?
>
>  http://wiki.squeak.org/squeak/2657
>
> The Installer script provided there is correct, I'm not sure what happened..
>
> You could also use Monticello Configurations, but they appear to not
> be working in Pharo 1.1 right now.  I don't know whether Miguel
> updated his Metacello config for Magma; I have not yet had time to get
> into Metacello or I would have done it.
>
> So how did you install this?
>
>
> On Fri, May 14, 2010 at 9:43 AM, Michael Roberts <[hidden email]> wrote:
>> Hi just trying to run the tests via the standard magma test
>> expression. So it is looking to see if Display exists. That's the
>> point on my mac I recognize that it annoyingly changes my screen
>> resolution :-)
>>
>> anyway it is missing your ma extension to query the namespace.
>>
>> Cheers
>> mike
>>
>> On Friday, May 14, 2010, Chris Muller <[hidden email]> wrote:
>>>> installer) it seems. I am missing an implementation of a method
>>>> maAt:ifPresent:ifAbsent: on Smalltalk.
>>>
>>> Hi Mike, this is left-over from when Smalltalk became a
>>> SmalltalkImage.  But I am confused because I thought I had those all
>>> cleaned up.  Indeed, I did not find any senders of that to Smalltalk.
>>>
>>> Were you just trying to load it or run the test suite?  If you would
>>> post the stack I would be able to see what you were trying to do and
>>> would be happy to fix it.
>>>
>>>  - Chris
>>>
>>>>
>>>> anyone with a spare moment might like to figure that out. The
>>>> underscores need fixing in dependent packages (write barrier tests)
>>>> as well
>>>>
>>>> so we should maybe do something simpler to test the network.
>>>>
>>>> thanks,
>>>> Mike
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>

> In Pharo 1.0 there were some problems with the network stack (namely
> the NetNameResolver) and the IP6 code was reverted shortly before
> release, see the following issue for details:
>
>      http://code.google.com/p/pharo/issues/detail?id=1884
>
> Today I was checking with Stef for the presence of these problems in
> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
> Linux. Does anybody have problems with the following expressions in
> Pharo 1.1?
>
>     NetNameResolver localHostAddress.
>     NetNameResolver addressForName: 'www.yahoo.com'.
>
> Or are we doing the wrong thing to reproduce?
>
> Lukas

> El sáb, 08-05-2010 a las 17:54 +0200, Lukas Renggli escribió:
>> In Pharo 1.0 there were some problems with the network stack (namely
>> the NetNameResolver) and the IP6 code was reverted shortly before
>> release, see the following issue for details:
>>
>>     http://code.google.com/p/pharo/issues/detail?id=1884
>>
>> Today I was checking with Stef for the presence of these problems in
>> Pharo 1.1, but we could not reproduce neither on Mac, Windows nor
>> Linux. Does anybody have problems with the following expressions in
>> Pharo 1.1?
>>
>>    NetNameResolver localHostAddress.
>>    NetNameResolver addressForName: 'www.yahoo.com'.
>>
>> Or are we doing the wrong thing to reproduce?
>>
>> Lukas
>
> Sorry for arriving late to the party :).
> I tried the doits from the problem on Pharo 1.0 in a Pharo Core 11364
> image. I got some error, although not as severe as in Pharo 1.0.
>
> I added an issue for this
>
> http://code.google.com/p/pharo/issues/detail?id=2444
>
> Now, I'm going to test with Magma to see if some other error shows
>
> Cheers
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project