September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

by Adrian Lienhard

On Sep 22, 2010, at 12:12 , Henrik Johansen wrote: >> - In the line contentBytes := contentBytes + (self basicSize * bytesPerElement), why is contentBytes added because it should be always 0 because self class instSize should return 0 in case of variable classes. Or do I miss something? > You can have instance variables in variable classes: Yes, of course; I forgot this case. Adrian

Sept. 22, 2010

Re: [Pharo-project] Morphic

by Fernando olivero

There's a whole bunch of documentation available in the web, i posted here some interesting ones. http://www.google.ch/url?sa=t&source=web&cd=4&ved=0CDEQFjAD&url=http%3A%2F%… http://wiki.squeak.org/squeak/30 http://portal.acm.org/citation.cfm?id=215636 http://static.squeak.org/tutorials/morphic-tutorial-1.html Fernando On Sep 21, 2010, at 6:06 PM, reluctant wrote: > > Hi, iâm one of the â hobbyist â end users.. > > All i read about Morphic is really thrilling, and all i miss is > documentation. Expecially on the subject of what design principles Morphic > was designed in mind with. > > All i could find about Morphic was the > - one chapter in the Pharo/Squeak by Example book, > - the original Self documentation > - and a thesis on the subject of âNaked Objectsâ which talks a bit about the > ideas that might have been behind Morphic. > > The little bit of Morphic i could understand seems really interesting and i > would really love someone could explain the ideas (it seems it had a > different design principle in mind than the MVC paradigm?) of Morphic in > Pharo/Squeak more thoroughly to âend usersâ. > > It also seems that other users have similar problems: > http://stackoverflow.com/questions/670727/writing-a-gui-in-squeak > -- > View this message in context: http://forum.world.st/Morphic-tp2544184p2548950.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 22, 2010

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

by Mariano Martinez Peck

On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote: > > > Some notes: > > > > - What should be answered for small ints? 1 sizeInMemory -->8. That's > wrong. Shouldn't this answer 0? > > Philosophical question really, imo both 4 (Again, in 32bit images at least) > and 0 would be "correct" answers in their own ways. 8 is definitely wrong > though :) > The method comment should probably highlight which definition is used. > > At the beginning I also thought to have 4, instead of 0. The problem is that if you put 4 and you have an object with and instVar that it is a SmallInteger, it will be counted twice, when actually it is only one. That's why I thoguht 0 was better, since I want the really occupated memory. On the other hand, if you do "4 sizeInMemory" and see zero, I have to admit it is a litlte confusing. The problem is that if I do for example: Class >> spaceForInstances | totalSize | totalSize := 0. self allInstancesDo: [ :inst | totalSize := totalSize + inst sizeInMemory. ]. ^ totalSize SmallInteger spaceForInstances ->> 0 So I don't know...maybe we have to answer 4 instead of 0? Adrian what do you think? > > > - In the line contentBytes := contentBytes + (self basicSize * > bytesPerElement), why is contentBytes added because it should be always 0 > because self class instSize should return 0 in case of variable classes. Or > do I miss something? > You can have instance variables in variable classes: > > ArrayedCollection variableSubclass: #TallyArray > instanceVariableNames: 'tally' > classVariableNames: '' > poolDictionaries: '' > category: 'Collections-Arrayed' > > TallyArray instSize 1 > (TallyArray new: 5) basicSize 5 > > Sure, they're not used very often in Squeak/Pharo since become: is so slow, > but there's no theoretical reason why you can't for example implement Set as > a variable subclass with a tally inst var. > > > > > - Please remove the inline comment "inst vars"; if a comment is needed it > should go into the main comment. > I agree, should be self-explanatory. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 22, 2010

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

by Henrik Johansen

