Oh! I should have guessed there'd be more alternative suggestions and held back.
Anyway, its done now, so just pick out what you like...
Now I tend to think of the Image as more than just the .image file, so...
The heart of Pharo is the *Image*. This holds the live running state
of a Pharo system. Tools like the IDE, language parser and interactive
playground run *inside* the Image to write code and create interacting
objects which comprise your application. Saving the Image to a
".image" file creates a frozen-in-time snapshot of the running system
state. This can be moved to another system and resumed running as if
the Image had never stopped. The Pharo download provides
/Pharo.image/ file as the starting point for the live environment that
you adapt to your needs.
The Image runs on a Virtual Machine. This abstracts away operating
system and CPU architecture differences to allow the same ".image"
file (the snapshot of you live system) to open and run on any support
platform. The VM executable file is a different for each platform:
* pharo for Linux and Unix
* Pharo.exe for Windows
* Pharo for OSX
Your source-code is compiled to byte-code in Image to become part of
the live system state. This occurs as soon as a modified method is
accepted. Only the modified method is compiled, not the whole source
code, and the bytecode is immediately runnable. This facilitates a
very fast edit-compile-run-debug loop at the root of Pharo's
productivity. The VM optimally interprets or just-in-time compiles
the bytecode as appropriate for best performance.
As an implementation detail carried over from when ram was scarce, the
source-code is not stored in-Image. It is spread across two files:
* Sources for parts of Pharo (i.e. the tools) that don’t change
frequently are stored in the "*.sources" files. It is generated as a
static file per major release. Thus for Pharo 4.0 it is named
PharoV40.sources, and keeps that name when the image file name
changes. The *.sources file is not essential for running the Image,
but is important because without it, you can't examine and learn from
the implementation of Pharo's tools (e.g Collections, Graphics
libraries, IDE and compiler.)
* All source code changes are journal logged to the "*.changes" file.
This facilitates easy access to per method history for diffs or
reverting. Further, if you close or crash your image without saving,
an in-Image tool can replay your "lost" changes from this file. The
"*.changes" file is tightly coupled to the "*.image" file because it
records the source code changes for a particular Image. The basename
of these two files must always be the same (e.g. my.image &
my.changes). Each release provides a near empty file, for example
Pharo4.changes to match Pharo4.image.
Typically the VM and .sources files are distributed/stored together,
since both are static files (per machine per Pharo Release) and both
can be shared between multiple Images; and the dynamic .image and
.changes files are distributed/stored together.
The other components below are portable across operating systems, and
The image file provides a frozen in time snapshot of a running Pharo
system. This is the file where the Pharo bytecode is stored and as such its
a cross platform format. This is the heart of Pharo, containing the live
state of all objects in the system (including classes and methods, since
they are objects too). The file is named for the release (like
Pharo4.0.image).
On Wed, Jan 13, 2016 at 7:58 PM, Dimitris Chloupis
<kilon.al...@gmail.com> wrote:
So I am correct that the image does not store the source code, and that the
source code is stored in sources and changes. The only diffirence is that
the objects have a source variable that points to the right place for
finding the source code.
This is the final text if you find anything incorrect please correct me
---------------
1. The virtual machine (VM) is the only component that is different for each
operating system. The purpose of the VM is to take Pharo bytcode that is
generated each time user accepts a piece of code and convert it to machine
code in order to be executed. Pharo 4 comes with the Cog VM a very fast JIT
VM. The VM executable is named:
• Pharo.exe for Windows; • pharo for Linux ; and
• Pharo for OSX (inside a package also named Pharo.app).
The other components below are portable across operating systems, and
can be copied and run on any appropriate virtual machine.
2. The sources file contains source code for parts of Pharo that don’t
change frequently. Sources file is important because the image file format
stores only the bytecode of live objects and not their source code.
Typically a new sources file is generated once per major release of Pharo.
For Pharo 4.0, this file is named PharoV40.sources.
3. The changes file logs of all source code modifications since the .sources
file was generated. This facilitates a per method history for diffs or re-
verting.That means that even if you dont manage to save the image file on a
crash or you just forgot you can recover your changes from this file. Each
release provides a near empty file named for the release, for example
Pharo4.0.changes.
4. The image file provides a frozen in time snapshot of a running Pharo
system. This is the file where the Pharo bytecode is stored and as such its
a cross platform format. This is the heart of Pharo, containing the live
state of all objects in the system (including classes and methods, since
they are objects too). The file is named for the release (like
Pharo4.0.image).
The .image and .changes files provided by a Pharo release are the starting
point for a live environment that you adapt to your needs. Essentially the
image file containes the compiler of the language (not the VM) , the
language parser, the IDE tools, many libraries and acts a bit like a virtual
Operation System that runs on top of a Virtual Machine (VM), similarly to
ISO files.
I don't get this similarity with ISO files.
As you work in Pharo, these files are modified, so you need to make sure
that they are writable. The .image and .changes files are intimately linked
and should always be kept together, with matching base filenames. Never edit
them directly with a text editor, as .images holds your live object runtime
memory, which indexes into the .changes files for the source. It is a good
idea to keep a backup copy of the downloaded .image and .changes files so
you can always start from a fresh image and reload your code. However the
most efficient way for backing up code is to use a version control system
that will provide an easier and powerful way to back up and track your
changes.
The four main component files above can be placed in the same directory,
although it’s also possible to put the Virtual Machine and sources file in a
separate directory where everyone has read-only access to them.
If more than one image file is present in the same directory pharo will
prompt you to choose an image file you want to load.
Do whatever works best for your style of working and your operating system.
On Wed, Jan 13, 2016 at 12:13 PM Sven Van Caekenberghe <s...@stfx.eu> wrote:
On 13 Jan 2016, at 10:57, Dimitris Chloupis <kilon.al...@gmail.com>
wrote:
I was adding a short description to the UPBE about sources file , I
always thought that the sources file is the file that contains the source
code of the image because the image file itself stores only the bytecode.
However its just came to my attention that the sources file does not
contain code that is recently installed in the image.
So how exactly the sources file works and what it is ?
The main perspective is from the object point of view: methods are just
objects like everything else. In order to be executable they know their byte
codes (which might be JIT compiled on execution, but that is an
implementation detail) and they know their source code.
Today we would probably just store the source code strings in the image
(maybe compressed) as memory is pretty cheap. But way back when Smalltalk
started, that was not the case. So they decided to map the source code out
to files.
So method source code is a magic string (RemoteString) that points to some
position in a file. There are 2 files in use: the sources file and the
changes file.
The sources file is a kind of snapshot of the source code of all methods
at the point of release of a major new version. That is why there is a Vxy
in their name. The source file never changes once created or renewed (a
process called generating the sources, see PharoSourcesCondenser).
While developing and creating new versions of methods, the new source code
is appended to another file called the changes file, much like a transaction
log. This is also a safety mechanism to recover 'lost' changes.
The changes file can contain multiple versions of a method. This can be
reduced in size using a process called condensing the changes, see
PharoChangesCondenser.
On a new release, the changes file will be (almost) empty.
HTH,
Sven
