[Pharo-users] Understanding the role of the sources file

Ben Coman btc at openinworld.com
Wed Jan 13 11:16:01 EST 2016


On Wed, Jan 13, 2016 at 11:41 PM, Dimitris Chloupis
<kilon.alios at gmail.com> wrote:
> great explanation Ben thanks for sharing, I agree 100% .

On Wed, Jan 13, 2016 at 11:46 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> I like Ben's version too. (It helps to be a native English speaker as well ;-)
> Please write more, Ben.

Thanks.  But damn, I need to correct my own grammar...
I've _underlined_ updates...

>> On Wed, Jan 13, 2016 at 5:31 PM Ben Coman <btc at openinworld.com> wrote:
>> 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 _modify_ code and create interacting
>> objects which comprise your application.  Saving the Image to _an_
>> ".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 _Release_ download provides _the_
>> /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 _supported_
>> platform. The VM executable file is __ 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 _system_ source
>> __, 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 _in-Image_ tools) that don’t change
>> frequently are stored in the "*.sources" _file_.   It is generated as a
>> static file per major release. Thus for  Pharo 4.0 it is named
>> PharoV40.sources, and keeps that name (_while_ the .image file name
>> _can change_).   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 _changes to_ source code __ 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 _before_ 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 _match_  (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.  _The paired_ dynamic .image and
>> .changes files _are inherently_ distributed/stored together.  _The static and dynamic pairs can be stored in separate folders._

___________________________________






>> > 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.alios at 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 <sven at stfx.eu> wrote:
>> >>
>> >>
>> >> > On 13 Jan 2016, at 10:57, Dimitris Chloupis <kilon.alios at 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
>> >>
>> >>
>> >>
>> >
>>
>
>




More information about the Pharo-users mailing list