- Pharo-dev - lists.pharo.org

[Pharo-project] pseudo class
by Sean Allen April 27, 2011

April 27, 2011

i've been poking around trying to figure out what pseudo class does in pharo and haven't really been successul. can someone give me some basic background on the role it serves?

3 2

Re: [Pharo-project] Fix proposed to make alt+t open a transcript in PharoCore 1.3
by Marcus Denker April 27, 2011

April 27, 2011

On Apr 25, 2011, at 3:55 PM, Damien Cassou wrote: > http://code.google.com/p/pharo/issues/detail?id=4093 > We should role back to the old transcript... all of the many problems with transcript will then be fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-project] [Vm-dev] Re: A possible Cog bug (was: Re: [squeak-dev] Direct implementation of shift/reset in Smalltalk)
by Eliot Miranda April 27, 2011

April 27, 2011

Hi Levente, 2011/4/26 Levente Uzonyi <leves(a)elte.hu> > > Hi Eliot, > > On Tue, 26 Apr 2011, Eliot Miranda wrote: > > Hi Levente, >> try out the latest VMs. They don't fix the bugs, but do change the >> symptoms. e.g. in >> >> c := [ 3 + PartialContinuationNotification signal ] >> on: PartialContinuationNotification >> do: [ :not | not continuation ]. >> c value: 4. "==> 7" >> >> there is now an MNU of #+ since 3 has been replaced by a MethodContext. >> >> So if I could ask you could dig in again, that would help. >> > > the symptoms are much better now. The cause of the MNU seems to be that the > copied contexts have some "junk" at their indexable slots. Implementing > ContextPart >> #copyTo: as below solves (hides) the problem. > > ContextPart >> copyTo: aContext > "Copy self and my sender chain down to, but not including, aContext. > End of copied chain will have nil sender." > > | copy | > self == aContext ifTrue: [ ^nil ]. > copy := self copy. > "Cog doesn't copy the temps properly, so copy them here." > 1 to: self size do: [ :i | copy at: i put: (self at: i) ]. > sender ifNotNil: [ copy privSender: (sender copyTo: aContext) ]. > ^copy > > To reproduce the "junk" copying bug, evaluate the following: > > | context | > context := thisContext copy. > { context. context copy } explore > > The first context's first slot will be nil, while the second context's > first slot will point to the sender context. Actually the indexable slots > are filled with the values of the fixed slots, that's why the sender context > is at the first indexable slot of the second context. Here's an example with > more indexable slots: > > | context a b c d e | > context := thisContext copy. > a := b := c := d := e := context. > { context. context copy } explore. > { a. b. c. d. e } "This is here to avoid compiler complaints." > Hmm... the above behavior is intentional and correct in that to speed up context-to-stack mapping Cog makes no guarantee to preserve the values of temporary values after a context has returned. You'll notice that the entire closure scheme is centered around this, in that temporaries that must outlive their dynamic extent for the correct working of blocks are either copied into blocks (as copied values) or stored into remote temp vectors, hence breaking any dependence on the temporaries in enclosing contexts. If you can live with this restriction then instead of stating "Cog doesn't copy the temps properly, so copy them here." in your reimplementation of copyTo: it would be more accurate to state "Cog doesn't preserve non-closed-over temps beyond their dynamic extent, so copy them here." or some such. Note that Cog /does/ preserve arguments. However, I've clearly still got some bug because look at the following. In the copy the arguments ba1 & ba2 (1 & 2) are in the wrong place on the stack. Sigh... [:ba1 :ba2| | context a b c d e | context := thisContext copy. a := b := c := d := e := context. { context. context copy } explore. { a. b. c. d. e } "This is here to avoid compiler complaints."] value: 1 value: 2 > > > Levente > > >> thanks! >> >> best, >> Eliot > > >

1 0