On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote: > Some notes: > > - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0? Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :) The method comment should probably highlight which definition is used. > > - In the line contentBytes := contentBytes + (self basicSize * bytesPerElement), why is contentBytes added because it should be always 0 because self class instSize should return 0 in case of variable classes. Or do I miss something? You can have instance variables in variable classes: ArrayedCollection variableSubclass: #TallyArray instanceVariableNames: 'tally' classVariableNames: '' poolDictionaries: '' category: 'Collections-Arrayed' TallyArray instSize 1 (TallyArray new: 5) basicSize 5 Sure, they're not used very often in Squeak/Pharo since become: is so slow, but there's no theoretical reason why you can't for example implement Set as a variable subclass with a tally inst var. > > - Please remove the inline comment "inst vars"; if a comment is needed it should go into the main comment. I agree, should be self-explanatory. Cheers, Henry

Sept. 22, 2010

Re: [Pharo-project] Webpage for research paper about Pharo?

by StÃ©phane Ducasse

good idea. May be pharo in research :) > Hi! > > I would like to create a webpage that lists papers about Pharo. > There were some announcements on smalltalk-research(a)googlegroups.com, but it is not really useful for me to keep track of what's going on. > Maybe a page accessible from > http://www.pharo-project.org/about/success-stories > or http://www.pharo-project.org/about/ > will be good. > > If the community agrees on this, I am willing to lead this effort. > Opinion? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 22, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Sven Van Caekenberghe

MCHttpRepository location: 'http://www.squeaksource.com/DejaVu' user: '' password: '' On 22 Sep 2010, at 11:42, StÃ©phane Ducasse wrote: > where is the package? > >>> >> This package works great (Pharo 1.1, Cog, OSX). Thanks for the pointer. >> >> Due to the size issue, I wouldn't include them all by default. >> >> Maybe we could make some clever set of MC packages that you can load for each font size that you want ? >> Or load the spec data from a file/url ? >> >> I think most people will only need one or two sizes. The fallback should just be miminal. >> >> Sven >> >> >> _______________________________________________ >> 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

Sept. 22, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by StÃ©phane Ducasse

where is the package? >> > This package works great (Pharo 1.1, Cog, OSX). Thanks for the pointer. > > Due to the size issue, I wouldn't include them all by default. > > Maybe we could make some clever set of MC packages that you can load for each font size that you want ? > Or load the spec data from a file/url ? > > I think most people will only need one or two sizes. The fallback should just be miminal. > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 22, 2010

Re: [Pharo-project] Launching class form command line ...

by Henrik Johansen

On Sep 22, 2010, at 3:12 10AM, John M McIntosh wrote: > > > Begin forwarded message: > >> From: John M McIntosh <johnmci(a)smalltalkconsulting.com> >> Date: September 21, 2010 3:55:54 PM PDT >> To: Henrik Johansen <henrik.s.johansen(a)veloxit.no> >> Cc: pharo-dev(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Launching class form command line ... >> Reply-To: johnmci(a)smalltalkconsulting.com >> >> >> >> On 2010-09-21, at 7:01 AM, Henrik Johansen wrote: >>>> >>> >>> BTW, dunno if it's a crossplatform Cog issue ( haven't checked others) but in John's new OSX Cog-based VMs (last tested 5.8b9), it doesn't look like the arguments are present in systemAttributes at position 2 onwards. >>> Thus, ProjectLauncher will fail to execute scripts at all. >> >> This should work, can you supply an example of use. Here are the command lines I used: /Applications/Squeak\ 4.2.5beta1U.app/Contents/MacOS/Squeak\ VM\ Opt /Users/henrikjohansen/Dropbox/Pharo/PharoCore-1.2-12137.image spaceTally.st In image: Smalltalk documentPath 'spaceTally.st' /Applications/Squeak\ 64-32\ 5.7b1.app/Contents/MacOS/Squeak /Users/henrikjohansen/Dropbox/Pharo/PharoCore-1.2-12137.image spaceTally.st In image: Smalltalk documentPath nil ('spaceTally.st' not in any system attribute < 4000 either) /Applications/Squeak\ 5.8b9.app/Contents/MacOS/Squeak /Users/henrikjohansen/Dropbox/Pharo/PharoCore-1.2-12137.image spaceTally.st Same in-image behavior as 5.7b1. So doesn't seem specifically Cog-related, as it affects 5.7 as well Cheers, Henry

