[Pharo-users] Need help badly

[Md Shahidul Hoque]

Dear admin team
Can u please remove my email (shawo...@gmail.com) from user list. I got a
lot of email from other discussion. I don't want to get those. please help
me.
Thanks


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Russ Whaley]

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 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
>> problems.
>>
>> All this does not mean that you cannot (by accident maybe) make mistakes
>> and keep global references to your larger model that prevents it from being
>> garbage collected.
>>
>> Typically, fixing the one culprit solves all your problems. The trick is
>> finding it ;-)
>>
>> Sven
>>
>> > On 1 Apr 2020, at 20:04, Russ Whaley  wrote:
>> >
>> > 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
>> right up!  When I close the GUI, GC and check for errant object
>> instances... NONE!!  I can open the UI over and over and my object
>> instances stay at zero.
>> >
>> > So it feels like I'm on the right track.
>> >
>> > I still need a bunch of work/learning around the App/Presenter/Model
>> interactions... so if anyone can point me to a good tutorial on this,
>> including changing data and UI widgets - I'd greatly appreciate it.
>> >
>> > Thanks to all on this issue!
>> >
>> > Russ
>> >
>> >
>> > On Wed, Apr 1, 2020 at 12:14 PM Russ Whaley 
>> wrote:
>> > 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 -
>> but doing so systematically by object to perhaps see what was holding on to
>> things).  Finally I got things down to a few objects with instances in the
>> hundreds and thousands - instead of 50,000 and 400,000 - and I finally set
>> everything to String new.  Interestingly enough, after garbage collection,
>> when I do String instanceCount - I get 0 (zero) instances.
>> >
>> > All that - and thank you again - I closed all the system browsers,
>> checked playground to delete bindings, I did a bunch of garbageCollection
>> runs, did a System>Do Image Cleanup... then did a Save As.
>> >
>> > And... it is 8MB bigger than before I did all this cleanup.  My image
>> was 346MB and grew to 354MB AFTER the cleanup.  Go figure.  Maybe it will
>> automagically GC sometime.
>> >
>> > I'm looking into what you and Sven mentioned - the pointersTo - I'm
>> trying to figure out how to use it.
>> >
>> > 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 message, since I'm passing the actual
>> object - I curious how it ever gets GC'd.
>>
>
> Russ,
>
> I didn't see anyone really answer these two points. It is important to
> understand that a variable, whether temporary or instance, is a holder of a
> reference to an object. It's not the object, per se. So, yes, when that
> method exits, the temporary variable on the stack frame is dropped,
> effectively eliminating the reference its temporary variable held. That
> formerly referenced object will be garbage collected when the automatic
> garbage collection finds it has no reachable references to it at all.
>
> "reachable" is the key to GC. If traversing the VM's object graph, the
> garbage collector cannot reach an object, then it is garbage, even if it
> has a million references (from other also unreachable objects). Things are
> slightly complicated by the notion of a weak reference. The garbage
> collector doesn't follow a weak reference, so if an object is only
> reachable via weak references, it is considered unreachable and can be
> collected.
>
>
> >   • All my ObjectTest classes create their own data to work with - I
>> have the creation in centralized messages, but they return 'fresh' data for
>> each test.  Whatever the answer is in the first 2 bullet points, this could
>> be a contributor to the volume.
>> > I'm running some tests of the GUI after clearing out all the Object
>> instances... and I'm seeing the growth as expected... it just doesn't go
>> away when I close the GUI window.  I'm not using SpApp correctly, nor am I
>> using SpPresenter correctly (I'm forcing my model data into an SpPresenter
>> instVar (via the SpApp start) so the presenter can use my data.  This is
>> all wrong but I'm 

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Tim Mackinnon]

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 message, since I'm passing the actual object - I curious 
> how it ever gets GC'd.
> All my ObjectTest classes create their own data to work with - I have the 
> creation in centralized messages, but they return 'fresh' data for each test. 
>  Whatever the answer is in the first 2 bullet points, this could be a 
> contributor to the volume.


