On Wed, Jan 13, 2016 at 11:41 PM, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > great explanation Ben thanks for sharing, I agree 100% .
On Wed, Jan 13, 2016 at 11:46 PM, Sven Van Caekenberghe <s...@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 <b...@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.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 >> >> >> >> >> >> >> > >> > >
