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

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

by StÃ©phane Ducasse

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

Sept. 22, 2010

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

by Adrian Lienhard

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

Sept. 22, 2010

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

by Andreas Wacknitz

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.

Sept. 22, 2010

Re: [Pharo-project] Help vs Tutorial

by laurent laffont

On Tue, Sep 21, 2010 at 7:43 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi again! > > Help and Tutorial seem to follow similar construction patterns. I was > wondering why Help expect methods on the class side and Tutorial on the > instance side. > I wonder too :) Maybe when I have the will to do it I should discard Lesson/Tutorial classes and use HelpTopic instead...... Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > 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] [squeak-dev] Morphic

by Hannes Hirzel

Thank you Sean, for bringing up this topic, joining a bit late, here a few remarks. --Hannes On 9/17/10, DeNigris Sean <sean(a)clipperadams.com> wrote: > I was doing a lot of playing with Morphic this week at ESUG in Barcelona. > Many people seem to really not like it and complain about it, but it seems > very vague i.e. they can't point to a specific problem with it. > > I think it's amazingly powerful and universally misunderstood. Many people > are pushing for native widgets for end users, which I think is awesome, but > serves a different role. For me, there are two use cases: > 1. People (mostly Smalltalkers, including myself) interested in the UI's of > the future and exploring what's possible Yes, > 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. > enterprise) where they have to use a particular GUI. > Morphic seems ideal for group #1. I think the key questions are: > * if you were implementing Morphic today, knowing what you know after it > being used over the years, how would you do it? > * what would it take (if possible) to get there from the current > implementation? > > Two issues I've noticed: > 1. there seems to be an explosion of classes with slightly different > behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, > PluggableShoutMorph. > 2. I'm not clear whether the hooks for modifying behavior are > a. available in all the right places > b. working > c. widely understood Yes > I'm forming an informal panel to discuss this. I've reached out to > Morphic's creators and some original users. > > A quick example of my (seemingly common) experience: > For example, I'm writing an implementorsOf browser that shows the execution > path as a graph of MethodMorphs connected by LineMorphs, because the > standard paned browser does not capture the metaphor of drilling down > through implementors. So I Created a MethodMorph and added as a submorph a > PluggableShoutMorph to hold the code. At that point, I couldn't figure out > a good/easy way to react to mouse events and pop out a new MethodMorph. > > I tried (one of these felt very satisfying): > * Morph>>on:send:to:, which sounded good, but never got called > * intercepting Morph>>processEvent:using: (which I was told was not a good > idea) > * (after seeking help), locking the submorphs and overriding the dozen or so > event-related methods in the chain from my morph to TextMorphForShout (the > Morph that actually handles the text and input). > * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to > use that subclass. Which method did you like best? There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......) I assume Juan does not have this variety anymore in his CUIS image..... Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo. I have started reading the Cuis code, it is helpful for understanding Morphic and once you know your way around you do not mind so much that there are a lot of other things.

Sept. 22, 2010

Re: [Pharo-project] Morphic

by Hannes Hirzel

On 9/22/10, Chris Muller <asqueaker(a)gmail.com> wrote: >> 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. > > Here you go: > > > http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final… > > This is chapter 2 of the "New Blue Book" which describes Morphic > top-to-bottom. From design-principles to proper implementation of > your #drawOn: method. The chapter is still a good introduction. The only thing is that now every Morph has the capability to do the layout of its submorphs. So there is no need for an AlignmentMorph anymore. Class comment of AlignmentMorph in current Squeak 4.1 "Used for layout. Since all morphs now support layoutPolicy the main use of this class is no longer needed. Kept around for compability. Supports a few methods not found elsewhere that can be convenient, eg. newRow " See also some info which still holds on http://wiki.squeak.org/squeak/1820 (Morph) http://wiki.squeak.org/squeak/1285 (Morphic Architecture) > This is just one of many books that you can read on-line at: > > http://stephane.ducasse.free.fr/FreeBooks.html > > - Chris > > > > >> >> 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

Sept. 22, 2010

Re: [Pharo-project] Morphic

by Chris Muller

> 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. Here you go: http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final… This is chapter 2 of the "New Blue Book" which describes Morphic top-to-bottom. From design-principles to proper implementation of your #drawOn: method. This is just one of many books that you can read on-line at: http://stephane.ducasse.free.fr/FreeBooks.html - Chris > > 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] Launching class form command line ...

by John M McIntosh

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 ===========================================================================

Sept. 22, 2010

Re: [Pharo-project] SparseLargeTable instances and Unicode

by Eliot Miranda

