[Squeakland] duplicate (not sibling) - garbage collection?

Dreyfuss Pierre-André (EDU) pierre-andre.dreyfuss at edu.ge.ch
Mon Feb 18 12:53:25 PST 2008


Hi Scott,

I have got the same problem especially with projects using parts-bin like  a set of objects for simulating logicals circuits or trees of math expressions.

the instances of players remains in the project even after the trash is emptied.


When  developing projects, I save a project the try things, if I found bugs, I reload the project saved and make the corrections in it and save again before trying things.

At least this is what I try to do since most of the time I save just when things are working :-) and projects become huge...

Exploring the problem today her are some observations that may help.

Players without scripts are instances of Unscripted player  as you can check with the code :


Player subclasses select: [:t|'Unscript*' match:  t   externalName asString ]thenCollect: [:n|n allInstances  ]

siblings are instances of the same subclass of Player

For each copy a new subclass of player is created and the player is an instance of it.

Try:
Player subclasses select: [:t|'Player*' match:  t   externalName asString ]thenCollect: [:n|n allInstances  ] 

This code will let blink all players, players deleted even after having emptied the trash will reappear in the world (or in a playfield if you change 'World' by a variable pointing on a playfield.

Player subclasses select: [:t|'Player*' match:  t   externalName asString ]thenDo: [:n|n allInstances do: [:i| i revealPlayerIn:World]]

After saving the the project and reloading it, the players in the trash are no more there.
This with the squeakland image

But surprise !!!!!

With the new fresh Yoshiki's OLPC Image:  Players remain in the project, even afte empty trash !!!! And this code restore the delete objects:

Player subclasses select: [:t|'Player*' match:  t   externalName asString ]thenDo: [:n|n allInstances do: [:i| i revealPlayerIn:World]]

C:\DOCUME~1\PIERRE~1\LOCALS~1\Temp\paper21.pdf

 It restore three objects sleeping in the image too.

Squeakland image was : Sqzeakland 3.8-05 latest update #556


OLPC experimental image :  Squeakland-OLPC  latest update #0

and the same with the oldest

OLPC2.0  latest update #1420



I hope this will help solving the problem.

Regards


-------- Message d'origine--------
De: squeakland-bounces at squeakland.org de la part de Scott Wallace
Date: lun. 18/02/2008 03:57
À: Squeakland list
Objet : Re: [Squeakland] duplicate (not sibling) - garbage collection?
 
Thank you Mark!

There have been other reports recently about project-size growing  
dramatically with each re-saving, even if no substantive change has  
been made, but we've had difficulty reproducing the problem.

Armed with your insight that the presence of "duplicates" in a project  
seems to correlate with the rapidly-increasing-project-size problem,  
hopefully we may now start having some success in our attempts to  
track down and fix the problem.

Cheers,

   -- Scott


On Feb 15, 2008, at 8:48 AM, Mark Nelson wrote:

> ... As students are
> developing their scripts, their project files keep growing rapidly in
> size. We start off with a 'template' project that is about 300 kB.
> Each round of program development and debugging usually involves
> creating and destroying multiple 'duplicates' using the above method.
> Before long, the project files are many MB in size, even after all
> players have been cleared from the playfield and the trashcan has been
> emptied.  Loading and saving project files gets slower and slower.
>
> I've discovered this happens even if the duplicates are created using
> the halo icon, rather than the textual script. Each duplicate that is
> ever created seems to leave a 'ghost' that take up about 130 kB of
> storage.  In the process of debugging their scripts, students
> typically create and destroy dozens of 'duplicates', leading to
> multi-MB file sizes.  This growth in file size seems to happen only
> with 'duplicates', not with 'siblings'.
>
> Is there some way to do garbage collection to get rid of these
> 'ghosts' so we can keep the file sizes manageable?
>
> Thanks,
> --Mark
>
> _______________________________________________
> Squeakland mailing list
> Squeakland at squeakland.org
> http://squeakland.org/mailman/listinfo/squeakland


_______________________________________________
Squeakland mailing list
Squeakland at squeakland.org
http://squeakland.org/mailman/listinfo/squeakland




More information about the Squeakland mailing list