For the first 1, its not so much the  “temp” ness of variables, but more about 
how the object they point to gets referenced. Normally in a method, you assign 
an object to a variable, you use it, nothing else references it, and it just 
gets GC’d.

However if you call a setter: of another object, and pass in your temp variable 
as an argument, that other object now has a reference to it. Now if that other 
object is referenced in a class variable (or some other global), the gc will 
consider it referenced and won’t eliminate it. Basically every object reference 
gets traversed to see if its pinned in some way. Those objects that are not 
pinned (i.e. held onto anymore) get collected. There are numerous algorithms to 
do this efficiently, and you can read up on them (the basic one is mark and 
sweep).

I recall that a global variable is anything that can be traced back to the 
Smalltalk system dictionary (which is the root of the world). There might be 
some other known roots (this is my vague memory on this.

The above should answer your question #2 (if not, I’m sure we can find the 
relevant docs on this, its quite well explained somewhere).

For #3, it shouldn’t be the volume of data created - its what is holding on to 
this data - do you cache it somehow (and end up referencing it in a global 
variable so it can’t be gc’d) - OR - if its just UI related (this might be a 
good test, if you create your model without a UI, and print something on the 
transcript, does memory still grow?). If its UI related - this could be some 
Spec handler that reaches back into the global system dictionary to process 
events (or something like this), and this is what is pinning your model. Or is 
there some phantom window that is tied to OS resources which stop it from 
properly terminating (but might not be visible). This is the kind of thing you 
need to look for.

Spec2 is quite new, so it could be something there that is causing this. If you 
suspect its UI related, maybe you can create a really simple example with a 
simpler model subset that can recreate it.

Hope this helps guide you on next steps.

Tim

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Richard Sargent]

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).
>
> Your model looks pretty harmless, even with cycles there should be no
> problems.
>
> All this does not mean that you cannot (by accident maybe) make mistakes
> and keep global references to your larger model that prevents it from being
> garbage collected.
>
> Typically, fixing the one culprit solves all your problems. The trick is
> finding it ;-)
>
> Sven
>
> > On 1 Apr 2020, at 20:04, Russ Whaley  wrote:
> >
> > 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
> right up!  When I close the GUI, GC and check for errant object
> instances... NONE!!  I can open the UI over and over and my object
> instances stay at zero.
> >
> > So it feels like I'm on the right track.
> >
> > I still need a bunch of work/learning around the App/Presenter/Model
> interactions... so if anyone can point me to a good tutorial on this,
> including changing data and UI widgets - I'd greatly appreciate it.
> >
> > Thanks to all on this issue!
> >
> > Russ
> >
> >
> > On Wed, Apr 1, 2020 at 12:14 PM Russ Whaley 
> wrote:
> > 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 -
> but doing so systematically by object to perhaps see what was holding on to
> things).  Finally I got things down to a few objects with instances in the
> hundreds and thousands - instead of 50,000 and 400,000 - and I finally set
> everything to String new.  Interestingly enough, after garbage collection,
> when I do String instanceCount - I get 0 (zero) instances.
> >
> > All that - and thank you again - I closed all the system browsers,
> checked playground to delete bindings, I did a bunch of garbageCollection
> runs, did a System>Do Image Cleanup... then did a Save As.
> >
> > And... it is 8MB bigger than before I did all this cleanup.  My image
> was 346MB and grew to 354MB AFTER the cleanup.  Go figure.  Maybe it will
> automagically GC sometime.
> >
> > I'm looking into what you and Sven mentioned - the pointersTo - I'm
> trying to figure out how to use it.
> >
> > 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 message, since I'm passing the actual object - I
> curious how it ever gets GC'd.
>

Russ,

I didn't see anyone really answer these two points. It is important to
understand that a variable, whether temporary or instance, is a holder of a
reference to an object. It's not the object, per se. So, yes, when that
method exits, the temporary variable on the stack frame is dropped,
effectively eliminating the reference its temporary variable held. That
formerly referenced object will be garbage collected when the automatic
garbage collection finds it has no reachable references to it at all.

