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
"Mark" == Mark Nelson prof.mark.nelson@gmail.com 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?
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@squeakland.org 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: squeakland-bounces@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@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
_______________________________________________ Squeakland mailing list Squeakland@squeakland.org 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:
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@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
squeakland@lists.squeakfoundation.org
-
Dreyfuss Pierre-André (EDU) -
Mark Nelson -
merlyn＠stonehenge.com -
Scott Wallace