- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Reify the VM in the image [WAS] Why we have Behavior >> flushCache?

by Guillermo Polito

+1 BTW, in the case where it's natural to have a flushCache in behavior, I'd like to have it in the class side, not the instance side. On Tue, Apr 26, 2011 at 3:56 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Let's change the name of the thread :) > > On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Mariano, >> >> the point is that it is classes that manage adding methods to classes >> and hence it is their private behavior to flush the VM's method cache. >> > > Ok...I agree, but still it is misleading when we are talking about "method > cache". Because methods are in classes...so I promise everybody that didn't > know and you ask what Behavior >> flushCache does, and everybody will say > that it flushed the cache of the methods of that class, not the whole cache. > I can understand CompiledMethod >> flushCache and even Symbol >> flushCache > ... but this one looks really strange. > > >> You'll see "self flushCache" in Smalltalk-80 v2 images. >> > > that makes more sense indeed > > >> Now of course the VM provides selective cache flushing but back in the >> day adding or removing a method implied flushing the whole cache. >> Personally I don't see that this justifies adding Smalltalk vm yet. I >> would wait until you have a few more use cases. >> > > Sorry but in this case, I disagree. I think the opposite: it is the perfect > moment to reify the VM in the image and start using it. Why? exactly > because right now we have few uses and it is really easy to migrate. In > fact, for Behavior >> flushCache there are only 3 senders. And I don't > pretend to remove them right now, but with the normal deprecation policy. > This is, in Pharo 1.3 we let the messages like Behavior >> flushCache, > SmalltalkImage >> vmVersion, etc. But we let them as deprecated explaining > that now they should use XXX. And of course, inside the image we do fix the > senders. > > In fact, in Pharo 1.3, the method SmalltalkImage >> vm > "Answer the object to query about virtual machine." > > ^self > > already exists :) > > I see the following possible behavior for VM right now (I mean, the > following methods are already in SmalltalkImage): > > - #flushCache > - #buildDate > - #interpreterSourceVersion > - #platformSourceVersion > - #versionLabel > - #extraVMMemory > - #extraVMMemory: > - #gcBiasToGrow: > - #gcBiasToGrowLimit: > - #getVMParameters > - #primitiveGCBiasToGrow: > - #vmParameterAt: > -#vmParameterAt:put: > - #reportCPUandRAM > - #vmStatisticsReportString > - #vmStatisticsShortString > > So....I think they are enough. And the sooner we do this, the easier it > would be to reify the VM in the image. > > Cheers > > Mariano > > > >> >> On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi. As far as I can see, >>> >>> Behavior >> flushCache >>> "Tell the interpreter to remove the contents of its method lookup >>> cache, if it has >>> one. Essential. See Object documentation whatIsAPrimitive." >>> >>> <primitive: 89> >>> self primitiveFailed >>> >>> >>> And primitive 89 does nothing in particular with the receiver (the class >>> in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, >>> there is NOTHING related to the receiver class. Of course, that's at least >>> what it looks for me (please tell me if I am wrong). >>> So...if this is the case, wouldn't make sense to move it elsewhere? like >>> Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to >>> reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm >>> flushCache, Smalltalk vm parameterAt: , etc.... >>> >>> If you don't like doing "Smalltalk vm" then we can create a VM class with >>> all class methods, or a singleton and use #current or a singleton and put it >>> in Smalltalk globals...etc >>> >>> We will need to fix a couple of senders, thus. >>> >>> What do you think? For me is really confusing, and you don't understand >>> it until you see the primitive implementation. >>> >>> Cheers >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com > >

April 26, 2011

Re: [Pharo-project] roeltyper problem

by Lukas Renggli

It works for me, please try the version here: http://source.lukas-renggli.ch/unsorted Lukas On 26 April 2011 20:31, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I am trying to use RoelTyper, but I encountered subscript out of bounds and empty collection errors. It looks like this problem can be reproduced on 29 classes from Pharo 1.2.1. You can test it using: > > classes := Dictionary new. > Object withAllSubclassesDo: [:each | > Â Â Â Â [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. > classes inspect > > I am not knowledgeable enough to dive into this. Can anyone help? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > > -- Lukas Renggli www.lukas-renggli.ch

April 26, 2011

[Pharo-project] Reify the VM in the image [WAS] Why we have Behavior >> flushCache?

by Mariano Martinez Peck

