3 ms·

> … but at the same time a way to recover when you fat finger and delete the "Object" class from your image and murder it. Smalltalk will let you do that. You'l

by igouy 4y ago

> … but at the same time a way to recover when you fat finger and delete the "Object" class from your image and murder it. Smalltalk will let you do that. You'll regret it, but it'll let you do it. Doesn't Smalltalk let you rollback the changes file to just before you borked something up? "The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

whartung 4y ago
To recover in normal Smalltalk, you revert to a known good image, and then roll forward changes from the Changes file, ideally not executing that last bit that killed it in the first place. I would think this would be challenging a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to. For this use case, there is no "file system". Just the living image -- and it's big, ostensibly larger than RAM. So, rather, you'd want something like the write-ahead log in databases, but one that you can roll back through a primitive restart process to a known good point. This is why I mentioned CouchDB which versions all of its page writes making recovery from catastrophe possible (at a not small cost of garbage collection). And, I appreciate the difficulty. Imagine simply having a thread tracking a real time clock. Every second a page gets persisted to the disk...tic tic tic. 86000 pages a day, just "sitting idle". Or does it? Maybe pages never get persisted to disk until snapshot or swapped out. (And since you have stupid amounts of memory, swapping is rare). Anyway, just musing.
- igouy 4y ago
  > … a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to. I'm finding it difficult to understand how we would both have a "persistent image" and not have a "known good" image to revert to. Seems as though deleting Object might well prevent the image being persisted.

by igouy 4y ago

whartung 4y ago

To recover in normal Smalltalk, you revert to a known good image, and then roll forward changes from the Changes file, ideally not executing that last bit that killed it in the first place. I would think this would be challenging a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to. For this use case, there is no "file system". Just the living image -- and it's big, ostensibly larger than RAM. So, rather, you'd want something like the write-ahead log in databases, but one that you can roll back through a primitive restart process to a known good point. This is why I mentioned CouchDB which versions all of its page writes making recovery from catastrophe possible (at a not small cost of garbage collection). And, I appreciate the difficulty. Imagine simply having a thread tracking a real time clock. Every second a page gets persisted to the disk...tic tic tic. 86000 pages a day, just "sitting idle". Or does it? Maybe pages never get persisted to disk until snapshot or swapped out. (And since you have stupid amounts of memory, swapping is rare). Anyway, just musing.

igouy 4y ago
> … a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to. I'm finding it difficult to understand how we would both have a "persistent image" and not have a "known good" image to revert to. Seems as though deleting Object might well prevent the image being persisted.