Thank you I appreciate the explanation.
On Wed, Apr 1, 2020 at 2:56 PM Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:
> On Wed, Apr 1, 2020 at 11:17 AM Sven Van Caekenberghe
> wrote:
>
>> Hi Russ,
>>
>> That is great to hear.
>>
>> I wanted to add that Pharo has automatic memory
Hi Russ -
> On 1 Apr 2020, at 17:14, Russ Whaley wrote:
>
> A couple of basic questions...
> I thought tempVariables, inside a method were automatically destroyed when
> the method terminated?
> If I pass an object (either a parm or tempVariable) that resides in that
> message to another
On Wed, Apr 1, 2020 at 11:17 AM Sven Van Caekenberghe wrote:
> Hi Russ,
>
> That is great to hear.
>
> I wanted to add that Pharo has automatic memory management and there is
> normally no need for doing anything manually (like nilling out instance
> variables let alone ugly become hacks).
>
>
Hi Russ,
That is great to hear.
I wanted to add that Pharo has automatic memory management and there is
normally no need for doing anything manually (like nilling out instance
variables let alone ugly become hacks).
Your model looks pretty harmless, even with cycles there should be no
Okay! I made some additional changes to my app/presenter/model so that I'm
doing this:
MyApp>>start
| model pres |
model := MyModel loadData.
pres := MyPresenterWithModel newApplication: self with: model.
pres openWithSpec.
I changed my code in Presenter to reference the model - and it pops
Tim,
Thanks for the reply! When I eliminated (with your become: solution), it
did not a small chunk of the objects instances off. Another 'holder' of
object instances accounted for another slug. But things still were not
dropping like I hoped (this is without just setting everything to strings
On Wed, Apr 1, 2020, 01:30 Tim Mackinnon wrote:
> 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
> Am 01.04.2020 um 12:17 schrieb Richard O'Keefe :
>
> 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
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,
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
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,
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
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
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,
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
On Tue, Mar 31, 2020 at 9:25 AM Russ Whaley wrote:
> Sven,
> Thanks for the reply :)
>
> I will try to move my code over to another image (I'm not very good with
> GitHub - we'll see how this goes).
>
> But it just seems like there ought to be a way to at least delete all of
> these instances -
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
Hi Russ,
It is quite hard to debug somebody else's application, especially without
access to the code, but here are some suggestions of what I would do.
Can you move your code to a new/fresh image and see what happens there
(especially after just one iteration of loading your data) ?
Is there
My image size keeps growing and growing. I've been scouring Google and
mailing lists, trying to find a solution.
Observables:
- Running this 'query' shows I have a whole lot instances of Objects
I've created that are not "releasing". There are 65000 instances of one
Object/Class, and
19 matches
Mail list logo