2010/9/21 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Tue, Sep 21, 2010 at 7:55 PM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> On 21.09.2010 19:10, Mariano Martinez Peck wrote: >> >>> Hi folks. I wasn't aware of the class SparseLargeTable but it seems it >>> has two important instances "SparseLargeTable allInstances size -> 2" >>> >>> They are the class side variables #DecimalProperty and #GeneralCategory >>> in Unicode. >>> >>> Actually, >>> >>> (Unicode classPool at: 'GeneralCategory') size -> 917632 >>> >>> (Unicode classPool at: 'DecimalProperty') size -> 917632 >>> >>> So...collections of almost 1 million elements. >>> >>> Now a couple of questions: >>> >>> 1) Is this normal/expected? In my calculus both arrays are like 3mb of >>> memory >>> >> Look at the implementation, there's a reason they're called sparse. >> If my math is correct (crosses fingers), DecimalProperty is ~15KB, >> GeneralCategory ~70KB > > > So...there must be a problem with my code, I was doing something like > SpaceTally does: > > > spaceForUsedInstancesOf: aClass withInstanceCount: instCount > "Answer the number of bytes consumed by all instances of the given > class, including their object headers." > > | isCompact instVarBytes bytesPerElement headerBytes total | > instCount = 0 ifTrue: [^ 0]. > isCompact := aClass indexIfCompact > 0. > instVarBytes := aClass instSize * 4. > aClass isVariable > ifTrue: [ > bytesPerElement := aClass isBytes ifTrue: [1] ifFalse: [4]. > total := 0. > aClass allInstancesDo: [:inst | | contentBytes | > contentBytes := instVarBytes + (inst size * > bytesPerElement). > headerBytes := > contentBytes > 255 > ifTrue: [12] > ifFalse: [isCompact ifTrue: [4] ifFalse: [8]]. > (UnusedObjectDiscoverer current primitiveGetUsedBit: > inst) ifTrue: > [total := total + headerBytes + contentBytes]]. > ^ total] > ifFalse: [ > headerBytes := > instVarBytes > 255 > ifTrue: [12] > ifFalse: [isCompact ifTrue: [4] ifFalse: [8]]. > ^ instCount * (headerBytes + instVarBytes)]. > > > > SparseLargeTable instanceCount ->>> 2 > > SpaceTally new spaceForUsedInstancesOf: SparseLargeTable withInstanceCount: > 2 ->>> 7341112 > You must use basicSize not size. This is a sparse table. It has a virtual size. size answers that virtual size, not the actual size. If you use basicSize you'll also need to traverse su structure to correctly compute the size of the entire sparse array including its pages. HTH Eliot > > thanks > > >> >> >>> 2) If I don't use UTF and I send an encoding as parameter in the VM >>> (different from UTF), do I need this class side variables? >>> >> What Lukas said. >> >> 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 >

Sept. 21, 2010

Re: [Pharo-project] Issue 2744: Renaming the path to the image is not caught in Pharo on OS X

by Mariano Martinez Peck

2010/9/21 Guillermo Polito <guillermopolito(a)gmail.com> > But if the changes file is pointed as "./myImage.changes" instead of > "/home/mariano/pharo/myImage.changes" the problem will not exist. > > But I don't know if the vm supports relative paths... > > > Maybe you are right. I have no idea at all :( > 2010/9/21 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> 2010/9/21 Guillermo Polito <guillermopolito(a)gmail.com> >> >> >>> >>> 2010/9/21 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> Yes, I have this probelm several times....what I did is to change the >>>> >>>> logChange: so that it does nothing, save it, and then quit the image. >>>> >>>> >>>> Anyway, what could be a solution for this problem? >>>> >>> >>> Relative paths? :/ >>> >>> >> >> No, it won't wotk. >> >> Suppose my .image and .changes are now in /home/mariano/Pharo and while >> the image is running you rename the directory to /home/mariano/pharoRenamed >> >> Your smalltalk image is still pointing to your .changes in >> /home/mariano/Pharo and it was not updated. >> >> So...the only way I see is that the OS somehow should notify SqueakVM >> about that..... >> >> >> >>> >>>> thanks >>>> >>>> mariano >>>> >>>> >>>> On Tue, Aug 3, 2010 at 3:28 PM, Mircea Lungu <lungu(a)iam.unibe.ch>wrote: >>>> >>>>> Hi guys, >>>>> >>>>> If I rename any of the directories in the path of a running image I >>>>> will >>>>> break the image: I can't save it, I can't close it. I get a debugger >>>>> at any step. It seems the image is not informed of the path change >>>>> and it still tries to log the changes in the the changes file which has >>>>> already moved. >>>>> >>>>> I verified this on OS X,. >>>>> >>>>> I opened an issue for this: >>>>> http://code.google.com/p/pharo/issues/detail?id=2744 >>>>> >>>>> Mircea. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> _______________________________________________ >> 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. 21, 2010