- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 9 May 2010 20:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The problem was mainly that the UI did not show that it was destroying a lot of methods and I thought it was > blocked. So if you wait enough it seems ok. Lukas checked and reparse and check the system and it seems ok. > Yeah, i also had some troubles with interrupting it, caused by running an infinite loop. :) > Stef > > On May 9, 2010, at 6:55 PM, Igor Stasenko wrote: > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

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

by StÃ©phane Ducasse

The problem was mainly that the UI did not show that it was destroying a lot of methods and I thought it was blocked. So if you wait enough it seems ok. Lukas checked and reparse and check the system and it seems ok. Stef On May 9, 2010, at 6:55 PM, Igor Stasenko wrote: > Probably , a more crash-proof #condenseChanges > would be to use a mass-become. > So, you are not modifying existing methods, but making their copies > with updated source pointers > and copying their source into new changes file. > Then you do a single mass-become and so, all old methods get swapped > with new ones using a single massive blow. > In that way, its more safe, since if you interrupt the > #condenseChanges in the middle, > you can use debugger and browse the code , and if you decide to abort > it, nothing bad happen, > since methods with new source pointers is held in your temp collection > and not yet applied. > > On 9 May 2010 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 9 May 2010 13:29, Alain Plantec <alain.plantec(a)free.fr> 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. >> >> This was a result of lack of attention, not my real intent. :) >> >> In bug entry for this issue i added a method which does just: >> (CompiledMethod allInstances reject: #isInstalled) do: #destroySourcePointer. >> >> there's no way how method can become installed when you changin its trailer. >> So, a single test #isInstalled is sufficient. >> A more faster way is to use a mass-become. >> But i think this is not a place where you need to care too much about >> performance. >> >>> 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. >> >> You mean running #condenseChanges multiple times in a row, or >> interrupting it and then start over again? >> You should know, that it is important to not interrupt it in the >> middle, because when you doing that, >> part of your methods having old source pointers, while rest part >> having new ones, >> and there is no way to tell, which one is correct. >> >>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > 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

May 9, 2010

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

by Igor Stasenko

Probably , a more crash-proof #condenseChanges would be to use a mass-become. So, you are not modifying existing methods, but making their copies with updated source pointers and copying their source into new changes file. Then you do a single mass-become and so, all old methods get swapped with new ones using a single massive blow. In that way, its more safe, since if you interrupt the #condenseChanges in the middle, you can use debugger and browse the code , and if you decide to abort it, nothing bad happen, since methods with new source pointers is held in your temp collection and not yet applied. On 9 May 2010 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 May 2010 13:29, Alain Plantec <alain.plantec(a)free.fr> 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. > > This was a result of lack of attention, not my real intent. :) > > In bug entry for this issue i added a method which does just: > (CompiledMethod allInstances reject: #isInstalled) do: #destroySourcePointer. > > there's no way how method can become installed when you changin its trailer. > So, a single test #isInstalled is sufficient. > A more faster way is to use a mass-become. > But i think this is not a place where you need to care too much about > performance. > >> 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. > > You mean running #condenseChanges multiple times in a row, or > interrupting it and then start over again? > You should know, that it is important to not interrupt it in the > middle, because when you doing that, > part of your methods having old source pointers, while rest part > having new ones, > and there is no way to tell, which one is correct. > >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

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

by Igor Stasenko

On 9 May 2010 13:29, Alain Plantec <alain.plantec(a)free.fr> 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. This was a result of lack of attention, not my real intent. :) In bug entry for this issue i added a method which does just: (CompiledMethod allInstances reject: #isInstalled) do: #destroySourcePointer. there's no way how method can become installed when you changin its trailer. So, a single test #isInstalled is sufficient. A more faster way is to use a mass-become. But i think this is not a place where you need to care too much about performance. > 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. You mean running #condenseChanges multiple times in a row, or interrupting it and then start over again? You should know, that it is important to not interrupt it in the middle, because when you doing that, part of your methods having old source pointers, while rest part having new ones, and there is no way to tell, which one is correct. > 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 > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] Emerging Languages Camp

by Michael Haupt

Hi Mariano, 2010/5/9 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I agree. But PyPy seems to be also an implementation of Python. And > Stratified JavaScriptÂ a JavaScript implementation. Clojure may be consider > a Lisp dialect that runs on a JVM. yup. Hey, I didn't say I agree with all items on the list there. :-) What is specific about those items on the list? PyPy is meta-circular in a very interesting way (never seen that for Python before). I don't know about Stratified JS. Clojure is not just a Lisp, it is a really interesting Lisp implementation on the JVM (to my knowledge, the first one, and it really connects well to the JVM). What specificities / new edges do we have for any of the Smalltalks out there? Best, Michael

May 9, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by StÃ©phane Ducasse

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(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 > > _______________________________________________ > 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 Mariano Martinez Peck

On Sun, May 9, 2010 at 3:57 PM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Hi Mariano, > > 2010/5/9 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > I have just see the website and seems very interesting! Although > Smalltalk > > is not an emerging language anymore, maybe Pharo does ? > > uh, sorry again, but that's a particular Smalltalk implementation, right? > I agree. But PyPy seems to be also an implementation of Python. And Stratified JavaScript a JavaScript implementation. Clojure may be consider a Lisp dialect that runs on a JVM. These are just examples from the conference: http://emerginglangs.com/speakers/ Cheers Mariano > > Best, > > Michael > > _______________________________________________ > 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 Mariano, 2010/5/9 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I have just see the website and seems very interesting!Â Although Smalltalk > is not an emerging language anymore, maybe Pharo does ? uh, sorry again, but that's a particular Smalltalk implementation, right? Best, Michael

May 9, 2010

Re: [Pharo-project] Emerging Languages Camp

by Reg Krock

So why is C# on the list? It certainly is not an emerging language. There are two Smalltalk influence languages on the list: Slate and Newspeak Regards, Reg On 2010-05-09, at 9:40 AM, Mariano Martinez Peck wrote: > I have just see the website and seems very interesting! Although Smalltalk is not an emerging language anymore, maybe Pharo does ? > > Cheers > > Mariano > > 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/ > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > 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 Mariano Martinez Peck

I have just see the website and seems very interesting! Although Smalltalk is not an emerging language anymore, maybe Pharo does ? Cheers Mariano 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/ > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > 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