[Pkg] The Trunk: Help-Squeak-Project-cmm.53.mcz
commits at source.squeak.org
commits at source.squeak.org
Tue Jun 5 19:42:39 UTC 2018
Chris Muller uploaded a new version of Help-Squeak-Project to project The Trunk:
==================== Summary ====================
Time: 5 June 2018, 2:42:27.90827 pm
Update SqueakV46.sources to SqueakV50.sources.
=============== Diff against Help-Squeak-Project-tpr.52 ===============
Item was changed:
----- Method: SqueakProjectHelp class>>workingWithSqueak (in category 'pages') -----
"This method was automatically generated. Edit it using:"
"SqueakProjectHelp edit: #workingWithSqueak"
title: 'Working with Squeak'
'Working with Squeak
Take few minutes and get familiar with the image concept of the Squeak/Smalltalk system. This includes starting and quitting the image, learning where all the objects live, and understanding where your source code resides.
1. Starting and Quitting
Like most Smalltalks, the machine-executable portion is a relatively small program known as the "virtual machine" (VM). The VM''s job is to provide services from the physical machine to real Smalltalk objects. Services like input and output. The Smalltalk system, including all data and code, is a system of objects, built from the ground up, and interpreted by this virtual computer. This affords Smalltalk system platform portability.
Smalltalk cannot run without the VM. The VM can''t do anything useful except process Smalltalk systems.
To start the system, drag the ".image" data file to the VM executable "squeak". There are myriad command-line options for starting the system via the command-line (see squeak --help). By default, the system will open on the screen in a single OS window.
To quit a Squeak session, choose ''quit'' from the menu bar. If you save, the image file will be overwritten and resume from that place the next time it''s launched.
2. The Image File
Squeak is an environment built in its own objects from the ground up, including one or more end-user applications. All of the objects in the system -- Classes, Dictionaries, Windows, Customers and other objects that make up the Squeak environment are stored in a binary ".image" file. This is the "object-data file" loaded by the VM when Squeak is launched.
When an image is started, every object resumes exactly from where it was last saved.
3. The Sources File
Smalltalk is traditionally includes the source code in the running system. However, keeping multiple copies of the same source code in all images files is wasteful. Therefore, the source code itself is kept in a read-only .sources file and accessed by all images. The image files merely have pointers into this file, which is read on-the-fly to present original source code.
+ The code of the base system is stored in the file "SqueakV50.sources". This file does not change except between releases of Squeak. Normally this file should be placed in the folder containing the VM executable.
- The code of the base system is stored in the file "SqueakV46.sources". This file does not change except between releases of Squeak. Normally this file should be placed in the folder containing the VM executable.
4. The Changes File
The purpose of Squeak is to develop new programs and systems. Code changes to the running system are effective immediately. But since multiple images can be running, they cannot all update the .sources file safely. Therefore, each image file is accompanied by a ".changes" file which contains source code changes for that and only that Smalltalk system..
The changes file is important for project work. It keeps a sequential log of development activity for the purpose of recovering work performed since the last image-save. Any of several events could lead to the need to recover work, including a power-outage or making an erroneous change to code required to keep the system running.
The changes file does not consume memory space, so Squeak is able to keep a complete history of all program changes. This makes it easy to examine or even reinstate older versions of methods (see ''versions'' option in browser selector pane). This encourages experimentation, since you can easily revert to the original versions of any set of methods.
In extreme cases where sources and/or changes files are not available, the system can still run, and will automatically decompile the bytecode methods in image memory, if necessary, into readable and editable versions of the original source code (only comments and temporary variable names are lost).
5. Transferring Code-Snippets Between Images
In addition to the ''save'' command that saves the entire state of the system, the code of individual methods, categories or classes may be ''filed out'' and then filed-in to another image.
The code of an entire project is encapsulated by a Package. This allows users to share their code with other users. Code of packages are delineated by the categories of their classes, and methods. The Monticello browser is then used to wrap that code into a Package object which can be saved to a Monticello repository at http://ss3.gemtalksystems.com/ss.
Some projects end up using the resources provided by several packages, resulting in a hierarchy of packages that make up a system. Installer can be used to install such systems.!!
]style[(19 225 26 969 17 449 19 596 19 1351 44 189 12 539)b,,i,,i,,i,,i,,i,,i,!!' readStream nextChunkText)
More information about the Packages