[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 April 26, 2011

April 26, 2011

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

2 1

[Pharo-project] [update 1.3] #13173
by Marcus Denker April 26, 2011

April 26, 2011

13173 ----- Issue 4094: Object>>chooseUniqueClassName can be removed Issue 2177: Generalize stream protocol #readInto:startingAt:count: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Memory profiling
by Alexandre Bergel April 26, 2011

April 26, 2011

Hi! I have been working on a memory profiler for Pharo. People who attended Smalltalks'10 may remember Mariano Coca's presentation. Unfortunately, I am not satisfied with what we can obtain from the execution of a piece of code in Pharo. The amount of memory consumed by a method _significantly varies_ across execution. I have the impression that memory consumption is a less stable metric than execution time. For example, I used this as a benchmark: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 7 timesRepeat: [ 5 timesRepeat: [ Smalltalk garbageCollect]. MemoryProfiler viewProfiling: [ 20 timesRepeat: [| view | 5 timesRepeat: [ Smalltalk garbageCollect]. Object new. Object new. 5 timesRepeat: [ Smalltalk garbageCollect]. view := MOViewRenderer new. view nodes: (1 to: 5000). view root applyLayout] ] inPackagesMatching: 'Mondrian-*' ] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It opens a simple visualization in Mondrian. I tried to clean as much as I can before executing the code with multiple garbage collect. This piece of code return 7 profiles. In a profile I have for the method MOBoundedShape>>heightFor: : Number of Young Allocated Bytes: 42,879,008 bytes Number of Old Allocated Bytes: 6,000,660 bytes Total Allocated Bytes: 48,879,668 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,415 Number of Full GC's: 0 Number of Tenures of Surving Objects: 164 In another profile I have: Number of Young Allocated Bytes: -7,857,156 bytes Number of Old Allocated Bytes: 6,008,872 bytes Total Allocated Bytes: -1,848,284 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,373 Number of Full GC's: 0 Number of Tenures of Surving Objects: 165 In another: Number of Young Allocated Bytes: -11,956,720 bytes Number of Old Allocated Bytes: 5,315,216 bytes Total Allocated Bytes: -6,641,504 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,354 Number of Full GC's: 0 Number of Tenures of Surving Objects: 145 And another: Number of Young Allocated Bytes: 59,132,472 bytes Number of Old Allocated Bytes: 6,177,772 bytes Total Allocated Bytes: 65,310,244 bytes Number of Increased Memory Bytes: 0 bytes Number of Incremental GC's: 1,361 Number of Full GC's: 0 Number of Tenures of Surving Objects: 167 The metric "Number of Young Allocated Bytes", "Number of Old Allocated Bytes", "Total Allocated Bytes" are highly unpredictable: i.e., two profiles are likely to be completely different. I am not sure why is this so. I use the standard Pharo1.2 One click, without additional parameter to the VM. Do you think that other platforms and languages behave the same? However, the positive point is that it seems that the amount of incremental GC and the number of tenured objects may play an important role in estimating the memory consumption. These metrics are much more stable. What do you think on this? Does it make sense to say that more a method triggers incremental GC, more it consumes memory? What exactly triggers an incremental GC? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

[Pharo-project] Process for fixing a package in stable but not in core?
by Michael Forster April 26, 2011

April 26, 2011

Hi, Forgive me, but I'm still new to the Pharo development process, and my problem lies somewhere between being a Pharo developer and user. First, "Beeper beep" does not work in the current 1.2.1 image that I'm using for production. I need to fix it and would like to share that fix with the community. Second, I see from (closed) Issue 3489 that this is not a Pharo core problem, but one with the PharoSound package, and that, apparently, it might be fixed in the latest package version. Third, I fire up my 1.2.1 image, open the PharoSound squeaksource repository in the monticello browser and discover that, as expected, squeaksource does have some newer packages than the image. For example, 1.2.1-image: Sound-GuillermoPolito.63 vs. squeaksource: Sound-MarianoMartinezPeck.65 However, in other cases, the squeaksource package is _older_ than the image's. For example, squeaksource: ConfigurationOfPharoSound-GuillermoPolito.17 vs. 1.2.1-image: ConfigurationOfPharoSound-GuillermoPolito.22. How does one make sense of this? While can I reliably get the latest version of PharoSound loaded in a 1.2.1 image so that I know I'm writing and testing my fixes against a version that I can give back to the community -- and, more importantly, won't be blown away by some upcoming package version juggling? Thanks, Mike

2 1

[Pharo-project] a problem with Zinc on Pharo 1.1.1
by Esteban Lorenzano April 26, 2011

April 26, 2011

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

3 4

[Pharo-project] NetNameResolver localHostName - Mac OS always returns an ip address string
by Chris Cunnington April 26, 2011

April 26, 2011

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

1 0

[Pharo-project] Reify the VM in the image [WAS] Why we have Behavior >> flushCache?
by Mariano Martinez Peck April 26, 2011

April 26, 2011

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

2 1