"reachable" is the key to GC. If traversing the VM's object graph, the
garbage collector cannot reach an object, then it is garbage, even if it
has a million references (from other also unreachable objects). Things are
slightly complicated by the notion of a weak reference. The garbage
collector doesn't follow a weak reference, so if an object is only
reachable via weak references, it is considered unreachable and can be
collected.


>   • All my ObjectTest classes create their own data to work with - I
> have the creation in centralized messages, but they return 'fresh' data for
> each test.  Whatever the answer is in the first 2 bullet points, this could
> be a contributor to the volume.
> > I'm running some tests of the GUI after clearing out all the Object
> instances... and I'm seeing the growth as expected... it just doesn't go
> away when I close the GUI window.  I'm not using SpApp correctly, nor am I
> using SpPresenter correctly (I'm forcing my model data into an SpPresenter
> instVar (via the SpApp start) so the presenter can use my data.  This is
> all wrong but I'm struggling finding good examples in Spec2 of how to get
> these to work together.
> >
> > Thanks for the info - your suggestions have been very helpful!
> > Russ
> >
> > On Wed, Apr 1, 2020 at 2:43 AM Tim Mackinnon  wrote:
> > Hi Russ - a quick look at your stats 

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Sven Van Caekenberghe]

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 problems.

All this does not mean that you cannot (by accident maybe) make mistakes and 
keep global references to your larger model that prevents it from being garbage 
collected.

Typically, fixing the one culprit solves all your problems. The trick is 
finding it ;-)

Sven 

> On 1 Apr 2020, at 20:04, Russ Whaley  wrote:
> 
> 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 right up! 
>  When I close the GUI, GC and check for errant object instances... NONE!!  I 
> can open the UI over and over and my object instances stay at zero.  
> 
> So it feels like I'm on the right track.  
> 
> I still need a bunch of work/learning around the App/Presenter/Model 
> interactions... so if anyone can point me to a good tutorial on this, 
> including changing data and UI widgets - I'd greatly appreciate it.
> 
> Thanks to all on this issue!
> 
> Russ
> 
> 
> On Wed, Apr 1, 2020 at 12:14 PM Russ Whaley  wrote:
> 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 - but doing 
> so systematically by object to perhaps see what was holding on to things).  
> Finally I got things down to a few objects with instances in the hundreds and 
> thousands - instead of 50,000 and 400,000 - and I finally set everything to 
> String new.  Interestingly enough, after garbage collection, when I do String 
> instanceCount - I get 0 (zero) instances.
> 
> All that - and thank you again - I closed all the system browsers, checked 
> playground to delete bindings, I did a bunch of garbageCollection runs, did a 
> System>Do Image Cleanup... then did a Save As.
> 
> And... it is 8MB bigger than before I did all this cleanup.  My image was 
> 346MB and grew to 354MB AFTER the cleanup.  Go figure.  Maybe it will 
> automagically GC sometime.
> 
> I'm looking into what you and Sven mentioned - the pointersTo - I'm trying to 
> figure out how to use it.
> 
> 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 message, since I'm passing the actual object - I 
> curious how it ever gets GC'd.
>   • All my ObjectTest classes create their own data to work with - I have 
> the creation in centralized messages, but they return 'fresh' data for each 
> test.  Whatever the answer is in the first 2 bullet points, this could be a 
> contributor to the volume.
> I'm running some tests of the GUI after clearing out all the Object 
> instances... and I'm seeing the growth as expected... it just doesn't go away 
> when I close the GUI window.  I'm not using SpApp correctly, nor am I using 
> SpPresenter correctly (I'm forcing my model data into an SpPresenter instVar 
> (via the SpApp start) so the presenter can use my data.  This is all wrong 
> but I'm struggling finding good examples in Spec2 of how to get these to work 
> together.
> 
> Thanks for the info - your suggestions have been very helpful!
> Russ
> 
> On Wed, Apr 1, 2020 at 2:43 AM Tim Mackinnon  wrote:
> 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. 
> 

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Russ Whaley]

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 right
up!  When I close the GUI, GC and check for errant object instances...
NONE!!  I can open the UI over and over and my object instances stay at
zero.

