3 ms·

The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number

The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number of different formats. These external text files can be version controlled with Git or any other VCS. In turn the the text files can be imported into an image as well. I never worked with Smalltalk professionally but I imagine deployment works in a very similar way to the deployment pipelines you might be used to. Start with a base image, import code pulled from the VCS repo, start the image, run some test verifications and copy the image to its designated virtual insurance host.

codesnik 4y ago
it's not only a code, it's a also current _state_ of the system, no? some kind of root/singleton objects, their instance variables, etc. I mean, for a web application most state should be in a database, but this takes some discipline. And importing updated code to a live system sounds like a black magic. What happens while it's still in progress? Or does one have to start a new process, like we do in other frameworks? Erlang has live updates, but I imagine live update in smalltalk works very differently. So many questions!
- 0x445442 4y ago
  Yeah, the entire state can be saved off. I was just trying to limit the context of the reply to code WRT VCS. > I mean, for a web application most state should be in a database, but this takes some discipline. This state could also reside in an image and Smalltalk has solutions like GemStone and Magma (OODBMS) solutions. > And importing updated code to a live system sounds like a black magic. Yeah, I don't think for most use cases this would be done. A new image would be built and deployed with the relevant code changes applied.
- folmar 4y ago
  The short answer is: just try it, you are in for a lot of fun and puzzles. If you have Windows nearby I would recommend Dolphin Smalltalk due to a great system browser. > it's not only a code, it's a also current _state_ of the system There is no difference in Smalltalk. The code includes all the created instances with current field values. > updated code to a live system From the user point of view everything is simple, yet the simplicity is the advantage of the compiler, not the user. If you update the code the instances that you upgrade run the new code, and if you don't upgrade the old objects they run the old code.
whartung 4y ago
Typically, a ST image is a combination of the base image, and the change set applied to the image. The change set can be code loaded in from an external source, or someone hacking in the system. By default, all changes made to an image are serialized to a changes file. That way, if your image implodes, you can start with the previous image and roll forward your changes. That said, projects in general are NOT change sets. They're just collections of classes serialized out as ST source code. These source code files capture the state of the source code within the image, but not the state of the image itself. Done properly, you don't have any aspects of the source code depending on some existing state within the image, but not captured in a class. But, you don't know that for sure. All of the source code relies somewhat on the vast amount of global state within the image. If global variables make you itch, well, let me introduce to you an ST image. Pharo is a fork of Squeak, and it's distributed as an image. Now the Pharo folks have done a lot of VM work, but even in the beginning I imagine that having a chain of custody of source code that converted a stock Squeak image into a nascent Pharo image probably never existed. I bet even with their long github history it would be very difficult to generate later Pharo images from source code checked in to github. The ST image is a ball of clay that the developers add to and cut away from in an ad hoc manner. I'm sure they strive to repeatability and such, but I imagine it's not really a high priority for them when some sneaks into a core developers image (which can be from their work, or changes merged from someone else). Having been raised in a world of "make clean install", where the finished product is a deterministic result of all these pieces I can see and touch, the ST image world has always made me a bit uncomfortable. Obviously the users cope, and it's a "me" thing, but there you are.

codesnik 4y ago

it's not only a code, it's a also current _state_ of the system, no? some kind of root/singleton objects, their instance variables, etc. I mean, for a web application most state should be in a database, but this takes some discipline. And importing updated code to a live system sounds like a black magic. What happens while it's still in progress? Or does one have to start a new process, like we do in other frameworks? Erlang has live updates, but I imagine live update in smalltalk works very differently. So many questions!

0x445442 4y ago
Yeah, the entire state can be saved off. I was just trying to limit the context of the reply to code WRT VCS. > I mean, for a web application most state should be in a database, but this takes some discipline. This state could also reside in an image and Smalltalk has solutions like GemStone and Magma (OODBMS) solutions. > And importing updated code to a live system sounds like a black magic. Yeah, I don't think for most use cases this would be done. A new image would be built and deployed with the relevant code changes applied.
folmar 4y ago
The short answer is: just try it, you are in for a lot of fun and puzzles. If you have Windows nearby I would recommend Dolphin Smalltalk due to a great system browser. > it's not only a code, it's a also current _state_ of the system There is no difference in Smalltalk. The code includes all the created instances with current field values. > updated code to a live system From the user point of view everything is simple, yet the simplicity is the advantage of the compiler, not the user. If you update the code the instances that you upgrade run the new code, and if you don't upgrade the old objects they run the old code.

whartung 4y ago

Typically, a ST image is a combination of the base image, and the change set applied to the image. The change set can be code loaded in from an external source, or someone hacking in the system. By default, all changes made to an image are serialized to a changes file. That way, if your image implodes, you can start with the previous image and roll forward your changes. That said, projects in general are NOT change sets. They're just collections of classes serialized out as ST source code. These source code files capture the state of the source code within the image, but not the state of the image itself. Done properly, you don't have any aspects of the source code depending on some existing state within the image, but not captured in a class. But, you don't know that for sure. All of the source code relies somewhat on the vast amount of global state within the image. If global variables make you itch, well, let me introduce to you an ST image. Pharo is a fork of Squeak, and it's distributed as an image. Now the Pharo folks have done a lot of VM work, but even in the beginning I imagine that having a chain of custody of source code that converted a stock Squeak image into a nascent Pharo image probably never existed. I bet even with their long github history it would be very difficult to generate later Pharo images from source code checked in to github. The ST image is a ball of clay that the developers add to and cut away from in an ad hoc manner. I'm sure they strive to repeatability and such, but I imagine it's not really a high priority for them when some sneaks into a core developers image (which can be from their work, or changes merged from someone else). Having been raised in a world of "make clean install", where the finished product is a deterministic result of all these pieces I can see and touch, the ST image world has always made me a bit uncomfortable. Obviously the users cope, and it's a "me" thing, but there you are.