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: [email protected] > [mailto:[email protected]] On Behalf Of Michael > Roberts > Sent: Sunday, May 09, 2010 3:21 AM > To: [email protected] > Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1 > > On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <[email protected]> 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 >> [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 > > _______________________________________________ > 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