Let's change the name of the thread :) On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Mariano, > > the point is that it is classes that manage adding methods to classes > and hence it is their private behavior to flush the VM's method cache. > Ok...I agree, but still it is misleading when we are talking about "method cache". Because methods are in classes...so I promise everybody that didn't know and you ask what Behavior >> flushCache does, and everybody will say that it flushed the cache of the methods of that class, not the whole cache. I can understand CompiledMethod >> flushCache and even Symbol >> flushCache ... but this one looks really strange. > You'll see "self flushCache" in Smalltalk-80 v2 images. > that makes more sense indeed > Now of course the VM provides selective cache flushing but back in the day > adding or removing a method implied flushing the whole cache. Personally I > don't see that this justifies adding Smalltalk vm yet. I would wait until > you have a few more use cases. > Sorry but in this case, I disagree. I think the opposite: it is the perfect moment to reify the VM in the image and start using it. Why? exactly because right now we have few uses and it is really easy to migrate. In fact, for Behavior >> flushCache there are only 3 senders. And I don't pretend to remove them right now, but with the normal deprecation policy. This is, in Pharo 1.3 we let the messages like Behavior >> flushCache, SmalltalkImage >> vmVersion, etc. But we let them as deprecated explaining that now they should use XXX. And of course, inside the image we do fix the senders. In fact, in Pharo 1.3, the method SmalltalkImage >> vm "Answer the object to query about virtual machine." ^self already exists :) I see the following possible behavior for VM right now (I mean, the following methods are already in SmalltalkImage): - #flushCache - #buildDate - #interpreterSourceVersion - #platformSourceVersion - #versionLabel - #extraVMMemory - #extraVMMemory: - #gcBiasToGrow: - #gcBiasToGrowLimit: - #getVMParameters - #primitiveGCBiasToGrow: - #vmParameterAt: -#vmParameterAt:put: - #reportCPUandRAM - #vmStatisticsReportString - #vmStatisticsShortString So....I think they are enough. And the sooner we do this, the easier it would be to reify the VM in the image. Cheers Mariano > > On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi. As far as I can see, >> >> Behavior >> flushCache >> "Tell the interpreter to remove the contents of its method lookup >> cache, if it has >> one. Essential. See Object documentation whatIsAPrimitive." >> >> <primitive: 89> >> self primitiveFailed >> >> >> And primitive 89 does nothing in particular with the receiver (the class >> in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, >> there is NOTHING related to the receiver class. Of course, that's at least >> what it looks for me (please tell me if I am wrong). >> So...if this is the case, wouldn't make sense to move it elsewhere? like >> Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to >> reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm >> flushCache, Smalltalk vm parameterAt: , etc.... >> >> If you don't like doing "Smalltalk vm" then we can create a VM class with >> all class methods, or a singleton and use #current or a singleton and put it >> in Smalltalk globals...etc >> >> We will need to fix a couple of senders, thus. >> >> What do you think? For me is really confusing, and you don't understand >> it until you see the primitive implementation. >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] glamour chapter

by Tudor Girba

When the book will be finished, it will probably be available in another format as well. Cheers, Doru On 26 Apr 2011, at 10:22, Mariano Martinez Peck wrote: > THanks Doru...BTW, do you plan to do a pdf/print of the book in the future? > > cheers > > Mariano > > On Tue, Apr 26, 2011 at 10:19 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > For those interested, I updated the Glamour chapter on the Moose Book: > http://www.themoosebook.org/book/internals/glamour > > The examples are meant to work in the latest Moose development image, but the engine is not tied to this image. Please let me know if there are still issues you would like to see discussed. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Beauty is where we see it."

April 26, 2011

Re: [Pharo-project] a problem with Zinc on Pharo 1.1.1

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 8:25 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 26 Apr 2011, at 19:10, Sven Van Caekenberghe wrote: > > > However, full Pharo 1.1.1 compatibility is not yet up to where it was ;-) > > I will try to make all tests green again later on, but it will take some > time. > > OK, Zinc now has all tests green again in Pharo 1.1.1, 1.2.1 and 1.3. > > I don't understand why, but I thought MC always executed class > initializations, but apparently not (or not for existing classes). > ZnMimeType initialize fixed all failed tests. > > Hi Sven, first, cool!!!! Second, I've seen that problem too. I am sure that when loading a new version of a certain package, some class side #initialize are not called. When? which ones? I have no idea. I couldn't reproduce it. Can you? -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Why we have Behavior >> flushCache?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Mariano, > > the point is that it is classes that manage adding methods to classes > and hence it is their private behavior to flush the VM's method cache. > Ok...I agree, but still it is misleading when we are talking about "method cache". Because methods are in classes...so I promise everybody that didn't know and you ask what Behavior >> flushCache does, and everybody will say that it flushed the cache of the methods of that class, not the whole cache. I can understand CompiledMethod >> flushCache and even Symbol >> flushCache ... but this one looks really strange. > You'll see "self flushCache" in Smalltalk-80 v2 images. > that makes more sense indeed > Now of course the VM provides selective cache flushing but back in the day > adding or removing a method implied flushing the whole cache. Personally I > don't see that this justifies adding Smalltalk vm yet. I would wait until > you have a few more use cases. > Sorry but in this case, I disagree. I think the opposite: it is the perfect moment to reify the VM in the image and start using it. Why? exactly because right now we have few uses and it is really easy to migrate. In fact, for Behavior >> flushCache there are only 3 senders. And I don't pretend to remove them right now, but with the normal deprecation policy. This is, in Pharo 1.3 we let the messages like Behavior >> flushCache, SmalltalkImage >> vmVersion, etc. But we let them as deprecated explaining that now they should use XXX. And of course, inside the image we do fix the senders. In fact, in Pharo 1.3, the method SmalltalkImage >> vm "Answer the object to query about virtual machine." ^self already exists :) I see the following possible behavior for VM right now (I mean, the following methods are already in SmalltalkImage): - #flushCache - #buildDate - #interpreterSourceVersion - #platformSourceVersion - #versionLabel - #extraVMMemory - #extraVMMemory: - #gcBiasToGrow: - #gcBiasToGrowLimit: - #getVMParameters - #primitiveGCBiasToGrow: - #vmParameterAt: -#vmParameterAt:put: - #reportCPUandRAM - #vmStatisticsReportString - #vmStatisticsShortString So....I think they are enough. And the sooner we do this, the easier it would be to reify the VM in the image. Cheers Mariano > > On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi. As far as I can see, >> >> Behavior >> flushCache >> "Tell the interpreter to remove the contents of its method lookup >> cache, if it has >> one. Essential. See Object documentation whatIsAPrimitive." >> >> <primitive: 89> >> self primitiveFailed >> >> >> And primitive 89 does nothing in particular with the receiver (the class >> in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, >> there is NOTHING related to the receiver class. Of course, that's at least >> what it looks for me (please tell me if I am wrong). >> So...if this is the case, wouldn't make sense to move it elsewhere? like >> Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to >> reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm >> flushCache, Smalltalk vm parameterAt: , etc.... >> >> If you don't like doing "Smalltalk vm" then we can create a VM class with >> all class methods, or a singleton and use #current or a singleton and put it >> in Smalltalk globals...etc >> >> We will need to fix a couple of senders, thus. >> >> What do you think? For me is really confusing, and you don't understand >> it until you see the primitive implementation. >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

