I was reading you code snapshot (still called that?) and I am amazed at how easily I can still read and understand Smalltalk. It is also interesting how some problems are always being resolved. Please, I mean no offense at all, your solution is fine. It just seems that upgrading images is still the same issue it was back then, different circumstances and technology but still the same issue, how to upgrade a running image without bringing down everything to do it. I’ve looked at Squeak and Seaside a number of times and I am very happy to see that there are still people enthusiasticly learning the right way to code with objects.

I am currently working with Ruby and Rails, I like Ruby a lot, Rails maybe not so much, but you have to do what customer’s want. I am always tempted to go back to Smalltalk. I don’t have similar feelings about C or Pascal or Ada or any other language. Perhaps if you ever need a testomial that’s one.

Smalltalk grows on you and some how you know it is the right way to program and you are changed forever. No matter how people try to tell you it is dead, and turn away when you just can’t stop talking about how you did this and that in 3 months or prototyped this huge app in a few weeks. I loved the Workspace and interactive coding. And so, one issue with pure OO langs, such as Smalltalk or Ruby is they change the way you go about coding. With Smalltalk you can take bigger risks, because you didn’t invest so much. So if some piece of code doesn’t feel right you still have time to refactor before things get too complicated. I’ve written very large and complex systems in my time, and found out the hard way if I abandoned the Smalltalk way. XP all the way. And MVC, I love to remind people how we used to use MVC in Smalltalk back in the 80’s especially when I was at Sun.

That’s not to say it is all perfect, but It is easy to change and customize. This is one reason I like Ruby. One reason I don’t is it is command line no IDE built-in and the IRB well good is not great. So, if I keep reading your blog and studying your code I might just be pulled in again — my wife would kill me. Keep up the great work, may the Smalltalk Way live forever.

That an image might take a few extra megs on disk due to active Seaside sessions is of little to no concern to me, I could always just schedule a cron job to create the empty load file at 2am to ensure another image save during low or no load to get back a smaller image.

Is there some need to temporarily “suspend” active sessions until the load is complete, to avoid callbacks getting executed with a partial set of packages loaded?

@Bret, because I don’t run X on my server, it’s command line only, I do all management via ssh.

Sure, it will be a small post but something good to have and to know (I think) as it’s a real practice that increases productivity (or at least increases the developer helpers that squeak is missing) and I found it’s in the spirit of your blog… :)

Cédrick

Granted, this precludes running on a Windows box (unless someone could hack together a cygwin/X version of the squeak VM, along with a cygwin version of Xvnc), but it works quite nicely. And in my case, it allows me to work on the running image remotely (it’s not a production image, so I just hack away, and revert things if I break something horribly :).

I’m not sure I follow the last part of your question, unless I’m mistaken, Seaside runs at a lower priority so it just hangs tight doing nothing until the package is finished loading.

@Cédrick, I hadn’t planned on posting on that but I guess if you’re interested maybe others are as well. I think I pretty much explained exactly what I do already, there’s not much left but a small handful of lines of code.

it seems you do not deal with package dependencies, you only load mcz in a random order. Moreover, how will the web application react when Monticello has only load part of the new mcz files?

Is 5s not too often? I’d prefer trigger the watch for changes from a minimal seaside interface. but maybe it’s not handy when you use several images. Anyway nice stuff :)

Cédrick

ps: Seeing your last answer on seaside list, I thought you would have made a blog post on image configuration at startup based on profile. I quote you “I keep three
profiles, dev, prod, test, with a file in the root that determines which
profile is used (easily toggled). Inside the directory for a profile, each
setting is stored in a separate file where the filename is the setting name
and the file contents are the value.” I’d love you post on that too :)