Skip to main content

Seaside Community Service (Picking Up Garbage)

(OK, this post is more for my reference than to teach anything, but hopefully at least I'll learn something!)

Pharo, Squeak, and most Smalltalks have the ability to save everything you are working on when you exit the environment. This saves all of the objects you have created, any text you've written, and if your program is running, it will still be running when you restart the environment, exactly where you left off.

In Smalltalk, we call it saving the image.

Images are cool, but you really shouldn't depend on them for source code control. You should back up your program code using a separate source code control system. Examples include CVS, Subversion, and Git. Some Smalltalks can use those tools and there are certainly bridges for others, but most Smalltalkers use a version control tool written especially for Smalltalk.

In Pharo, I use Monticello. Monticello integrates nicely with the existing tools. In fact, most of the time, I don't even think that I'm using Monticello at all. I just code and when it comes time to save my code, I switch to the Monticello Browser window, click Save and type in a comment. I then save my image.

Still, it takes a bit of time to load a new image from scratch. I try to do it once a month. I know a good agile process would let me do it every day or at any moment, but I'm not there yet with my Pharo work.

Even though I'm only running a personal web server and my load is light, I'm pumping a fair bit of data from a back-end data store. I cache a lot in memory to keep my query time light. Over a few weeks of running, my image will start to grow. Today I noticed I was over 100MB! That seemed like a bit much. I'm in the 30-40MB when I load from source on top of a full set of development and web serving tools.

I went searching for a quick cleanup script and I turned up a message from Bill Schwab where he had found a Seaside FAQ with some workspace code:

WARegistry clearAllHandlers.
Smalltalk garbageCollect.

That knocked 30MB off my image.

Adrian Lienhard noted that to go further, he might want to look at SpaceTally.

SpaceTally new systemWideSpaceTally inspect.

I was about to spend some time inspecting the tally, but I noticed as soon as I ran that, another 50MB flew off. I was back under 60MB, which is my pain point.

Comments

Popular posts from this blog

Pride and Shame: A simple code review format for developing developers

Gave this talk at BarCamp Omaha this September. Thanks to TechOmaha for recording!

Iowa Code Camp 5 on May 1, 2010

The site is still showing ICC4 info, but the countdown clock has been updated to a new date! Looks like I need to free up a spring day for some hacking! While browsing the site, found a picture of me presenting Seaside at ICC4. The book in the picture is Learning Programming with Robots. I think I was answering a question about Alice.

Refactoring – Ruby Ed.

The original Refactoring book by Martin Fowler had a big impact on how I thought about writing software. I’d used the refactoring tools in Smalltalk, but the book changed the way I thought about refactoring and gave names to many new refactorings. This Ruby edition of the book is highly anticipated. I received my copy at a drawing in our local Ruby user’s group. Part of the deal was you had to write a review (you are reading it) in exchange for the book. Nearly everyone at the meeting wanted a crack at the book. The authors suggest that if you have the original work, you probably shouldn’t purchase this new edition. I don’t agree. There is plenty of new content with around 20 new refactorings and a few new code smells to make the difference worthwhile. There is a tremendous amount of thoughtful Ruby code snippets inserted throughout the text. In fact, this is one of those books that is great for everyone on a team to have a copy. It is the kind of book that can be used to raise t