So it feels like I'm on the right track.

I still need a bunch of work/learning around the App/Presenter/Model
interactions... so if anyone can point me to a good tutorial on this,
including changing data and UI widgets - I'd greatly appreciate it.

Thanks to all on this issue!

Russ



On Wed, Apr 1, 2020 at 12:14 PM Russ Whaley  wrote:

> 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 -
> but doing so systematically by object to perhaps see what was holding on to
> things).  Finally I got things down to a few objects with instances in the
> hundreds and thousands - instead of 50,000 and 400,000 - and I finally set
> everything to String new.  Interestingly enough, after garbage collection,
> when I do String instanceCount - I get 0 (zero) instances.
>
> All that - and thank you again - I closed all the system browsers, checked
> playground to delete bindings, I did a bunch of garbageCollection runs, did
> a System>Do Image Cleanup... then did a Save As.
>
> And... it is 8MB bigger than before I did all this cleanup.  My image was
> 346MB and grew to 354MB AFTER the cleanup.  Go figure.  Maybe it will
> automagically GC sometime.
>
> I'm looking into what you and Sven mentioned - the pointersTo - I'm trying
> to figure out how to use it.
>
> 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 message, since I'm passing the actual object - I
>curious how it ever gets GC'd.
>- All my ObjectTest classes create their own data to work with - I
>have the creation in centralized messages, but they return 'fresh' data for
>each test.  Whatever the answer is in the first 2 bullet points, this could
>be a contributor to the volume.
>
> I'm running some tests of the GUI after clearing out all the Object
> instances... and I'm seeing the growth as expected... it just doesn't go
> away when I close the GUI window.  I'm not using SpApp correctly, nor am I
> using SpPresenter correctly (I'm forcing my model data into an SpPresenter
> instVar (via the SpApp start) so the presenter can use my data.  This is
> all wrong but I'm struggling finding good examples in Spec2 of how to get
> these to work together.
>
> Thanks for the info - your suggestions have been very helpful!
> Russ
>
> On Wed, Apr 1, 2020 at 2:43 AM Tim Mackinnon  wrote:
>
>> 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  wrote:
>>
>> 
>> Here 

Re: [Pharo-users] Unicode migration from SmalltalkHub to Github

[Kasper Osterbye]

Awesome. If you have a little spare energy, make an issue or pull request
on https://github.com/pharo-open-documentation/awesome-pharo - this stuff
should be there!

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Russ Whaley]

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 -
but doing so systematically by object to perhaps see what was holding on to
things).  Finally I got things down to a few objects with instances in the
hundreds and thousands - instead of 50,000 and 400,000 - and I finally set
everything to String new.  Interestingly enough, after garbage collection,
when I do String instanceCount - I get 0 (zero) instances.

All that - and thank you again - I closed all the system browsers, checked
playground to delete bindings, I did a bunch of garbageCollection runs, did
a System>Do Image Cleanup... then did a Save As.

And... it is 8MB bigger than before I did all this cleanup.  My image was
346MB and grew to 354MB AFTER the cleanup.  Go figure.  Maybe it will
automagically GC sometime.

I'm looking into what you and Sven mentioned - the pointersTo - I'm trying
to figure out how to use it.

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 message, since I'm passing the actual object - I
   curious how it ever gets GC'd.
   - All my ObjectTest classes create their own data to work with - I have
   the creation in centralized messages, but they return 'fresh' data for each
   test.  Whatever the answer is in the first 2 bullet points, this could be a
   contributor to the volume.

