Squeak the development environment does not protect a developer from doing something dangerous. It probably won't ever, but maybe a file based Smalltalk like GNU does.
Smalltalk become: nil
is but one of a many ways to destroy your image (not saying that's what you did, just something dangerous to do).
By your definition of stable, Squeak would protect you from trashing your image. That's not how images work. I've also used VisualWorks and IBM VisualAge and they were both super-stable for deployment but similarly easy to crash (well, not nearly as easy to crash as Squeak, but still...).
Squeak applications can be very stable. I've had swikis run for months and months in the 2.x and early 3.x days on WinNT (this was many moons ago). Frankly, NT was more likely to tank than Squeak. Those images weren't safe from me if I was doing something dangerous, but the users couldn't do much harm just using the wiki.
I don't run anything on Squeak right now that has a long uptime (since even my web apps are suspended when I close my laptop), but I suspend and resume all the time on my deployed images (not development images) and they just keep on running. These are in Seaside.
The good news is your code isn't lost. You can roll it back from a clean image from the .changes file. This is handy, but it is even better to use something like Monticello.
Images are great for jump starting (loading a distro with useful tools) and great for returning right where you left off, but they aren't a substitute for version control. Images are really hard to repair once they've gone bad. I certainly don't know how and I've been doing Smalltalk since 95.
On Fri, Jan 9, 2009 at 6:39 PM, Cameron Sanders < csanders.personal@functional-analyst.com> wrote:
I thought the Pharo base image (3.10 with a few fonts & Balloon3d added) running on Windows was looking pretty stable (compared to other images). But after an hour of editing code on a Vista machine --an hour since the last save—Squeak has abandoned me. It is unresponsive. Trying both control and alt in combination with '.', 'l' (lower case L), 'c', does nothing apparently useful.
The process stack reported by Vista shows it to be incurring page-faults like mad. [OK, that has subsided while I typed this email.] My machine has 4 GB of RAM, I am running two instances of internet-explorer, and I have turned off the Windows search-indexing service. I know Vista has a guess-the-next-program pre-loader that could be a little overzealous in displacing programs from RAM… but still… it seems like this 101MB program shouldn't generate any page faults when the other two leading memory pigs are using less than double that much virtual memory. Vista's Resource Monitor claims I am using only 43% of physical memory. The page-fault count for Squeak.exe doubled while I typed this message.
When I click the Squeak icon on the window frame of the running copy (upper left on Windows), I do see the menu for VM Preferences. It shows me the menu and allows me to invoke actions. It will allow me to toggle the "Show output console" on and off. The output console shows me changes to memory (as I have that option checked). I can use my mouse wheel to scroll this console. Control-'.' and Control-c (and lower case L) in this console do not change anything.
After mucking around in the console area, I am now getting "WARNING: event buffer overflow" just moving my mouse around in squeak. After turning the console off, the pointer is now invisible except when you click. It appears that the overall squeak window is repainting itself properly.
-- Help me debug it
I have an interest in building a commercial application in Squeak. The FAQs says squeak is stable. Given the active community of developers (including The Great Ones), I imagine that it is stable, and that I am just doing something dumb… repeatedly. However, for Squeak to be adopted more broadly, it can't go zombie on users, even when the user does something dumb. That's an absolute.
What is the longest uptime a squeak image has ever endured (while doing something useful)? Which version was that and on what platform?
So I am willing to work to help make squeak more robust, but as a complete newbie with it, I need much guidance. So right now, with this hung-up image, what should I do? Should I attach to it with gdb? And if so, then what? [If the internal process control is working, I won't be able to make heads or tales out of it from gdb, right?] Or can I launch another squeak and send it a signal in some way [is it listening?]? What is most useful in this case?
[Is there a way in Windows/Vista to signal an app so as to force a core dump?]
Thanks in advance,
Cam
PS: I want to emphasize that I do not care about the code lost in this particular instance (it was tutorial code), instead I am looking for a stable free development environment… and I'm willing to help make one.
__________ Information from ESET Smart Security, version of virus signature database 3755 (20090109) __________
The message was checked by ESET Smart Security.
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners