A standard installation procedure ("INSTALL") is included on the
distribution media - in most situations, this defaults to a usable
installation and the following is not required to be known.
However, if you like to remove certain parts, share parts in a network
or otherwise need a personal setup, read the following chapters to
gain insight on what the parts are, and where they are to be installed.
The full development package can be licensed for non commercial or commercial use.
Beside the legal differences, the commercial version adds source code revision management, additional compatibility classes and some additional goodies.
The components of the demo package are distributed under a less strict license: it may be used and copied free of charge for non commercial use.
.
./configurations
./doc
./doc/online
./doc/online/english
./stc
./include
./librun
./libbasic
./libbasic2
./libbasic3
./libcomp
./libview
./libview2
./libwidg
./libwidg2
./libwidg3
./libtool
./libtool2
./libui
./libhtml
./libxt
./libsnmp
./support
./clients
./goodies
./contrib
./contrib/libPVM
./projects
./projects/smalltalk
./projects/smalltalk/source
./projects/smalltalk/resources
./projects/smalltalk/bitmaps
./projects/smalltalk/binary
./projects/smalltalk/lib
"projects/smalltalk" are included.
To run ST/X using the incremental compiler only, you will
need all the directories "projects/smalltalk" and below.
This is enough (*) to play with the system, learn the language and write programs
which execute in the integrated environment.
With the help of startup scripts, you can even create pseudo
standalone applications.
To compile classes into machine code, you need the include files and the stc compiler.
To recompile all classes you need a full tree as above and lots of disk space. However, there is usually no need to recompile the standard classes as provided with the system.
(*) Notice:
many ST/X users actually stay in this environment throughout
the whole development process - compiling to machine code only when creating
new deliverables for shipment or if inline C code is required to create
interfaces to existing C libraries.
An installation consisting of the source files and the resulting class libraries only (as contained on the distribution medium) requires approx. 30 Mb of disk space.
Create a new directory where the files should go,
and change into it.
In the following description, we call this directory "TOP".
mkdir stx
cd stx
tar xfv /dev/yourFloppyHere
and uncompressed with:
gunzip *.gz
Finally, the resulting tar files have to be extracted themselves with:
tar xvf *.tar
After that, the tar files can be removed. They are no longer needed.
tar xfv /dev/yourTape
while for CDROM, copying with:
cp -R whereYourCDIsMounted .
If your system does not support long filenames on CD, you have to use
a copy program which is contained on the CD. Read the instructions supplied
with the booklet.
"INSTALL")
installs the components into two directories: a binary directory, where
the smalltalk and stc executables are installed,
and a lib directory, where all the rest is placed (most files are placed
into subdirectories of the lib-directory).
The default installation only installs the libraries required to execute smalltalk - it does NOT install a complete development tree, which is required to rebuild the system or to build a new smalltalk executable.
The resulting installation can be used by multiple users - however, make certain, that the shared sources, executables etc. are made readOnly to non-administrators, and that different directories are used by the users (since each has to maintain its own changes file, for example).
cd TOP/projects/smalltalkor, if you installed the demo version:
smalltalk
cd TOP
smalltalk
.
$HOME/.smalltalk
$STX_LIBDIR
/usr/local/lib/smalltalk
/usr/lib/smalltalk
where $HOME is your login directory and $STX_LIDIR
is a shell environment variable which can be left undefined.
For example, a personal startup-script "smalltalk.rc" can be
put into "HOME/.smalltalk/smalltalk.rc".
Since $HOME comes before "/usr/local/lib/smalltalk"
in the searchpath, ST/X will consult this private file;
even if some other "smalltalk.rc" file exists there.
There are rare situations, in which the above searchpath is not adequate for
a particular setup. Therefore, the searchpath can also be initialized
from a shell variable named "STX_SEARCHPATH". If defined, it should
contain a colon-separated list of directory names. However, it does not affect the
builtin searchpath for VM required files - especially the "symbols.stc" file.
To install the system into some standard place
(usually "/usr/local/lib"
or "/usr/lib"),
you should create the following directories:
/usr/local/lib/smalltalk
/usr/local/lib/smalltalk/source
/usr/local/lib/smalltalk/resources
/usr/local/lib/smalltalk/bitmaps
/usr/local/lib/smalltalk/include
/usr/local/lib/smalltalk/doc
and copy the files from corresponding subdirectories
found in "projects/smalltalk" to those new directories.
Also, all files ending in ".rc" should be copied to this
new directory.
You can also create symbolic links in those directories to
point to the files found under your actual TOP.
(dont symlink to the directories;
many system's chdir command gets a bit confused when
changing back to ".." from a symlinked directory.)
The ST/X executable itself should go to
or any other directory in your path.
Alternatively, create a symbolic link, or adjust your $PATH
variable to have its directory included.
/usr/local/bin/smalltalk
If you do not have access to "/usr/local/lib", you can also
put the stuff into any directory you like, and set the shell-variable
$STX_LIBDIR to the name of that directory.
Thus, your global directory should look like:
.../source
.../source/*.st
.../resources
.../resources/*.rs
.../resources/*.style
.../include
.../include/symbols.stc (**)
.../bitmaps
.../bitmaps/*.xbm
.../fileIn/...
.../doc/coding
.../doc/misc
.../doc/...
.../smalltalk.rc
.../smalltalk_r.rc
.../display.rc
.../host.rc
.../d_*.rc
.../h_*.rc
.../abbrev.stc
.../patches
and (if "..." is not one of "/usr/lib/smalltalk" or
"/usr/local/lib/smalltalk") the shell environment should contain
a variable named STX_LIBDIR, which is set to whatever "..." is.
Since compiled code does not include the source code itself,
but instead a reference (filename & position) to it,
an incorrect installation will lead to no source code being shown
in the browser
(the "smalltalk.rc"-script which is described below does a quick check and gives a warning).
Also, please do not manually edit the source files themselfes - you will make the position-information in compiled code invalid, and therefore see funny source code (parts only) in the browser.
The free demo package does not include all sources - some stuff is only avaliable in the non-free release. Therefore some methods source will not be visible in the browsers - even with a correct installation.
"make target"
"projects/smalltalk"
"INSTALL" procedure
"Make.proto" files
(to change the set of classes in a classLibrary),
or by changing the package list (to change the set of classLibraries which are
included in the initial executable).
(Package definitions for common configurations are found in
"configurations/PACKS").
ST/X can execute with a much smaller set of initial classes
(even most of the user interface classes can be left out) -
due to the autoload mechanism, missing classes will be loaded on demand and
installed as bytecode interpreted code.
Of course, this slows down the initial startup. However, the loading will be done
only once, since after a snapshot restart, the image will already contain them.
"smalltalk.rc" to
setup some internal stuff. Since the search for this file is done
using the above path, you can put your private "smalltalk.rc" into
either the current directory or "HOME/.smalltalk".
This script contains smalltalk expressions which will first do some
display-specific setup
(by executing "display.rc"),
followed by host-specific setup (executing "host.rc"),
and (if present) private definitions from "private.rc".
Finally it launches some default applications (currently the
Transcript
and
Launcher).
You can of course add more to this
(for example, if you like to arrange for a systemBrowser to come
up automatically).
"display.rc" tries to find out the kind of display hardware
you are working with and then executes one of the
"d_xxx.rc"
scripts.Have a look at "display.rc" to see how this is done.
Some display specific scripts are already provided with the system,
but you can add your own ones, if you are not happy with those settings.
However, please leave the existing "d_xxx.rc"-files
unmodified -
better add your own new, and call it "d_displayname.rc".
Your new "d_xxx.rc" file should set your personal preferences,
such as view-look and keyboard mappings
(use "d_sample_display.rc" as a guide).
Also, keyboard mappings are set up in both "display.rc" and
the individual "d_xxx.rc" files.
For example, national keyboard variants are set there.
The same strategy is used for host specific setup,
which consists mainly of printer setup.
"host.rc" tries to find out, what host you are running on
(which is NOT always the same as the display in X).
Like with the display files, you should leave the existing host
files untouched and add a new one, called "h_hostname.rc".
Use "h_sample_host.rc" as a guide.
The other startup script "smalltalk_r.rc" is consulted, when
a snapshot image is restarted; it also does the display and host
setup but does not launch any new applications.
Thus, the existing views will reopen after restart, but the look may be
different, if started with another DISPLAY setting.
Summary, startup actions:
#initialize to each)
"patches" (if present)
"smalltalk.rc"
"display.rc"
"d_xxx.rc"
"host.rc"
"h_xxx.rc"
"private.rc"
Please read the document on ``configuration and customization'' for details on how to change ST/X's settings to meat your personal preferences.
Hint:
the above mentioned search-path is valid for all files used and read by ST/X. The order allows both sharing of startup files and individual setups both per user and per project.
For example, you can put global default scripts into"/usr/local/lib", workgroup specific files into"STX_LIBDIR", user private things into each users"HOME/.smalltalk"and finally project specifics into individual subdirectories.
Since bitmaps and resource files are too found along that path, you can even define your private bitmaps (for example: icons), by creating a"bitmaps"directory somewhere in the path and putting your own bitmap files there (most view classes use their abbreviated class name and append".xbm"to construct the name of the icon bitmap file).
Hint:
actually the above was not completely correct: the name of the startup script is"executable-name.rc"- not strictly"smalltalk.rc". Thus, you can create an application by simply linking to the smalltalk executable, call it "whatever" and create a corresponding"whatever.rc".Of course, if you have a full distribution (including the stc-compiler) you can also create stand alone executables.
However, using the same executable for multiple applications (customized by startup scripts) is not as stupid as it may look at first: all UNIX systems share the physical memory of the text space if multiple processes execute the same program. Therefore, all running smalltalk processes will use the same physical memory containing the code.
Especially in multiuser setups, this may lead to a much better memory utilization than creating multiple standalone applications. (BTW: on Ultrix, this is the reason for those monster executables found in "/usr/bin/X11" ;-)
For systems which support shared libraries, the same is true on a finer grain level: here individual class libraries share their memory.The above is - of course - only valid for the text segment (i.e. for statically compiled machine instructions). Interpreted bytecode (and also: on the fly generated machine code) has to be placed into the data space. Unless special tricks are used, these data segments are not shared.
ST
class (SystemPath) and can be accessed via class methods.
You can add components to the path or change it completely from your startup file
"smalltalk.rc" or "private.rc".
Obviously, the startup file itself must be found in the initial (default)
searchpath to do that.
(**) symbol file
This file is not required for all architectures - in those that do require
it, ST/X will NOT work without it or if it is corrupted
(so, never change or remove it).
Also, since this file is read by the VM during early startup time
(before any smalltalk objects exist), a builtin searchpath
is used for it (i.e. the setting of the above described searchPath
class variable has no effect).
The builtin searchpath for the symbols file is:
for Unix, and:
./include/symbols.stc
$SMALLTALK_LIBDIR/include/symbols.stc
$STX_LIBDIR/include/symbols.stc
/usr/local/lib/smalltalk/include/symbols.stc
/usr/lib/smalltalk/include/symbols.stc
/opt/smalltalk/include/symbols.stc
for MS-Windows systems.
.\include\symbols.stc
$SMALLTALK_LIBDIR\include\symbols.stc
$STX_LIBDIR\include\symbols.stc
\Programme\eXept\SmalltalkX\include\symbols.stc
\Programs\eXept\SmalltalkX\include\symbols.stc
\Programme\SmalltalkX\include\symbols.stc
\Programs\SmalltalkX\include\symbols.stc
\SmalltalkX\include\symbols.stc
For a default installation:
INSTALL
... use /usr/local/bin
and /usr/local/lib
as target directories
For a full developmen installation:
CD:
tape:
mkdir stx
cd stx
copy --recursive yourCD .
follow this by a quick go/nogo check:
mkdir stx
cd stx
tar xvf /dev/yourTape
cd projects/smalltalk
smalltalk
Copyright © 1996 Claus Gittinger Development & Consulting
Copyright © 1996 eXept Software AG
<cg@exept.de>