I'm running some tests of the GUI after clearing out all the Object
instances... and I'm seeing the growth as expected... it just doesn't go
away when I close the GUI window.  I'm not using SpApp correctly, nor am I
using SpPresenter correctly (I'm forcing my model data into an SpPresenter
instVar (via the SpApp start) so the presenter can use my data.  This is
all wrong but I'm struggling finding good examples in Spec2 of how to get
these to work together.

Thanks for the info - your suggestions have been very helpful!
Russ

On Wed, Apr 1, 2020 at 2:43 AM Tim Mackinnon  wrote:

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

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Richard Sargent]

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 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?)
>

VA become: is one way. You can use multiBecome: to have a two way become:.
I don't have the details to hand.


> 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 
>  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 
> 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
> 
>
>
> --
> ---
> Objektfabrik Joachim Tuchel  

[Pharo-users] [ANN] 50th Anniversary of Smalltalk

[Richard Kenneth Eng]

https://smalltalk.tech.blog/2020/04/01/50th-anniversary-of-smalltalk/

The final wish of a dying man.

Re: [Pharo-users] Unicode migration from SmalltalkHub to Github

[Alistair Grant]

Thanks, Sven and Guille.

The Unicode library is now available at:
https://github.com/pharo-contributions/pharo-unicode

Metacello new
repository: 'github://pharo-contributions/pharo-unicode/src';
baseline: 'Unicode';
load.


Cheers,
Alistair

On Wed, 1 Apr 2020 at 12:14, Sven Van Caekenberghe  wrote:
>
> Please do, great initiative.
>
> > On 1 Apr 2020, at 11:57, Alistair Grant  wrote:
> >
> > Hi Sven and All,
> >
> > We have a need to migrate the Unicode library
> > (http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release
> > tagging process).
> >
> > I've imported the code, with full history, in to:
> > https://github.com/feenkcom/pharo-unicode
> >
> > If there's no suggestions / objections, I'll request that it be added
> > to https://github.com/pharo-contributions.
> >
> > Thanks,
> > Alistair
> >
>
>

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[Norbert Hartl]

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

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[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 the unlikely event that I have understood correctly,
Array>>elementsForwardIdentityTo:
is Pharo's one-way become.

On Wed, 1 Apr 2020 at 22:43, 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  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  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 

Re: [Pharo-users] Unicode migration from SmalltalkHub to Github

[Guillermo Polito]

Thanks Alistair!!

> El 1 abr 2020, a las 11:57, Alistair Grant  escribió:
> 
> Hi Sven and All,
> 
> We have a need to migrate the Unicode library
> (http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release
> tagging process).
> 
> I've imported the code, with full history, in to:
> https://github.com/feenkcom/pharo-unicode
> 
> If there's no suggestions / objections, I'll request that it be added
> to https://github.com/pharo-contributions.
> 
> Thanks,
> Alistair
> 

Re: [Pharo-users] Unicode migration from SmalltalkHub to Github

[Sven Van Caekenberghe]

Please do, great initiative.

> On 1 Apr 2020, at 11:57, Alistair Grant  wrote:
> 
> Hi Sven and All,
> 
> We have a need to migrate the Unicode library
> (http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release
> tagging process).
> 
> I've imported the code, with full history, in to:
> https://github.com/feenkcom/pharo-unicode
> 
> If there's no suggestions / objections, I'll request that it be added
> to https://github.com/pharo-contributions.
> 
> Thanks,
> Alistair
> 

[Pharo-users] Unicode migration from SmalltalkHub to Github

[Alistair Grant]

Hi Sven and All,

We have a need to migrate the Unicode library
(http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release
tagging process).

I've imported the code, with full history, in to:
https://github.com/feenkcom/pharo-unicode

If there's no suggestions / objections, I'll request that it be added
to https://github.com/pharo-contributions.

Thanks,
Alistair

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[jtuc...@objektfabrik.de]

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  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 > 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
mailto: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

Re: [Pharo-users] Pharo on a chromebook?

[kmo]

Google have an official linux environment that you can switch on in ChromeOs
Settings. Should allow you to switch easily betweeen ChromeOs and Linux.
 



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[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  
>>>  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 >> > 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 
>>> mailto: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 
>>> 
> 
> -- 
> 

Re: [Pharo-users] Pharo on a chromebook?

[Guillermo Polito]

Yes, I’ve heard some other people doing similar stuff.
I put in cc Olivier, maybe he can share a bit more if he has time :)

Guille

> El 1 abr 2020, a las 1:40, tbrunz  escribió:
> 
> Hi Paul,
> 
> It *is* possible!  I've got it running on one of my Chromebooks, a Pixelbook
> model.  (I gave my 2015 Pixel LS to my wife; I've yet to try it on that
> one.)  See the attached image.
> 
> You'll likely need to install a Linux container, which is how I got it to
> work.  (I didn't try to get it running in the native Linux OS, which I
> believe is a modified Gentoo.)
> 
> You can have an icon associated with it; if you do, you can pin it to your
> icon tray and launch Pharo that way -- which is what I do.  (You should be
> able to see the icon in my image.)  I have a script that generates a
> '.desktop' file with an icon, which is how I think I got this to work.  (I'm
> about to rewrite the script; the first attempt was a hack extracted from a
> script suite I wrote, and Pharo deserves better.)
> 
> One thing you'll want to do is correct for the 4K display.  I have a script
> that automates enlarging the pointer arrow at
> https://github.com/tbrunz/pharo-support (which also has the above-mentioned
> script), but I just finished it and haven't yet tested it on a Chromebook
> install.
> 
> -Ted
> 
>  
> 
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] UFFI code problem

[Guillermo Polito]

> El 1 abr 2020, a las 9:31, Esteban Lorenzano  escribió:
> 
> There has been a change in how the constant values needs to be declared 
> (because in a 64bit environment, you cannot “guess” the type by its value: 42 
> can be (int32)42 or (int64)42. 
> Hence, you need to be explicit on the time. 

Parentheses are not needed anymore (yet they are still supported I guess) :)

You can now do

int -42

Since there is no ambiguity possible, and this is consistent with

int x

;)

> 
> That’s why @tbrunz suggestion is accurate. 
> 
> Now, I remember writing that example years ago, but I do not remember where :P
> Can you point me to the source, so I can correct it ? (it should have been 
> done before, but better later than never ;) 

I wonder if for Pharo9 we should put the UFFI parser in strict mode.
Strict mode should
 - not let people use constants without type declarations (because not doing so 
is a source of bugs)
 - not let people use String declarations without declaring encodings (because 
not doing so is a source of bugs)

Of course, strictness is just a flag that people could turn off, at their own 
risk...

> Esteban
> 
>> On 1 Apr 2020, at 06:57, tbrunz  wrote:
>> 
>> Try using this expression:
>> 
>> ^ self ffiCall: #( int abs ( int TheAnswer ) ) module: LibC
>> 
>> i.e., add 'int' to tell Pharo that 'TheAnswer' is to be interpreted as a C
>> integer.
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
> 
> 

Re: [Pharo-users] UFFI code problem

[Esteban Lorenzano]

There has been a change in how the constant values needs to be declared 
(because in a 64bit environment, you cannot “guess” the type by its value: 42 
can be (int32)42 or (int64)42. 
Hence, you need to be explicit on the time. 

That’s why @tbrunz suggestion is accurate. 

Now, I remember writing that example years ago, but I do not remember where :P
Can you point me to the source, so I can correct it ? (it should have been done 
before, but better later than never ;) 

Esteban

> On 1 Apr 2020, at 06:57, tbrunz  wrote:
> 
> Try using this expression:
> 
> ^ self ffiCall: #( int abs ( int TheAnswer ) ) module: LibC
> 
> i.e., add 'int' to tell Pharo that 'TheAnswer' is to be interpreted as a C
> integer.
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] Ballooning image size! Approaching 400MB

[jtuc...@objektfabrik.de]

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  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 > 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
mailto: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 




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

Re: [Pharo-users] Ballooning image size! Approaching 400MB

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