- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Schwab,Wilhelm K

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(a)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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] Emerging Languages Camp

by Michael Haupt

Hi Serge, On Sun, May 9, 2010 at 7:02 AM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > No one could talk about Pharo at this event ? > http://emerginglangs.com/speakers/ now I don't want to be nitpicking, but Smalltalk ain't much of an emerging language any more, right? Best, Michael

May 9, 2010

[Pharo-project] Text selection color too dark in Pharo 1.1

by Adrian Lienhard

In Pharo 1.0 the background color of selected text looks as follows: In Pharo 1.1: The text is harder to read with the new color. Was this changed on purpose? Adrian

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by StÃ©phane Ducasse

Arghhhhhhh Apparently I did two condenseChanges and I get a problem with code. I could not browse anymore condenseChanges On May 9, 2010, at 1:09 PM, StÃ©phane Ducasse wrote: > Alain > with the latest unstable it seems to work. > You just have to wait a lot once the progress bar is finished to display. > > Then we got only 34/35 methods not installed which is ok. > I will fix condenseSources then :) > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by StÃ©phane Ducasse

Alain with the latest unstable it seems to work. You just have to wait a lot once the progress bar is finished to display. Then we got only 34/35 methods not installed which is ok. I will fix condenseSources then :) Stef

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Lukas Renggli

On 9 May 2010 12:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > probably flushing the cache of MC and PragmaBuilder PragmaBuilder seems to refer to a couple of compiled methods that are not installed in the system. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by StÃ©phane Ducasse

but do you save and quit the image. I added a fix to avoid iterate while changing the collection and we will see. On May 9, 2010, at 12:29 PM, Alain Plantec wrote: > Hi all, >>> i just replaced it with following: >>> >>> (CompiledMethod allInstances reject: #isInstalled) do: [:e | e >>> isInstalled ifFalse: [e destroySourcePointer]]. >>> >> Yes clearly a conceptual bug. >> But with the solution alain proposed ie not destroying while iterating on methods does not work >> (yes it condenses well but accessing some methods is broken). >> > yes but Igor solution is a little bit different because 'e isInstalled' is tested twice, > one for the reject: and the second in the do: block. > But unfortunately, this solution seems to be broken to. It works one time, but while trying to > condenseChanges again several time, my squeak process is killed without flushing any log. > Alain >> Lukas did a cool test that checks whether the we can parse the method. >> >> >> >>> and made it to the end.. took about 5 minutes to wait. (12k methods + >>> become on every method is a little time consuming ;) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] Build squeak vm screencast updated (with FT2Plugin and Alien)

by Alain Plantec

Le 09/05/2010 09:43, laurent laffont a Ã©crit : > on pharocasts: > http://pharocasts.blogspot.com/2010/03/build-squeak-vm-on-linux.html > > Feedback always appreciated :) Hi Laurent, thanks a lot !!!!! Alain > > Cheers, > > Laurent Laffont > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Alain Plantec

Hi all, >> i just replaced it with following: >> >> (CompiledMethod allInstances reject: #isInstalled) do: [:e | e >> isInstalled ifFalse: [e destroySourcePointer]]. >> > Yes clearly a conceptual bug. > But with the solution alain proposed ie not destroying while iterating on methods does not work > (yes it condenses well but accessing some methods is broken). > yes but Igor solution is a little bit different because 'e isInstalled' is tested twice, one for the reject: and the second in the do: block. But unfortunately, this solution seems to be broken to. It works one time, but while trying to condenseChanges again several time, my squeak process is killed without flushing any log. Alain > Lukas did a cool test that checks whether the we can parse the method. > > > >> and made it to the end.. took about 5 minutes to wait. (12k methods + >> become on every method is a little time consuming ;) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

May 9, 2010

Re: [Pharo-project] Fwd: Pharo 1,1 -beta

by StÃ©phane Ducasse

> > Dear Stephane. > Please forward to whomever else it may concern, a bit too rantish to send to the general mailing list though :) No it is not :) It is good to talk and have different opinion. This is what makes life more fun. > I'd wish we were able to meet face to face, as the 2 points I'd like to make would be much easier to make without creating any sort of animosity if I had an an instant opportunity to clearify any details. > > 1.RevertLinkedLists or not, I don't really care. (though, reading through my late-night posts, some degree of personal pride might wrongfully be read into it, for which I apologize) I do not read it like proud :) > It's a trade-off between handling adding objects and links equivalently, or disallowing this. The current implementation is easier to use, while one which allows adding links only is simpler implementation-wise. > It IS important to reach a deciscion for 1.1 though, as it can have long-lasting consequences support-wise. > No matter what the outcome, please don't remove the objective improvements over Squeak, like the swap method, which actually works. ;) Sure do not worry. This asLink is a no brainer. I just think that linkedList should be an internal only used by the scheduler stuff :). > Point 2: We CAN NOT release a beta version of 1.1 in which WeakDictionaries depend on their users to register them for finalization in order to work correctly/reliably. That more important than the other issues > The idea behind the new weakdicts is sound (avoid rehashes whenever removals occur), the implementation however is unsound. (independent of the 10 or so issues which have been resolved for it so far). I have detailed some of my frustrations in comments to / new issues, afraid I can't reference those when writing from my iPhone though. Ok what can we do? I'm still stupid with weak stuff. Do you have code? :))) > The weather here at my friend's is really nice, and I hope you (and Lukas?)'ll have better weather tomorrow :D No it is cold here. May be we will dare to go to brugges instead of getting stuck in front of our screens. :) > > Cheers, > Henry

May 9, 2010