Sept. 22, 2010

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

by Mariano Martinez Peck

Thanks Adrian for the feedback. I agree with your comments. What about this now: sizeInMemory "Answer the number of bytes consumed by this instance including object header." | isCompact headerBytes contentBytes | (self isMemberOf: SmallInteger) ifTrue: [^0]. self class isVariable ifTrue: [ | bytesPerElement | bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4]. contentBytes := (self basicSize * bytesPerElement).] ifFalse: [ contentBytes := self class instSize * Smalltalk wordSize.]. isCompact := self class indexIfCompact > 0. headerBytes := contentBytes > 255 ifTrue: [3 * Smalltalk wordSize] ifFalse: [isCompact ifTrue: [Smalltalk wordSize] ifFalse: [2 * Smalltalk wordSize]]. ^ headerBytes + contentBytes is it better? cheers Mariano On Wed, Sep 22, 2010 at 9:59 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Some notes: > > - What should be answered for small ints? 1 sizeInMemory -->8. That's > wrong. Shouldn't this answer 0? > > - In the line contentBytes := contentBytes + (self basicSize * > bytesPerElement), why is contentBytes added because it should be always 0 > because self class instSize should return 0 in case of variable classes. Or > do I miss something? > > - Please remove the inline comment "inst vars"; if a comment is needed it > should go into the main comment. > > Adrian > > > On Sep 21, 2010, at 22:14 , Mariano Martinez Peck wrote: > > > 2010/9/21 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > > > >> On 21.09.2010 20:47, Mariano Martinez Peck wrote: > >> > >> > >> > >> On Tue, Apr 27, 2010 at 1:19 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> > >>> Its a simple method in Object: > >>> > >>> Object>>sizeInMemory > >>> "Returns the number of bytes used by this object in memory > >>> (including its header)" > >>> > >>> | headerSize instanceSize | > >>> headerSize := (self class indexIfCompact > 0 ifTrue: [ 4 ] > ifFalse: > >>> [ 8 ]). > >>> instanceSize := (self class isVariable > >>> ifFalse: [ self class instSize * Smalltalk wordSize ] > >>> ifTrue: [ (self basicSize * (self class isBytes > >>> ifTrue: [ 1 ] ifFalse: [ Smalltalk wordSize ])) > ]). > >>> ^ headerSize + instanceSize > >>> > >>> > > ^ headerSize + contentBytes > > > > :) > > > > Thanks Henry....so do you think we can integrate this? > > > > Adrian? > > > > > > > >> > >> Hi Adrian. Sorry for returning to this thread. I am trying to > contemplate > >> all the cases. > >> > >> I was looking at SpaceTally and I found that maybe a better > implementation > >> could be something like this: > >> > >> Object >> sizeInMemory > >> "Answer the number of bytes consumed by this instance including > object > >> header." > >> > >> | isCompact instVarBytes bytesPerElement headerBytes total > contentBytes > >> | > >> isCompact := self class indexIfCompact > 0. > >> instVarBytes := self class instSize * 4. > >> self class isVariable > >> ifTrue: [ > >> bytesPerElement := self class isBytes ifTrue: [1] ifFalse: > [4]. > >> total := 0. > >> contentBytes := instVarBytes + (self basicSize * > >> bytesPerElement). > >> headerBytes := > >> contentBytes > 255 > >> ifTrue: [12] > >> ifFalse: [isCompact ifTrue: [4] ifFalse: [8]]. > >> total := headerBytes + contentBytes. > >> ^ total] > >> ifFalse: [ > >> headerBytes := > >> instVarBytes > 255 > >> ifTrue: [12] > >> ifFalse: [isCompact ifTrue: [4] ifFalse: [8]]. > >> ^ headerBytes + instVarBytes ]. > >> > >> > >> > >> I guess I did some mistake but if we can arrive to a good implementation > it > >> would be really cool. > >> > >> Thanks > >> > >> mariano > >> > >> > >> Please, at least do some refactoring :) > >> > >> Object >> sizeInMemory > >> "Answer the number of bytes consumed by this instance including > object > >> header." > >> | isCompact headerBytes contentBytes | > >> > >> isCompact := self class indexIfCompact > 0. > >> contentBytes := self class instSize * Smalltalk wordSize. "inst vars" > >> > >> self class isVariable ifTrue: > >> [ |bytesPerElement| > >> bytesPerElement := self class isBytes ifTrue: [1] ifFalse: > [4]. > >> contentBytes := contentBytes + (self basicSize * > >> bytesPerElement)]. > >> > >> headerBytes := > >> contentBytes > 255 > >> ifTrue: [12] > >> ifFalse: [isCompact ifTrue: [4] ifFalse: [8]]. > >> ^ headerBytes + instVarBytes > >> > >> Also, in a 64-bit image, I suspect you may have to make a distinction > >> between class isWords as well. > >> ie: > >> self class isBytes ifTrue: [1] ifFalse: [self class isWords ifTrue: [4] > >> ifFalse: [Smalltalk wordSize]] > >> > >> Cheers, > >> Henry > >> > >> _______________________________________________ > >> 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 >

