duplicate (not sibling) - garbage collection?

Hi Scott,

Recently you gave me a useful tip for creating duplicates (not
siblings) from a textual script using "costume duplicate player". This
has been working great except for one problem.  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
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

>>>>> "Mark" == Mark Nelson <[hidden email]> writes:

Mark> Is there some way to do garbage collection to get rid of these
Mark> 'ghosts' so we can keep the file sizes manageable?

Just a wild guess, but does "Player abandonUnnecessaryUniclasses"
help?  Or anything else in the "housekeeping" class protocol?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

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:


_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

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: [hidden email] 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:


_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland


_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

Update 1924lingeringPlayers-sw (an update published to the olpc  
etoys3.0 system in mid-March) provided (finally) a fix for this problem.

A bloated project of the sort reported by Mark, Pierre-André, and  
others, can now theoretically be slimmed by simply loading it into an  
up-to-date image, then immediately saving the project afresh.  The  
resulting new version of the .pr file should be a lot smaller.

Experience reports, positive or negative, would be welcome.  If anyone  
has a huge project that does not slim down substantially after being  
loaded and re-saved, please email it to me privately.

-- Scott


On Feb 17, 2008, at 6:57 PM, Scott Wallace wrote:


_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland