Where Pharo code actually lives

Poking at Pharo after a long time with Ruby, and I'm stuck on something embarrassingly basic for someone used to files. I made a class in the system browser and saved a few methods, and no .st file appeared anywhere on disk. Save the image, reopen it, and the methods are all still there (a little unnerving, coming from Ruby, to have nothing to show with ls).

So the code lives inside the image, and there is no source file as such? The .changes file next to the image looks related, but opening it in a text editor only made things worse, since it lists everything I did in order, mistakes included.

In Ruby this ends with git add lib/. How do Pharo people get it into git? I'm only guessing that nobody commits the image file whole.

The conversation continues 1

Follow the reasoning

tobinPermalink
Yes, it lives in the image, and that's the part worth getting used to rather than fighting (I still find it lovely, though I'll admit it makes sharing harder than it should be). Classes and compiled methods are objects in the image. Their source text sits in two files next to it, .sources for the base system and .changes for everything saved since, appended in order, with each method pointing at its own spot. That's why .changes reads like a diary.

For git, Pharo comes with Iceberg. You add a repository in it, add your package to that repository, and commit from the same window. The package gets written out as plain text, one file per class, so diffs look like ordinary source. A fresh image gets the code back by cloning in Iceberg and loading the package.

So the image is your workbench and the repository is the record. Nobody commits the .image file, you guessed right.

Where Pharo code actually lives

The conversation continues 1

Other sides of the same question

round(2.5) gives 2, and learners don't believe it

3 + 4 * 2 is 14, and that is the easy part

Translating old CoffeeScript by hand is a decent JavaScript lesson