> Am 01.04.2020 um 12:17 schrieb Richard O'Keefe <rao...@gmail.com>:
>
> ProtoObject>>become: is two-way in Pharo.
> "...Swap the object pointers of the receiver and the argument.
> All variables in the entire system that used to point to the
> receiver now point to the argument, and vice-versa."
>
> In the unlikely event that I have understood correctly,
> Array>>elementsForwardIdentityTo:
> is Pharo's one-way become.
>
It is #becomeForward:
Norbert
> On Wed, 1 Apr 2020 at 22:43, jtuc...@objektfabrik.de
> <jtuc...@objektfabrik.de> wrote:
>>
>> Tim,
>>
>> okay, so I understand the reason. Thanks for clarifying/confirming?
>>
>> I don't think VAST has two-way become. IIRC, VW has. At least I can tell you
>> using nil instead of String new has worked for me on VAST versions ever
>> since 3.0 in the early nineties.
>>
>> What about Pharo? Does it do one-way or two-way become?
>>
>>
>> Joachim
>>
>>
>>
>> Am 01.04.20 um 10:29 schrieb Tim Mackinnon:
>>
>> Yeah, I was taught (and it may be out of date), that as become: is a 2 way
>> operation the identity of nil (as a singleton) would get swizzled, so it was
>> safer to create a simple new object that could be easily gc’d (that’s what I
>> vaguely recall anyway). (This was in early VA from the OTI guys, but maybe
>> that gets handled better in modern VA, as I think become: is two way in VA
>> right?)
>>
>> Tim
>>
>> On 1 Apr 2020, at 08:11, jtuc...@objektfabrik.de wrote:
>>
>> Tim,
>>
>> out of curiosity: why do you suggest to create hundreds of thousands of
>> Strings instead of become: nil?
>>
>> Does Pharo do two-way become: ?
>> I'be been nilling instances for a little over 2 decades in VAST so far and
>> never had any troubles with it...
>>
>> Other than that: the become: nil (or String new as you suggest) thing was
>> the first that came to my mind for the intermediate solution as well. Of
>> course that doesn't fix the code which doesn't dispose of the objects in the
>> UI or model...
>>
>>
>> Joachim
>>
>>
>>
>>
>> Am 01.04.20 um 08:42 schrieb Tim Mackinnon:
>>
>> Hi Russ - a quick look at your stats seems to indicate that something is
>> holding on to your model, I didn’t understand the first object growing by 2,
>> but the second increases by 1 each time, and it looks like some form of root
>> object holding on to the others ? This of course means the GC can’t reclaim
>> the chain of objects if something is holding on to that root globally.
>>
>> Assigning something in the playground will hold onto it (I believe) so you
>> can continue to reuse and inspect it - so that’s expected, but this looks
>> like something in your UI?
>>
>> You can break the chain manually (but it’s not a full solution), simply
>> iterate over your root and become: String new (Save your image before doing
>> it and see if it works to free up the cycles). Eg try something like this
>> (haven’t tried this in Pharo myself, but worked in VA, so it should work
>> here)
>>
>> MyRootModel allInstances do: [ :m | m become: String new ]
>>
>> If this works and reduces your memory usage, you now need to inspect one of
>> those MyRootModel instances and see who is referencing it, and explain why.
>> This is Sven’s pointerTo explanation.
>>
>> For roots, you sometimes can use a WeakDictionary so that when nothing is
>> referencing them, they get gc’d if you are doing some caching or have some
>> factory concept.
>>
>> It’s not uncommon to hit this when you get your system nearing completion ,
>> it’s the downside of not having to worry about memory referencing -
>> ultimately you have to worry about it at the edges.
>>
>> It is possible there is a Pharo bug, as over time I see large Pharo images
>> but I was just messing around and put it down to failed experiments.
>>
>> Hope this helps.
>>
>> Tim
>>
>> On 31 Mar 2020, at 20:47, Russ Whaley <whaley.r...@gmail.com> wrote:
>>
>>
>> Here is some additional data - attached - I checked the number of instances
>> on select Classes before a UI load, during the UI load and after the UI load
>> (and again). The class instances grow as expected, but do no release. I'm
>> doing something wrong. I'm going to try a fresh image next, however, I
>> expect the same thing to happen, just starting over at zero.
>>
>>
>>
>> On Tue, Mar 31, 2020 at 12:57 PM Russ Whaley <whaley.r...@gmail.com> wrote:
>>>
>>> Dario,
>>> Thanks for the reply!
>>>
>>> When I closed my image - after running that huge query and leaving it in an
>>> inspector... my image grew to 1.3GB, lol.
>>>
>>> When I closed the inspector, and all the class browsers, did the garbage
>>> collection, etc., it dropped back to 384MB. Still huge, and all my Class
>>> instances are still there. I'm getting ready to also drop my Playground -
>>> after I copy all the code snippets out and see if that has any impact. I'm
>>> also going to try a fresh image and see if there is the same growth pattern
>>> as here.
>>>
>>> Perhaps I'm doing something wrong with the way I'm creating and storing my
>>> object instances - which is generally Class new, fill out some attributes,
>>> then add it to a collection or Dictionary.
>>>
>>> All my Object tests create sample data (objects) - over and over as well.
>>>
>>>
>>> On Tue, Mar 31, 2020 at 12:20 PM dario.trussardi65
>>> <dario.trussard...@gmail.com> wrote:
>>>>
>>>> Ciao,
>>>>
>>>>
>>>>> My image size keeps growing and growing. I've been scouring Google and
>>>>> mailing lists, trying to find a solution.
>>>>
>>>> i have the same problem with a Pharo 7 image.
>>>>
>>>> Maybe it has nothing to do.
>>>>
>>>> But after close all the class browser windows the image save return
>>>> to a " valid " size.
>>>>
>>>> Dario
>>>
>>>
>>>
>>> --
>>> Russ Whaley
>>> whaley.r...@gmail.com
>>
>>
>>
>> --
>> Russ Whaley
>> whaley.r...@gmail.com
>> <Class instances tests.pdf>
>>
>>
>> --
>> -----------------------------------------------------------------------
>> Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
>> Fliederweg 1 http://www.objektfabrik.de
>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>>
>>
>>
>>
>> --
>> -----------------------------------------------------------------------
>> Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
>> Fliederweg 1 http://www.objektfabrik.de
>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>>
>>
>
