April 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Monticello doesn't always call all class side #initalize ?? [WAS] Re: a problem with Zinc on Pharo 1.1.1

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 9:31 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 26 Apr 2011, at 20:39, Mariano Martinez Peck wrote: > > > 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? > > I can't figure it out either, but I haven't really looked deeply into it. > > As far as I can tell it just doesn't work: I guess #initialize is only > called when the class is new or maybe when its definition is changed, maybe > when the #initialize method changes, but certainly not all the time when you > load new(er) versions of methods of that class. Maybe that is too much to > expect, I don't know, it would be handy. > > So when your #initialize calls say #initializeConstants and only that > method is changed, you have a problem. > > Maybe somebody else knows ? > > Sven > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

[Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

Hi guys...with just 2 little methods, I am able to add a button to the debuger and a button to the context of the debugger, to copy the stakctrace to clipboard. Going to PharoDebug.log is anoying: 1) I never know where my image is, so I first need to do print Smalltlak imagePharo 2) then I need to go to such folder, and open the PharoDebug.log 3) most of the times, PharoDebug has appended a lot of other (un) issues so it is quite confusing to use such file for a bug report. Hence I need to: 4) remove PharoDebug.log and 5) Reproduce my problem again, so that to generate a new PharoDebug.log 6) finally search it again, open, and do the copy paste :) So....I think it should be muuuch easier from the debugger. So I added two possibilities 1) copy to clipboard from the "pre debugger windows" See attached screenshot. 2) copy to clipboard from the debugger context menu. See attached screenshot. So...do you like it? which one do you want of them ? both ? Cheers -- Mariano http://marianopeck.wordpress.com

April 26, 2011

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

by Sven Van Caekenberghe

On 26 Apr 2011, at 20:39, Mariano Martinez Peck wrote: > 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? I can't figure it out either, but I haven't really looked deeply into it. As far as I can tell it just doesn't work: I guess #initialize is only called when the class is new or maybe when its definition is changed, maybe when the #initialize method changes, but certainly not all the time when you load new(er) versions of methods of that class. Maybe that is too much to expect, I don't know, it would be handy. So when your #initialize calls say #initializeConstants and only that method is changed, you have a problem. Maybe somebody else knows ? Sven

April 26, 2011

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

by Chris Cunnington

http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146581.ht… NetNameResolver chooses an interface in an almost random manner. It can't be configured as the logic is baked into the VM. The thread above has some details concerning the topic and mentions a workaround. (You might think that being on a Mac, you could make a configuration change in the plist that comes with the VM and then restart. But I don't think there are any arguments in the plist for network interfaces.) Chris

April 26, 2011

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