[Pharo-project] roeltyper problem

by Tudor Girba

Hi, I am trying to use RoelTyper, but I encountered subscript out of bounds and empty collection errors. It looks like this problem can be reproduced on 29 classes from Pharo 1.2.1. You can test it using: classes := Dictionary new. Object withAllSubclassesDo: [:each | [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. classes inspect I am not knowledgeable enough to dive into this. Can anyone help? Cheers, Doru -- www.tudorgirba.com "Value is always contextual."

April 26, 2011

Re: [Pharo-project] a problem with Zinc on Pharo 1.1.1

by Sven Van Caekenberghe

On 26 Apr 2011, at 19:10, Sven Van Caekenberghe wrote: > However, full Pharo 1.1.1 compatibility is not yet up to where it was ;-) > I will try to make all tests green again later on, but it will take some time. OK, Zinc now has all tests green again in Pharo 1.1.1, 1.2.1 and 1.3. I don't understand why, but I thought MC always executed class initializations, but apparently not (or not for existing classes). ZnMimeType initialize fixed all failed tests. Sven

April 26, 2011

[Pharo-project] NetNameResolver localHostName - Mac OS always returns an ip address string

by Nick Ager

Hi, When I call the following on my Mac: NetNameResolver localHostName the result is an ip address string eg '192.168.4.174' Is there some configuration work required on the Mac to ensure that #localHostName returns a name rather than ip address. Currently: $ hostname Nick-Agers-MacBook-Pro2.local $ cat /etc/hosts cat /etc/hosts 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts I'd be happy with #localHostName returning the hostname or an entry in /etc/hosts I've tested on Pharo 1.1.1 & 1.2.1 both using a COG vm Thanks Nick

April 26, 2011

Re: [Pharo-project] a problem with Zinc on Pharo 1.1.1

by Sven Van Caekenberghe

Esteban, On 26 Apr 2011, at 18:20, Esteban Lorenzano wrote: > Hi, > I'm trying to execute this: > > ZnClient > get: 'http://127.0.0.1:333/analytics/feeds/data' > username: 'estebanlm(a)gmail.com' > password: 'shhhh' > > ... on a Pharo 1.1.1 image, with latest #stable Zinc version, and I'm getting DNU on: #mimeEncode:multiLine: > > ZnUtils class>encodeBase64: string > ^ (Base64MimeConverter mimeEncode: string readStream multiLine: false) contents > > is a bug, or something I have wrong? > > cheers, > Esteban This should get you past that problem: --- Name: Zinc-HTTP-SvenVanCaekenberghe.145 Author: SvenVanCaekenberghe Time: 26 April 2011, 7:01:32 pm UUID: f9f0831d-5ffa-4a5c-a8ec-b276c9babc35 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.144 fixed ZnUtils class>>#encodeBase64: to test whether Base64MimeConverter responds to #mimeEncode:multiLine:, fall back to #mimeEncode: and manually remove Character cr occurences; this should fix Pharo 1.1.1 compatibility (Thanks Esteban Lorenzano for reporting this) --- However, full Pharo 1.1.1 compatibility is not yet up to where it was ;-) I will try to make all tests green again later on, but it will take some time. Regards, Sven

April 26, 2011