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

[Pharo-project] Fwd: [Vm-dev] Weak finalization enh. are still not integrated into VM(s)
by Andreas Wacknitz Sept. 22, 2010

Sept. 22, 2010

Hi guys, are there any plans to integrate this in Pharo? As I want to do some experiments with Magma I am specially interested in Pharo-1.1 for it. Regards, Andreas Anfang der weitergeleiteten E-Mail: > Von: "David T. Lewis" <lewis(a)mail.msen.com> > Datum: 22. September 2010 05:23:36 MESZ > An: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org>, siguctua(a)gmail.com > Betreff: Re: [Vm-dev] Weak finalization enh. are still not integrated into VM(s) > Antwort an: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > On Tue, Sep 21, 2010 at 04:22:22PM +0300, Igor Stasenko wrote: >> >> On 21 September 2010 06:20, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> >>> On Tue, Sep 21, 2010 at 03:28:35AM +0300, Igor Stasenko wrote: >>>> >>>> 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.

2 2

Re: [Pharo-project] Fwd: [Vm-dev] Weak finalization enh. are still not integrated into VM(s)
by StÃ©phane Ducasse Sept. 22, 2010

Sept. 22, 2010

thanks for your effort. Stef On Sep 22, 2010, at 3:41 PM, Igor Stasenko wrote: > 2010/9/22 Andreas Wacknitz <a.wacknitz(a)gmx.de>: >> Hi guys, >> are there any plans to integrate this in Pharo? >> As I want to do some experiments with Magma I am specially interested in >> Pharo-1.1 for it. >> Regards, >> Andreas >> > > Yes, i will put changesets into pharo issue tracker, to integrate it > with Pharo as well. > >> Anfang der weitergeleiteten E-Mail: >> >> Von: "David T. Lewis" <lewis(a)mail.msen.com> >> Datum: 22. September 2010 05:23:36 MESZ >> An: Squeak Virtual Machine Development Discussion >> <vm-dev(a)lists.squeakfoundation.org>, siguctua(a)gmail.com >> Betreff: Re: [Vm-dev] Weak finalization enh. are still not integrated into >> VM(s) >> Antwort an: Squeak Virtual Machine Development Discussion >> <vm-dev(a)lists.squeakfoundation.org> >> >> >> On Tue, Sep 21, 2010 at 04:22:22PM +0300, Igor Stasenko wrote: >> >> On 21 September 2010 06:20, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Tue, Sep 21, 2010 at 03:28:35AM +0300, Igor Stasenko wrote: >> >> 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 >> > > > > -- > 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

1 0

[Pharo-project] Pharocasts: Document with HelpSystem
by laurent laffont Sept. 22, 2010

Sept. 22, 2010

You will learn how to: - write an HelpSystem book - use PackageAPIHelpBuilder to generate the API documentation of a package - create your own builder to dynamically create a documentation from the system Starting from now, no excuses to not write documentation ;) http://pharocasts.blogspot.com/2010/09/document-with-helpsystem.html Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

3 2

Re: [Pharo-project] Fwd: [Vm-dev] Weak finalization enh. are still not integrated into VM(s)
by StÃ©phane Ducasse Sept. 22, 2010

Sept. 22, 2010

Thanks David too many emails and flood of information. Stef On Sep 22, 2010, at 2:20 PM, David T. Lewis wrote: > FYI, the change sets were posted on Mantis, so you can use that for > reference also. I'm not sure if these are the final versions, but they > should be close. > > http://bugs.squeak.org/view.php?id=7473 > > Dave > > On Wed, Sep 22, 2010 at 10:52:37AM +0200, St?phane Ducasse wrote: >> 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 >> >> >> _______________________________________________ >> 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

1 0

Re: [Pharo-project] Fwd: [Vm-dev] Weak finalization enh. are still not integrated into VM(s)
by StÃ©phane Ducasse Sept. 22, 2010

Sept. 22, 2010

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

2 1

[Pharo-project] Colstme in September
by Alexander LazareviÄ Sept. 22, 2010

Sept. 22, 2010

Hi! Just a short reminder that the next Cologne Smalltalk Meetup will be happening next Thursday at the usual time and location. For any details have a look at [1]. Cheers, Alex [1] http://colstme.selfish.org/events/2010.4-Stammtisch

1 0

Re: [Pharo-project] Webpage for research paper about Pharo?
by StÃ©phane Ducasse Sept. 22, 2010

Sept. 22, 2010

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

1 0

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?
by StÃ©phane Ducasse Sept. 22, 2010

Sept. 22, 2010

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

2 1

Re: [Pharo-project] Launching class form command line ...
by John M McIntosh Sept. 22, 2010

Sept. 22, 2010

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. > > >> >> >> In -help: >>> -encoding <enc> set the internal character encoding (default: MacRoman) >> >> Sounds strangel, should probably be updated to Latin1/ removed (depending on how it's actually used)? > > No the only supported type is UTF8. I've removed the bogus help text line. > > >> >> >> Also, nonrelated to the VM, the comment in SmalltalkImage>>#documentPath seems misleading (not to mention the method name itself), there seems to be no conversion by the vm to absolute path going on in neither OSX nor Windows, the string is passed through raw. >> This is reinforced by the --help mentioning: >>> The first <argument> _normally_ names a Squeak `script' to execute. > > > Any comment in the image might be 15 years out of date. > > > >> >> >> Cheers, >> Henry >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 1

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?
by StÃ©phane Ducasse Sept. 22, 2010

Sept. 22, 2010

then publish it on the BT ;) On Sep 22, 2010, at 10:00 AM, Adrian Lienhard 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

1 0