Sept. 22, 2010

Re: [Pharo-project] Fwd: [Vm-dev] Weak finalization enh. are still not integrated into VM(s)

by StÃ©phane Ducasse

Andreas we cannot simply merge package of squeak (we would get all their changes and we have to sort). I asked igor to see if he can publish code to be integrated in pharo. > are there any plans to integrate this in Pharo? Yes but we do not have the time. Again for the weak changes somebody with a bit of time and concentration can help. So far we cannot. > As I want to do some experiments with Magma I am specially interested in Pharo-1.1 for it. > > Regards, > Andreas > >>>>> I am also uploaded a slice of system changes with new classes & rest >>>>> of stuff into inbox: >>>>> >>>>> >>>>> CollectionsTests-Igor.Stasenko.169 >>>>> Collections-Igor.Stasenko.370 >>>>> Kernel-Igor.Stasenko.478 >>>>> System-Igor.Stasenko.358 >>>>> >>>>> note, that despite of these changes, system are still using old >>>>> WeakRegistry instance, >>>>> and obviously 'WeakRegistry default' needs to be modified to be >>>>> replaced with new functionality. >>>> >>>> These inbox changes are out of date with respect to the trunk, so >>>> would need to be merged with care. >>> >>> Yeah, i did not updated the image before applying changesets. >>> >>>> But aside from that, is there >>>> any reason that your changes should *not* be moved into trunk now? >>>> If no objections, then we should include them now. >>>> >>> >>> There are a couple of doits, which should be invoked after loading changes: >>> >>> WeakArray restartFinalizationProcess >>> and of couse >>> Smalltalk recreateSpecialObjectsArray >>> >>> Btw, i found that in image i was using, >>> Smalltalk specialObjectsArray size >>> was 50 >>> while in #recreateSpecialObjectsArray method there was already 55 entries >>> (and with weak finalization it should be 56). >> >> This should already be updated in trunk: >> >> Name: System-dtl.333 >> Author: dtl >> Time: 25 May 2010, 9:00:22.752 pm >> Ancestors: System-spd.332 >> Update SmalltalkImage>>recreateSpecialObjectsArray for support of Alien and improved >> finalization (Mantis 7473). Corresponding VM support is in SqS/VMMaker-dtl.175. >> >> So after a #recreateSpecialObjectsArray the size is 56, and the last slot >> is used for WeakFinalizer if present in the image. >> >> I think that everything is ready for your WeakFinalizer updates. Unless >> there are any other issues, please just go ahead and commit them to trunk. >> >> :) >> >> Dave >> >>> >>>> I understand that the VM changes are not yet available in the >>>> official VMs, but this should be corrected the next time that new >>>> VMs are distributed. >>>> >>>> Dave >>>> >>>> >>> Thanks, David. >>> >>> >>> -- >>> 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

Sept. 22, 2010