May 2010 - 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 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

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