Compiler Settings
The settings described below used to be presented in
a single page within the settings dialog.
This has been changed in one of the recent ST/X versions;
you will find those flag settings
in the "Translation", the "Bytecode" and "STC" subpages.
- Methods & Sources
- Bytecode compilation
- STC Compilation
- Warnings
If enabled, the system will open a warnBox, if some existing method
is redefined by a method from another package.
This prevents system methods from being redefined by filedIn code.
(useful, when alien code is loaded, and you want to make certain,
that is does no harm to any system class ...)
A methods package is determined by its
packageSymbol (an instance variable in Method), and is either set by the
stc compiler, or by the incremental compiler.
For stc compilation, a command line argument is used to define
the package; for incremental compilation, the active projects package symbol
is used.
Finally, a compiler directive can be used within the source file itself,
to define the package. However, when compiling with stc, any package
command line argument has higher priority.
When alien code (PD-code) is filed in, it is highly recommended to
turn this flag on - to prevent any standard methods from being overwritten
by code from the file.
Like the above, but for redefinitions of a class.
This is useful to prevent a classes definition from being overwritten
by a loaded (alien) class, during a fileIn.
If enabled, the HistoryManager is enabled, catching any method change,
to automatically append a history comment to the end of the methods source
code. Only the initial creation and the last modification (per user) are
reported.
In a development group,
this helps in finding the person who made the very last modification to
some method.
If a sourceCodeManagement system is used, this information is somewhat
obsoleted by the classes revision log.
However, the HistoryManager provides a more finegrained modification history
(per method) than the sourceCodeManager (which only records checkin dates
for the complete class).
Using the HistoryManager may lead to a small performance overhead in the system browsers.
If enabled, the HistoryManager will maintain a method called
#history in a classes documentation category, adding
a comment for every change made in the class.
This is much like the method-history lines described above, but
all history lines are concentrated in one place.
(this makes it very easy, to track and auto-document changes made to a class).
Using the HistoryManager may lead to a small performance overhead in the system browsers.
When loading methods from a sourceFile, there are various possibilities,
on how the methods sourceCode should be kept for later browsing.
The sourceCode may be either kept as a string in the objectMemory,
or as a reference (fileName + filePosition).
The following modes are available:
- keep as string (#keep)
when methods are fileIn (or compiled in the browser), a methods sourceCode
is kept as a string (held in the method object).
This has the advantage, that the image is fully self contained - moving it
to another machine or copying it, will also move all source information with it.
The disadvantage is that it may require a lot of memory to keep all those
source strings in the computers memory.
But don't panic: the MemoryMonitor has a menu function to copy out all inmemory
sources to a file and release those strings, if you later run out of memory,
or if the paging performance becomes unacceptable.
- reference to filename (#reference)
only a reference to the fileName (from which the method is filedIn) is
kept with the method.
To access the methods sourceCode later, that file must be found along
the source file path.
If a snapshot image is moved, you have to make certain, that
those files are found along the source path - otherwise, the browser
will not be able to show any sourceCode.
This is the recommended setting.
However, be careful when filing in classes from a file contained
in a directory which is NOT in the sourcePath. Either add the directories
path to the searchPath, or switch to the full-path mode (described below)
before the fileIn is performed.
- reference to full path (#absReference)
a reference to the files full pathName (from which the method is filedIn) is
kept with the method.
To access the methods sourceCode later, that directory must be present.
If a snapshot image is moved to another machine, you have to make certain, that
those directories exist on the target machine.
This setting is useful in networks where all hosts mount their
server files on a common path.
- append and reference in ``st.src'' (#sourceReference)
the methods source is appended to a file named ``st.src'' and
a reference to that file is kept in the method.
To access the methods sourceCode later, this ``st.src'' file must be present.
If a snapshot image is moved to another machine, you have to move the corresponding
``st.src'' file with it - otherwise, no sources will be available on
the target machine.
Be careful to keep distinct source files if you have multiple images in
one directory. Also, do never edit, compress or otherwise modify this
source file.
- discard (#discard)
does not keep any source information in methods.
No browsing or fileOut of those methods is possible.
This is only useful with completely tested applications,
if huge amounts of code must be loaded.
Do not set this sourceMode during development.
If enabled, autoloaded classes will first be searchied in existing
compiled class libraries (binary compiled object files).
The sourceFile will only be consulted if no such compiled binary is found.
This option is only available if the system supports dynamic loading of
machinecode classes (i.e. dynamic object loading).
This enables the just-in-time (JIT-) compiler, which compiles internal bytecode
methods into fast machine code when a method is called for the first
time. Typically, this results in a 2-20 fold speedup of the executed byte code,
but leads to a short (usually unnoticable) delay, when the method
is called the first time. (However, these times may add up to a noticable
delay during startup ...)
Although faster than interpreted bytecode, JIT compiled code is typically
somewhat slower than statically compiled (stc-compiled) code.
The just-in-time compilation feature is relatively new,
and is still tested. For production, we recommend, to compile the classes
using the stc compiler and to disable the JIT compiler.
Please report any strange effects, which may appear with this enabled.
JIT compilation is not avaliable with all systems.
Please refer to the
``Architecture specific features'' section for more information.
Notice, that the presence of a JIT-compiler has less effect on the
overall performance in ST/X than in other (Smalltalk-) systems.
The reason is that in ST/X, most methods are already present as statically (stc-)
compiled machine code, when Smalltalk starts.
Here, JIT-compilation only affects methods which have been
modified (i.e. accepted or loaded) after the initial startup.
This controls if methods are to be (stc-) compiled to machine code (using stc)
when accepted in the browser or loaded via a fileIn.
Stc compilation takes much longer (seconds or even minutes),
compared to bytecode compilation; but results in faster execution
of those methods (3-100 times faster; often even faster than JIT-compiled code).
Not all systems support dynamic machine code compilation
(i.e. from within the browser);
on some, machine code compilation will always be disabled
(those that do not support dynamic loading of object files).
Read the
``Architecture specific features'' section for more information.
The following modes are available:
- primitive code only
All methods which do NOT contain primitive code, are compiled using the
fast bytecode compiler. When such a method is evaluated, these bytecodes
will be executed by a builtin interpreter. This interpretation is slower
than machine code execution, but the methods take less space (a factor of 6 to 10),
and compilation is pretty fast.
This is the recommended mode.
- always
All methods are compiled using the machine code compiler.
This creates high performance methods, but takes very long to compile.
You should only switch to this mode for performance measurements.
- never
Methods which do NOT contain primitive code are compiled to a bytecode
version as described above.
However, methods which do contain primitive code are not compiled at all.
Instead, a trapping stub method is created which enters the debugger,
whenever executed.
This mode is useful, to enter primitive code without being slowed down
by long computation pauses.
It also allows primitive code to be entered, edited and saved (filedOut)
on systems which do not support dynamic loading.
(I.e. you have to leave & rebuild the system using the stc batch
compiler).
This defines any (-I) include directories for stc-compilation.
This string is passed literally to both the STC- and the C-compilers.
The list should at least include the path to the ST/X include
directory (i.e. where the "stc.h" file is found).
In the default development environment (as found on the installation medium),
this file is found in the
"include"-subdirectory of
"projects/smalltalk".
If any method to be compiled includes inline-C code, which needs definitions
from some other include file, you have to add the files directory to the list,
and add a #include-directive to the classes primitiveIncludes section.
This is not used with bytecode compilation.
This defines any (-D) define arguments for stc-compilation.
This string is passed literally to the C-compiler.
This is not used with bytecode compilation.
This defines any compiler options for stc-compilation.
This string is passed literally to the stc-compiler.
Read the stc manual page for
possible options.
This is not used with bytecode compilation.
This defines any compiler options for stc-compilation.
This string is passed literally to the CC-compiler.
Read your systems cc manual page for possible options.
This is not used with bytecode compilation.
This lists additional libraries, which are consulted to resolve
undefined symbols when compiled machine code is dynamically loaded
into the system.
On systems which support true shared libraries (SGI, Linux-ELF, Solaris and Unixware),
this is not required iff the loaded object has been prelinked with any
other shared library (however, the LD_LIBRARY_PATH must be correct for the system
to find those shared libraries).
On systems which do not support shared libraries (Linux pre ELF),
the loaded objects should NOT be prelinked (to avoid multiple definitions),
and any required libraries are to be set here.
This is not used with bytecode compilation.
The following settings affect the bytecode compiler,
which is invoked when a method is accepted in the browser.
Changes on those have no effect on methods which have already
been accepted - you should re-accept your methods,
or change things at the beginning of your session.
This controls if and how the incremental bytecode compiler
should perform constant folding (i.e. compute constants at compile
time).
The following modes are available:
- disabled
no constant folding is performed
- level1 (always safe)
simple arithmetic & trigonometric
messages to numeric constants are folded, which are considered safe,
(such as "1.0 + 0.5" or "Float pi / 2").
Also, constant character messages (i.e. "Character cr")
are preevaluated and a constant is generated instead of the message send.
- level2 (usually safe)
in addition to above, also conversion of constant arrays via
#asFloatArray or #asDoubleArray
are performed.
- full (can be unsafe)
in addition to above, also creation of points
(i.e. "1.0 @ 0.5") and some other more obscure messages
are performed at compile time. Since this can result in strange program behavior,
it is not recommend to enable this.
Constant folding in Smalltalk is possibly unsafe, because redefined
methods to which sends were folded before are never executed;
therefore, the default behavior is to be very conservative (level1).
Note:
it is questionable whether it makes sense to allow control
over this setting - false settings may lead to obscure bugs and interesting
behavior (changing literal constants) to appear.
Consider the case where "1.0 @ 0.5" got folded into a
constant point, which is passed to some method, and sent an "x:"
message there. This modifies the ``constant'' point, which is certainly not
the expected behavior.
Controls if the underscore character is valid in identifiers.
Disabling this, allows old ST-80 code (where underscore was the
assignment character) to be filedIn.
When loading such code, no automatic translation into
new syntax is performed by the system.
This functionality has been added to support import of alien code,
it is not useful for production code.
After loading such code, we recommend rewriting it into portable ANSI Smalltalk.
Controls if the constructed array syntactic sugar extension is recognized.
This extension allows for arrays to be constructed via
{ e1. e2. ... eN }
For example:
{ (1@2). ('hello' , 'world') asLowercase. }
Notice that this does NOT generate a literal constant; instead, the generated code
constructs that array at run time.
Enabling this, allows for Squeak code using this syntax extension to be filedIn.
When loading such code, no automatic translation into
new syntax is performed by the system - it should be manually rewritten if the code
should be portable among all Smalltalk versions.
This functionality has been added to support import of alien code,
it is not useful for production code.
After loading such code, we recommend rewriting it into portable ANSI Smalltalk.
Allows reading (a subset) of dolphins compileTime constants.
This is a q&d hack to support fileIn of dolphin class files.
Currently only computed Character- and ByteArray-Constants are supported.
For example:
##( Character value:123 )
or,
##( 'this is revision ' , Smalltalk revisionNr printString )
Notice: as the ST/X compiler does some constant folding anyway, the first example above is
equivalent to:
Character value:123
This functionality has been added to support import of alien code,
it is not useful for production code.
After loading such code, we recommend rewriting it into portable ANSI Smalltalk.
Allows reading visualAge primitive code specifications.
This is a q&d hack to support fileIn of v'age class files.
No code to execeute the primitive is generated; instead, the method will
report an error at execution time.
This functionality has been added to support import of alien code,
it is not useful for production code.
After loading such code, we recommend rewriting those methods.
Controls if the dollar character is valid in identifiers.
This allows fileIn of methods which where written for
Smalltalk dialects where dollars are valid and treated like
a letter in an identifier (i.e. some VMS Smalltalk versions).
When loading such code, no automatic translation into
a portable syntax is performed by the system.
We do not recommend use of this feature - it makes your
programs highly unportable.
This functionality has been added to support import of alien code,
it is not useful for production code.
After loading such code, we recommend rewriting it into portable ANSI Smalltalk.
If enabled, some additional special characters are recognized as binary selectors.
These are: ± (plus-minus), × (times), · (centered dot) and ÷ (divide).
We do not recommend use of this feature - it makes your
programs highly unportable. It has been mainly added to allow for alien code to be loaded.
After loading such code, we recommend rewriting it into portable ANSI Smalltalk.
Controls if oldStyle assignments via the leftArrow- or underline-character are recognized.
The default is on.
Disabling this, allows VW code with degenerated variableNames (consistig of a single underline only)
to be filedIn.
When loading such code, no automatic translation into
new syntax is performed by the system - after loading, the code should be manually rewritten.
This functionality has been added to support import of alien code,
it is not useful for production code.
After loading such code, we recommend rewriting it into portable ANSI Smalltalk.
Controls if array constants are to be created as instances
of Array or as instances of ImmutableArray.
A typical beginners errror is to return a reference to a
constant array from some method, and later modify that array
using #at:put: messages. When this method is called again,
the modified array is returned and the programmers eyebrows are raised.
ImmutableArrays will raise an exception whenever modified,
which helps to track down this error more easily.
If you encounter strangely self modifying array constants,
recompile your methods with this option enabled, and wait for a debugger to come up.
Be reminded, that mutable literal arrays are the language standard.
If enabled, the bytecode compiler inserts more line number information
and the just-in-time compiler generates code
which supports full single stepping. When single stepping in the debugger,
it will stop on variable modifications, simple increments/decrements, simple
integer addition and method returns.
If disabled, these operations will be invisible, and a single step will
run up to the next message send or loop-jump.
If disabled, the code executes a bit faster, but may be harder to debug,
since the granularity of single stepping is slightly larger.
Change of this setting has no effect on methods which have already
been compiled to machine code - you should reaccept your methods,
or change this setting at the beginning of your session.
Should be enabled during development.
Enables/disables various warning messages in the incremental
compiler.
Enables/disables warnings if non-standard ST/X language extensions
are used.
(end-of-line comments or 'here'-sends, for example)
This should be enabled,
if you plan to port your program to other systems later, since
the use of ST/X
language extensions will certainly affect the portability.
Enables/disables warnings when identifiers with underscores are encountered.
These may not be allowed in other vendors' older Smalltalk systems
(i.e. ST-80 rel 2.x).
Enables/disables warnings when identifiers with dollars are encountered.
These are most unlikely to be allowed
in most other vendors' Smalltalk systems.
Enables/disables warnings if an oldStyle assignement is encountered.
(i.e. using the underscore, ``_'' instead of the assignment ``:='' token).
These were used by some old Smalltalk systems (i.e. ST-80 rel 2.x).
Enables/disables warnings about code which may lead
to a runtime error when executed, and often results from typing errors.
For example, constructs such as: "(a > 1) whileTrue:[...]"
(receiver is not a block) will generate this type of warning.
You should check the code carefully, since a redefined #> method
may theoretically return a block object - so the above is not incorrect in the
strict sense, and can therefore not be flagged as an error by the compiler.
Enables/disables warnings about constructs which are possibly incompatible
with other Smalltalk systems. For example, the expression "1-2"
is invalid on some systems (requires a space before the minus to be recognized
as a selector).
This should be enabled (in addition to the ST/X language extension warnings),
if you plan to port your program to other systems later,
since the use of those constructs may affect the portability.
It is not guaranteed, that all possibly incompatible constructs are warned
about, as we depend on user feedback for more information about other systems.
Reenable Suppressed Warnings
Sometimes, you are not interested in some warnings for a particular method.
For example, during development, the "unused variable warning" may be annoying
if a method's code is accepted repeatedly during an explorative development session,
and you get the same warning over and over again.
Therefore, some warnings can be suppressed on a per-method basis,
via a checkbox in the parser's warn dialog.
For disabled warnings,
the classname and selector is kept and remembered in a table of the ParserFlags class.
Pressing this button clears that table,
so that the parser will issue the warning
as usual in the future.
Only some warnings can be suppressed temporarily on a per-method basis.
Temporarily means, that after some time (currently 30 minutes),
warnings of this type are automatically reenabled after that time.
Currently, these are:
- unused variable
- possible operator precidence mistake
- local hides instance variable or argument
Copyright © Claus Gittinger Development & Consulting, all rights reserved
Doc $Revision: 1.35 $ $Date: 2016/12/09 12:01:38 $