[Pharo-project] 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
We should run the Magma test suite. 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. I'll have a dig around. cheers, Mike On Sat, May 8, 2010 at 4:54 PM, Lukas Renggli <renggli@gmail.com> wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We should run the Magma test suite.
Could you do that?
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? 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. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts Sent: Sunday, May 09, 2010 3:21 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1 On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes and we accept code :) On May 9, 2010, at 2:41 PM, Schwab,Wilhelm K wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts Sent: Sunday, May 09, 2010 3:21 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1
On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, Speaking of code, I have a fair bit of it that I need to check for slips and make available. The slips that are relevant would be anything in comments that might violate non-disclosure agreements[*]. What I need is something/anything that produces syntax colored output given a package name. The idea is that anything in the comment color needs careful scrutiny. Even colored html files that I could view in a web browser would probably do the trick. There was some mention that Seaside might already do this?? I will eventually look for or build something to do it, but pointers would be appreciated. [*] I try to be careful about it now, but sometimes run across old comments that were not for public consumption. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, May 09, 2010 9:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1 yes and we accept code :) On May 9, 2010, at 2:41 PM, Schwab,Wilhelm K wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts Sent: Sunday, May 09, 2010 3:21 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1
On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I thought initially we could do something with netcat and some scripts. But that is a bit limiting on the local host. Ideally we build a test server providing a bunch of network services that would respond to example protocols. I imagine somewhere there is a project that already does this. Most linux distros have all the tools anyway (ftp, http, etc). it seems just a question of configuration and locking-down. cheers, Mike On Thu, May 13, 2010 at 7:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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 <asqueaker@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
MIguel which version of 1.1 because we rollback the changes so normally we should have now the same as in 1.0 Stef On May 19, 2010, at 8:48 PM, Miguel Enrique Cobá Martinez wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Chris Muller -
Lukas Renggli -
Michael Roberts -
Miguel Enrique Cobá Martinez -
Schwab,Wilhelm K -
Stéphane Ducasse