https://wiki.liberty-eiffel.org/api.php?action=feedcontributions&user=Dkearns&feedformat=atomLiberty Eiffel Wiki - User contributions [en]2024-03-28T19:41:16ZUser contributionsMediaWiki 1.37.0https://wiki.liberty-eiffel.org/index.php?title=Liberty_Eiffel_users_list&diff=2521Liberty Eiffel users list2016-07-05T03:41:49Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category:Community]]<br />
<div id="LibertyEiffelUsersList"><br />
'''List of Liberty Eiffel users'''. Register yourself in the list below. After [[SmartEiffelImport|import]] we removed all SmartEiffel users, so if you switch to Liberty, please add yourself again.<br />
<div><br />
<HR><br />
<br />
==Schools or universities==<br />
Empty slot.<br />
----<br />
Empty slot.<br />
----<br />
<br />
==Projects or individuals==<br />
[[User:Ramack|Raphael Mack]]<br />
----<br />
[[User:Cadrian|Cyril Adrian]]<br />
----<br />
Empty slot<br />
----</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=ToDo&diff=2520ToDo2016-07-05T03:40:19Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>* describe polymorphism<br />
* [[Cloning_objects]]<br />
* describe difference between variable and object (should be already there, so make it easier to find, maybe add aliasing as effect)<br />
* restructure to simplify the entry into Liberty Eiffel for newcomers (remove the separation between "The Grand Book" and Community pages)<br />
* clean up syntax diagrams</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Install&diff=2519Install2016-07-05T03:38:43Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div> The Liberty Eiffel '''install''' tool is '''not used anymore''', as it is<BR>replaced by a shell script [http://git.savannah.gnu.org/cgit/liberty-eiffel.git/tree/install.sh install.sh] and its [[Getting Started|manual]].<br />
<br />
The eiffel ''install'' tool is still available in the Liberty repository, but it is - like this page here - obsolete. Maybe once upon a time it may resurrect, so we keep this page until it's buried.<br />
<br />
[[Category:Tool]]<br />
[[Category:Obsolete]]<br />
<br />
= Usage =<br />
The install command is the installation program for Liberty Eiffel The GNU Eiffel Compiler. <br />
This command does not support any option.<br />
This command (class install.e) is written entirely in Eiffel and is the one recommended for installing Liberty Eiffel The GNU Eiffel Compiler. <br />
<br />
The install.e source code as well as the generated C code install.c are in the Liberty Eiffel directory. <br />
<br />
The very first step in installing Liberty Eiffel is to unpack the Liberty Eiffel directory somewhere on disk. The second step (not mandatory) is to set the Liberty Eiffel environment variable to the full path leading to the SmartEiffel/sys/system.se file. The last step is to compile the install.c file (it is pre-compiled for Windows) and to run it from the Liberty Eiffel directory. <br />
<br />
For Unix, Elate and OpenVMS people, a Makefile is also provided, that does just that. Look at the comments in the Makefile itself for details. <br />
<br />
The install command will do the rest of the work and will try to report possible problems. See the examples below. <br />
<br />
See also at the end of the page for more details on how to use the interactive installer. <br />
<br />
= Example for UNIX =<br />
<br />
As an example, we assume below that we want to install Liberty Eiffel in the directory /foo/SmartEiffel/. If you are using bash, add the following two lines to your .bashrc file:<br />
<br />
export SmartEiffel=/foo/SmartEiffel/sys/system.se<br />
export PATH=/foo/SmartEiffel/bin:$PATH<br />
<br />
If you are using csh or tcsh, add the following two lines to your .cshrc file:<br />
<br />
setenv SmartEiffel /foo/SmartEiffel/sys/system.se<br />
setenv PATH /foo/SmartEiffel/bin:$PATH<br />
<br />
Don't forget to open a new terminal window in order to take into account the new settings of the SmartEiffel and PATH variables. Then, in this new terminal window, just type the following commands: <br />
<br />
cd /foo<br />
gunzip se.tgz (or bunzip2 se.tar.bz2)<br />
tar xvf se.tar<br />
cd SmartEiffel<br />
make<br />
<br />
You now just have to wait for the compiler installation to complete. Actually, it may take some time because all of the tools are recompiled from scratch using the Eiffel source code of SmartEiffel itself. <br />
<br />
If you want to use the menus (as explained below), you should consider typing make interactive instead of just make. If your system has no gcc installed, compile install.c yourself and run it. <br />
<br />
= Example for Windows =<br />
<br />
The first step under Windows is to get a C compiler working on your computer. If you don't already have a C compiler installed, we recommend the LCC-Win32 compiler (a free C compiler system for Windows by Jacob Navia, http://www.cs.virginia.edu/~lcc-win32/ or http://www.q-software-solutions.com/lccwin32/). <br />
<br />
At this point, it is assumed you have a C compiler installed. Further, we assume below that we want to install SmartEiffel in the C:\SmartEiffel directory. <br />
<br />
The last step is to open an explorer window, go to C:\SmartEiffel, and double-click INSTALL.EXE. <br />
<br />
You now go along the menu options (as described below), then you have to wait for the compiler installation to complete. Actually, it may take some time because all of the tools are recompiled from scratch using the Eiffel source code of SmartEiffel itself. <br />
<br />
= Example for Other Systems =<br />
For elate and OpenVMS systems, you can use make elate or make openvms.<br />
On other systems, the very first step for installation is to compile the install.c file in order to run it. <br />
<br />
= Using the installer =<br />
The installer helps you install SmartEiffel in the smartest way possible: yours :) <br />
<br />
Except when using the plain make on Unix/Linux (which just picks default options and goes ahead), the installer asks help from you to install SmartEiffel. Of course, in many cases, the installer is Smart enough to choose good default values; those values are but defaults, though. It's up to you to tune them, or go along with them. <br />
<br />
The install process is split in six phases, each of which is accessed via an entry in the main menu. The first three concern tuning the configuration; the rest deals with the installation itself. <br />
<br />
Note that when a phase completes gracefully, the default option is to do the next one. Of course, you can skip phases, or go back to some, at your convenience (indeed, it's a menu) :) Also note that if the installer successfully computes acceptable default values, the first default value will be to verify the configuration (phase 3). <br />
<br />
Furthermore, if SmartEiffel finds a valid configuration file (either at a default place or because you provided it via the SmartEiffel environment variable), the first default value will be to start the installation! You've been warned... <br />
== 1. General configuration ==<br />
This phase can be automatically computed. <br />
<br />
In that first phase, you are asked to provide: <br />
<br />
*The operating system SmartEiffel is to be installed on (generally the one you're currently running...); <br />
*The path to the configuration file (a good idea is to accept the default; otherwise, you will always have to set the SmartEiffel environment variable); <br />
*Various paths pointing to parts of the SmartEiffel installation: <br />
**the path to the binaries,<br />
**the path to the sys directory,<br />
**the path to the short directory;<br />
* Default loadpath files: it is a sub-menu that lets you see, add, and remove default loadpath files. Remember that all those loadpaths will be read at each compilation; keep your hand light! (more about that in the finder man page) <br />
<br />
== 2: C modes configuration ==<br />
This phase can be automatically computed. <br />
<br />
In that menu you can add and modify C modes. Removing them are not allowed; be careful if you add a new one. Default C modes are provided, one for each assertion level. <br />
<br />
Each C mode lets you set the following values: <br />
* The C compiler type. The currently supported lists are: <br />
** '''gcc''' The GNU Compiler Collection; specifically, the C/C++ compiler.<br />
** '''lcc-win32''' The C compiler developed by Jacob Navia.<br />
** '''tcc''' The Tiny C Compiler, developed by Fabrice Bellard.<br />
** '''wcl386''' The Open Watcom C/C++ compiler.<br />
** '''bcc32''' The Borland C/C++ compiler (needs free registration).<br />
** '''cc-unix''' The vanilla Unix C compiler. There are as many flavours of cc as of Unix... This one is generic; if some specific support is needed, please file an enhancement request in SmartZilla.<br />
** '''cc-openvms''' The Open VMS C compiler.<br />
** '''vpcc''' The Elate C compiler.<br />
** '''cl''' The Microsoft C/C++ compiler.<br />
** '''sas_c''' ?<br />
** '''dice''' ?<br />
** '''vbcc''' ?<br />
** '''ccc''' ?<br />
* The C compiler path (e.g. for gcc, you can use /usr/bin/gcc-2.7.2) <br />
* The C compiler options (e.g. for gcc, -ggdb3 -fomit-frame-pointers) <br />
* The C linker path (e.g. for lcc, lcclnk) <br />
* The C linker options (e.g. -lmylib) <br />
* The SmartEiffel extra options for this mode. Only a subset of the command line options are recognised. Those are: <br />
**-no_gc<br />
**-no_strip<br />
**-no_split<br />
**-sedb<br />
<br />
== 3: Verification ==<br />
This phase is skipped by default if the previous two were automatically computed. <br />
<br />
In that phase, all the options you chose are displayed again, as a verification. <br />
<br />
== 4: Writing the configuration file ==<br />
In that phase, the configuration file is written to the place you chose in phase one. <br />
<br />
== 5: Installing SmartEiffel itself ==<br />
This is the most important phase! Indeed, now the installer can compile the SmartEiffel tools. <br />
<br />
Just before starting the compilation, you are asked with which C mode the tools should be compiled. It is not always useful, except if you're in a hurry (not a good idea, that) :) <br />
<br />
== 6: Exit! ==<br />
If you successfully installed SmartEiffel, then you can exit the installer and enjoy your new Eiffel compiler.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Eiffeldoc&diff=2518Eiffeldoc2016-07-05T03:36:16Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category:Tool]]<br />
<br />
<code>eiffeldoc</code> is the tool that documents your Liberty Eiffel project. Currently only HTML output is supported, but maybe others will be added in the future.<br />
<br />
<br />
== Synopsis ==<br />
<br />
* <code>eiffeldoc {-title title} {-home_address address} {-nav_css file} {-doc_css file} {-class_css file} {-arrow_address address} {-separator_address address} {-depends} {-prune cluster...} {-verbose} {-help} {-wiki_prefix prefix} [loadpath.se | ACE file] </code><br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| valign="top" width="20%" | <code>-title</code><br />
| The title of the generated documentation<br />
|-<br />
| valign="top" | <code>-home_address</code><br />
| The address of the ''go home'' upper-left link. If <code>-home_address</code> is not given, the ''go home'' upper link won't be generated.<br />
|-<br />
| valign="top" | <code>-home_image_address</code><br />
| The address of the ''go home'' image<br />
|-<br />
| valign="top" | <code>-nav_css</code><br />
| The stylesheet to use in the navigation bar (i.e. the left frames)<br />
|-<br />
| valign="top" | <code>-doc_css</code><br />
| The stylesheet to use in the cluster documentation (i.e. on the right frames)<br />
|-<br />
| valign="top" | <code>-class_css</code><br />
| The stylesheet to use in the class documentation (i.e. on the right frames)<br />
|-<br />
| valign="top" | <code>-arrow_address</code><br />
| The address of the arrow image. If the <code>-arrow_address</code> is not given, links in the left navigation bar won't have an arrow.<br />
|-<br />
| valign="top" | <code>-separator_address</code><br />
| The address of the separator image. If the <code>-separator_address</code> is not given, there will be no separation before the description of a cluster.<br />
|-<br />
| valign="top" | <code>-prune</code><br />
| Don't show the cluster nor its classes in the left navigation bar. It uses the loadpath.se or ACE syntax for paths. Note that it also removes all the subclusters.<br />
|<br />
|-<br />
| valign="top" | <code>-remote</code><br />
| replace the generation of that class by the address of the class generated by another instance of eiffeldoc at the given address. Note that, like -prune, the clusters don't show in eiffeldoc. It is useful for consistency. For example: <code>eiffeldoc -remote 'lib' 'http://doc.liberty-eiffel.org/libraries/'<code><br />
<br />
As a special case, <tt>-prune cwd</tt> allows not to take the current working directory into account.<br />
<br />
Example:<br />
se doc -prune 'lib/scoop'<br />
|-<br />
| valign="top" | <code>-depends</code><br />
| Generate dependant classes even if their cluster is pruned. This helps avoiding dangling links.<br />
|-<br />
| valign="top" | <code>-verbose</code><br />
| Output a lot of information about what eiffeldoc is doing.<br />
|-<br />
| valign="top" | <code>-wiki_prefix</code><br />
| Generate links to wiki URLs (in square brackets)<br />
|}<br />
<br />
== Stylesheets ==<br />
<br />
The stylesheets are heavily used to customize the output of Eiffeldoc. The known classes are:<br />
<br />
{|<br />
|-<br />
| A.home<br />
| for the home link<br />
|-<br />
| A.title<br />
| for the titles<br />
|-<br />
| A.cluster<br />
| for the clusters<br />
|-<br />
| A.class<br />
| for the classes<br />
|-<br />
| A.client<br />
| for the upper-right clients frame<br />
|-<br />
| A.description<br />
| for the one-sentence description in the cluster summary<br />
|-<br />
| TD.home<br />
| for the home link<br />
|-<br />
| TD.title<br />
| for the titles<br />
|-<br />
| TD.cluster<br />
| for the clusters<br />
|-<br />
| TD.class<br />
| for the classes (except in the short proper)<br />
|-<br />
| TD.client<br />
| for the upper-right clients frame<br />
|-<br />
| TD.description<br />
| for the one-sentence description in the cluster summary<br />
|-<br />
| B.obsolete<br />
| for the obsolete header<br />
|-<br />
| I.obsolete<br />
| for the obsolete message<br />
|-<br />
| TD.comment<br />
| for a class comment<br />
|-<br />
| PRE.comment<br />
| for a class comment<br />
|-<br />
| B.comment<br />
| for a feature clause comment<br />
|-<br />
| I.comment<br />
| for a feature comment<br />
|-<br />
| LI.summary<br />
| for a feature in the summary<br />
|-<br />
| A.summary<br />
| for the feature link in the summary<br />
|-<br />
| TD.details<br />
| for a feature definition in the details section<br />
|-<br />
| B.details<br />
| for the feature name in the details section<br />
|-<br />
| B.assertion<br />
| for the assertion tags<br />
|-<br />
| TT.assertion<br />
| for the assertion expressions<br />
|-<br />
| I.assertion<br />
| for the assertion comments<br />
|-<br />
| A.link<br />
| for a class link in the class documentation<br />
|-<br />
| U.wiki_entity<br />
| for a link to a field in a comment, not anchored ''?Is 'anchor' the correct translation of 'lier' here?''<br />
|-<br />
| A.wiki_entity<br />
| for a link to a field in a comment, anchored<br />
|-<br />
| B.wiki_bold<br />
| for bold elements in a comment (wiki syntax)<br />
|-<br />
| I.wiki_italics<br />
| for italic elements in a comment (wiki syntax)<br />
|-<br />
| TT.wiki_class_name<br />
| for class names in a comment<br />
|-<br />
| TT.wiki_string<br />
| for character strings in a comment<br />
|-<br />
| TT.wiki_character<br />
| for characters in a comment<br />
|-<br />
| UL.wiki_bullet_list<br />
| for bullet-point lists<br />
|-<br />
| LI.wiki_bullet_list<br />
| for bullet-point list items<br />
|-<br />
| OL.wiki_numbered_list<br />
| for numbered lists<br />
|-<br />
| LI.wiki_numbered_list<br />
| for numbered list items<br />
|-<br />
| A.wiki_url<br />
| for URLs (between <nowiki>[...]</nowiki>)<br />
|-<br />
| A.wiki_word<br />
| for wiki words (between <nowiki>[[...]]</nowiki>)<br />
|}<br />
<br />
== Usage ==<br />
<br />
=== Project ===<br />
<br />
Eiffeldoc analyses a project's whole set of classes in order to provide HTML<sup>[[Eiffeldoc#note1|1]]</sup> documentation organised by cluster and class. Eiffeldoc can be used to produce the API for these classes.<br />
<br />
Eiffeldoc has been designed to generate the documentation for a whole '''project'''. But what is a project?<br />
<br />
A project is a set of classes that makes a coherent whole: a library, an application, a set of applications, a plug-in, and so on.<br />
<br />
Eiffeldoc defines the project by the set of class search paths. It uses the same method as <TT>[[finder]]</TT>:<br />
using the ACE file or else <TT>loadpath.se</TT> and the paths from the system [[Configuration file|configuration file]].<br />
<br />
=== Documentation ===<br />
<br />
A high quality API does not only list its features with their signatures and contracts. The reader generally needs documentation at a higher level, which does not only explain how to call some method, but also explains the purpose of each feature and the way it is implemented, together with more general considerations.<br />
<br />
In order to do this, Eiffeldoc uses two complementary mechanisms. The classes and their features are described by their comments; the clusters are described by a special file.<br />
<br />
==== Comments ====<br />
<br />
Eiffeldoc makes full use of comments. There is a convention about the ''position'' of comments.<br />
<br />
'''For classes''', the ''class comment'' is the comment placed just after the class declaration. For example:<br />
class MY_CLASS<br />
-- this is the class comment<br />
end<br />
''The convention'' is to describe the overall purpose of the class, what it is used for, in what context, and so on.<br />
<br />
'''For groups of features''', the ''feature group comment'' is the comment placed just after the <TT>'''feature'''</TT> clause. For example:<br />
feature {ANY} -- Consultation:<br />
''The convention'' is to use short comments, because they are used as feature group headings.<br />
<br />
'''For features''', the ''feature comment'' is the comment placed just after the feature signature (after the return type for attributes, after the keyword <TT>'''is'''</TT> for routines). For example:<br />
my_routine (i: INTEGER): INTEGER is<br />
-- a function that depends on the argument `i'<br />
''The convention'' for complicated comments is to begin with a summary sentence. This sentence<sup>[[Eiffeldoc#note2|2]]</sup> is extracted and used in the first part of the class description.<br />
<br />
==== cluster.html ====<br />
<br />
Each cluster can be documented by a file <TT>cluster.html</TT>, stored in the same directory as the cluster's classes. If this file exists, Eiffeldoc extracts from it the HTML code between the elements &lt;body&gt; and &lt;/body&gt;. Here too, it extracts the first sentence to use in the page that describes the whole group of clusters.<br />
<br />
----<br />
<DIV id="note1">1. Other output formats are expected to be possible in the future.</DIV><br />
<br />
<DIV id="note2">2. A sentence is delimited by a full-stop, ellipsis, question mark or exclamation mark, followed by a space. Note that Eiffeldoc keeps track of parentheses, so that <TT>(`lower' .. `upper')</TT> is not the end of a sentence. As a special case, a sentence like <TT> does lots of things (this, that, etc.)</TT> finishes ''after the parenthesis''.</DIV></div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=External_types&diff=2517External types2016-07-03T06:50:00Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Interfacing]]<br />
todo: describe what actually IS implemented and update [[Externals]]<br />
<br />
The syntax will have to be flexible enough to work for any reasonable external language, not just C (e.g. Java). No provision is made for embedding variable-sized external types.<br />
<br />
= The plug-in for the examples =<br />
For syntactic experiments, we'll assume the following C files are used.<br />
<br />
'''my_struct.h''':<br />
typedef struct {<br />
double x;<br />
int c;<br />
} my_struct;<br />
<br />
'''my_struct.c''':<br />
#include "my_struct.h"<br />
use (my_struct *x) {<br />
x->x = 3.14;<br />
<br />
if(x->c == 0) x->c = 5;<br />
else x->c++;<br />
<br />
printf("x = %f, c = %d\n", x->x, x->c);<br />
}<br />
<br />
use_copy (my_struct x) {<br />
x.x = 3.14;<br />
<br />
if(x.c == 0) x.c = 5;<br />
else x.c++;<br />
<br />
printf("x = %f, c = %d\n", x.x, x.c);<br />
}<br />
<br />
The program should print<br />
x = 3.14, c = 5<br />
x = 3.14, c = 6<br />
<br />
= Embedding external types in Liberty Eiffel =<br />
There are currently two competing mechanisms. Their expressivity is roughly the same (when you have one it is easy to emulate the other).<br />
<br />
== External attributes ==<br />
The "external" keyword is used as a type name to tell the Eiffel compiler that an attribute should be represented by a user-specified external type. (The precise syntax is not fixed: the attribute may look better with a "plug_in" manifest string or an "is" keyword)<br />
<br />
class SHOW<br />
<br />
creation<br />
make<br />
<br />
feature<br />
make is<br />
do<br />
use($ext)<br />
use_copy(ext)<br />
end<br />
<br />
use (x: POINTER) is<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
feature_name: "use"<br />
}"<br />
end<br />
<br />
use_copy (x: like ext) is<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
feature_name: "use_copy"<br />
}"<br />
end<br />
<br />
ext: external<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
attribute_type: "my_struct"<br />
}"<br />
end<br />
end<br />
<br />
== External classes ==<br />
A special marker is used to tell the Eiffel compile that a class should be represented by a user-specified external type. Methods of that class can be implemented by passing Current as a parameter to external routines. Whether Current is passed by copy or by reference could be determined by the reference/expanded status of the external class.<br />
<br />
Issues:<br />
* Forces the programmer to write one class for each external type they want to wrap<br />
<br />
expanded class SHOW<br />
<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
attribute_type: "my_struct"<br />
}"<br />
<br />
creation<br />
make<br />
<br />
feature<br />
make is<br />
do<br />
-- Memory is zeroed, so we probably don't need to initialize x and<br />
-- c. If we do, we'll have to call a C function to do it.<br />
use($Current)<br />
use_copy(Current)<br />
end<br />
<br />
use (x: POINTER) is<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
feature_name: "use"<br />
}"<br />
end<br />
<br />
use_copy (x: like Current) is<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
feature_name: "use_copy"<br />
}"<br />
end<br />
<br />
end<br />
<br />
Two variants (along with possible hybrids)<br />
<br />
=== Living at the edge of the Eiffel world ===<br />
* External classes always insert exactly ANY (and don't inherit from anything)<br />
* they can't be inherited from (and probably not inserted either)<br />
* they can't have ordinary Eiffel attributes.<br />
<br />
=== Ordinary Eiffel citizens ===<br />
* External classes can have Eiffel attributes<br />
* External classes can be inherited from and inserted<br />
* External classes ca, inherit from or insert other classes<br />
<br />
Likely to result in a very unclean implementation (need either to reorder the struct so that the external part is at the beginning, or to represent references to such objects as pointers 'into' the object (rather than to its head), or to mess with the pointer when passing it to the C world). Even more mess likely in case of multiple external parents.<br />
<br />
== Inline external classes ==<br />
Ok, so there are actually three mechanisms, but this one is hybrid between the previous two (give the external attribute an Eiffel type that doesn't need to be defined anywhere else)<br />
<br />
With this approach we can even allow this type for external features, which would solve the pass-by-value/reference question: do a copy or use a pointer to it.<br />
<br />
Issues:<br />
* What is the scope of such a type? Only visible in the class it is written in? Are two external types with the same "name" in different classes the same?<br />
<br />
class SHOW<br />
creation<br />
make<br />
<br />
feature<br />
make is<br />
do<br />
use($ext)<br />
copy_use(ext)<br />
end<br />
<br />
use (x: POINTER) is<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
feature_name: "use"<br />
}"<br />
end<br />
<br />
use_copy (x: like ext) is<br />
-- Here a copy of x would be passed<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
feature_name: "use_copy"<br />
}"<br />
end<br />
<br />
ext: external MY_STRUCT is -- inline declaration of external type<br />
external "plug_in"<br />
alias "{<br />
location: "./"<br />
module_name: "struct"<br />
attribute_type: "my_struct"<br />
}"<br />
end<br />
end<br />
<br />
= Helper functions =<br />
It must be possible for plugin writer to supply functions to help the Liberty Eiffel runtime implement a few of ANY's standard routines: standard_copy, deep_twin, standard_is_equal, deep_is_equal.<br />
<br />
== Optional vs. mandatory helpers ==<br />
Putting helpers could be made mandatory or optional (if a reasonable default can be found).<br />
<br />
=== Provide defaults where possible ===<br />
A reasonable default is to assume that the external types are shallow, so the helpers for deep_twin and deep_is_equal can be made optional (but the plugin writer can provide them if he wants a special treatment)<br />
<br />
Some backends may also be able to provide reasonable default helpers for standard_is_equal and standard_copy, making them optional. For other backends, the plugin-writer may have to provide one or both of the helpers. That may seem inconsistent but it's not really a problem as a plugin needs to be tested with every back-end it is supposed to work with anyway, so missing helpers will be detected. The C backend can generate a default copy function (using memcpy and sizeof), but it can't genereate a default equality testing function (the == operator can't be applied to structures, memcmp is unacceptable because two structures may differ only by garbage in the padding).<br />
<br />
=== Don't provide defaults at all ===<br />
Just throw an error if one of the helpers is missing.<br />
<br />
=== Provide silly defaults, emit a warning ===<br />
The default helpers just crash (with a run time stack if possible). Emit a warning if the plugin writer doesn't provide the required helpers.<br />
<br />
== Granularity ==<br />
The granularity could be one pack of helpers per Eiffel class or one pack of helpers per external type (obvisouly there's no difference if the "external classes" implementation is chosen).<br />
<br />
=== Eiffel class granularity ===<br />
The helpers are eiffel functions with "magical" names.<br />
<br />
=== External type granularity ===<br />
The helper's names appear inside the "alias" clause.<br />
<br />
= Relevance to backends =<br />
Depending on the backend, the mechanism can add real expressivity or be of the "sugar" variety.<br />
<br />
== C ==<br />
This is the only way to embed C structures into Eiffel objects. It also makes it easier to interact with C types that are typedef'd or #defined to a basic type that is not known in advance (up to now, plugin-writers had to guess if it would be e.g. an INTEGER_32 or an INTEGER_64).<br />
<br />
== Java ==<br />
All the basic types are already wrapped and there are no typedefs or #defines. Finally, it is not possible to embed Java objects, so the gain would be limited. At least it means that we ''could'' rewrite the wrappers for the basic types using external types if we had the time (less magic is always a good thing!), and the we can embed more precise references to java objects than just "Object".</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Lib/xml&diff=2516Lib/xml2016-07-03T06:48:45Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Library]]<br />
== XML parsing ==<br />
<br />
XML is used a lot these days, including by the library itself (the [[library_class:STORABLE|storable]] [[library_class:REPOSITORY|repository]] uses it, see [[lib/storage]]).<br />
<br />
=== The parser ===<br />
<br />
To use the XML parser, you need to proceed in two steps:<br />
# Connect the parser to an [[library_class:OUTPUT_STREAM|output stream]], using the <tt>[[library_class:XML_PARSER|XML_PARSER]].connect_to</tt> feature;<br />
# Parse the document by sending parsing events to the provided [[library_class:XML_CALLBACKS|events receiver]], using the <tt>[[library_class:XML_PARSER|XML_PARSER]].parse</tt> feature. Either you use a real events receiver, SAX-fashion (just inherit from [[library_class:XML_CALLBACKS|<tt>XML_CALLBACKS</tt>]]); or you can provide an [[library_class:XML_TREE|<tt>XML_TREE</tt>]], DOM-fashion (this tree implements the events receiver interface and builds its nodes when receiving events from the parser).<br />
<br />
=== Events interface ("SAX") ===<br />
<br />
[http://www.saxproject.org/ SAX] means "Simple API for XML". Liberty Eiffel's API is not exactly identical; nonetheless it resembles the API found in other languages.<br />
<br />
In this case, you have to inherit from [[library_class:XML_CALLBACKS|<tt>XML_CALLBACKS</tt>]] and implement its many deferred features.<br />
<br />
During the parsing, the [[library_class:XML_PARSER|XML parser]] calls that class to tell it it enters a node, finds some attribute, some text, and so on. Errors are also reported.<br />
<br />
=== Tree interface ("DOM") ===<br />
<br />
[http://www.w3.org/DOM/ DOM] means "Document Object Model". Liberty Eiffel's DOM implementation is not endorsed by W3C but its API is equivalent.<br />
<br />
To use an [[library_class:XML_TREE|XML tree]], you have to give it to the [[library_class:XML_PARSER|XML parser]]. The tree builds itself when called back by the parser's events.<br />
<br />
If there were no errors, the XML tree provides a <tt>root</tt> feature that is an [[library_class:XML_NODE|<tt>XML_NODE</tt>]].<br />
<br />
Errors can be managed by using the <tt>with_error_handler</tt> feature. The given agent will be called with the errors the parser finds.<br />
<br />
=== Small Comparison SAX vs. DOM ===<br />
<br />
Using one or the other is not only a matter of taste, but it also depends on where you put your priorities. In other words, you have to evaluate performance against simplicity.<br />
<br />
{| cellspacing="10px" width="100%"<br />
|- style="background-color: #fff3f3"<br />
|valign="top" align="center"| Topic<br />
|valign="top" align="center"| '''DOM'''<br />
|valign="top" align="center"| '''SAX'''<br />
|-<br />
|valign="center" align="center" style="background-color: #fff3f3"| Simplicity<br />
|valign="top"|Very simple: the whole tree is built in a preliminary pass and all the nodes are available for as long as needed afterwards.<br />
|valign="top"|Less simple: the parser provides a stream of events that have to be dealt with.<br />
On the other hand you have more control over which events are important and what you actually ''do'' with them.<br />
|-<br />
|valign="center" align="center" style="background-color: #fff3f3"| Memory<br />
|valign="top"|Memory hungry since objects are built to represent the whole tree<br />
|valign="top"|Not necessarily memory hungry since there is only a stream of feature calls. Of course you may need to create your own objects but that's up to you.<br />
|-<br />
|valign="center" align="center" style="background-color: #fff3f3"| Performance<br />
|valign="top"|The XML document is used in two passes:<br />
# create the tree (parse the whole document)<br />
# use the tree (navigate in the tree to find nodes of interest)<br />
|valign="top"|The XML document may be exploited in one pass since you have first-hand access to the events during the parsing.<br />
|}<br />
<br />
== Validation ==<br />
<br />
To validate an XML file, Liberty Eiffel provides a DTD parser. The XML parser may parse the provided DTD and validate your file.<br />
<br />
The parser recognizes any kind of DTD: inlined, in a file or on the network. You may also use a cache that locally provides network DTDs (see [[library_class:XML_DTD_PUBLIC_REPOSITORY|<tt>XML_DTD_PUBLIC_REPOSITORY</tt>]]).<br />
<br />
== Namespaces and other advanced features ==<br />
<br />
Namespaces are not yet natively implemented in Liberty Eiffel, but they will be added later ('''contributions welcome!!''')<br />
<br />
The idea is to implement some new kind of XML_CALLBACK that takes the semi-colon in nodes names into account.<br />
<br />
Schema validation (therefore using namespaces) may be set by calling <tt>[[library_class:XML_CALLBACKS|XML_CALLBACKS]].set_validator</tt>.<br />
<br />
Path parsing has to be implemented.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Generated_c_code&diff=2515Generated c code2016-07-03T06:48:04Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div> *** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I<br />
*** have noted some statements that are now obsolete in view of recent compiler changes.<br />
*** This article and its French counterpart need revising by the development team.<br />
<br />
*** You can also use [http://SmartEiffel.loria.fr/man/c_code.html the original article]<br />
<br />
People who want to interface with applications and/or libraries written in C should as far as possible limit themselves to the interfaces provided by [[Cecil]], [[externals|external]] and [[plugins]]. This page gives details about the generated C code, but these details ought not to be of any use to you. ;-)<br />
<br />
== The type identifiers ==<br />
<br />
=== Description ===<br />
<br />
Liberty Eiffel generates one unique identifying number for each active type in the Eiffel code<sup>[[Generated c code#note1|1]]</sup>. A lot of symbols in the generated C code depend on that identifier.<br />
<br />
'''Don't depend on those identifiers!''' The mangling table is only valid for one specific compilation of one specific application with one specific compiler version, for one compiler [[compile_to_c]] in one specific version and libraries in one specific version... We do not guarantee the stability of these identifiers.<br />
<br />
If ''27'' is an identifier, then:<br />
<br />
* The C type of an Eiffel object is '''T27''';<br />
* The corresponding C structure is '''struct&nbsp;S27'''; in that structure, the names of the attributes are prefixed with an underscore (there may be some other fields used by Liberty Eiffel, in particular, the <TT>id</TT> field, which in this case has the value 27). <br> Each reference type can be cast to <TT>T0</TT> (although some reference types may not have the <TT>id</TT> field).<br />
* Each method is called '''r27''method_name''()'''<br />
* Each prefix method is called '''r27_px_''method_name''()'''<br />
* Each infix method is called '''r27_ix_''method_name''()'''<br />
* Each late-binding method is called '''X27''method_name''()'''<br />
* The object's creation method (when the [[Garbage collector|garbage collector]] is used) is called '''new27()'''<br />
* The type model is a variable called '''M27'''. Models are used for initialisation. For example:<br />
T27 M27 = {27,NULL,NULL,0,0};<br />
...<br />
{T27*n=((T27*)se_malloc(sizeof(*n)));<br />
*n=M27;<br />
r27make(n);<br />
...<br />
<br />
Some characters in method names, such as <TT>"&lt;"</TT> or <TT>"+"</TT>, will be replaced by their corresponding ASCII code in decimal.<br />
<br />
=== An example ===<br />
<br />
For example: [[library_class:STRING|<TT>STRING</TT>]] has the identifier '''7'''<sup>[[Generated c code#note2|2]]</sup>. So:<br />
<br />
* The object type is '''T7'''.<br />
typedef struct S7 T7;<br />
* The structure is defined in '''struct&nbsp;S7'''.<br />
struct S7{Tid id;T9 _storage;t2 _count;t2 _capacity;};<br />
* The <TT>append</TT> method becomes:<br />
void r7append(se_dump_stack*caller,T7* C,T0* a1)<br />
(See below for details on the ''dump stack'' execution stack.)<br />
<br />
=== The <TT>.id</TT> file ===<br />
<br />
When the application is compiled, the list of identifiers is stored in a file whose name is suffixed <TT>.id</TT>. The file is reread in incremental compilations (which allows some stability in the identifiers, so long as the whole project is not recompiled).<br />
<br />
This file is structured in ''entries'', each entry being separated from others by a hash character (<TT>#</TT>). This file looks like this:<br />
<br />
5 "REAL"<br />
class-path: "/SmartEiffel/lib/numeric/real.e"<br />
class-name: REAL<br />
assertion-level: all<br />
parent-count: 1 inherit: 49<br />
#<br />
72 "FAST_ARRAY"<br />
class-path: "/SmartEiffel/lib/storage/collection/fast_array.e"<br />
class-name: FAST_ARRAY<br />
assertion-level: all<br />
parent-count: 1 inherit: 58<br />
#<br />
62 "STD_ERROR"<br />
class-path: "/SmartEiffel/lib/io/terminal/std_error.e"<br />
class-name: STD_ERROR<br />
assertion-level: all<br />
parent-count: 1 inherit: 39<br />
c-type: T62 reference: yes<br />
ref-status: live id-field: yes<br />
destination-graph-nodes: ->OUTPUT_STREAM<br />
run-time-set-count: 1<br />
run-time-set:<br />
STD_ERROR (62)<br />
#<br />
. . .<br />
<br />
You should never depend on these identifiers. In any case, when an identifier is computed, collisions may occur, and affect the process. Thus, the identifier and name of each type depends not only on the type name, but also on the order in which the types are compiled. That is, on the order of ''application'' and ''library'' types combined... They also depend on the compilation mode used (since that can change the list of active types), and the version of the compiler you're using. So what is <TT>T145</TT> today may be <TT>T234</TT> tomorrow<sup>[[Generated c code#note3|3]]</sup>!<br />
<br />
Consequently, '''do not ever rely on the generated identifiers, because they are not constant!''' Do not try to write in your own C code horrible things like <TT>new123</TT> or <TT>T456</TT>, because the only thing we can guarantee is that this code will not work.<br />
<br />
== Naming convention ==<br />
<br />
The preceding section has explained how methods are generated.<br />
<br />
The function prototype <TT>r7append()</TT> from the example above is presented as<br />
v7append(se_dump_stack*caller,T7* C,T0* a1);<br />
This shows how ''Current'' and the arguments are passed. The rules are as follows:<br />
<br />
* ''Current'' is called <TT>C</TT> and is always strongly typed (with its own exact type). This parameter may be omitted if Current is not used by the method. In some cases (when code is inlined), ''Current'' can be copied in local variables named <TT>C1</TT>, <TT>C2</TT>...<br />
* The arguments are called <TT>a1</TT>, <TT>a2</TT>... and are typed <TT>T0*</TT> for reference types or given their exact type for expanded types (e.g. <TT>T2</TT> for an integer)<br />
* Inside functions, a local variable <TT>R</TT> is defined. This is ''Result''.<br />
* Local variable keep their Eiffel name, prefixed by an underscore.<br />
<br />
=== Agent routines ===<br />
<br />
Functions of the form _T111C222l333c444 are agent creations.<br />
<br />
222 is the id of the class where the agent creation was written (look it up in <br />
the .id file);<br />
333 is the line number;<br />
444 is the column number.<br />
<br />
111 is a little more difficult to explain. It is the id of the type from which <br />
this agent creation will be executed. It can be the same as 222, but it will <br />
be different if 222 corresponds to a generic class, and it can also be <br />
different if a class inherits from 222.<br />
<br />
For example, function _T832C832l1362c106<br />
was declared in class #832, on<br />
line 1362 column 106.<br />
<br />
== The mangling table ==<br />
<br />
OK, now you understand why you cannot use type numbers, but you still want to know what those fields in the mangling table mean (in the <TT>.id</TT> file)>..<br />
<br />
First, a big caveat. Although it may have been very stable for quite some time now, '''the mangling table coding may change'''! We currently have no plans to change it, and we prefer keeping it the way it is. But once again: we do not commit ourselves to the current representation.<br />
<br />
Let's look again at the extract of a <TT>.id</TT> file. The part shown covers nearly all the possible cases:<br />
<br />
5 "REAL"<br />
class-path: "/SmartEiffel/lib/numeric/real.e"<br />
class-name: REAL<br />
assertion-level: all<br />
parent-count: 1 inherit: 49<br />
#<br />
72 "FAST_ARRAY"<br />
class-path: "/SmartEiffel/lib/storage/collection/fast_array.e"<br />
class-name: FAST_ARRAY<br />
assertion-level: all<br />
parent-count: 1 inherit: 58<br />
#<br />
62 "STD_ERROR"<br />
class-path: "/SmartEiffel/lib/io/terminal/std_error.e"<br />
class-name: STD_ERROR<br />
assertion-level: all<br />
parent-count: 1 inherit: 39<br />
c-type: T62 reference: yes<br />
ref-status: live id-field: yes<br />
destination-graph-nodes: ->OUTPUT_STREAM<br />
run-time-set-count: 1<br />
run-time-set:<br />
STD_ERROR (62)<br />
#<br />
. . .<br />
<br />
There is one entry per type (active or not); each entry spans many lines and is terminated by a hash symbol (<TT>#</TT>).<br />
<br />
Each entry contains a lot of information. Not all of it is always present; missing entries take default values.<br />
<br />
Only the first line is compulsory. It contains the type identifier, and its name (as would be returned by <TT>generating_type</TT>).<br />
<br />
The following lines contain different fields, marked by a keyword, a colon and a value. There may be one or more fields on a single line. Those fields are: <br />
<br />
{|<br />
|-<br />
| '''class-path'''<br />
| The path to the file containing the source code. May be omitted if the class has no associated file (uncommon).<br />
|-<br />
| '''class-name'''<br />
| The name of the class, as returned by <TT>generator</TT>.<br />
|-<br />
| '''parent-count'''<br />
| Le number of parents.<br />
|-<br />
| '''inherit'''<br />
| On the same line as '''parent-count''' if the latter is not null; it gives the list of parent class identifiers.<br />
|-<br />
| '''c-type'''<br />
| The C type, usually in the form '''T27'''. If it is omitted, the class has no runnable type.<br />
In that case, the following fields do not appear either.<br />
|-<br />
| '''reference'''<br />
| On the same line as '''c-type''', <TT>yes</TT> for a reference type or <TT>no</TT> for an expanded type.<br />
|-<br />
| '''ref-status'''<br />
| Either <TT>live</TT> for an active type (i.e. instances of this type are created at run-time), or <TT>dead</TT> otherwise.<br />
|-<br />
| '''id-field'''<br />
| On the same line as '''ref-status''', <TT>yes</TT> if the <TT>id</TT> field has to be generated in the C structure (as its first element), <TT>no</TT> otherwise. This field is present if one of these confitions is true:<br />
* some late binding may occur on targets of that type,<br />
* or the structure may be accessed by an [[external]] or by [[cecil]].<br />
Note that a lot of calls are statically computed; the type inference algorithm used in SmartEiffel increases the number of such types that do not need the id field.<br />
<br />
|-<br />
| '''destination-graph-nodes'''<br />
| ????? <!-- someone please write an explanation for this --><br />
|-<br />
| '''run-time-set-count'''<br />
| The number of concrete, active descendants of the type (including itself). This is the number of items in '''run-time-set''' below.<br />
|-<br />
| '''run-time-set'''<br />
| The concrete, active heirs of this type (including itself). One class per line, tab-indented.<br />
|}<br />
<br />
== The dump stack ==<br />
<br />
'''When not in boost mode''', a stack is managed by the runtime environment generated by Liberty Eiffel. This stack is displayed when an uncaught exception is raised. It is also used by the debugger [[sedb]].<br />
<br />
Technically, the Liberty Eiffel stack is built upon the native (C) stack. Each stack element is a <TT>se_dump_stack</TT><sup>[[Generated c code#note4|4]]</sup> usually allocated on the stack<sup>[[Generated c code#note5|5]]</sup>. It is made up of several parts:<br />
<br />
* a frame descriptor, of type <TT>se_frame_descriptor</TT><sup>[[Generated c code#note4|4]]</sup> which is a static description of the feature, as follows:<br />
** run type,<br />
** does it use Current,<br />
** number and type of the local variables, and<br />
** an anti-recursion flag (for contracts)...<br />
* a dynamic part:<br />
** a pointer to ''Current'' (i.e. either a pointer to an expanded object, or else a pointer to a reference object, it being a pointer to the object itself). That is why the type of the <TT>current</TT> field is <TT>Void**</TT>. This field will be <TT>NULL</TT> if ''Current'' is not used by the ''feature'',o<br />
** the position (used mainly by [[sedb]]),<br />
** a pointer to the caller (i.e. the <TT>se_dump_stack</TT> of the calling function),<br />
** a pointer to the exception origin: if not <TT>NULL</TT>, it means that this <TT>se_dump_stack</TT> ''is not'' in the stack, but was malloc'ed to preserve the exception stack trace,<br />
** an array of local variables (with double indirection as for ''Current''), hence the type void***.<br />
<br />
Macros handle the linking between the <TT>se_dump_stack</TT> frames.<br />
<br />
* Normally, the top of the dump stack is the global variable <TT>se_dst</TT> defined in <TT>SmartEiffel/sys/runtime/no_check.c</TT>. The macro <TT>set_dump_stack_top</TT> accomplishes the assignment of its argument in this variable.<br />
* In [[SCOOP]] mode, each processor has its own stack. So the <TT>set_dump_stack_top</TT> macro has two arguments: the processor and the new dump stack top.<br />
<br />
<br />
----<br />
<div id="note1">1. There is a bijection (a one to one relationship) between the number and the ''name'' of the type (including the value of its generic parameters in the case of generic types). </div><br />
<br />
<div id="note2">2. There are some identifiers that are reserved for "basic" types. They are:<br />
<br />
* '''0''': the type any other can be cast to<br />
* '''1''': [[library_class:INTEGER_8|<TT>INTEGER_8</TT>]]<br />
* '''2''': [[library_class:INTEGER|<TT>INTEGER</TT>]] (or [[library_class:INTEGER_32|<TT>INTEGER_32</TT>]])<br />
* '''3''': [[library_class:CHARACTER|<TT>CHARACTER</TT>]]<br />
* '''4''': [[library_class:REAL_32|<TT>REAL_32</TT>]]<br />
* '''5''': [[library_class:REAL_64|<TT>REAL_64</TT>]] (or [[library_class:REAL|<TT>REAL</TT>]])<br />
* '''6''': [[library_class:BOOLEAN|<TT>BOOLEAN</TT>]]<br />
* '''7''': [[library_class:STRING|<TT>STRING</TT>]]<br />
* '''8''': [[library_class:POINTER|<TT>POINTER</TT>]]<br />
* '''9''': [[library_class:NATIVE_ARRAY|<TT>NATIVE_ARRAY</TT>]]<TT>[</TT>[[library_class:CHARACTER|<TT>CHARACTER</TT>]]<TT>]</TT><br />
* '''10''': [[library_class:INTEGER_16|<TT>INTEGER_16</TT>]]<br />
* '''11''': [[library_class:INTEGER_64|<TT>INTEGER_64</TT>]]<br />
* '''12''': [[library_class:REAL_EXTENDED|<TT>REAL_EXTENDED</TT>]]<br />
<br />
<br />
So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').<br />
<br />
All [[library_class:NATURAL|<tt>NATURAL</TT>]] classes ([[library_class:NATURAL|NATURAL]], [[library_class:NATURAL_8|NATURAL_8]], [[library_class:NATURAL_16|NATURAL_16]], [[library_class:NATURAL_32|NATURAL_32]], [[library_class:NATURAL_64|NATURAL_64]] and [[library_class:NATURAL_GENERAL|NATURAL_GENERAL]]) does not have a fixed id.<br />
<br />
<br />
</div><br />
<br />
<div id="note3">3. The compiler will do its best not to change the identifiers uselessly. The <TT>.id</TT> file is loaded at the beginning of the compilation process, and saved again at its end. But [[clean]], for example, erases that file.</div><br />
<br />
<div id="note4">4. You can find the definition of these structures in the <TT>SmartEiffel/sys/runtime/c/no_check.h</TT> file.</div><br />
<br />
<div id="note5">5. The exception is when an exception is raised: in that case, part of the stack is allocated onto the heap before the <TT>longjmp</TT>. </div></div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Inlining&diff=2514Inlining2016-07-03T06:47:33Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Interfacing]]<br />
There exists a capability unique to Liberty Eiffel of putting C code in line. Of course, this method is only usable with [[compile_to_c]].<br />
<br />
Two methods <TT>c_inline_c</TT> and <TT>c_inline_h</TT> are defined in [[library_class:ANY|<TT>ANY</TT>]]. These two methods take a single parameter, a '''manifest''' character string.<br />
<br />
* <TT>c_inline_c</TT> inserts in line, at the appropriate spot in the generated feature, the C code of the character string;<br />
* <TT>c_inline_h</TT> inserts the C code of the character string in the Liberty Eiffel generated header file (<TT>.h</TT>).<br />
<br />
Use of these functions implies a precise knowledge of the Liberty Eiffel C code (and doesn't favour portability). '''We don't guarantee backwards compatibility with code using these two methods'''.<br />
<br />
If, despite all these warnings, you want to know more, read [[Generated c code|this page]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=C_code_generation&diff=2513C code generation2016-07-02T10:09:39Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>= General aspects =<br />
<br />
== Generated files ==<br />
<br />
When [[Compile to c|compiling to C]], Liberty Eiffel generates the following output:<br />
<br />
* One or more C files<br />
* A C header file, ''projectname''<tt>.h</tt>.<br />
* A type-to-id mapping file (see [[#Mapping types to IDs]] section below).<br />
* A C compilation script (''projectname''<tt>.make</tt> or ''projectname''<tt>.bat</tt> depending on the platform).<br />
<br />
If you are using the <code>-no_split</code> mode, all the C code will be put inside a ''projectname''<tt>.c</tt> file. Otherwise, code will be split in chunks (of more or less the same size) called ''projectnameN''<tt>.c</tt>, where ''N'' is a positive integer number. The number of chunks may vary depending on the size of the project.<br />
<br />
The compilation script will contain a list of commands to invoke the system C compiler and compile the relevant files with the proper flags (extracted from the command line, ACE file and/or [[Plugins|plugin]] options). It will only include compile commands for those C files which have no associated object file, or that have changed since the previous compilation. It will also contain a final linking command (to generate the executable) when any of the relevant C flags has changed.<br />
<br />
The Liberty Eiffel runtime (i.e., auxiliar routines to handle some mechanisms like garbage collection, exceptions, etc) and plugins are not linked, but embedded instead. That means that the code for those components will be embedded inside the .c/.h files. The runtime files are located in the <code>sys/runtime/c</code> directory of the compiler distribution. For example when compiling with the GC enabled, the file <code>sys/runtime/c/gc_lib.c</code> is copied verbatim into one of the generated ''projectN''<tt>.c</tt> and the file <code>sys/runtime/c/gc_lib.h</code> is copied verbatim into the ''projectN''<tt>.h</tt>.<br />
<br />
== Mapping types to IDs ==<br />
<br />
When compiling to C, every type existing in the system is assigned an ''id'', which is a unique positive integer number. This number is used in different parts of the C code instead of the actual type name. For example if the type ''STRING'' is assigned id 7, the feature is_equal of type ''STRING'' will be mapped to a C routine called <tt>r7is_equal</tt> (the 7 in the name comes from the type id).<br />
<br />
Note that ids are assigned to types and not to classes. Most of the time there is one type per class, but there can be possibly more types per class. For example, even if [[library_class:ARRAY|<tt>ARRAY</tt>]] is a single class, ''ARRAY[INTEGER]'' and ''ARRAY[STRING]'' are distinct types, and as such will get different ids.<br />
<br />
A few of the types based on library classes (all ''INTEGER*'', ''REAL*'', ''CHARACTER'', ''BOOLEAN'', ''POINTER'', ''NATIVE_ARRAY[CHARACTER]'' and ''STRING'') have a predefined, fixed id. For details on implementation of this fixed mapping, check the [[tool_class:ID_PROVIDER|<tt>ID_PROVIDER</tt>]] class, specially feature <tt>make</tt>.<br />
<br />
After compilation, the mapping of types to ids is stored in a text file called ''project''<tt>.id</tt>. This file is a useful help to read the generated C code. It is also used by the compiler itself when recompiling; the compiler uses it to keep the mapping between different runs. Maintaining the mapping helps to get similar generated code between compiler runs, which means that fewer C files need to be recompiled.<br />
<br />
= Mapping Eiffel types to C types =<br />
<br />
Not every type needs a direct C implementation. A lot of types are never instantiated, because they are deferred or just because the system never creates an instance of them. Types which are effectively used in the system are called "live" types. For each live type with id ''N'', a C type is created called <code>T</code>''N''. For some of the standard base types, the definition of the type is hardcoded in the compiler; for example, in your project <tt>.h</tt> file you will find:<br />
<br />
<code>typedef int32_t T2</code> ("2" is the id for ''INTEGER'')<br />
<br />
<code>typedef double T5</code> ("5" is the id for ''REAL_64'')<br />
<br />
For references (which might be polymorphic), the C type <code>T0</code> is defined, and references are of type <code>T0 *</code>.<br />
<br />
For most other live types, a C struct is used, where fields of the struct correspond to the attributes (proper and inherited) of the type. The struct of the type is called <code>struct S</code>''N''. For example, if the type <tt>STD_OUTPUT</tt> has id 38, you will get the following code in the <tt>.h</tt> file:<br />
<br />
<pre><br />
typedef struct S38 T38;<br />
/* ... */<br />
struct S38{Tid id;T0* _filter;T2 _buffer_position;T9 _buffer;T2 _capacity;};<br />
</pre><br />
<br />
Note that each field has the corresponding field name on Eiffel, preceded by an underscore (to avoid possible name clashes with C keywords, for example if you have a class with some field called "static" or "int"). The type of the field has the corresponding C type if the field is expanded: you can see in the struct above that the attribute <code>buffer_position</code> was declared as [[library_class:INTEGER_32|<tt>INTEGER</tt>]] whose type has id 2; <code>buffer</code> is of type <code>T9</code> because type id 9 was mapped to type ''NATIVE_ARRAY[CHARACTER]''. If the field is not of an expanded type, it is declared as a C field with type <code>T0 *</code>.<br />
<br />
Also note that there is an additional field <code>Tid id</code>. This field is an integer field containing the type id for this structure, in this case the field should always be set to 38. The field is used to identify the type in every case that a pointer (usually a <code>T0 *</code> may point to more than one type of structure). That happens not only when using polymorphism on the original source, but also when using some internal polymorphic functions existing in the stack-dump printing code and in the garbage collector. If the compiler decides that the <code>id</code> field is not needed (happens a lot on boost mode with no GC, but also in expanded types), the field is omitted.<br />
<br />
Now it is easy to explain the definition of type <code>T0</code>:<br />
<br />
<pre><br />
typedef struct S0 T0;<br />
struct S0{Tid id;};<br />
</pre><br />
<br />
Native arrays have a special, different implementation. The C type is defined as a a pointer to the element type. When the element type is a reference type, the mapping of that element type is a <code>T0 *</code> so:<br />
* ''NATIVE_ARRAY[CHARACTER]'' , with ''CHARACTER'' having type id 3, will be mapped to a <code>T3 *</code><br />
* ''NATIVE_ARRAY[STRING]'' , with ''STRING'' having type id 7, will be mapped to a <code>T0 **</code><br />
<br />
For each type, there is also an initialization constant defined to set the default values for the object. The constant to initialize values of type with id ''N'' is called <code>M</code>''N''. For default values, the constant gets a hardcoded value and is defined as a macro:<br />
<br />
<pre><br />
#define M5 (0.0) /* 5 is the id for REAL_64 */<br />
</pre><br />
<br />
For generic instantiations of [[library_class:NATIVE_ARRAY|<tt>NATIVE_ARRAY</tt>]], the default is also defined as a macro and is always <code>NULL</code>:<br />
<br />
<pre><br />
#define M9 NULL<br />
</pre><br />
<br />
For structures, the initial value is an <code>extern</code> variable defined at the <tt>.h</tt> file, with its value set at one of the <tt>.c</tt> files. The initial value sets the id field if present to the correct type id, while other fields are respectively set to their default values. for the example struct above, the initialization code is:<br />
<br />
<pre><br />
extern T38 M38; /* in the .h file */<br />
/* in the .c file */<br />
T38 M38={38,(void*)0,0,(void*)0,0};<br />
</pre><br />
<br />
(explain what happens when an type has no attributes)<br />
<br />
= Mapping Eiffel features to C code =<br />
<br />
== Routines ==<br />
<br />
Eiffel routines are mapped to C functions. For a routine in the type with id ''N'', called ''eiffel_name'', a C function called <code>r</code>''Neiffel_name'' is generated. That routine:<br />
* Is declared as <code>void</code> for procedures or has a return type of the obvious mapping type of the result for functions (that is <code>T0 *</code> for references, or <code>T</code>''N'' for expanded types).<br />
* Has an argument <code>se_dump_stack *caller</code>. This argument is used for describing the activation record of the caller routine; more details about this are given in the [[#Exception handling]] section. In boost mode, this information is not needed and this argument is removed.<br />
* Has an argument called <code>C</code> with the type of ''Current'' directly mapped. This is one of the few cases where references are not changed to <code>T0 *</code>, but the specific id is used even for reference types. Note that an expanded current will have a declaration of <code>Tnn C</code>, while a reference type will have a declaration of <code>Tnn *C</code>; this is because there is no possible polymorphism here. In a few cases, for routines that do not need information on the current instance, this argument is omitted.<br />
* Has arguments called <code>a1, a2, ...</code> for each of the arguments of the Eiffel routine. This arguments are mapped to C types in the usual way.<br />
<br />
Note that each routine in the Eiffel source may be remapped as multiple C functions, one per live descendant type (and generic variation). This happens even if there is no redefinition, because C types may be different for the same piece of Eiffel code (due to anchors, generics, and the change of Current). Note that when generating code for this routines, anchored types and generics are resolved to specific types and thus require no special handling.<br />
<br />
When there is a call and the compiler can statically decide the run time type of the call target, the call is mapped directly to one of these functions. When there is a possible polymorphic target, a "switching function" is generated. The switching function is called as <code>X</code>''Mname'', where M is the type id of the static target. This function has a similar prototype to the functions described above, but with <code>C</code> (the argument to pass ''Current'') declared as <code>T0 *</code> (note that polymorphic calls are always done on reference targets). The implementation of the function is a <code>switch</code> or nested <code>if</code>s, which call the corresponding <code>r</code>''P'' when the run-time type of the object is the one with id ''P'' (''P'' should be the id of a type which conforms to the type with id ''M''). The switching function may contain an argument called <code>position</code> in non-boost modes, with a codification of the source position of the call for error reporting purposes (see [[#Exception handling]]).<br />
<br />
In boost mode, some simplifications may be made. Specially, some routines are inlined instead of being mapped to a C function. The switching functions may be inlined too.<br />
<br />
== Attributes ==<br />
<br />
As seen before, Eiffel attributes have corresponding attributes in the C structures which represent instances. Attribute access is translated to structure field access when the type of the object can be decided at compile-time. However, an Eiffel expression <code>x.attr</code>, when the run-time type of <code>x</code> is not completely decided, can not be translated directly as field access, because the compiler doesn't know at compile time how to typecast the <code>T0 *</code> which represents <code>x</code>; and in fact a cast can not be done safely, because due to inheritance (possibly multiple), the attribute can be at different offsets in the structures that represent the possible live run time types of <code>x</code>.<br />
<br />
In those cases, a switching function is also generated. The branches on the switch check the live type and do the proper typecast and field access in each case.<br />
<br />
Note that this also generalizes to the cases where a query is implemented in some subtypes as a function and in other subtypes as an attribute. In those cases, the switching function has some branches doing function calls and other branches doing field access.<br />
<br />
== Once routines ==<br />
<br />
For once routines, one or more routines are generated like for other non-once routines. But also one or two global variables are generated: a flag to remember if the routine has already been called, and in the case of once functions a second one for the cached result. These two variables have in their name the id of the class where the once function is declared. By "id of a class", it actually means "the id of the type which directly represents the class" (which is always one because generic classes can not have once features declared directly on them).<br />
<br />
The flag variable is called <code>int fBC</code>''Mname'' (fBC means "flag at base class"); the cached result is called "<code>oBC</code>''Mname''" (once for base class), with the type mapped in the normal way. They are declared in the<tt>.h</tt> file, and initialized on one of the <tt>.c</tt> files. The routines in the live-types (which may be more than one, and their type ids of several of them will not be ''M''), will have code like:<br />
<br />
<pre><br />
if (fBCmmname==0) {<br />
fBCmmname=1; {<br />
/* translation of routine body here, using oBCmmname as `Result' */<br />
}}<br />
return oBCmmname; /* Only in functions */<br />
</pre><br />
<br />
Note that using the id of the base class and not of the live type ensures that the once results are effectively shared systemwide (once-per-system instead of once-per-live-type).<br />
<br />
== Implementing local variables and Result values ==<br />
<br />
Local variables in Eiffel routines are mapped one by one to local variables in the mapped C function. The C types used is the usual mapping (<code>T0 *</code> for references, <code>TN</code> for expanded types). Locals are declared an initialized at the top of the routine. The name of the local is the Eiffel name preceded by an underscore. So, if you have <code>local i:INTEGER; some_string: STRING</code>, the C code for implementations of that routine will have<br />
<br />
<pre><br />
T2 _i=0;<br />
T7 _some_string=(void *)0;<br />
</pre><br />
<br />
Additionaly, Eiffel functions get an additional local variable in the C code called <code>R</code>, which maps the Eiffel ''Result'' special variable. It is typed and initialized as any other local variable. Eiffel functions always get exactly one <code>return</code> statement in their C mapping, on their last line, saying <code>return R;</code>.<br />
<br />
An exception to the above are once functions. As mentioned [[#Once routines|before]], the result for that functions is a global variable. In that case, the <code>R</code> local is not declared, uses of ''Result'' in the Eiffel code are mapped to uses of the global variable, and the last line of the routine will be a <code>return oBCmmname;</code>.<br />
<br />
= Exception handling =<br />
<br />
== The managed stack ==<br />
<br />
Even if not required for implementing the rescue construct, Liberty Eiffel implements a "managed stack". This managed stack consists on extra information embedded on the execution stack, which is useful to provide debugging and backtrace information; it is also used for assertion checking. The managed stack is used in all compilation modes except for the boost mode.<br />
<br />
In C, for every function call executed a stack frame is allocated. The stack frame contains the function arguments, the local variables, and probably some machine-dependent and C compiler dependent information (for example, a return address). The order of these elements on the stack frame may also be variable between platforms. Liberty Eiffel adds some local variables to each routine which hold some metadata about the structure of those stack frames, for example:<br />
* which routine is the one corresponding to that frame<br />
* where are the locals and arguments located in the stack<br />
* where is each frame located in the call chain<br />
<br />
This information is stored in a local variable of every routine called <code>ds</code> of type <code>se_dump_stack</code>. A variable size part of the information is stored in another local variable called <code>locals</code>, which is a stack allocated array of pointers. A typical stack frame might look like this:<br />
<br />
[[Image:example frame.svg|center]]<br />
<br />
The image above shows heap-allocated objects in blue, stack allocated (expanded) objects in red, global runtime structures in green and stack allocated runtime info/pointers in white. The routine above uses ''Current'' in some way (because of the local variable <code>C</code>. It has two arguments (<code>a1, a2</code>) and the first one is of an expanded type (shown in red). It is a function returning some expanded type (it has an <code>R</code> variable), and it has two local variables, <code>local_exp</code> of an expanded type, and <code>local_ref</code> of some reference type.<br />
<br />
The local <code>ds</code> variable is initialized on routine entry. It has the following fields<br />
* <code>ds.fd</code> points to the frame descriptor. The frame descriptor is a structure declared as a local static variable (so, it is globally allocated and shared) and contains information shared by all the stack frames of the same routine (a string with the Eiffel routine name and class, number of arguments, etc).<br />
* <code>ds.current</code> is initialized to <code>&C</code>. This allows code using the data structure to get the value of ''Current'' in this stack frame. Note that the pointer points to the location of the <code>C</code> variable, which may be the current object if ''Current'' is of an expanded type, but usually will be again a pointer to the actual object. If the routine has no need for ''Current'', this value will be <code>NULL</code><br />
* <code>ds.p</code> is an integer value with an encoding of the position (file, line, column) inside the source Eiffel code which was last executed while this frame was active. See the [[#Encoding source positions|next section]] for details.<br />
* <code>ds.locals</code> is initialized to <code>&locals</code> or to <code>NULL</code> in the cases where <code>locals</code> is not needed (see below).<br />
* <code>caller</code> points to the <code>ds</code> local variable of the calling function. This value is passed on the <code>caller</code> argument added by the compiler to each routine.<br />
<br />
There is a global runtime variable called <code>se_dst</code> (SmartEiffel dump-stack top) which always points to the <code>se_dump_stack</code> of the currently running routine. So, starting from <code>se_dst</code> and following the <code>caller</code> attribute of the dump-stacks, you can follow a linked list of all the active routines in the call stack. For example if you compile a system with root class <code>ROOT</code> with id 37 and creation routine <code>make</code> and that routine calls some <code>routine1</code> of the same class, which calls the <code>item</code> function of string, at some point the link chain will look like this (stack grows towards the bottom of the figure):<br />
<br />
[[Image:call chain.svg|center]]<br />
<br />
== Encoding source positions ==<br />
<br />
For debugging purposes, it is useful to map positions in C code to source files. In the compiled C code, source positions are represented as an unsigned int. The implementation expects that the C int type has at least 32 bits.<br />
<br />
There are two ways of encoding positions, one that encodes just a file and a line number, and another one that also encodes a column number. The last bit of the value is 0 when there is an encoded column. The column number, if present, is in the following 7 least significant bits. Then, the line number comes (16 bits if no column present, or 13 bits otherwise). Finally, a file identifier is in the remaining bits. So the two possible layouts are (see http://smarteiffel.loria.fr/tools/api/tools.d/kernel.d/POSITION.html#mangling):<br />
<br />
* 15 bits for file id, 16 bits for line number, 1 bit set to 1<br />
* 11 bits for file id, 13 bits for line number, 7 bits for column number, 1 bit set to 0<br />
<br />
There are macros to decode positions in the <tt>no_check.h</tt> runtime header. They are used when printing tracebacks and error messages. The macros are called <code>se_position2*</code>. The mangling, in the compiler, is defined in the [[tool_class:POSITION|<tt>POSITION</tt>]] class.<br />
<br />
File ids are actually the same number as type ids. A globally allocated array <code>char *p[N]</code> is declared by the compilers where <code>N</code> is the highest type id. The routine <tt>initialize_eiffel_runtime</tt> assigns initial values to the elements of this array, in the style of <code>p[7]="/usr/lib/SmartEiffel/lib/string/string.e";</code>. Some assignments are also done aliasing the strings, for example <code>p[99]=p[88];</code> this happens when 99 and 88 are ids of two types which are actually based on the same class (due to genericity).<br />
<br />
On the generated C code, you will find a lot of encoded positions. Each time the compiler generates code for a piece of Eiffel source at a distinct position, an assignment <code>ds.p=0x<encoded>;</code> is inserted (usually with a human readable comment like <code>/*l133c5/string.e*/</code>). The assignment modifies the status of the current dump stack frame (see [[#The managed stack|previous section]]); in that way, if an exception triggers, there is detailed information about the source code positions for each of the routines in the stack.<br />
<br />
== Recovering from exceptions ==<br />
<br />
When an exception is triggered internally (a developer exception, assertion check, or internal checks like the one for Void targets) the <code>internal_exception_handler</code> is called. When an external signal is received, <code>signal_exception_handler</code> is called. Both behave similarly (the signal catcher does some platform specific signal handling stuff). If there is no rescue clause, they print a traceback (except in boost mode, which has no managed stack to print), and exits.<br />
<br />
When the program passes through a routine with a rescue handler, the information about the handler is added to a stack. When exiting one of those routines, the top of that stack is removed. The internal handlers know whether there is some rescue clause to catch the exception or not by looking if the stack is empty.<br />
<br />
The stack is implemented as a linked list of nodes stored locally, at the stack frames of routines with rescue clauses. The top of the stack is pointed by a global variable <code>rescue_context_top</code>, set to NULL when the stack is empty. Each node of the rescue stack is of type <code>rescue_context</code>, a structure containing the following fields:<br />
* <code>jb</code>, a jump buffer returned by the C function setjmp, which is used to jump back to the routine when handling the exception.<br />
* <code>next</code>, a pointer to the rescue context below, or NULL when we are at the bottom of the stack.<br />
* <code>top_of_ds</code>, a pointer to the managed stack frame of the routine which had this rescue close. This field is not present in boost mode, because there is no managed stack.<br />
<br />
Every routine containing a rescue class (or in a class with a redefined default_rescue feature) declares a variable called <code>rc</code> of type <code>struct rescue_context</code>. At the very beginning of the compiled routine, the <code>jb</code> field of this context is initialized, with a block like this:<br />
<br />
<code><br />
if(SETJMP(rc.jb)!=0){/*rescue*/<br />
... compiled rescue clause ...<br />
internal_exception_handler(Routine_failure);<br />
}<br />
</code><br />
<br />
This will set the jump buffer, so the body of the rescue clause is executed after a longjmp (which will happen on the event of an exception).<br />
The last line of the block describes the standard behaviour of propagating the routine failure if a rescue block ends without running a retry statement.<br />
<br />
After the rescue section at the beginning of the routine there is a C label called <code>retry_tag:</code>; the '''retry''' statement is implemented as a <code>goto retry_tag;</code>. Note that this means that SE is unable to retry from outside the routine (and the compiler actually checks that a retry statement is inside a rescue clause); this is a bit different to other Eiffel variants which allow retry instructions anywhere. Precondition checking is after this tag, so the check is actually done again if the rescue clause retries.<br />
<br />
After precondition checking, the rescue context is actually added to the stack context (which means that a precondition failure will trigger an outer rescue clause, not the rescue clause of the same routine with the rescue handler. The initialization looks like:<br />
<br />
<code><br />
rc.next = rescue_context_top;<br />
rescue_context_top = &rc;<br />
rc.top_of_ds=&ds;<br />
</code><br />
<br />
At the end of the routine, the context is removed:<br />
<br />
<code><br />
rescue_context_top = rc.next;<br />
</code><br />
<br />
Any exception produced internally (by assertion checking, void-checking, loop variants, etc.) is implemented by a call to the <code>internal_exception_handler</code> function, defined in sys/runtime/c/exceptions.c. Signals are handled by <code>signal_exception_handler</code> which is very similar. These functions do the folowing:<br />
<br />
# Setting some meta-information about the exception cause; specially global variables, <code>internal_exception_number</code> (exception cause, same constants as in class [[library_class:EXCEPTIONS|<tt>EXCEPTIONS</tt>]]), <code>signal_exception_number</code> (signal id when exception is caused by signal), <code>original_exception_number</code> (original cause of exception; preserved even when the final cause is usually "routine failure") and <code>additional_error_message</code> (sometimes some extra info, the assertion tag for assertions).<br />
# If <code>rescue_context_top == NULL</code> it means that there is no rescue clause to catch this. An error message and a stack trace (on non-boost mode) are printed, and the program ends with <code>exit (EXIT_FAILURE);</code>.<br />
# If <code>rescue_context_top != NULL</code>:<br />
## The top rescue context is stored in the variable <code>current_context</code><br />
## The top rescue context is removed from the top of the stack.<br />
## Assertion checking is reset, calling to <code>reset_assertion_checking</code>. See section on how assertion checking works for details.<br />
## It does a <code>longjmp()</code> to <code>current_context->jb</code>. This should send the control flow right into the rescue handler.<br />
<br />
== Printing tracebacks ==<br />
<br />
= Garbage Collection =</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Profile&diff=2512Profile2016-07-02T10:06:15Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Liberty Eiffel offers an ''embedded profiler''. That means that to use it, you have to compile your<br />
application with a special <TT>-profile</TT> option. The generated executable will then be equipped with the profiler and you can start your application in the normal way.<br />
<br />
Note: <TT>-profile</TT> is available only with [[compile_to_c]] (or [[compile]]).<br />
<br />
At the end of a program run, the profiler lets you obtain certain information about its execution.<br />
All this information is written into a file called <TT>profile.se</TT> in the current directory.<br />
<br />
== Results obtained ==<br />
<br />
The file <TT>profile.se</TT> is produced at the end of the program run, just before control is returned to the user.<br />
<br />
This file contains two kinds of information: execution times and a graph of feature calls.<br />
<br />
The information is presented first in summary and then in detail.<br />
<br />
Although it is human-readable, the file contains a great deal of information. It might be useful in the future to build a utility to extract some of this information.<br />
<br />
=== Execution graph ===<br />
<br />
For each function, the profiler gives the following data:<br />
* '''number of calls''': how often the function has been executed.<br />
* '''callers''': by which functions it has been called, and how many times.<br />
* '''callees''': which functions it has called, and how many times.<br />
<br />
=== Execution times ===<br />
<br />
Note: because it is embedded, the profiler ''slows the program down''; it is necessary to take this into account<br />
and regard the times reported as ''relative'', never as absolute times.<br />
<br />
For each function, the profiler displays two times:<br />
* '''cumul time''' (cumulative time) which is the total time spent in the function ''and the functions it calls''.<br />
* '''own time''' which is the time spent only in the function itself, apart from calls to other functions.<br />
<br />
Since the number of calls to each function is known, an average time is also given.<br />
<br />
The summary displays all the data together, sorted by ''own time''.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Performance&diff=2511Performance2016-07-02T10:05:55Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Performance]]<br />
==Very High Performance Programs==<br />
<br />
Eiffel is a beautiful method and language, based on strong and elegant principles. But, what interest (except intellectual pleasure) would you have in using a wonderful language with poor performance for writing your programs?<br />
<br />
Hopefully, Eiffel has been designed with performance in mind. Furthermore, the Liberty Eiffel compiler and the associated libraries are expressly designed to combine performance with expressivity.<br />
<br />
In the Eiffel language, expressivity is in the power of concepts. For example multiple inheritance and genericity are very powerful concepts, as are static type and dynamic type. This means that properly designed programs will be made with small code, this is '''global code compactness'''. On the other hand, there is '''no local code compactness'''. The Eiffel spirit is to make your code as legible as possible, because it is written once but is read many, many times (code is designed for change and reuse). So there is no point in using many unreadable abbreviations or symbols in order to save some keystrokes. Of course Eiffel code with its standard formatting rules needs many lines where other languages only need one line. The purpose is to achieve '''legibility''' because that is a prerequisite for code maintenance and reuse.<br />
<br />
To convince you, I'll just give one example:<br />
<br />
1000[p]s2[lip/dli%0=1dvsr]s12sid2%0=13sidvsr[dli%0=1lrli2+dsi!>.]ds.xd1<2<br />
<br />
Good luck to anyone who wants to understand this program in the ''dc'' language, reuse it, improve it or anything else! For the curious, you can run ''dc'' on any UNIX-like system and paste this code; it will print the prime number decomposition of the first value, which is 1000 here. How can you know the principles used here? Does the algorithm search from 2 each time? Does the program stop when the square root has been reached?<br />
<br />
Now, back to the performance aspect, you can see how Liberty Eiffel behaves on [http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=&ackermann=1&binarytrees=5&chameneos=5&message=4&fannkuch=3&fasta=3&harmonic=1&knucleotide=5&mandelbrot=4&nbody=3&nsieve=3&nsievebits=2&pidigits=2&random=1&regexdna=4&revcomp=3&spectralnorm=5&hello=0&sumcol=1&takfp=1&tcprequest=4 this site] (where code lines count are ignored because it is not a relevant design aspect, as shown above).<br />
<br />
NOTE: currently alioth.debian.org does not publish any data<br>pertaining to any Eiffel compiler. Perhaps we could take the<br>old SE code, improve on it where possible and re-submit..? /HZ<br />
<br />
Liberty Eiffel generates highly efficient code, doesn't it? In fact, we have many ideas for improving generated code. This means you can choose Liberty Eiffel now and expect your code to run even faster under future releases of the compiler!<br />
<br />
The main areas for improvement are generated code for dynamic linking, flow analysis and garbage collector. Of course, these projects will be much helped if they were funded!</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Lib/storage&diff=2510Lib/storage2016-07-02T10:04:31Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/ and typo</p>
<hr />
<div>[[Category:Library]]<br />
<br />
This library is one of the most essential ones of Liberty Eiffel. It is generally used along with [[lib/abilities]] because some classes require specific properties about objects they can contain. Most of the storage classes are also [[library_class:TRAVERSABLE|<tt>TRAVERSABLE</tt>]], and also supply [[library_class:ITERATOR|<tt>ITERATOR</tt>]] objects (see the [[lib/iterator]] library).<br />
<br />
The point here is to store objects. This implies not only to "remember" them, but also to "retrieve" them, of course. But everything is based on the ''way'' to retrieve a stored object.<br />
<br />
== Collections ==<br />
[[library_class:COLLECTION|Collections]] are classes that allow to store objects and recover them by using integers. The two most known implementations are available: arrays (contiguous storage of elements) and linked lists (storage of elements with references to other elements).<br />
<br />
The most useful classes are:<br />
* [[library_class:ARRAY|<tt>ARRAY</tt>]], the well-known array<br />
* [[library_class:RING_ARRAY|<tt>RING_ARRAY</tt>]], an array whose implementation is optimized for extensions at both ends<br />
* [[library_class:FAST_ARRAY|<tt>FAST_ARRAY</tt>]], an array whose lower bound is always 0<br />
* [[library_class:LINKED_LIST|<tt>LINKED_LIST</tt>]] and [[library_class:TWO_WAY_LINKED_LIST|<tt>TWO_WAY_LINKED_LIST</tt>]] are linked lists<br />
<br />
There are also [[library_class:COLLECTION2|two-]] and [[library_class:COLLECTION3|three-]]dimensional collections that allow to manipulate object matrices.<br />
<br />
== Dictionaries ==<br />
[[library_class:DICTIONARY|Dictionaries]] are classes that allow to store key-value couples. Thus a value is available with its key.<br />
<br />
One can say that collections are equivalent to dictionaries whose keys are integers, but the case of collections is kept because it is very frequent.<br />
<br />
There are several dictionary implementations, that use different properties of the keys to accelerate access to the elements without having to look through the whole dictionary.<br />
<br />
* If the keys are [[library_class:HASHABLE|<tt>HASHABLE</tt>]], one can use the [[library_class:HASHED_DICTIONARY|<tt>HASHED_DICTIONARY</tt>]] class that uses the <tt>hash_code</tt> of the keys.<br />
* If the keys are [[library_class:COMPARABLE|<tt>COMPARABLE</tt>]], one can use the [[library_class:AVL_DICTIONARY|<tt>AVL_DICTIONARY</tt>]] class that uses a balanced binary tree.<br />
* There is no implementation if the keys have none of these two properties.<br />
<br />
One will notice the [[library_class:BIJECTIVE_DICTIONARY|bijective dictionaries]] whose elements are all unique. One can also define an inverted bijective dictionary ''(planned class for the version 2.3)''.<br />
<br />
== Sets ==<br />
[[library_class:SET|Sets]] are classes that allow to store elements in a unique manner. The goal is not necessarily to retrieve them by a key, but to know how to ''look through'' the set of elements.<br />
<br />
As with dictionaries, there are two kinds of sets in accordance with the properties of the elements.<br />
<br />
* If the elements are [[library_class:HASHABLE|<tt>HASHABLE</tt>]], one can use the [[library_class:HASHED_SET|<tt>HASHED_SET</tt>]] classe that uses the <tt>hash_code</tt> of the elements.<br />
* If the elements are [[library_class:COMPARABLE|<tt>COMPARABLE</tt>]], one can use the [[library_class:AVL_SET|<tt>AVL_SET</tt>]] class that uses a balanced binary tree.<br />
* There is no implementation if the elements have none of these two properties.<br />
<br />
== Multi-sets ==<br />
<tt>MULTI_SET</tt>s are not yet implemented.<br />
<br />
== Queues and stacks ==<br />
The [[library_class:QUEUE|<tt>QUEUE</tt>]] class implements queues of objects.<br />
<br />
The [[library_class:STACK|<tt>STACK</tt>]] class implements stacks of objects.<br />
<br />
== Repositories ==<br />
[[library_class:REPOSITORY|Repositories]] allow to store objects so as to retrieve them later. The point here is to ''serialize'' objects. This is useful, for example, to store objects on the hard drive (by using [[lib/io]]), or to transmit them on the network (by using [[lib/net]]), etc.<br />
<br />
These repositories behave like dictionaries whose keys are [[library_class:STRING|strings]] and values are [[library_class:STORABLE|<tt>STORABLE</tt>]]. Their interface is similar to the one of the dictionaries, with additional features to load objects (<tt>update</tt>) and store them (<tt>commit</tt>).<br />
<br />
There is a single implementation of repository: the [[library_class:XML_REPOSITORY|<tt>XML_REPOSITORY</tt>]] class that transforms objects into an XML stream (using [[lib/xml]]).</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Dynamic_type_testing&diff=2509Dynamic type testing2016-06-27T17:45:14Z<p>Dkearns: Typo</p>
<hr />
<div>Sometimes, you need to decide at run-time if a variable <br />
(or [[Glossary#Expression|expression]]) refers to an instance of a specific class or type.<br />
Well, it is almost always better to rely on [[dynamic dispatch]], but, in some situations, it can be necessary<br />
to explicitly test the [[Glossary#DynamicType|dynamic type]] of some expression.<br />
While other languages provide a cast operator to do (unsafe) type casting, Liberty Eiffel provides you three operators for doing that:<br />
the <br />
[[#AssignmentTest|<tt>?:=</tt>]] assignment test operator, <br />
the [[#ForcedAssignment|<tt>::=</tt>]] forced assignment statement as well as the <br />
traditional [[#AssignmentAttempt|<tt>?=</tt>]] assignment attempt statement.<br />
<br />
For some examples about dynamic type testing, check also the <br />
<tt>tutorial/downcasting.e</tt> file.<br />
<br />
Please note that assignment testing cannot be used with [[Expanded_or_reference|expanded types]], for which [[dynamic dispatch]] is not applicable.<br />
<br />
<div id="AssignmentTest"><br />
== The <tt>?:=</tt> assignment test ==<br />
</div><br />
The assignment test <tt>?:=</tt> is a [[library_class:BOOLEAN|<tt>BOOLEAN</tt>]] expression<br />
allowing you to check if the given right-hand side expression refers to an object which conforms to<br />
some explicitly written type.<br />
As an example, you can use the <tt>?:=</tt> operator as follows to check that <br />
some <tt>expression</tt> actually holds an instance which could be assigned to some <br />
variable declared with <tt>SOME_TYPE</tt>:<br />
if {SOME_TYPE} ?:= expression then<br />
print ("The 'expression' denotes something which can be held by the variable declared of type SOME_TYPE.")<br />
else<br />
print ("Something else which is non Void.")<br />
end<br />
It evaluates <tt>expression</tt> and returns <tt>True</tt> if the resulting object <br />
can be legally assigned to some variable declared of type <tt>SOME_TYPE</tt>. <br />
To take now a more concrete example using existing types of our library:<br />
if {FAST_ARRAY[INTEGER]} ?:= my_collection then<br />
print ("Expression 'my_collection' is either Void or conforms to FAST_ARRAY[INTEGER].")<br />
else<br />
print ("Something else which is non Void.")<br />
end<br />
In the previous example, <tt>my_collection</tt> is declared of type <br />
[[library_class:COLLECTION|<tt>COLLECTION</tt>]]<tt>[</tt>[[library_class:INTEGER|<tt>INTEGER</tt>]]<tt>]</tt>.<br />
As explained below, [[library_class:COLLECTION|<tt>COLLECTION</tt>]]<tt>[</tt>[[library_class:STRING|<tt>STRING</tt>]]<tt>]</tt> would make the previous code <br />
invalid thus rejected by the compiler.<br />
<br />
To avoid testing impossible situations which are probably coding mistakes, one cannot use any <br />
type for the right-hand side of a <tt>?:=</tt> test expression.<br />
The rule is simple and naturally related to the rule used for an ordinary assignment <br />
(the common well known <tt>:=</tt> assignment).<br />
Consider the following general example:<br />
if {SOME_TYPE} ?:= some_expression then<br />
...<br />
else<br />
...<br />
end<br />
The check performed by the compiler is that an expression of type <tt>SOME_TYPE</tt> could be <br />
legally assigned to some variable declared of the <br />
[[Glossary#StaticType|static type]] of <tt>some_expression</tt>.<br />
Actually, this simply means that you trust the type system and that you really want to reject <br />
invalid or, to say the least, weird code.<br />
Because of the redefinition mechanism, the validation check for the <tt>?:=</tt> operator is only <br />
performed at the class where it appears, and is '''not''' revalidated in subtypes even if they <br />
redefine the static type of <tt>some_expression</tt>.<br />
The latest decision was driven by our experimentations. <br />
We made this decision because the strict rule would reject mostly valid situations.<br />
Similar checks are performed for all other statements of the same family <br />
(the [[#ForcedAssignment|<tt>::=</tt>]] statement <br />
and the [[#AssignmentAttempt|<tt>?=</tt>]] statement).<br />
<br />
As we have seen previously, the left-hand side operand of the <tt>?:=</tt> type test can be some <br />
explicit type name.<br />
The second form of the <tt>?:=</tt> test operator is to be used in place of the <br />
explicit type, some [[Syntax diagrams#Writable|writable]] entity as in:<br />
if my_variable ?:= expression then<br />
...<br />
else<br />
...<br />
end<br />
which evaluates to <tt>True</tt> iff the actual content of <tt>expression</tt> <br />
''could be assigned'' to <tt>my_variable</tt>.<br />
Note that the assignment is '''not''' performed.<br />
This variant avoids the need to repeat the static type of <tt>my_variable</tt> here.<br />
It is also because the <tt>?:=</tt> type test operator is often used in conjunction with <br />
the [[#ForcedAssignment|<tt>::=</tt>]] forced assignment.<br />
<br />
<div id="ForcedAssignment"><br />
<br />
== The <tt>::=</tt> forced assignment ==<br />
</div><br />
The <tt>::=</tt> forced assignment statement allows you to actually perform an assignment<br />
proved valid at runtime with a corresponding [[#AssignmentTest|<tt>?:=</tt>]] assignment <br />
test.<br />
As an example, the following code would always work without any possible <br />
runtime error:<br />
if destination_variable ?:= source_variable then<br />
destination_variable ::= source_variable<br />
else<br />
-- Handle this case specially...<br />
end<br />
Actually, the <tt>?:=</tt> test can be considered as the precondition of the <tt>::=</tt> part.<br />
In non <tt>-boost</tt> mode, when some <tt>::=</tt> statement is executed but does not<br />
satisfy the <tt>?:=</tt> condition, you get an error at runtime.<br />
In <tt>-boost</tt> mode no runtime check is performed and the runtime cost of a <br />
<tt>::=</tt> statement is exactly the runtime cost of a common <br />
<tt>:=</tt> statement.<br />
A very low cost indeed.<br />
Usage of <tt>::=</tt> can be slightly more efficient (and result in simpler code) than <br />
similar code using the traditional [[#AssignmentAttempt|<tt>?=</tt>]] assignment attempt.<br />
Besides, it helps debugging because it will raise an exception when your assumption is not <br />
correct.<br />
<br />
As explained for the [[#AssignmentTest|<tt>?:=</tt>]] assignment test, one can not use <br />
any combination of static types.<br />
The same checks are performed for the <tt>::=</tt> statement.<br />
To summarize checks that are performed, please consider:<br />
my_variable ::= expression<br />
The entity <tt>my_variable</tt> must be a valid [[Syntax diagrams#Writable|writable]].<br />
The declaration type of <tt>my_variable</tt> must be a possible valid source type of some <br />
normal assignment into some destination variable declared with the <br />
[[Glossary#StaticType|static type]] of <tt>expression</tt>.<br />
Finally, the check in performed only where the <tt>::=</tt> is written.<br />
<br />
<div id="AssignmentAttempt"><br />
<br />
== The <tt>?=</tt> assignment attempt ==<br />
</div><br />
The traditional assignment attempt <tt>?=</tt> statement is still supported for <br />
historical reasons.<br />
Indeed, now that we have both the <br />
[[#AssignmentTest|<tt>?:=</tt>]] assignment test and<br />
the [[#ForcedAssignment|<tt>::=</tt>]] forced assignment<br />
statement, the <tt>?=</tt> statement is no longer necessary.<br />
In the long-term future, let's say, one or two years, usage of <br />
<tt>?:=</tt> and <tt>::=</tt> may become the preferred coding style.<br />
Again, there is no rush, and the traditional <br />
<tt>?=</tt> will be supported for some more years.<br />
From a compiler writer's point of view, the support for <tt>?=</tt> is really cheap because<br />
it is implemented in terms of <tt>?:=</tt> and <tt>::=</tt>.<br />
<br />
Furthermore, it is easy and elegant to explain <tt>?=</tt> as a simple <br />
source code transformation using only <tt>?:=</tt> and <tt>::=</tt>.<br />
Consider the following <tt>?=</tt> usage:<br />
destination_variable ?= source_variable<br />
If the value of <tt>source_variable</tt> cannot be legally assigned<br />
to <tt>destination_variable</tt>, the <tt>destination_variable</tt> will be set to <br />
[[Void|<tt>Void</tt>]] instead of the value of the <tt>source_variable</tt>.<br />
Note that if <tt>source_variable</tt> actually contains <tt>Void</tt>, <br />
<tt>destination_variable</tt> will always be reset with <tt>Void</tt>.<br />
Finally, the previous <tt>?=</tt> example can be translated into<br />
the equivalent form:<br />
if destination_variable ?:= source_variable then<br />
destination_variable ::= source_variable<br />
else<br />
destination_variable := Void<br />
end<br />
Note that the previous transformation scheme may not work for all kinds of <br />
right-hand side [[Glossary#Expression|expressions]]<br />
because the transformation scheme incurs two evaluations of the right-hand side<br />
part.<br />
To be valid, the previous transformation scheme assumes that the right-hand side <br />
expression incurs no [[Glossary#SideEffect|side effect]].<br />
Anyway, this transformation scheme is just here to explain the semantic of<br />
the <tt>?=</tt> statement and not as a general translation scheme to patch <br />
your (not so obsolete) code.<br />
<br />
As explained for the [[#AssignmentTest|<tt>?:=</tt>]] assignment test,<br />
one can not use any combination of [[Glossary#StaticType|static type]] on <br />
both sides of <tt>?=</tt> operator.<br />
The very same kind of checks are performed for the <tt>?=</tt> statement.<br />
To summarize checks, now consider:<br />
my_variable ?= expression<br />
The entity <tt>my_variable</tt> must be a valid [[Syntax diagrams#Writable|writable]].<br />
The declaration type of <tt>my_variable</tt> must be a possible source type of some normal<br />
assignment into some destination variable declared with the <br />
[[Glossary#StaticType|static type]] of <tt>expression</tt>.<br />
Finally, as usual the check is performed only where the <tt>?=</tt> statement is written.<br />
<br />
Assuming that type <tt>TRUCK</tt> and type <tt>APPLE</tt> are completely distinct types (i.e.<br />
you are not allowed to perform an assignment of <tt>TRUCK</tt> into <tt>APPLE</tt><br />
nor of <tt>APPLE</tt> into <tt>TRUCK</tt>), the following assignment attempt is statically<br />
rejected, which is good news:<br />
my_apple ?= my_truck -- hopefully this is statically rejected!<br />
You can always workaround by using the following trick:<br />
a_any := a_truck<br />
an_apple ?= a_any -- This is valid, APPLE conforms to ANY<br />
The example above is clearly a weird one, but you could need something like this if you have two <br />
unrelated classes with a common heir. And at least the code shows that you know what you are doing.<br />
This situation should arise in extremely rare situations only, that are not worth to be explained <br />
here.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Dynamic_type_testing&diff=2508Dynamic type testing2016-06-27T17:40:16Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Sometimes, you need to decide at run-time if a variable <br />
(or [[Glossary#Expression|expression]]) refers to an instance of a specific class or type.<br />
Well, it is almost always better to rely on [[dynamic dispatch]], but, in some situations, it can be necessary<br />
to explicitly test the [[Glossary#DynamicType|dynamic type]] of some expression.<br />
While other languages provide a cast operator to do (unsafe) type casting, Liberty Eiffel provides you three operators for doing that:<br />
the <br />
[[#AssignmentTest|<tt>?:=</tt>]] assignment test operator, <br />
the [[#ForcedAssignment|<tt>::=</tt>]] forced assignment statement as well as the <br />
traditional [[#AssignmentAttempt|<tt>?=</tt>]] assignment attempt statement.<br />
<br />
For some examples about dynamic type testing, check also the <br />
<tt>tutorial/downcasting.e</tt> file.<br />
<br />
Please note that assignment testing cannot be used with [[Expanded_or_reference|expanded types]], for which [[dynamic dispatch]] is not applicable.<br />
<br />
<div id="AssignmentTest"><br />
== The <tt>?:=</tt> assignment test ==<br />
</div><br />
The assignment test <tt>?:=</tt> is a [[library_class:BOOLEAN|<tt>BOOLEAN</tt>]] expression<br />
allowing you to check if the given right-hand side expression refers to an object which conforms to<br />
some explicitly written type.<br />
As an example, you can use the <tt>?:=</tt> operator as follows to check that <br />
some <tt>expression</tt> actually holds an instance which could be assigned to some <br />
variable declared with <tt>SOME_TYPE</tt>:<br />
if {SOME_TYPE} ?:= expression then<br />
print ("The 'expression' denotes something which can be held by the variable declared of type SOME_TYPE.")<br />
else<br />
print ("Something else which is non Void.")<br />
end<br />
It evaluates <tt>expression</tt> and returns <tt>True</tt> if the resulting object <br />
can be legally assigned to some variable declared of type <tt>SOME_TYPE</tt>. <br />
To take now a more concrete example using existing types of our library:<br />
if {FAST_ARRAY[INTEGER]} ?:= my_collection then<br />
print ("Expression 'my_collection' is either Void or conforms to FAST_ARRAY[INTEGER].")<br />
else<br />
print ("Something else which is non Void.")<br />
end<br />
In the previous example, <tt>my_collection</tt> is declared of type <br />
[[library_class:COLLECTION|<tt>COLLECTION</tt>]]<tt>[</tt>[[library_class:INTEGER|<tt>INTEGER</tt>]]<tt>]</tt>.<br />
As explained below, [[library_class:COLLECTION|<tt>COLLECTION</tt>]]<tt>[</tt>[[library_class:STRING|<tt>STRING</tt>]]<tt>]</tt> would make the previous code <br />
invalid thus rejected by the compiler.<br />
<br />
To avoid testing impossible situations which are probably coding mistakes, one cannot use any <br />
type for the right-hand side of a <tt>?:=</tt> test expression.<br />
The rule is simple and naturally related to the rule used for an ordinary assignment <br />
(the common well known <tt>:=</tt> assignment).<br />
Consider the following general example:<br />
if {SOME_TYPE} ?:= some_expression then<br />
...<br />
else<br />
...<br />
end<br />
The check performed by the compiler is that an expression of type <tt>SOME_TYPE</tt> could be <br />
legally assigned to some variable declared of the <br />
[[Glossary#StaticType|static type]] of <tt>some_expression</tt>.<br />
Actually, this simply means that you trust the type system and that you really want to reject <br />
invalid or, to say the least, weird code.<br />
Because of the redefinition mechanism, the validation check for the <tt>?:=</tt> operator is only <br />
performed at the class where it appears, and is '''not''' revalidated in subtypes even if they <br />
redefine the static type of <tt>some_expression</tt>.<br />
The latest decision was driven by our experimentations. <br />
We made this decision because the strict rule would reject mostly valid situations.<br />
Similar checks are performed for all other statements of the same family <br />
(the [[#ForcedAssignment|<tt>::=</tt>]] statement <br />
and the [[#AssignmentAttempt|<tt>?=</tt>]] statement).<br />
<br />
As we have seen previously, the left-hand side operand of the <tt>?:=</tt> type test can be some <br />
explicit type name.<br />
The second form of the <tt>?:=</tt> test operator is to be used in place of the <br />
explicit type, some [[Syntax diagrams#Writable|writable]] entity as in:<br />
if my_variable ?:= expression then<br />
...<br />
else<br />
...<br />
end<br />
which evaluates to <tt>True</tt> iff the actual content of <tt>expression</tt> <br />
''could be assigned'' to <tt>my_variable</tt>.<br />
Note that the assignment is '''not''' performed.<br />
This variant avoids the need to repeat the static type of <tt>my_variable</tt> here.<br />
It is also because the <tt>?:=</tt> type test operator is often used in conjunction with <br />
the [[#ForcedAssignment|<tt>::=</tt>]] forced assignment.<br />
<br />
<div id="ForcedAssignment"><br />
<br />
== The <tt>::=</tt> forced assignment ==<br />
</div><br />
The <tt>::=</tt> forced assignment statement allows you to actually perform an assignment<br />
proved valid at runtime with a corresponding [[#AssignmentTest|<tt>?:=</tt>]] assignment <br />
test.<br />
As an example, the following code would always work without any possible <br />
runtime error:<br />
if destination_variable ?:= source_variable then<br />
destination_variable ::= source_variable<br />
else<br />
-- Handle this case specially...<br />
end<br />
Actually, the <tt>?:=</tt> test can be considered as the precondition of the <tt>::=</tt> part.<br />
In non <tt>-boost</tt> mode, when some <tt>::=</tt> statement is executed but does not<br />
satisfy the <tt>?:=</tt> condition, you get an error at runtime.<br />
In <tt>-boost</tt> mode no runtime check is performed and the runtime cost of a <br />
<tt>::=</tt> statement is exactely the runtime cost of a common <br />
<tt>:=</tt> statement.<br />
A very low cost indeed.<br />
Usage of <tt>::=</tt> can be slightly more efficient (and result in simpler code) than <br />
similar code using the traditional [[#AssignmentAttempt|<tt>?=</tt>]] assignment attempt.<br />
Besides, it helps debugging because it will raise an exception when your assumption is not <br />
correct.<br />
<br />
As explained for the [[#AssignmentTest|<tt>?:=</tt>]] assignment test, one can not use <br />
any combination of static types.<br />
The same checks are performed for the <tt>::=</tt> statement.<br />
To summarize checks that are performed, please consider:<br />
my_variable ::= expression<br />
The entity <tt>my_variable</tt> must be a valid [[Syntax diagrams#Writable|writable]].<br />
The declaration type of <tt>my_variable</tt> must be a possible valid source type of some <br />
normal assignment into some destination variable declared with the <br />
[[Glossary#StaticType|static type]] of <tt>expression</tt>.<br />
Finally, the check in performed only where the <tt>::=</tt> is written.<br />
<br />
<div id="AssignmentAttempt"><br />
<br />
== The <tt>?=</tt> assignment attempt ==<br />
</div><br />
The traditional assignment attempt <tt>?=</tt> statement is still supported for <br />
historical reasons.<br />
Indeed, now that we have both the <br />
[[#AssignmentTest|<tt>?:=</tt>]] assignment test and<br />
the [[#ForcedAssignment|<tt>::=</tt>]] forced assignment<br />
statement, the <tt>?=</tt> statement is no longer necessary.<br />
In the long-term future, let's say, one or two years, usage of <br />
<tt>?:=</tt> and <tt>::=</tt> may become the preferred coding style.<br />
Again, there is no rush, and the traditional <br />
<tt>?=</tt> will be supported for some more years.<br />
From a compiler writer's point of view, the support for <tt>?=</tt> is really cheap because<br />
it is implemented in terms of <tt>?:=</tt> and <tt>::=</tt>.<br />
<br />
Furthermore, it is easy and elegant to explain <tt>?=</tt> as a simple <br />
source code transformation using only <tt>?:=</tt> and <tt>::=</tt>.<br />
Consider the following <tt>?=</tt> usage:<br />
destination_variable ?= source_variable<br />
If the value of <tt>source_variable</tt> cannot be legally assigned<br />
to <tt>destination_variable</tt>, the <tt>destination_variable</tt> will be set to <br />
[[Void|<tt>Void</tt>]] instead of the value of the <tt>source_variable</tt>.<br />
Note that if <tt>source_variable</tt> actually contains <tt>Void</tt>, <br />
<tt>destination_variable</tt> will always be reset with <tt>Void</tt>.<br />
Finally, the previous <tt>?=</tt> example can be translated into<br />
the equivalent form:<br />
if destination_variable ?:= source_variable then<br />
destination_variable ::= source_variable<br />
else<br />
destination_variable := Void<br />
end<br />
Note that the previous transformation scheme may not work for all kinds of <br />
right-hand side [[Glossary#Expression|expressions]]<br />
because the transformation scheme incurs two evaluations of the right-hand side<br />
part.<br />
To be valid, the previous transformation scheme assumes that the right-hand side <br />
expression incurs no [[Glossary#SideEffect|side effect]].<br />
Anyway, this transformation scheme is just here to explain the semantic of<br />
the <tt>?=</tt> statement and not as a general translation scheme to patch <br />
your (not so obsolete) code.<br />
<br />
As explained for the [[#AssignmentTest|<tt>?:=</tt>]] assignment test,<br />
one can not use any combination of [[Glossary#StaticType|static type]] on <br />
both sides of <tt>?=</tt> operator.<br />
The very same kind of checks are performed for the <tt>?=</tt> statement.<br />
To summarize checks, now consider:<br />
my_variable ?= expression<br />
The entity <tt>my_variable</tt> must be a valid [[Syntax diagrams#Writable|writable]].<br />
The declaration type of <tt>my_variable</tt> must be a possible source type of some normal<br />
assignment into some destination variable declared with the <br />
[[Glossary#StaticType|static type]] of <tt>expression</tt>.<br />
Finally, as usual the check is performed only where the <tt>?=</tt> statement is written.<br />
<br />
Assuming that type <tt>TRUCK</tt> and type <tt>APPLE</tt> are completely distinct types (i.e.<br />
you are not allowed to perform an assignment of <tt>TRUCK</tt> into <tt>APPLE</tt><br />
nor of <tt>APPLE</tt> into <tt>TRUCK</tt>), the following assignment attempt is statically<br />
rejected, which is good news:<br />
my_apple ?= my_truck -- hopefully this is statically rejected!<br />
You can always workaround by using the following trick:<br />
a_any := a_truck<br />
an_apple ?= a_any -- This is valid, APPLE conforms to ANY<br />
The example above is clearly a weird one, but you could need something like this if you have two <br />
unrelated classes with a common heir. And at least the code shows that you know what you are doing.<br />
This situation should arise in extremely rare situations only, that are not worth to be explained <br />
here.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Sedb&diff=2507Sedb2016-06-26T19:48:15Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Tool]]<br />
The Liberty Eiffel debugger is an ''Embedded debugger''. This means that in order to use it, you need to compile your application with a special flag <TT>-sedb</TT>. The executable will then have the debugger inside, you can launch your application the usual way.<br />
<br />
Note: <TT>sedb</TT> is only available with [[compile_to_c]] (or [[compile]]).<br />
<br />
The debugger offers powerful commands which allows you to examine the bowels of your program:<br />
* commands to control execution,<br />
* commands to set or unset breakpoints,<br />
* commands to print your data,<br />
* other various commands.<br />
<br />
== Execution control ==<br />
<br />
These commands allow your program to execute. You can either run step by step or make bigger strides, or even force execution until the end.<br />
<br />
Whatever your choice is, the program will run until the next breakpoint (see below), or until the next <TT>^C</TT>.<br />
<br />
The available commands are (in increasing order of step size):<br />
<br />
{|<br />
|-<br />
|valign="top"| <TT>s</TT>&nbsp;<br />
| Move only one ''step'' forward. This means entering a routine if the step is a [[Glossary#Feature|feature]] call.<br />
|-<br />
|valign="top"| <TT>n</TT>&nbsp;<br />
| Move only one step forward (next), but without entering a routine (this means that a [[Glossary#Feature|feature]] call is considered as one step).<br />
|-<br />
|valign="top"| <TT>f</TT>&nbsp;<br />
| Move to the next routine return (finish).<br />
|-<br />
|valign="top"| <TT>c</TT>&nbsp;<br />
| Move as far as possible (continue), perhaps even to the end of the program.<br />
|-<br />
|valign="top"| <TT>C</TT>&nbsp;<br />
| Continue until the end of the program, ignoring all breakpoints (whether static or dynamic).<br />
|}<br />
<br />
== Breakpoints ==<br />
<br />
There are two kinds of breakpoints:<br />
* those explicitly placed in the code, with the instruction <TT>sedb_breakpoint</TT>,<br />
* those dynamically placed in the debugger. To modify dynamic breakpoints, you can use the following commands:<br />
<br />
{|<br />
|-<br />
|valign="top"| <TT>b</TT>&nbsp;<br />
| Add a dynamic breakpoint. There are many possible criteria, described below. All chosen criteria must be valid to activate the breakpoint.<br />
|-<br />
|valign="top"| <TT>B</TT>&nbsp;<br />
| Print all dynamic breakpoints.<br />
|-<br />
|valign="top"| <TT>-&lt;num&gt;</TT>&nbsp;<br />
| Remove a dynamic breakpoint designated by its number. The numbers are printed by the <TT>B</TT> command.<br />
|}<br />
<br />
=== The <TT>sedb_breakpoint</TT> instruction===<br />
<br />
The <TT>sedb_breakpoint</TT> instruction is defined in [[library_class:ANY|<TT>ANY</TT>]]. It places a static breakpoint directly in the Eiffel source. This command does nothing if the program is not compiled with the <TT>-sedb</TT> flag.<br />
<br />
These breakpoints cannot be removed by the <TT>-&lt;num&gt;</TT> command. The only way to ignore them is to use the <TT>C</TT> command (continue until the end of the program).<br />
<br />
=== Specifications of a dynamic breakpoint ===<br />
<br />
To set up a dynamic breakpoint, you can specify one or more criteria.<br />
* '''Name''': the name of the method and the class name in which the method is defined, separated by a space, for example <TT>"item STRING"</TT>. You can specify a substring of this name. Thus, if you specify <TT>item</TT>, the program will stop at the beginning of the <TT>item</TT> method of [[library_class:STRING|<TT>STRING</TT>]], but also at the beginning of the one in [[library_class:ARRAY|<TT>ARRAY</TT>]], etc. Similarly, if you specify <TT>STRING</TT>, the program will stop when encountering any method of [[library_class:STRING|<TT>STRING</TT>]], but also of [[library_class:HASHED_DICTIONARY|<TT>HASHED_DICTIONARY</TT>]]<TT>[</TT>[[library_class:STRING|<TT>STRING</TT>]]<TT>, </TT>[[library_class:INTEGER|<TT>INTEGER</TT>]]<TT>]</TT>. You can even be original: I will let you guess the behaviour of the <TT>is_</TT> specification :-)<br />
* '''File''': for example, <TT>string.e</TT>. As the file name is applied to the complete path, you can specify <TT>lib/kernel</TT> which will stop at all the methods in the classes of that cluster.<br />
* '''Line numbers''': you can specify a range of lines, for example <TT>[12,13]</TT>.<br />
* '''Execution stack''': this condition lets you track the size of the execution stack (useful for debugging a recursive function, for example). For instance, you can specify a stack size limit of <TT>10</TT>, which will stop the execution when the stack size reaches 10. An optional automatic increment permits the limit to be incremented each time the breakpoint is reached. If you don't use this option, this breakpoint can be a good way to track the stack's memory consumption.<br />
<br />
Of course, all these specifications are cumulative: they must all be true at the same time to activate the breakpoint.<br />
<br />
== Data printing ==<br />
<br />
The following commands allow to print the data of your program:<br />
<br />
{|<br />
|-<br />
|valign="top"| <TT>e&nbsp;&lt;exp&gt;</TT>&nbsp;<br />
| Evaluates and prints the result of an expression. '''Note that''' the general Eiffel expressions are not supported.<br />
|-<br />
|<br />
| Only the following can be printed:<br />
* ''Current''<br />
* local variables<br />
* a parameter of the current routine<br />
* the content of an instance of a [[library_class:NATIVE_ARRAY|<TT>NATIVE_ARRAY</TT>]]; suffixing the attribute name with a dot and an index beginning at zero prints the contents of the specified array element. For example <TT>storage.2</TT> prints the ''third'' element of <TT>storage</TT>.<br />
* the attributes of these objects, by using the classical notation with dots (for example <TT>my_string.count</TT> or <TT>my_string.storage.4</TT>), recursively<br />
* the result of [[Syntax_diagrams#RoutineBody|<TT>once</TT> functions]], provided that they have already been evaluated (i.e. the debugger does not execute the function call; it only checks the result)<br />
|-<br />
|valign="top"| <TT>p</TT><br />
<br />
<TT>p&nbsp;&lt;exp&gt;</TT>&nbsp;<br />
| Re-evaluates the last expression by suffixing a dot and the expression <TT>&lt;exp&gt;</TT> (if present). This is very useful for chain printing. Instead of a single dot you can also use the notation <TT>..</TT> which goes one level up, <TT>....</TT> which goes two levels up, etc.<br />
|-<br />
|<br />
| Example of the use of <TT>e</TT> and <TT>p</TT>&nbsp;:<br />
sedb> e Current<br />
STD_OUTPUT#0x807ab00<br />
[ filter = Void<br />
buffer_position = 0<br />
buffer = NATIVE_ARRAY[CHARACTER]#0x806c030<br />
capacity = 4096<br />
]<br />
sedb> e buffer<br />
NATIVE_ARRAY[CHARACTER]#0x806c030<br />
sedb> p.0<br />
(sedb) e buffer.0<br />
'H'<br />
sedb> p..1<br />
(sedb) e buffer.1<br />
'e'<br />
sedb> p....buffer_position<br />
(sedb) e buffer_position<br />
0<br />
sedb><br />
|-<br />
|valign="top"| <TT>.</TT>&nbsp;<br />
| Print the current frame; that is the content of the local variables of the current routine.<br />
|-<br />
|valign="top"| <TT>u</TT>&nbsp;<br />
| Goes up in the stack (i.e. goes to the caller). This means that the calling routine becomes the ''current routine''. Note that the <TT>e</TT>, <TT>p</TT> and <TT>.</TT> commands follow the current routine.<br />
|-<br />
|valign="top"| <TT>d</TT>&nbsp;<br />
| Goes down in the stack (opposite of <TT>u</TT>).<br />
|-<br />
|valign="top"| <TT>S</TT>&nbsp;<br />
| Prints the execution stack. There are two printing modes:<br />
* compact mode which only prints the name of the file and executed routine; an asterisk indicates the current routine<br />
* complete mode which prints the entire stack, with all frames (as the printed stack when a program crashes outside sedb).<br />
|}<br />
<br />
== Various commands ==<br />
<br />
{|<br />
|-<br />
|valign="top"| <TT>q</TT>&nbsp;<br />
| Quits the debugger; the program will be stopped. You can also use <TT>Q</TT> which doesn't ask for confirmation.<br />
|-<br />
|valign="top"| <TT>h</TT><br />
<br />
<TT>?</TT>&nbsp;<br />
| Prints help.<br />
|-<br />
|valign="top"| <TT>H</TT>&nbsp;<br />
| Prints detailed help.<br />
|-<br />
|valign="top"| <TT>G</TT>&nbsp;<br />
| Runs the [[Garbage_collector|garbage collector]], if it is present.<br />
|-<br />
|valign="top"| <TT>T</TT>&nbsp;<br />
| Changes the trace mode, if it is present (flag <TT>-trace</TT> when compiling). If the mode is active, the file <TT>trace.se</TT> fills up (very quickly!)<br />
|-<br />
|valign="top"| ''Return''&nbsp;<br />
| Re-executes the last command.<br />
|}</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Syntax_diagrams&diff=2506Syntax diagrams2016-06-26T19:47:03Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Syntax diagrams for the whole Liberty Eiffel language.<br />
<br />
All items in alphabetical order:<br />
[[#Assignment|Assignment]],<br />
[[#Assertion|Assertion]],<br />
[[#BinaryOperator|Binary_operator]],<br />
[[#Call|Call]],<br />
[[#Check|Check]],<br />
[[#ClassDeclaration|Class_declaration]],<br />
[[#ClassName|Class_name]],<br />
[[#ClassType|Class_type]],<br />
[[#Clients|Clients]],<br />
[[#Comment|Comment]],<br />
[[#Compound|Compound]],<br />
[[#CreateExpression|Create_expression]],<br />
[[#CreateInstruction|Create_instruction]],<br />
[[#CreationClause|Creation_clause]],<br />
[[#Current|Current]],<br />
[[#Debug|Debug]],<br />
[[#Digit|Digit]],<br />
[[#Digit_sequence|Digit_sequence]],<br />
[[#EntityDeclarationList|Entity_declaration_list]],<br />
[[#Expression|Expression]],<br />
[[#FeatureClause|Feature_clause]],<br />
[[#FeatureDeclaration|Feature_declaration]],<br />
[[#FeatureName|Feature_name]],<br />
[[#FormalGenericList|Formal_generic_list]],<br />
[[#IfThenElse|If_then_else]],<br />
[[#InfixOperator|Infix_operator]],<br />
[[#Inspect|Inspect]],<br />
[[#Instruction|Instruction]],<br />
[[#Loop|Loop]],<br />
[[#ManifestNotation|Manifest_notation]],<br />
[[#ManifestString|Manifest_string]],<br />
[[#NewExportItem|New_export_item]],<br />
[[#Notes|Notes]],<br />
[[#ParentList|Parent_list]],<br />
[[#PrefixOperator|Prefix_operator]],<br />
[[#Result|Result]],<br />
[[#Routine|Routine]],<br />
[[#RoutineBody|Routine_body]],<br />
[[#Type|Type]],<br />
[[#UnaryOperator|Unary_operator]],<br />
[[#UnqualifiedCall|Unqualified_call]],<br />
[[#Writable|Writable]].<br />
<br />
<HR><BR><br />
<div id="Notes"><br />
==Notes==<br />
A Notes section might be used at the beginning and end of a file to define notes on a class (e. g. for documentation, version management, license information, etc.). The have no influence on the execution semantics.<br />
<ebnf> "Notes" {Notes = "note" Note_list.<br />
Note_list = Note_entry ";" [Note_list] .<br />
Note_entry = Note_name Note_values .<br />
Note_name = Identifier ":".<br />
Note_values = Note_item "," [Note_value].<br />
Note_item = Identifier | Manifest_constant.<br />
}</ebnf><br />
<br />
</div><br />
<div id="Comment"><br />
<br />
==Comment==<br />
A comment is made of one or more line segments, each beginning with two consecutive <br />
dash characters <TT>--</TT> and extending to the end of the line:<br />
<br />
<ebnf> "Comment" { Comment = "--" {String} {Newline}.}</ebnf><br />
<br />
Inside the comment, the convention to denote Eiffel entities (i.e. variables,<br />
arguments or other features as well) is to enclose the corresponding name<br />
between ` and ' as follows:<br />
-- Here `my_variable' is supposed to be bla bla bla ...<br />
This convention allows some tools like [[Eiffeldoc]] or [[Short]] or emacs <br />
as well to use a different character font or color to emphasize the fact that<br />
<TT>my_variable</TT> refers to some existing entity of the Eiffel code.<br />
Previous convention must not be used for [[#Class_name|class names]] which are<br />
to be typed normally in comments as:<br />
-- My FOO clas is bla bla bla bla ...<br />
<br />
Also note that an URL inside the comment is also made automatically clickable <br />
by [[Eiffeldoc]].<br />
This way, each time some class of our library needs a long explanation that does<br />
not reasonably fit in the Eiffel comment itself, we just add the URL into the <br />
comment.<br />
As an example, the following comment displayed by Eiffeldoc would <br />
bring you back here :<br />
-- See also http://wiki.liberty-eiffel.org/index.php/Syntax_diagrams#Comment<br />
<div id="ClassDeclaration"><br />
<br />
==Class declaration==<br />
</div><br />
[[Image:SyntaxDiagramOf_Class_declaration.png|Class_declaration]]<br />
<br />
'''Related items''': <br />
[[#Assertion|Assertion]],<br />
[[#Class_name|Class_name]],<br />
[[#Creation_clause|Creation_clause]],<br />
[[#Feature_clause|Feature_clause]],<br />
[[#Formal_generic_list|Formal_generic_list]],<br />
[[#Manifest_string|Manifest_string]],<br />
[[#Parent_list|Parent_list]].<br />
<br />
<div id="FormalGenericList"><br />
==Formal generic list==<br />
</div><br />
[[Image:SyntaxDiagramOf_Formal_generic_list.png|Formal_generic_list]]<br />
<br />
To be used only when the class is generic.<br />
The ''Identifier'' is not the name of an existing class, but usually, just a simple <br />
upper case letter (see also [[#ClassName|Class_name]]).<br />
The ''Class_type'' part, when used, is the generic constraint.<br />
<br />
'''Related items''': [[#ClassType|Class_type]], [[#Identifier|Identifier]].<br />
<br />
<div id="ParentList"><br />
==Parent list==<br />
</div><br />
[[Image:SyntaxDiagramOf_Parent_list.png|Parent_list]]<br />
<br />
'''Related items''': [[#FeatureName|Feature_name]], [[#NewExportItem|New_export_item]].<br />
<br />
<div id="NewExportItem"><br />
==New export item==<br />
</div><br />
[[Image:SyntaxDiagramOf_New_export_item.png|New_export_item]]<br />
<br />
'''Related items''': [[#ClassName|Class_name]].<br />
<br />
<div id="CreationClause"><br />
==Creation clause==<br />
</div><br />
[[Image:SyntaxDiagramOf_Creation_clause.png|Creation_clause]]<br />
<br />
'''Related items''': [[#FeatureName|Feature_name]], [[#Comment|Comment]].<br />
<br />
<div id="FeatureClause"><br />
==Feature clause==<br />
</div><br />
[[Image:SyntaxDiagramOf_Feature_clause.png|Feature_clause]]<br />
<br />
'''Related items''': [[#Clients|Clients]], [[#Comment|Comment]], [[#FeatureDeclaration|Feature_declaration]].<br />
<br />
<div id="Clients"><br />
==Clients==<br />
</div><br />
[[Image:SyntaxDiagramOf_Clients.png|Clients]]<br />
<br />
'''Related items''': [[#ClassName|Class_name]].<br />
<br />
<div id="FeatureDeclaration"><br />
==Feature declaration==<br />
</div><br />
'is' is now optional, and the choice after 'is' now could include 'attribute' diagram requires update...<br />
[[Image:SyntaxDiagramOf_Feature_declaration.png|Feature_declaration]]<br />
<br />
Where the ''Manifest_constant'' can only be selected in the following set:<br />
<TT>{</TT><br />
<TT>BOOLEAN</TT>, <br />
<TT>CHARACTER</TT>, <br />
<TT>INTEGER_8</TT>,<br />
<TT>INTEGER_16</TT>,<br />
<TT>INTEGER_32</TT>,<br />
<TT>INTEGER</TT>,<br />
<TT>INTEGER_64</TT>,<br />
<TT>REAL_32</TT>,<br />
<TT>REAL_64</TT>,<br />
<TT>REAL</TT>,<br />
<TT>REAL_80</TT>,<br />
<TT>REAL_128</TT>,<br />
<TT>REAL_EXTENDED</TT>,<br />
<TT>STRING</TT>, <br />
<TT>UNICODE_STRING</TT><br />
<TT>}</TT>.<br />
See the file <TT>SmartEiffel/tutorial/manifest_notation.e</TT> to have a <br />
detailed explaination plus examples about all available notations for <br />
constants.<br />
<br />
'''Related items''': [[#EntityDeclarationList|Entity_declaration_list]], [[#FeatureName|Feature_name]], [[#Routine|Routine]], <br />
[[#Type|Type]].<br />
<br />
<div id="Routine"><br />
<br />
==Routine==<br />
</div><br />
[[Image:SyntaxDiagramOf_Routine.png|Routine]]<br />
<br />
'''Related items''': [[#Assertion|Assertion]], [[#Compound|Compound]], [[#EntityDeclarationList|Entity_declaration_list]], <br />
[[#FeatureName|Feature_name]], [[#ManifestString|Manifest_string]].<br />
<br />
<div id="RoutineBody"><br />
==Routine body==<br />
</div><br />
<ebnf> "Routine body" {<br />
Routine_body = ( "deferred" | "do" compound | "once" compound | <br />
"external_string" Manifest_string "Alias" Manifest_string ).<br />
}</ebnf><br />
<br />
'''Related items''': [[#Compound|Compound]], [[#ManifestString|Manifest_string]].<br />
<br />
<div id="EntityDeclarationList"><br />
<br />
==Entity declaration list==<br />
</div><br />
[[Image:SyntaxDiagramOf_Entity_declaration_list.png|Entity_declaration_list]]<br />
<br />
This notation is used for local variable list declaration as well<br />
as for formal argument list of routines.<br />
<br />
'''Related items''': [[#Identifier|Identifier]], [[#Type|Type]].<br />
<br />
<div id="Type"><br />
<br />
==Type==<br />
</div><br />
[[Image:SyntaxDiagramOf_Type.png|Type]]<br />
<br />
'''Related items''': [[#ClassType|Class_type]], [[#FormalGenericName|Formal_generic_name]], [[#Identifier|Identifier]].<br />
<br />
<div id="ClassName"><br />
===Class name===<br />
</div><br />
A class name must use '''only upper case letters''' plus the '_' underscore character.<br />
A class name must start with a letter, an upper case letter as all other letters used in <br />
that name.<br />
The convention is to not use two consecutive '_' underscore characters, nor to end a class name by an underscore character (by convention we keep simple names with a trailing underscore character, like <TT>O_</TT> as a formal parameter type of a generic type).<br />
Some examples of valid class names: <br />
<TT>ARRAY</TT>,<br />
<TT>ANY</TT>,<br />
<TT>LINKED_LIST</TT>.<br />
<br />
<div id="ClassType"><br />
<br />
===Class type===<br />
</div><br />
[[Image:SyntaxDiagramOf_Class_type.png|Class_type]]<br />
<br />
A class type does not use anchored types.<br />
<br />
'''Related items''': [[#ClassName|Class_name]].<br />
<br />
<div id="BinaryOperator"><br />
<br />
==Digit==<br />
<ebnf> "Digit" {<br />
Digit = ("0"|"1"|"..."|"9"|"a"|"b"|"..."|"f"|"A"|"B"|"..."|"F"|"_" ). }<br />
</ebnf><br />
<br />
==Digit_sequence==<br />
<ebnf> "Digit_sequence" {<br />
Digit_sequence = Digit {Digit}.<br />
}<br />
</ebnf><br />
<br />
==Binary operator==<br />
</div><br />
Following operators can be redefined in your own class:<br />
<br />
<ebnf> "Binary operator" {<br />
Binary_operator = (("+"|"-"|"*"|"/"|"//"|"\\")| <br />
("<"|">"|"<="|">=")|<br />
("and"|"or"|"xor")| <br />
("and then"|"or else"|"implies")).}</ebnf><br />
<br />
<br />
<div id="InfixOperator"><br />
<br />
==Infix operator==<br />
</div><br />
<ebnf> "Infix operator" {<br />
Infix_operator = (Binary_operator|Free_operator).}</ebnf><br />
<br />
'''Related items''': [[#BinaryOperator|Binary_operator]], [[#FreeOperator|Free_operator]].<br />
<br />
<br />
<div id="PrefixOperator"><br />
<br />
==Prefix operator==<br />
</div><br />
<ebnf> "Prefix operator" {<br />
Prefix_operator = (Unary_operator|Free_operator).}</ebnf><br />
<br />
'''Related items''': [[#UnaryOperator|Unary_operator]], [[#FreeOperator|Free_operator]].<br />
<br />
<br />
<div id="UnaryOperator"><br />
<br />
==Unary operator==<br />
</div><br />
<br />
<ebnf> "Unary operator" {<br />
Unary_operator = ("+"|"-"|"not").}</ebnf><br />
<br />
<br />
<br />
<div id="FreeOperator"><br />
<br />
==Free operator==<br />
<ebnf><br />
"Free_Operator" { Free_Operator = ( "+" | "-" | "*" | "/" | "\" | "=" |<br />
"<" | ">" | "@" | "#" | "|" |"&" | "~") { Free_Operator }.}<br />
</ebnf><br />
<br />
==Writable==<br />
</div><br />
What we call ''Writable'' here is what can be for example on <br />
the left-hand-side of the <TT>:=</TT> assignment operator.<br />
You have only 3 choices:<br />
* the name of one local variable of the enclosing [[Glossary#Method|method]],<br />
* the <TT>Result</TT> variable used to prepare the return value of the enclosing [[Glossary#Function|function]],<br />
* the name of one writable [[Glossary#attribute|attribute]] of [[Current]]. <br />
<br />
<div id="FeatureName"><br />
==Feature name==<br />
</div><br />
[[Image:SyntaxDiagramOf_Feature_name.png|Feature_name]]<br />
<br />
'''Related items''': [[#InfixOperator|Infix_operator]], [[#PrefixOperator|Prefix_operator]].<br />
<br />
<div id="Compound"><br />
==Compound==<br />
</div><br />
[[Image:SyntaxDiagramOf_Compound.png|Compound]]<br />
<br />
'''Related items''': [[#Instruction|Instruction]].<br />
<br />
<div id="Instruction"><br />
<br />
==Instruction==<br />
</div><br />
[[Image:SyntaxDiagramOf_Instruction.png|Instruction]]<br />
<br />
'''Related items''':<br />
[[#Assignment|Assignment]], <br />
[[#Call|Call]], <br />
[[#Check|Check]],<br />
[[#Create_instruction|Create_instruction]],<br />
[[#Debug|Debug]],<br />
[[#IfThenElse|If_then_else]],<br />
[[#Inspect|Inspect]],<br />
[[#Loop|Loop]],<br />
[[#Retry|Retry]].<br />
<br />
<div id="Assignment"><br />
===Assignment===<br />
</div><br />
[[Image:SyntaxDiagramOf_Assignment.png|Assignment]]<br />
<br />
'''Related items''': [[#Expression|Expression]], [[#Writable|Writable]].<br />
<br />
<div id="Call"><br />
===Procedure call or function call===<br />
</div><br />
[[Image:SyntaxDiagramOf_Call.png|Call]]<br />
<br />
'''Related items''': [[#Expression|Expression]], [[#UnqualifiedCall|Unqualified_call]].<br />
<br />
<div id="Loop"><br />
===Loop: the only construct for iterative computation===<br />
</div><br />
[[Image:SyntaxDiagramOf_Loop.png|Loop]]<br />
<br />
'''Related items''':<br />
[[#Assertion|Assertion]],<br />
[[#Compound|Compound]],<br />
[[#Expression|Expression]].<br />
<br />
<div id="IfThenElse"><br />
===If then else statement===<br />
</div><br />
[[Image:SyntaxDiagramOf_If_then_else.png|If_then_else]]<br />
<br />
'''Related items''':<br />
[[#Assertion|Assertion]],<br />
[[#Compound|Compound]],<br />
[[#Expression|Expression]].<br />
<br />
<div id="Inspect"><br />
<br />
===Inspect: the multi-branch selection statement===<br />
</div><br />
[[Image:SyntaxDiagramOf_Inspect.png|Inspect]]<br />
<br />
The order in which the <TT>when</TT> branches are written does not influence<br />
the effect of an <TT>inspect</TT> instruction.<br />
<br />
Also note that the ''Expression'' can only be of type <br />
<TT>INTEGER</TT>, <TT>CHARACTER</TT> or <TT>STRING</TT>.<br />
All used ''Constant''s must have the same type as the type of ''Expression''.<br />
Furthermore, all constants must be statically computable in order to allow <br />
the compiler to check for disjunction of various <TT>when</TT> parts (only one <br />
''Compound'' is ever selected).<br />
<br />
By writing no <TT>else</TT> part at all (no keyword <TT>else</TT> used),<br />
you state that ''Expression'' doe NEVER take a value not covered by the inspect constants.<br />
If your expectations prove wrong, the effect is to trigger a run-time error<br />
when the code is compiled with appropriate options, in boost mode the behavior is unspecified. Therefore it is suggested to always write an else clause as defensive programming.<br />
<br />
'''Related items''':<br />
[[#Expression|Expression]],<br />
[[#Compound|Compound]].<br />
<br />
<div id="CreateInstruction"><br />
<br />
===Create instruction===<br />
</div><ebnf> "Create_Instruction" {<br />
Create_Instruction = create ["{"Type"}"] writable ["." Unqualified_call].<br />
}<br />
</ebnf><br />
<br />
See also the [[#CreateExpression|Create_expression]] variant form. <br />
<br />
'''Related items''': [[#Type|Type]], [[#UnqualifiedCall|Unqualified_call]], [[#Writable|Writable]].<br />
<br />
<div id="Check"><br />
<br />
===Check list===<br />
</div><br />
A <TT>check</TT> instruction helps express a property that you believe will be satisfied<br />
whenever system execution reaches this instruction.<br />
<br />
<ebnf> "Check" {<br />
Check = "check" Assertion "end".<br />
}<br />
</ebnf><br />
<br />
'''Related items''': [[#Assertion|Assertion]].<br />
<br />
<div id="Debug"><br />
<br />
===Debug only compound===<br />
</div><br />
The <TT>Debug</TT> instruction serves to request the conditional execution of a certain <br />
sequence of [[#Instruction|Instructions]], depending on a compilation option.<br />
<br />
[[Image:SyntaxDiagramOf_Debug.png|Debug]]<br />
<br />
'''Related items''':<br />
[[#Compound|Compound]],<br />
[[#Instruction|Instruction]].<br />
<br />
<div id="Retry"><br />
===Retry for exceptions===<br />
</div><br />
The <TT>retry</TT> instruction is only for exceptions purpose and<br />
the <TT>retry</TT> statement is valid only when used inside the rescue clause <br />
of some enclosing [[Glossary#Routine|routine]].<br />
The form of this instruction is just:<br />
<br />
<ebnf> "Retry" {Retry = "retry".}</ebnf><br />
<br />
<br />
The effect of a the <TT>retry</TT> instruction is to restart ''nearly from scratch'' <br />
the execution of the enclosing [[Glossary#Routine|routine]].<br />
Actually, even the require assertion of the routine is re-checked.<br />
Only local variables (including <TT>Result</TT>) are not reset to the default value.<br />
<br />
<div id="Expression"><br />
<br />
==Expression==<br />
</div><br />
<br />
[[Image:SyntaxDiagramOf_Expression.png|Expression]]<br />
<br />
'''Related items''':<br />
[[#BinaryOperator|Binary_operator]],<br />
[[#Call|Call]],<br />
[[#Current|Current]],<br />
[[#ManifestNotation|Manifest_notation]],<br />
[[#Result|Result]],<br />
[[#Type|Type]],<br />
[[#UnaryOperator|Unary_operator]],<br />
[[#Writable|Writable]].<br />
<br />
<div id="Current"><br />
===Current is an expression===<br />
</div><br />
And this ''Expression'' denotes the [[Current|<TT>Current</TT>]] object.<br />
The notation is simply:<br />
<br />
<ebnf> "Current" { Current = "current". } </ebnf><br />
<br />
<br />
<div id="Result"><br />
<br />
===The Result variable===<br />
</div><br />
The <TT>Result</TT> variable is valid only inside the definition of some <br />
[[Glossary#Function|function]]. The notation is simply:<br />
<br />
<ebnf> "Result" { Result = "result". }</ebnf><br />
<br />
<br />
The purpose of the <TT>Result</TT> variable is to prepare the result of the<br />
enclosing function.<br />
Actually, the <TT>Result</TT> variable behave like an ordinary local variable.<br />
Like a local variable, the <TT>Result</TT> variable is automatically initialized <br />
with the default value of the corresponding type.<br />
Using the <TT>Result</TT> variable does not makes you returns from the enclosing<br />
function: it is just like a local variable. <br />
<br />
<br />
<div id="ManifestNotation"><br />
<br />
===Manifest notation===<br />
</div><br />
Manifest notation includes:<br />
* <TT>True</TT> and <TT>False</TT> for <TT>BOOLEAN</TT>,<br />
* <TT>'A'</TT>, <TT>'B'</TT>, <TT>'C'</TT>, ... for <TT>CHARACTER</TT><br />
* <TT>1</TT>, <TT>2</TT>, <TT>3</TT>, ... for <TT>INTEGER</TT><br />
* ...<br />
<br />
See the file <TT>SmartEiffel/tutorial/manifest_notation.e</TT> to have a <br />
detailed explaination plus examples about all available notations for <br />
constants of types:<br />
<TT>BOOLEAN</TT>,<br />
<TT>CHARACTER</TT>,<br />
<TT>INTEGER</TT>,<br />
<TT>REAL</TT>,<br />
<TT>STRING</TT> <br />
and <br />
<TT>UNICODE_STRING</TT>.<br />
<br />
Furthermore, the file ,<br />
<TT>SmartEiffel/tutorial/manifest_notation.e</TT><br />
also explain how to create explicitely objects of types<br />
<TT>ARRAY</TT>,<br />
<TT>FAST_ARRAY</TT>,<br />
<TT>LINKED_LIST</TT>,<br />
<TT>DICTIONARY</TT>,<br />
<TT>SET</TT>,<br />
etc., ...<br />
<br />
<br />
<div id="ManifestString"><br />
<br />
===Manifest string===<br />
<ebnf> "Manifest string" { Manifest_string = '"' string '"' . } </ebnf><br />
<br />
===Create expression===<br />
<ebnf> "Create expression" {<br />
Create_expression = create "{" type "}" [ "." Unqualified_call ].<br />
}<br />
</ebnf><br />
<br />
See also the [[#CreateInstruction|Create_instruction]] variant form. <br />
<br />
'''Related items''': [[#Type|Type]], [[#UnqualifiedCall|Unqualified_call]].<br />
<br />
<div id="UnqualifiedCall"><br />
<br />
==Unqualified call==<br />
</div><br />
[[Image:SyntaxDiagramOf_Unqualified_call.png|Unqualified_call]]<br />
<br />
Where ''Identifier_1'' is the name of the feature which is called.<br />
So ''Identifier_1'' can be the name of some attribute only when no parenthesis<br />
are used just after ''Identifier_1''.<br />
When parenthesis are used after ''Identifier_1'', it must be a <br />
[[Glossary#Routine|routine]] name.<br />
<br />
The ''Identifier_2'' used together with the <TT>$</TT> character indicates that the address <br />
of ''Identifier_2'' is passed to the callee.<br />
Thus, ''Identifier_2'' can be either some local variable name or the name of some attribute<br />
of [[Current]].<br />
This <TT>$</TT> facility is not supposed to be used in your every day life, but for some <br />
external interface facility.<br />
<br />
'''Related items''': [[#Expression|Expression]].<br />
<br />
<div id="Assertion"><br />
==Assertion==<br />
</div><br />
[[Image:SyntaxDiagramOf_Assertion.png|Assertion]]<br />
<br />
Here, the ''Identifier'' is just a name given to the assertion.<br />
This optional name which is supposed to explain the ''Expression'' is printed <br />
too in case of error at run-time.<br />
The syntax to use for the ''Identifier'' is the same used for local variables,<br />
attributes or argument names: only lower case letters plus the <TT>_</TT> underscore<br />
character.<br />
<br />
The ''Expression'' must be of type <TT>BOOLEAN</TT>. <br />
When the ''Expression'' is replaced by a ''Comment'' (which is bad news) this <br />
''Comment'' is considered equivalent to <TT>True</TT>.<br />
Finally, the semicolon used to separate the next ''Assertion''<br />
can be considered as the <TT>and</TT> operator.<br />
<br />
'''Related items''': [[#Comment|Comment]], [[#Expression|Expression]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Pretty&diff=2505Pretty2016-06-22T02:06:43Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category:Tool]]<br />
<br />
<TT>pretty</TT> is the Liberty Eiffel pretty-printer (code beautifier) for Eiffel source files. In a normal installation, it is invoked by the command <b><TT>[[se]]&nbsp;pretty</TT></b>.<br />
<br />
== Synopsis ==<br />
<br />
* <code>se pretty [options] &lt;source_file&gt;</code><br />
<br />
The <code>source_file</code> argument must be some existing Eiffel source file path as for example <code>"integer.e"</code> or <code>"lib/kernel/integer.e"</code>.<br />
<br />
One can specify more than one file name at a time in order to apply the pretty command to all the specified files. All the corresponding files are rewritten in a pretty way.<br />
<br />
There are four modes of pretty reformatting: ''-zen'', ''-default'', ''-end'' and ''-parano'' mode. Only one mode can be selected and ''-default'' is the default mode.<br />
<br />
=== Options ===<br />
<br />
==== Information ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-help</code><br />
| Display a short summary of the command line syntax, as well as a complete list of <code>pretty</code>'s options.<br />
|-<br />
| valign="top" | <code>-verbose</code><br />
| Display (an enormous amount of) information during the process: a complete list of files loaded, and so on.<br />
|-<br />
| valign="top" | <code>-version</code><br />
| Display the Liberty Eiffel version number.<br />
|}<br />
<br />
==== Warnings ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-style_warning</code><br />
| Display warning messages about non-compliance with Eiffel style rules.<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress all warning messages.<br />
|}<br />
<br />
==== Message Styles ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-flymake_mode</code><br />
| Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.<br />
|}<br />
<br />
==== Style ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
| valign="top" | <code>-zen</code><br />
| Produce as little as possible (i.e. very compact output). No end mark comment for routines, no end comments for statements (if, inspect, debug, ...).<br />
|-<br />
| valign="top" | <code>-default</code><br />
| The default mode. This is close to what we are using for our library.<br />
|-<br />
| valign="top" | <code>-end</code><br />
| The same format as <code>-default</code> but add end mark comments for all routines.<br />
|-<br />
| valign="top" | <code>-parano</code><br />
| Same format as <code>-end</code> but add end mark comments for all statements (if, inspect, debug, ...).<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress output for all warning messages (error messages are still printed).<br />
|}<br />
<br />
== Security and Backup File ==<br />
<br />
For the security of your sources files, a backup file is created before writing the new file. The backup file name is <code>"foo.bak"</code> when source file name is <code>"foo.e"</code>. The backup file is written in the same directory as the source file.<br />
<br />
If an old backup file already exists before pretty printing, the pretty command exits with an error message.<br />
<br />
To be sure that the pretty-printing is correct, the output file is parsed again. Even if the second parsing gives no errors, backup file is '''not''' removed. Thus you can recompile and test your Eiffel program to check that the beautified files did not break anything, before removing the backup files yourself.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Dynamic_dispatch&diff=2504Dynamic dispatch2016-06-22T02:01:30Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div> *** TO DO ! ***<br />
In the mean time, you can read [http://www.liberty-eiffel.org/papers/oopsla97.pdf this research paper,] which documents how [[dynamic dispatch]]<br />
initially was implemented in Liberty Eiffel's predecessor.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Cecil&diff=2503Cecil2016-06-22T02:01:06Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Interfacing]]<br />
Cecil (C-Eiffel Call-In Library) is a mechanism that permits to call Eiffel code from C. In this way, it is the opposite of [[externals]].<br />
<br />
In order to call Eiffel from C, you must use the flag <TT>-cecil&nbsp;&lt;cecil_file&gt;</TT> with [[compile]] or [[compile_to_c]]. The file <TT>&lt;cecil_file&gt;</TT> must give the list of [[Glossary#Feature|features]] that you want to call from C. The stub routines are automatically generated by Liberty Eiffel.<br />
<br />
When the flag <TT>-cecil</TT> is used, [[compile_to_c]] also produces one more C header file, which contains all stub routine prototypes.<br />
<br />
Your <TT>&lt;cecil_file&gt;</TT> file must contain at least two lines. The first line is the name of the C header file to produce (a <TT>.h</TT> file). The other lines have the following structure:<br />
<br />
&lt;c_name&gt; &lt;eiffel_type&gt; &lt;feature_name&gt; {create|creation}<br />
<br />
The <TT>&lt;c_name&gt;</TT> is the name of the C stub routine that wraps the Eiffel call. The couple <TT>&lt;eiffel_type&gt; &lt;feature_name&gt;</TT> gives the complete name of the Eiffel [[Glossary#Feature|feature]] to call.<br />
<br />
The <TT>create</TT> (or <TT>creation</TT>) optional keyword at the end of the line indicates that the given feature is used as a constructor. In that case the following rules apply:<br />
* the <TT>&lt;eiffel_type&gt;</TT> must not be deferred<br />
* the <TT>&lt;feature_name&gt;</TT> must be the one of a creation procedure listed in one of the creation clauses of the class; the client exports are not checked (i.e. a <TT>create {}</TT> clause can be useful in that case)<br />
* the <TT>&lt;c_name&gt;</TT> generated C function returns the created object<br />
<br />
You can also put Eiffel-style comments.<br />
<br />
For example:<br />
<br />
-- features from STRING :<br />
StringIsEmpty STRING empty<br />
StringItem STRING item<br />
StringGT STRING infix "&gt;"<br />
StringNew SRING make create<br />
-- features from ARRAY[INTEGER] :<br />
IntArrayCount ARRAY[INTEGER] count<br />
IntArrayItem ARRAY[INTEGER] item<br />
-- features from X :<br />
X_f X f<br />
<br />
Please note that<br />
* for "normal" features the <TT>&lt;type_eiffel&gt;</TT> must be a [[Glossary#LiveType|live type]]<br />
* for "creation" features the <TT>&lt;type_eiffel&gt;</TT> will be made [[Glossary#LiveType|alive]].<br />
<br />
For example, if the <TT>&lt;eiffel_type&gt;</TT> is [[library_class:ARRAY|<TT>ARRAY</TT>]]<TT>[</TT>[[library_class:INTEGER|<TT>INTEGER</TT>]]<TT>]</TT>, your Eiffel program must at least create one instance of type [[library_class:ARRAY|<TT>ARRAY</TT>]]<TT>[</TT>[[library_class:INTEGER|<TT>INTEGER</TT>]]<TT>]</TT>. Of course, if the called feature is a creation procedure, then the corresponding type is made alive.<br />
<br />
The name of the [[Glossary#Feature|feature]] to call, <TT>&lt;feature_name&gt;</TT>, can be a prefix or infix name. The [[Syntax_diagrams#FeatureName|syntax]] is the same as the one used in the Eiffel source code.<br />
<br />
''Nota bene:''<br />
* Since attributes are [[Glossary#Feature|features]], it is of course possible to access them with this mechanism.<br />
* The [[Glossary#LateBinding|late binding]] is also taken in account. In the above example, a call to <TT>X_f()</TT> in C is equivalent to the call <TT>x.f</TT> in Eiffel, with <TT>x</TT> of type <TT>X</TT> ''or a descendant of <TT>X</TT>''.<br />
<br />
Here is another example of a Cecil file (more can be found in the tutorial <TT>SmartEiffel/tutorial/cecil</TT>):<br />
-- The name of the include C file:<br />
eiffel.h<br />
-- The features you want to call from C:<br />
array_of_animal_item ARRAY[ANIMAL] item<br />
array_of_animal_lower ARRAY[ANIMAL] lower<br />
array_of_animal_upper ARRAY[ANIMAL] upper<br />
cry ANIMAL cry<br />
string_to_external STRING to_external<br />
<br />
Note that Cecil files can also be automatically included by C [[plugins]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Mock&diff=2502Mock2016-06-22T01:53:26Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>== Introduction ==<br />
<br />
While testing, it is frequently useful to be able to isolate the component being tested, and making it interact with "fake" objects, known as ''mocks'' in the Object-Oriented literature.<br />
<br />
Liberty Eiffel's mock implementation is quite straightforward: it takes a class to mock, and produce two classes: the mock implementation, and a test driver.<br />
<br />
* Instances of the mock implementation class will be used to interact with the component being tested.<br />
* Instances of the test driver class will be used by the test scenario to "prepare" the behavior of the mock implementation instances.<br />
<br />
There is only one requirement: the class to be mocked must be deferred.<br />
<br />
[[eiffeltest]] is also able to automatically generate mocks.<br />
<br />
== Calling ''mock'' directly ==<br />
<br />
The tool takes one parameter: the name of the class to mock, which must be deferred. It generates two classes:<br />
<br />
* the _MOCK class, which is the implementation of the class to mock;<br />
* the _EXPECT class, which is the test driver, used in test scenarios.<br />
<br />
There are options to change the name of the generated classes.<br />
<br />
== Using the test driver ==<br />
<br />
The test driver, or ''expect class'', allows to prepare the behavior of the mock instance.<br />
<br />
When the tester creates an ''expect'' instance, a ''mock'' instance is created by the test driver. It is available using the ''mock'' feature.<br />
<br />
For each deferred feature of the class to mock, the test driver exposes:<br />
<br />
* A feature with the same name, that takes the same arguments as the original function, and returns an expectation object (more on that below);<br />
* A feature with the same name and a ''__match'' suffix, only if the original feature takes arguments. In that case, the arguments are matchers, thus allowing a greater liberty on how to match arguments. The feature also returns an expectation object.<br />
<br />
The expectation object is used when the corresponding feature is called on the mock object (presumably by the component being tested). When building the test scenario, the expectation object is used to tune how the mock object behaves when the feature is called:<br />
<br />
* What object to return (if it is a function)<br />
* If a function must be called as side-effect<br />
* The number of times the feature is expected to be called<br />
<br />
== Using eiffeltest ==<br />
<br />
Eiffeltest brings the following features:<br />
<br />
* ''.mock'' files are read by [[eiffeltest]]. Each line must be a file name of a class to mock. Eiffeltest will call ''mock'' on each class.<br />
* [[library_class:EIFFELTEST_TOOLS|<tt>EIFFELTEST_TOOLS</tt>]] contains a feature ''scenario'', used to prepare the test scenario using mocks<br />
<br />
There is an example of such a usage in the <TT>test/tools/mocker</TT> directory in Liberty Eiffel source tree.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Compatibility&diff=2501Compatibility2016-06-22T01:52:52Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>This page is about language compatibility for Liberty Eiffel. You can find here the most important differences between Liberty Eiffel and other similar languages. The list is not intended to be exhaustive, it just intends to highlight the most important differences.<br />
<br />
See also [[ECMA]].<br />
<br />
== Unique peculiarities of Liberty Eiffel ==<br />
<br />
Liberty Eiffel has some features not implemented by any other implementation:<br />
<br />
* Case sensitivity: "abc", "Abc" and "ABC" are different identifiers<br />
* Compiler-enforced casing rules: Class names must be all-uppercase; camelCase is not allowed.<br />
* ANY is the root of the inheritance tree, but not of the conformance tree. <br />
* Conformance rules related to expanded types.<br />
* Non-conforming inheritance. See [[Conforming and non-conforming inheritance]]<br />
* The notation for non-conforming inheritance is "insert <Type_Class>".<br />
* New operators for run-time type checking. See [[Dynamic type testing]]<br />
* Removed the danger of automatic boxing (object allocation on assignment of expanded types to reference entities)<br />
* Lots of additional tools in the library. See [[Table of contents#Library|The Liberty Eiffel general purpose library]]<br />
* Notation for [[Manifest storage notation|manifest collections]]. The old <code>&lt;&lt;...&gt;&gt;</code> is still supported for simple arrays.<br />
* Unicode strings manifest notation.<br />
* Agents look contravariant, but they are not. Believe us. For details and explanations, see [http://www.jot.fm/issues/issue_2004_04/article7 this article].<br />
<br />
== Differences between ETL2 and the former SmartEiffel ==<br />
<br />
SmartEiffel was at some time based on ETL2; as all the members of the Eiffel language family, it has grown and improved on that, adding several features (some of them also implemented by other compilers)<br />
<br />
* The "Precursor" mechanism (proposed at OOSC2). see [[Precursor]]<br />
* Agents and tuples. see [[Agent]] and [[Tuple]]<br />
<br />
== Differences between the former SmartEiffel and ECMA Eiffel ==<br />
<br />
The [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA Eiffel specification] does not describe any current implementation at the time of writing this (November 2005). Despite being a standard it describes several features that fork away from what has been always called "Eiffel". The following aspects of ECMA Eiffel will not be implemented in SmartEiffel:<br />
<br />
* Conversions (implemented in ISE Eiffel)<br />
* Feature aliases (implemented in ISE Eiffel)<br />
* Bracket indexing (implemented in ISE Eiffel)<br />
* No-variant agent arguments.<br />
<br />
On the other hand, the following features were taken from the ECMA specification process:<br />
<br />
* Non-conforming inheritance (although the notation is different)</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Introduction&diff=2500Introduction2016-06-22T01:51:56Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>__NOTOC__<br />
Liberty Eiffel is a free compiler for the Eiffel programming language<br />
<br />
It '''continues''' the development of the legacy SmartEiffel system, which was the former GNU Eiffel Compiler - a role proudly taken over by Liberty Eiffel a number of years ago.<br />
<br />
Liberty Eiffel is a complete, small and fast Eiffel compiler, including an Eiffel to C compiler, documentation tools, a pretty printer, a debugger and various other tools. It also includes a large library of classes distributed under the terms of the MIT/X Consortium License as well as a comprehensive set of wrappers/bindings for widespread Free-Software libraries.<br />
<br />
Eiffel is an advanced object-oriented programming language that emphasizes the design and construction of high-quality and reusable software.<br />
<br />
If you are impatient hop over to [[Getting Started]] directly, otherwise read a few words about Liberty Eiffel's history:<br />
<br />
= Liberty's roots =<br />
<br />
== Etymology ==<br />
<br />
Liberty - as a name for our Eiffel compiler - has its origin in the [http://en.wikipedia.org/wiki/Statue_of_Liberty Statue of Liberty]. The structure of the statue was designed and built by [http://en.wikipedia.org/wiki/Gustave_Eiffel Gustave Eiffel], a famous French engineer.<br />
<br />
The origins of the language is [http://www.eiffel.com Eiffel] and more specifically [http://smarteiffel.loria.fr SmartEiffel]. At one point in time one could consider Liberty Eiffel a direct [http://en.wikipedia.org/wiki/Fork_(software_development) fork] of the legacy SmartEiffel code base. Since then Liberty Eiffel has evolved quite significantly beyond the original code base in multiple areas.<br />
<br />
== Manifesto ==<br />
<br />
We want to retain from SmartEiffel its rigour; but not its rigidity. Think of Liberty as ''SmartEiffel down from its ivory tower''.<br />
<br />
Liberty is free as in ''freedom''. We want people to contribute to Liberty from the start.<br />
<br />
So please, do join us to give Eiffel the leading position it should have won twenty years ago :-)<br />
<br />
== Foundation documents ==<br />
<br />
The following documents were published by the SmartEiffel team:<br />
<br />
* [http://www.jot.fm/issues/issue_2004_04/article7/ Conformance of agents in the Eiffel language]<br />
* [http://www.loria.fr/~colnet/publis/icsr9.pdf Reconciling Subtyping and Code Reuse in Object-Oriented Languages]<br />
<br />
<br />
= Liberty Eiffel's future =<br />
To get a glimpse of Liberty's future, please take a look at our plans for [[ECMA|EMCA features]] (partially implemented already) and our [https://savannah.gnu.org/bugs/?group=liberty-eiffel issue tracker].<br />
<br />
== Release names ==<br />
See [[Versions history|list of released versions]] and [[Upcoming releases]].<br />
<br />
== Liberty Eiffel Community ==<br />
Join us via our mailing list by simply e-mailing to [mailto:liberty-eiffel@gnu.org liberty-eiffel@gnu.org] or browse the [http://lists.gnu.org/archive/html/liberty-eiffel/ list archives]. Or choose any other way to [[Get in touch]] with the Liberty Eiffel team.<br />
<br />
==Origins of the SmartEiffel project==<br />
<br />
During the course of his work on his thesis, [[User:Colnet|Dominique Colnet]], principal author of SmartEiffel, discovered the Eiffel language while editing an encyclopedic work on object oriented languages <br />
([[Bibliography#MNCLT 1989|[MNCLT 1989]]], [[Bibliography#MNCLT 1991|[MNCLT 1991]]]).<br />
<br />
Holding the post of Assistant Professor of Computer Science in 1989, the Powers That Be at his educational institution at the time decided, in 1990, to use the Eiffel language for introductory computer science.<br />
It is amusing to mention here that Dominique Colnet was at the time a fervent defender of Smalltalk.<br />
As everyone knows, it's a pretty good thing that it's not up to a young Assistant Professor of Computer Science to decide which programming language is the best one to use.<br />
So, it is amusing to note that Dominique Colnet was forced to use Eiffel against his will in 1990!<br />
<br />
In order to reconcile his teaching and research work on the compilation of object oriented languages, Dominique Colnet decided therefore to abandon Smalltalk for Eiffel and to establish a project to kill two birds with one stone: combine interesting research with a free product that would also be useful for teaching.<br />
<br />
The SmartEiffel project, originally named ''SmallEiffel'' actually started in 1994 when Dominique Colnet decided to write his own Eiffel compiler.<br />
<br />
Writing an Eiffel compiler is no small undertaking. Before making this decision, Dominique Colnet had begun to write a new Eiffel class library whose architecture simply corresponded nearly word for word with the base classes of Smalltalk-80 libraries at the time ([[Bibliography#GR 1983|[GR 1983]]], <br />
[[Bibliography#Goldberg 1984|[Goldberg 1984]]]).<br />
Because of the very bad quality of the commercial Eiffel compilers available at that time the decision was taken to write a new one from scratch.<br />
The new compiler was named ''SmallEiffel'' to make reference to both Smalltalk <br />
and Eiffel ([[Bibliography#OOSC 1988|[OOSC 1988]]], [[Bibliography#ETL 1992|[ETL 1992]]]).<br />
An entire year was necessary to write the first version of SmallEiffel and it was not until July 1995 that SmallEiffel was able to compile itself. Since that time, more than <br />
[[versions_history|thirty versions]] have seen the light of day.<br />
<br />
==Little SmartEiffel developing into something bigger?==<br />
Starting out as simple research prototype and teaching aid, SmartEiffel has seen its capabilities steadily increase from version to version since 1995.<br />
<br />
In 1998, on the occasion of a visit to LORIA by Richard Stallman, president and founder of the FSF (Free Software Foundation), the GNU designation was added to the project's name. <br />
<br />
<div id="EcmaEiffel"><br />
From 2002 and up to 2005, Dominique Colnet participated actively in meetings with the initial objective of standardizing the Eiffel language <br />
('''ECMA''' standards committee TC39-TG4, ECMA standard number 367).<br />
Of course it goes without saying that the entire SmartEiffel team was associated with the standards work and its many long discussions...<br />
<br />
Finally, in May 2005, the SmartEiffel project team announced that it was going to continue to work on the ''true Eiffel language''. In reality, the language described by the ECMA TC39-TG4 working group clearly diverges from what was conventionally called Eiffel. ECMA-Eiffel is a very different language, and above all, not yet experimented. The SmartEiffel team decided to never implement ECMA TC39-TG4.<br />
'''Note:''' In this respect the Liberty Eiffel development team is<br> not as strict as the original SmartEiffel developers used to be.<br> See [[ECMA]] about Liberty's attitude to ECMA.<br />
</div><br />
<br />
In July 2005, at the time when we wrote these lines, after more than 10 years of work not only on the compiler but also on the Eiffel language itself, the SmartEiffel team considered that the Eiffel language as they knew it contained nearly all desirable features.<br />
Therefore, version 2.2 of SmartEiffel marked the debut of a new level of stability and corresponded to what the team thought of as being the ''true Eiffel language''.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Author_guidelines&diff=2499Author guidelines2016-06-22T01:51:16Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Concise usage guide for contributors to the [[Table of contents|LibertyEiffelWiki]].<br />
<br />
Everyone is invited to participate in creating and improving Liberty Eiffel documentation on this wiki. Just ask on the [[Get in touch#Mailing list|mailing list]] [mailto:liberty-eiffel@gnu.org liberty-eiffel@gnu.org] for an account.<br />
<br />
So far we did not yet see the need to setup rules for editing this wiki. Please be fair, friendly and don't use this wiki as a place for advertising or any form of discrimination or publishing any form of illegal content.<br />
<br />
Also note, that by contributing, you confirm that your changes are released under the GNU Free Documentation License as stated in [[Liberty_Eiffel_Wiki:Copyrights]] and that your contributions are not contrarily copyrighted.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=GSoC_-_Google%27s_Summer_of_Code&diff=2498GSoC - Google's Summer of Code2016-06-22T01:49:23Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>This year (2016) the Liberty Eiffel group participates in [https://developers.google.com/open-source/gsoc/ Google's Summer of Code Program] with '''two projects''', see further below. <br />
<br />
= What is the Google Summer of Code (GSoC)? =<br />
Summer of Code is Google's program to give students stipends for a 3 months programming task in an open source project. Every participating student gets a mentor assigned (early birds might even have a chance to select ;-) who supports the student with his experience from the community.<br />
<br />
= When will all this happen? =<br />
The [https://developers.google.com/open-source/gsoc/timeline timeline] is quite terse but the most important dates are application before 25th of March and free time between May 23 and August 23 to work on coding.<br />
<br />
= Why choosing Liberty Eiffel for the GSoC ? =<br />
Liberty Eiffel is the GNU compiler for the programming language Eiffel. It is based on the academic project SmartEiffel but evolved with the scope of being usable to real world programs. Eiffel in general is an excellent object oriented programming language which includes the specification of the program's functionality within the code. This is nice for debugging but also a step to be able to prove the program correct.<br />
<br />
= What could I do? =<br />
We are open to your ideas, as we are convinced that you will perform best in case you what your heart burns for. Feel free to suggest a project on the mailing list an we will find a mentor or subtasks to add or remove to make it appropriate. In case you just want to do something great for Liberty Eiffel you can choose from the following ideas.<br />
<br />
= 2016 Projects =<br />
[[GSoC - Windows Support]]<br />
<br />
[[GSoC - Eclipse Integration]]<br />
<br />
== Eclipse integration ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''Integrate Liberty Eiffel into Eclipse with Syntax highlighting, compilation (and parsing the output) and the sedb debugger<br />
<br />'''difficulty: '''Easy<br />
<br />'''skills: '''Java knowledge, basic Eiffel knowledge or interest, experience with Eclipse (plugin development) would be good<br />
<br />'''potential mentors: '''ramack<br />
<br />'''notes: '''Target is to have a Liberty integration similar to the CDT for C. A few years ago the project Eclipse Eiffel Development Tools (EDT) was started, which could be used as starting point, but this project targeted the commercial ISE compiler.<br />
<br />
<br />
= Ideas for future projects =<br />
Down below we collect new ideas for future projects: <br />
<br />
== Emit Standard C11 conforming C code ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''Make the Liberty Eiffel compiler emit C11 compatible C code without warnings even on the higher warning levels of gcc<br />
<br />'''difficulty: '''Advanced<br />
<br />'''skills: '''Deep experience in C programming, basic Eiffel knowledge<br />
<br />'''potential mentors: '''ramack, HZwakenberg<br />
<br />'''notes: '''The target is not to make the code requiring a C11 compatible compiler (e.g. by using new features) but to remove warnings in strict std modes. Can be extended to apply additional static checkers like pclint, MISRA rules, etc.<br />
<br />
== ECMA conformance ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''many ECMA features are already supported, implement the missing ones (beside No-variant agent conformance, which is not planned to be included in Liberty Eiffel)<br />
<br />'''difficulty: '''Advanced<br />
<br />'''skills: '''Deep Eiffel knowledge, willingness to dig into the ECMA standard document<br />
<br />'''potential mentors: '''ramack, Cadrian<br />
<br />'''notes: '''obviously test cases shall also be derived (integrated into the test suite and passed) for the new features<br />
<br />
== EiffelTest-NG ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''Implement a new version of the tool eiffeltest, to execute the test suite<br />
<br />'''difficulty: '''Advanced<br />
<br />'''skills: '''Good Eiffel knowledge, interest in Software testing<br />
<br />'''potential mentors: '''ramack, Cadrian<br />
<br />'''notes: '''the features should include: parallel test execution, time/progress monitoring and estimation, improved test status (ET integration), Coverage measurement (different criteria like Branch, MC/DC)<br />
<br />
== Embedded Systems Readiness / Static Memory Allocation ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''Improve the applicability of Liberty Eiffel programs to small embedded systems, by introduction of a mechanism to prevent dynamic memory allocation.<br />
<br />'''difficulty: '''Hard<br />
<br />'''skills: '''Deep understanding of Memory Managment, Eiffel experience<br />
<br />'''potential mentors: '''ramack<br />
<br />'''notes: '''<br />
<br />
== Evaluating, selecting and integrating an Open Source ARM C-compiler into Liberty Eiffel's back-end ==<br />
'''suggested by: '''HZwakenberg<br />
<br />'''summary: '''In lieu of the project above (Embedded System Readyness) implement an ARM (cross-)compiler backend. As Liberty Eiffel generates Std-C code, this project redefines into evaluating and selecting a suitable open source ARM compiler and integrate it in the Liberty Eiffel system back-end.<br />
<br />'''difficulty: '''Easy/Medium<br />
<br />'''skills: '''Understanding of C Compiler and a deep understanding of scripting languages to implement integration of the compiler.<br />
<br />'''potential mentors: '''ramack, HZwakenberg<br />
<br />'''notes: '''<br />
<br />
== Resurrect the compile_to_jvm compiler ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''Back in the SmartEiffel times there was a JVM backend, which compiled Eiffel to Java bytecode. This should be made working again with an example to build an Android App in Eiffel.<br />
<br />'''difficulty: '''Hard<br />
<br />'''skills: '''Good Eiffel experience, knowledge of Java bytecode and compiler technology.<br />
<br />'''potential mentors: '''ramack,Cadrian<br />
<br />'''notes: '''The option with difficulty "Unmanageable" would be to merge this with Eclipse integration and write the eclipse code plugin in Eiffel ;-)<br />
<br />
== Verification backend ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''generate proof obligations from contracts for formal verification, e. g. by generationg of ACSL specifications from the Eiffel contracts to use Frama-C as "verification backend"<br />
<br />'''difficulty: '''Hard<br />
<br />'''skills: '''background in formal verification, Eiffel experience<br />
<br />'''potential mentors: '''ramack<br />
<br />'''notes: '''<br />
<br />
== C++ support wrappers-generator ==<br />
'''suggested by: '''Tybor<br />
<br />'''summary: '''Add C++ support to wrappers-generator<br />
<br />'''difficulty: '''Advanced<br />
<br />'''skills: '''Good C++ knowledge, good Eiffel experience.<br />
<br />'''potential mentors: '''Tybor<br />
<br />'''notes: '''C++ support could be a boon yet it would pose quite a few tricky problems as C++ object model differs from Eiffel's in some ways.<br />
<br />
== Scientific wrappers ==<br />
'''suggested by: '''Tybor<br />
<br />'''summary: '''Add wrappers for scientific purposes: complexes, intervals, arbitrary precision integers and floats. Interesting libraries could be:<br />
* The GNU Multiple Precision Arithmetic Library https://gmplib.org/<br />
* MPFR: multiple-precision floating-point computations with correct rounding. http://www.mpfr.org/<br />
* Mpc: complex numbers with arbitrarily high precision and correct rounding of the result. http://www.multiprecision.org/<br />
* Multi precision intervals http://mpfi.gforge.inria.fr/ https://gforge.inria.fr/projects/mpfi/<br />
<br />'''difficulty: '''Advanced<br />
<br />'''skills: '''Good Eiffel experience, knowledge in floating point arithmetics<br />
<br />'''potential mentors: '''Tybor, ramack<br />
<br />'''notes: ''' Several GNU libraries would be a nice addition to Liberty yet their wrappers should be expanded types to be really useful.<br />
<br />
== JavaScript backend ==<br />
'''suggested by: '''Tybor<br />
<br />'''summary: '''Implement an Eiffel to Javascript transcompiler<br />
<br />'''difficulty: '''Easy/Advanced<br />
<br />'''skills: '''Medium Eiffel knowledge, good knowledge of Javascript<br />
<br />'''potential mentors: '''Tybor, ramack<br />
<br />'''notes: '''Javascript is the new "write once run everywhere as it is quickly becoming the new lingua franca of the web. Having an Eiffel to Javascript compiler would widen the usage fields available to Eiffel. A naive compiler would be easy; something that doesn't require writing tons of glue Eiffel libraries would be quite a harder task. Think about what's to provide "usable" wrappers for libraries such as RaphaelJS or Angular. Their design is all but strongly-typed.<br />
<br />
== Idea Template Title ==<br />
'''suggested by: '''ramack<br />
<br />'''summary: '''Summary of Project Idea (a few sentences)<br />
<br />'''difficulty: '''None/Easy/Advanced/Hard/Unmanageable<br />
<br />'''skills: '''what skills shall a student bring to do this?<br />
<br />'''potential mentors: '''ramack,Tybor,Cadrian<br />
<br />'''notes: '''anything further needs to be mentioned?<br />
<br />
<br />
= How can I participate? =<br />
First you should register to the [[Get_in_touch|mailing list]]. Last you should add a page here in this wiki to present your project proposal and communicate the following:<br />
* your name and contact data<br />
* your background (other projects you are/have been involved<br />
* list of known programming languages (rate with a scale of 3-10, omit the ones you know less)<br />
* your background and interests (hobbies?)<br />
* your motivation<br />
* your timeline (idea is to have 12 week full time, but some planned absence for vacation or exams is acceptable, include milestones and project subtasks, duration of subtask should be in granularity of 1-2 weeks each)<br />
* your project (what you want to do, why, how, etc. - This is THE main thing we are talking about)<br />
In between (first and last) feel free to discuss ideas and details on list or privately with potential mentors.<br />
<br />
Afterwards we will decide which project to accept, based on the subjective estimation of the Liberty Eiffel-GSoC-Ratio (benefit for Liberty Eiffel * success rate / amount of mentor effort). Note: amount of mentor effort is not linear! Of course the mentors will support you as much as possible, but an Eiffel-newbie working on a compiler-core redesign is just no feasible...<br />
<br />
Of course it would be great if you could continue to maintain the project you worked on during GSoC even after the program.<br />
<br />
= What about additional questions? =<br />
See our [[Get_in_touch]] page for contact data to the Liberty Eiffel community or check the [https://developers.google.com/open-source/gsoc/faq FAQ] provided by Google for this program.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=ACE&diff=2497ACE2016-06-22T01:47:32Z<p>Dkearns: s/no_style_warning/style_warning/</p>
<hr />
<div> * This page needs checking for accuracy and completeness.<br />
* safety_check (yes) needs to be documented<br />
<br />
== ACE File ==<br />
<br />
An ACE file defines the environment for a project, together with its root class and initial creation procedure.<br />
<br />
Use of an ACE file obviates the need for specifying many options on the<br />
command line and ensures consistency between successive compilations or <br />
other operations on the project. Such consistency makes it easier to test<br />
and debug, since changes from one compilation to the next are guaranteed to be<br />
limited to coding changes rather than to changes in the compilation environment.<br />
<br />
=== Naming ===<br />
<br />
An ace file must have a name ending with the suffix <TT>.ace</TT>.<br />
<br />
=== Structure of the ACE file ===<br />
<br />
The file is divided into sections, each introduced by a keyword. These are<br />
conventionally presented in an order laid out in the template ACE file, which<br />
is found under the Liberty Eiffel directory <TT>tutorial/ace/</TT>. These sections<br />
are: '''system''', '''root''', '''default''',<br />
'''cluster''', '''external''' and '''generate'''.<br />
<br />
==== System section ====<br />
<br />
The system section is introduced by the keyword '''system''' followed by the<br />
name to be given to the executable program which will be produced by a compilation.<br />
The system name should be enclosed in double quotes.<br />
<br />
Example:<br />
<br />
<TT><br />
system<br />
&nbsp;<br />
"my_system"<br />
</TT><br />
<br />
==== Root section ====<br />
<br />
The root section defines the root class of the system and the initial creation<br />
procedure. The creation procedure is the routine which is executed first<br />
when the executable program is run; it is equivalent to <TT>main()</TT> in<br />
a C program. This procedure must be a procedure in the root class and must be<br />
declared as a creation procedure in that class.<br />
<br />
Example:<br />
<br />
<TT><br />
root<br />
&nbsp;<br />
MY_SYSTEM: make<br />
</TT><br />
<br />
Here '''MY_SYSTEM''' is the root class and '''make''' is the initial creation<br />
procedure.<br />
<br />
==== Default section ====<br />
<br />
The default section defines the defaults which will apply to the whole<br />
compilation unless overridden for specific sections. It is introduced by<br />
the keyword '''default'''.<br />
<br />
Within the default section are listed various defaults and their settings.<br />
If any default is unlisted, it takes its value from the defaults compiled<br />
into Liberty Eiffel when it was installed.<br />
<br />
The syntax for setting a default is:<br />
<br />
<TT><br />
''setting_name'' (''setting'');<br />
</TT><br />
<br />
Do not forget the terminating semi-colon.<br />
<br />
These are the settings which may be included in the default section:<br />
<br />
* '''assertion'''<br />
This specifies the default level of assertion checking for the system.<br />
Choose the appropriate value as explained in the description of<br />
[[compile_to_c]]: '''boost''', '''no''', '''require''', '''ensure''',<br />
'''invariant''', '''loop''', '''check''' or '''all'''.<br />
<br />
* '''assertion_flat_check'''<br />
In flat mode each assertion will be executed in no_check mode.<br />
This means that while an assertion is being checked, no other assertion will<br />
be checked. This mode is only meaningful in assertion modes from<br />
require to debug. The possible values for this setting are '''yes''' or '''no'''.<br />
<br />
* '''debug'''<br />
This is the default debug level for the system. Choose '''yes''', '''no''',<br />
or any "key" you wish. When debugging is turned on, [[Syntax diagrams#Debug|<tt>debug</tt>]]<br />
sections in the source code are enabled.<br />
<br />
* '''trace'''<br />
This is the default trace mode for the system. Choose '''yes''' or '''no'''.<br />
When tracing is turned on, the [[sedb]] debugger is enabled when the<br />
executable is run.<br />
<br />
* '''collect'''<br />
Choose '''"bdw"''' here to add the Boehm-Demers-Weiser conservative collector linked into to your system.<br />
Choose '''yes''' here to add the native garbage collector support to your system.<br />
Choose '''no''' here to indicate that you don't want the garbage collector to be included in your system; '''no''' is the equivalent of the <TT>-no-gc</TT> flag in traditional command line mode.<br />
See [[Garbage collector]] for details.<br />
<br />
* '''style_warning'''<br />
If set to '''no''', this will suppress the display of warning messages<br />
about non-compliance with Eiffel style rules (for example, <TT>ItEm</TT><br />
will not trigger a message).<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''yes'''.<br />
This setting is the equivalent of the -style_warning flag in traditional<br />
command line mode.<br />
<br />
* '''no_warning'''<br />
If set to '''yes''', this will suppress all warning messages.<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
'''Yes''' is the equivalent of the -no_warning flag in traditional<br />
command line mode.<br />
<br />
* '''verbose'''<br />
Set to '''yes''' to display (an enormous amount of) information during<br />
compilation: a complete trace of files loaded, type inference scores,<br />
generated files and so on. This is the equivalent of the -verbose flag<br />
in traditional command line mode. (Note too that the -verbose flag is<br />
still accepted in ACE file mode.)<br />
<br />
* '''manifest_string_trace'''<br />
Set to '''yes''' to include in your executable a trace of the creation<br />
of manifest strings. This can be useful for tracking down some memory errors.<br />
This is the equivalent of the -manifest_string_trace flag in traditional<br />
command line mode.<br />
<br />
* '''high_memory_compiler'''<br />
When set to '''yes''', this allows the compiler to use more memory.<br />
This can allow faster compilation, if you have enough RAM.<br />
This is the equivalent of the -high_memory_compiler flag in traditional<br />
command line mode.<br />
<br />
* '''profile'''<br />
When set to '''yes''', this allows you to include the [[profile|profiler]]<br />
in your executable.<br />
This is the equivalent of the -profile flag in traditional<br />
command line mode.<br />
<br />
* '''relax'''<br />
This is the equivalent of the -relax flag in traditional<br />
command line mode. ''[What the -relax flag actually does is not documented.]''<br />
<br />
Example:<br />
<br />
<TT><br />
default<br />
&nbsp;<br />
assertion (require);<br />
&nbsp;<br />
assertion_flat_check (no);<br />
&nbsp;<br />
debug (no);<br />
&nbsp;<br />
trace (no);<br />
&nbsp;<br />
collect (yes);<br />
&nbsp;<br />
no_style_warning (no);<br />
&nbsp;<br />
no_warning (no);<br />
&nbsp;<br />
verbose (no);<br />
&nbsp;<br />
manifest_string_trace (yes);<br />
&nbsp;<br />
high_memory_compiler (no);<br />
&nbsp;<br />
profile (yes);<br />
&nbsp;<br />
relax (yes);<br />
&nbsp;<br />
</TT><br />
<br />
==== Cluster section ====<br />
<br />
The cluster section is introduced by the keyword '''cluster'''<br />
and defines an ordered list of clusters. Roughly speaking,<br />
a cluster can be considered as a directory in which Eiffel source files<br />
are to be searched for. The order of this list of clusters is<br />
important because clusters are considered sequentially when<br />
searching for an Eiffel source file. The first class file found in the<br />
search is the one that will be used.<br />
<br />
Each cluster is described as follows:<br />
<br />
<TT><br />
optional_cluster_name: "cluster_path_using_system_file_notation_here"<br />
default -- at this cluster level<br />
assertion (require)<br />
debug (no);<br />
trace (no);<br />
option -- for this cluster<br />
assertion (loop) : CLASS_NAME1, CLASS_NAME2;<br />
assertion (all) : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
debug (yes) : CLASS_NAME1, CLASS_NAME2, ...;<br />
debug ("KEY") : CLASS_NAME1, CLASS_NAME2, ...;<br />
-- ...<br />
trace : CLASS_NAME1, CLASS_NAME2;<br />
trace : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
end -- of one cluster<br />
</TT><br />
<br />
The '''default''' subsection is used to set defaults that apply<br />
only to classes from this particular cluster. The settings that<br />
may be used are '''assertion''', '''debug''' and '''trace'''.<br />
<br />
The '''option''' subsection is used to modify the cluster or system<br />
defaults for particular classes in the cluster<br />
<br />
The following cluster definition can be used, after all the other cluster<br />
definitions, to pull in Liberty Eiffel's standard library. Always<br />
put this last so that you can override options for parts of the standard<br />
library by writing your own replacement class files and placing them in<br />
earlier clusters.<br />
<br />
<TT><br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Example:<br />
<br />
<TT><br />
cluster<br />
&nbsp;<br />
utilities: "../../utilities"<br />
default<br />
assertion (all)<br />
debug (yes);<br />
trace (no);<br />
end<br />
&nbsp;<br />
utilities_se: "../../utilities/se"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (yes);<br />
end<br />
&nbsp;<br />
dbmap: "../../system/dbmap"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (no);<br />
option<br />
trace : JOB_DB_MAP, PURCHASED_JOB_DB_MAP;<br />
end<br />
&nbsp;<br />
egtk: "${EGTK}/lib/glib";end<br />
&nbsp;<br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Notice that when the trace option is used in relation to a particular class,<br />
the setting is always turned on; the setting value is not specified.<br />
<br />
==== External section ====<br />
<br />
The next section is introduced by the keyword '''external'''; it defines<br />
how the C code generated from the Eiffel classes is to be linked with<br />
system libraries and code written in other languages to make a complete<br />
executable.<br />
<br />
The external section contains the following settings:<br />
<br />
* '''external_header_path'''<br />
This is a space-separated list of directories to be searched for C include<br />
files (which typically have <TT>.h</TT> as a suffix).<br />
<br />
* '''external_object_files'''<br />
This is a space-separated list of the path names of object modules to be linked into the<br />
executable. These are files output by a C compiler with the suffix <TT>.o</TT>.<br />
<br />
* '''external_c_files'''<br />
This is a space-separated list of C source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''external_c_plus_plus_files'''<br />
This is a space-separated list of C++ source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''cecil''' ("''my_cecil_file1.se''")<br />
This line appears once for each Cecil file that is to be included in the build<br />
(see [[cecil]] for details).<br />
<br />
* '''external_lib_path'''<br />
A space separated list of directories which are to be searched for system<br />
libraries. On a Unix system a directory name may optionally be prefixed<br />
by <TT>-L</TT> (this used to be required before release -0,74 of SmallEiffel).<br />
<br />
* '''external_lib'''<br />
A list of libraries to be supplied to the linker. The <TT>lib</TT> prefix<br />
of the library name is always omitted; the prefix <tt>-l</TT> may optionally<br />
be used for each library. Other linker options can be included.<br />
<br />
Example (abridged for convenient display):<br />
<br />
<TT><br />
<br />
external<br />
&nbsp;<br />
external_object_files: "/usr/local/lib/libutils.a /usr/local/libeifpq.a"<br />
&nbsp;<br />
external_header_path: "/usr/include/gtk-1.2 /usr/include/gdk-1.2 -I. "<br />
&nbsp;<br />
external_c_files: "/usr/local/src/eif_gtk_se.c"<br />
&nbsp;<br />
cecil ("/usr/local/src/cecil.se")<br />
&nbsp;<br />
external_lib_path: " -L/usr/lib/debug -L/usr/X11R6/lib"<br />
&nbsp;<br />
external_lib: "-rdynamic -lpq -lgnomeui -lart_lgpl -lX11 -lm"<br />
<br />
</TT><br />
<br />
<br />
==== Generate section ====<br />
<br />
This section, introduced by the keyword '''generate''', controls the<br />
generation of C code by [[compile_to_c]].<br />
<br />
The section contains the following possible settings:<br />
<br />
* '''no_strip'''<br />
When set to '''yes''', this suppresses the running of '''strip''' on the<br />
generated executable. This is the equivalent of the <tt>-no_strip</tt><br />
flag of the traditional command line mode. (If you want to use a C level<br />
debugger on your system, you should choose '''yes''' here).<br />
<br />
* '''no_split'''<br />
When set to '''yes''', this causes [[compile_to_c]] to produce a single,<br />
large C file for the entire system, instead of the many small C files<br />
produced by default (when this is set to '''no''').<br />
This setting may be useful for delivery of the most efficient version. (Some<br />
C compilers, including gcc, can then do better inlining.)<br />
<br />
* '''clean'''<br />
When set to '''yes''', this makes the [[compile|compiler]] remove all<br />
generated C files, all generated object files and other temporary files<br />
generated during the compilation process. (See the command [[clean]].)<br />
This ensures that all code is freshly generated and compiled, but will<br />
extend the time needed for recompilation.<br />
<br />
* '''cc'''<br />
The equivalent of the -cc flag of the traditional command line mode.<br />
This defaults to the value, '''gcc'''. To select a different C compiler<br />
from the default, set the option to the appropriate system command.<br />
<br />
* '''c_compiler_options'''<br />
Use this keyword to supply additional options to be passed to the<br />
C compiler, to control optimisation or the production of debugging symbols,<br />
for example.<br />
<br />
* '''linker_options'''<br />
This option can be used to set compiler options that are to be passed<br />
only to the linker.<br />
<br />
* '''no_main'''<br />
Set this to '''yes''' to suppress the generation of a <TT>main()</TT> <br />
C code routine. This is used for generating object libraries.<br />
<br />
* '''gc_info'''<br />
When this option is set to '''yes''', the garbage collector displays at<br />
run time some information about its use.<br />
<br />
* '''wedit'''<br />
To Include support for the Wedit debugger, set this option to '''yes'''.<br />
<br />
Example:<br />
<br />
<TT><br />
generate -- section<br />
&nbsp;<br />
no_strip(yes);<br />
&nbsp;<br />
no_split(no);<br />
&nbsp;<br />
clean(no);<br />
&nbsp;<br />
c_compiler_options : "-Wall -g -pipe -DNEED_GNOMESUPPORT_H "<br />
&nbsp;<br />
<br />
</TT><br />
<br />
=== Variables ===<br />
<br />
As in the cluster and external section examples above, environmental variables<br />
can be used to save typing (and also to enable a whole directory tree to be<br />
moved at the cost only of redefining the variable rather than rewriting every<br />
ace file.<br />
<br />
A variable is referenced by the construct <TT>${''variable_name''}</TT>.<br />
<br />
Some variables are defined in the system configuration file (e.g.<br />
<TT>/etc/liberty-eiffel/liberty.se</TT>); such are the variables ${path_lib} and ${path_tutorial}.<br />
Other variables can be set and exported in the system environment, as, for example, by<br />
the Bourne shell command:<br />
<br />
<TT><br />
$ export EGTK=/usr/local/lib/egtk<br />
</TT><br />
<br />
=== Using an ACE file ===<br />
<br />
An ACE file may be used by specifying it immediately after the command which<br />
is to use it, before any other options to that command.<br />
<br />
For example:<br />
<br />
<TT><br />
se compile my_system.ace<br />
&nbsp;<br />
se short my_system.ace my_system<br />
&nbsp;<br />
se finder my_system.ace some_class<br />
</TT><br />
<br />
<br />
=== ACE syntax checking ===<br />
<br />
The syntax of an ACE file may be checked by the [[ace_check]] command.<br />
<br />
This command will report any errors and will also expand any loadpath.se files<br />
that are included in the ACE file and list each component directory.<br />
<br />
Example:<br />
<br />
<TT><br />
se ace_check my_system.ace<br />
</TT></div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Liberty_Eiffel_Programming_Environment_FAQ&diff=2491Liberty Eiffel Programming Environment FAQ2016-06-19T19:28:44Z<p>Dkearns: Add SciTE to editors list</p>
<hr />
<div>'''Frequently Asked Questions'''<br />
==General purpose questions about the Liberty Eiffel project==<br />
<div id="LibertyName"><br />
===Where does the name "Liberty" come from?===<br />
<br />
As most Eiffel hackers know, Gustave Eiffel (after whom the language is named), also built the metal structure of the Liberty Statue.<br />
<br />
More trivia:<br />
Some people may also know that I (Cyril) happen to live very near to Belfort, a town renowned for a sculpture of a lion by Auguste Bartholdi. Bartholdi sculpted the metallic sheets that make the Liberty Statue such an awesome sight.<br />
<br />
<div id="MailingList"><br />
<br />
===Is there a Liberty Eiffel '''mailing list'''?===<br />
</div><br />
Yes! Liberty Eiffel users and developers can share their experiences<br />
and ideas by subscribing to the<br />
[mailto:libertyeiffel@librelist.com Liberty Eiffel official mailing list] by just sending an empty email to this address.<br />
<br />
Please, note that this list is not moderated. <br />
Please, stay correct on that list.<br />
<br />
===Is it possible to have the complete '''source code of Liberty Eiffel'''?===<br />
Since it is a free (as in freedom) Eiffel Compiler, the complete source<br />
code of Liberty Eiffel is of course in the distribution. <br />
The Eiffel source code for additional libraries is also provided. <br />
See also this [[#CommercialApps|FAQ question]] which is related to [[License|licensing]].<br />
<br />
<div id="CommercialApps"><br />
<br />
===Is it possible to use Liberty Eiffel for '''large/commercial applications'''?===<br />
</div><br />
<br />
It is indeed possible to use Liberty Eiffel for a large application.<br />
An Eiffel compiler is a really big project and Liberty Eiffel itself is fully<br />
written in Eiffel.<br />
Liberty Eiffel is completely free and any private company can use<br />
it freely, and distribute (or sell) freely the products made with it.<br />
They do not have to pay royalties.<br />
<br />
Also note that <B>only classes which are closely related to the<br />
compiler itself are under GPL</B> (actually, only the classes of directory<br />
<TT>SmartEiffel/tools</TT> are under GPL).<br />
The other classes are <EM>not</EM> under GPL in order to let people completely<br />
free (i.e. all classes of <TT>lib</TT>).<br />
<br />
Always keep in mind that Liberty Eiffel doesn't come<br />
with any warranty (please read the COPYING file in the distribution).<br />
As explained in the header of non-GPL files, the only important thing<br />
is to keep the header unaltered when the corresponding source file<br />
is provided in your product.<br />
<br />
<!-- continue update to Liberty here --><br />
<br />
<div id="SmallEiffel"><br />
<br />
===What is <B>SmallEiffel</B> compared to <B>SmartEiffel</B>?===<br />
</div><br />
Sma<B>ll</B>Eiffel is the former name of the Sma<B>rt</B>Eiffel<br />
project. At some point in time the development team thought the compiler had become smart<br />
enough to warrant a renaming ;) For a list of changes between the various Small-/SmartEiffel versions, have a look<br />
[http://SmartEiffel.loria.fr/misc/HISTORY.html#1.0 there].<br />
<br />
<div id="HowCanIHelp"><br />
<br />
===How can I help?===<br />
</div><br />
The best way to help Liberty Eiffel and its users is probably to <B>pick up<br />
some area you're interested in, and develop</B> your own code, libraries, tools or extensions with Liberty Eiffel,<br />
and then release them to other users.<br />
<br />
A very good way to help us is to follow the<br />
[[Get involved]] guidelines when you find some problem with Liberty Eiffel.<br />
<br />
===Why don't you <B>change this and add that</B>?! It would be much better/cooler/whatever!===<br />
People must understand that we can't always do everything. We simply<br />
can't. Because we don't have the time. Whether we like it or not, we<br />
also have other things to do than provide free stuff, modify our<br />
compiler and/or libraries to please everybody. We do as much as we<br />
can, but we don't do miracles, sorry.<br />
<br />
Since Liberty Eiffel is free of charge and open-source, people who do<br />
need things we don't provide can always implement them and have them<br />
benefit everybody. A good way to do this is to start working on it,<br />
and ask other people (i.e. not the Liberty Eiffel team ;) ) to join and<br />
help. See the [[#HowCanIHelp|How can I help?]] question.<br />
<br />
Alternatively, someone or some company who does need us to implement<br />
something may always consider funding a bit the development of<br />
Liberty Eiffel... After all, we've even heard that some people were<br />
selling software and making a bit of money with it... ;)))<br />
<br />
===How do I '''keep informed''' about Liberty Eiffel?===<br />
The best way is to keep an eye on our web pages,<br />
more especially on the [http://www.liberty-eiffel.org/ Liberty Eiffel main website].<br />
<br />
<br />
===What <B>documentation</B> is provided with Liberty Eiffel?===<br />
The documentation provided with Liberty Eiffel is a transcript of what<br />
you can find on the original Liberty Eiffel Web site, see the link to this wiki.<br />
It is related only to the use and internals of Liberty Eiffel (yes,<br />
we know we still have to improve it ;) ).<br />
<br />
For information and documentation about the Eiffel programming language, check<br />
the links on our<br />
[http://SmartEiffel.loria.fr/general/resources.html Internet resources page].<br />
Note that we are not aware of any complete Eiffel language manual<br />
freely available on the Web (yet?).<br />
<br />
===Why don't you <B>post more messages</B> in newsgroups and/or mailing lists?===<br />
First, because we strongly believe that too much information kills information.<br />
Scientists call this "cognitive overload". :)<br />
<br />
Second, because we don't have the time. It takes an awful amount of time to follow<br />
discussions, whatever their quality. We try to do that. But it's even more<br />
time-consuming to be part of them. So, we often have to choose between<br />
posting/mailing, and working directly on Liberty Eiffel. Since our mailboxes tend<br />
to overflood, we generally choose the latter :)<br />
<br />
===Is it difficult to switch from some commercial Eiffel compiler to Liberty Eiffel?===<br />
If your original Eiffel software only uses simple types like INTEGER,<br />
STRING, ARRAY, BOOLEAN, CHARACTER and DOUBLE, it is usually very simple<br />
to modify your code in order to use Liberty Eiffel.<br />
<br />
It is a little bit difficult for simple input/output (used with predefined<br />
''io'') because some features have different names. If your original software<br />
heavily relies for example on the EiffelBase library, it may be '''very difficult'''.<br />
For example, one must keep in mind that SmartEiffel.ARRAY inherit <br />
SmartEiffel.COLLECTION and that ISE library also have a class COLLECTION. <br />
By the way, subclasses of ISE.COLLECTION cannot be used. <br />
The ISE.LINKED_LIST can be used in conjunction with SmartEiffel.ARRAY because <br />
ISE.LINKED_LIST do not inherit ISE.COLLECTION (no clash).<br />
<br />
==Questions about Languages and/or Object-Oriented Programming==<br />
<br />
<div id="StaticVsDynamicType"><br />
===What is the difference between the Static and the Dynamic Type?===<br />
</div><br />
The static type of a variable is determined at compile-time, the dynamic type during run-time.<br />
The dynamic type must conform to the static type (it may and often will be the same as the static type).<br />
<br />
E.g.: A variable might be declared to refer to an instance of class FRUIT (a_fruit: FRUIT), so the static type is FRUIT, but might be assigned an object of class APPLE (a_fruit := an_apple), which becomes the dynamic type. Obviously, APPLE has to be a descendant of FRUIT in this example.<br />
<br />
<div id="DynamicTypePrediction"><br />
===What is type prediction?===<br />
</div><br />
Type prediction is when the compiler attempts to predict an expression's [[#StaticVsDynamicType|dynamic type]] at compile time.<br />
<br />
==Questions about the Eiffel language of the Liberty Eiffel project==<br />
<br />
<div id="CaseSensitivity"><br />
===Why is Liberty Eiffel case-sensitive?===<br />
</div><br />
<br />
In fact, like most computer languages, Eiffel does distinguish between upper and lower case. Our decision is simply guided by the goals of legibility, organisation and simplification.<br />
<br />
As far as keywords are concerned, it is easier to distinguish them when they are always written in the same way. Thus, we always write '''loop''', rather than '''Loop''' or even '''LoOp'''. We have to get into good habits from now on in other matters too: this rule is going to be generalised so as to be even stricter in future. From now on, lets all get into the habit of writing '''Current''', '''Void''' or '''True''', for example.<br />
<br />
Upper case is also used to distinguish class names from other names. Thus, we can know that '''FOO''' is a class name and '''foo''' is not, without having to look elsewhere in the source code.<br />
<br />
A final advantage of the upper/lower case distinction is that it allows more precise error messages. What makes work simpler for humans also simplifies it for compilers.<br />
<br />
===What is the semantics (meaning) of a <B>manifest string</B>?===<br />
It can certainly be important to know what really happens when you define<br />
a constant STRING attribute by writing, for example: <br />
Message: STRING is "abc"<br />
that constant attribute definition is in fact a compact way of writing:<br />
Message: STRING is<br />
once<br />
create Result.make(3)<br />
Result.extend('a')<br />
Result.extend('b')<br />
Result.extend('c')<br />
end<br />
You realise, of course, that that function definition is a <TT>once</TT> function and<br />
consequently one string and one string only will be created, whatever happens.<br />
When you are investigating performance, you also have to know the difference between:<br />
string := "abc"<br />
and<br />
string := once "abc"<br />
You have probably guessed that, if the instruction without <TT>once</TT><br />
is in a loop, a new string is created each time that the line in question is executed!<br />
<br />
The <TT>once</TT> expression form above is only valid for manifest STRINGs and UNICODE_STRINGs.<br />
Here is an example of a manifest UNICODE_STRING (note the capital U):<br />
unicode_string := once U"abc"<br />
<br />
The [[http://SmartEiffel.loria.fr/man/compile_to_c.html compile_to_c]] command's <br />
<TT>-manifest_string_trace</TT> option <br />
allows you to locate unwanted non-once manifest strings.<br />
<br />
<div id="ConformanceVsCovariance"><br />
<br />
===Can you explain again the difference between <b>conformance</b> and <b>covariance</b>?===<br />
</div><br />
Our paper [http://SmartEiffel.loria.fr/papers/papers.html#JOT2004" Conformance of agents in the Eiffel language]<br />
has a note p.137 that looks surprising.<br />
<br />
<blockquote><br />
<i>Note that the previous rules define conformance rules, this has<br />
nothing to do with covariance or contravariance.</i><br />
</blockquote><br />
<br />
The concepts are distinct, even though there is a relation between<br />
them.<br />
<br />
Covariance is defined in terms of conformance. But assignment is<br />
''also'' defined in terms of conformance.<br />
<br />
That's exactly, and only, what our paper defines: assignment<br />
rules. Those rules were <i>not</i> defined anywhere before. It's<br />
important: <b>it's not that we disagreed with any earlier position. We<br />
just filled a hole in the specification.</b><br />
<br />
Also note that, even if the agent types notation uses square<br />
brackets, it's totally unrelated to the generic classes type notation;<br />
therefore generic classes rules cannot apply (except if proved<br />
otherwise). An agent type is not a generic type, anymore than a tuple<br />
type is a generic type. Those are distinct concepts, only with a<br />
similar notation.<br />
<br />
<P>Conformance is fundamental in any typed language; on the other hand<br />
covariance is "just" an Eiffel extra. Important, sure, but not as<br />
fundamental as conformance. Our paper never speaks of covariance,<br />
except in the note quoted above, and explained further here. Maybe the<br />
paper should have explained the subtlety in so many words.</P><br />
<br />
<div id="CATCALL"><br />
===What is a CATCALL?===<br />
</div><br />
In the Eiffel world ''CATCALL'' is about type safety problems which are still present in <br />
the language.<br />
In Eiffel, CATCALL is a short-hand for ''Changing Availability or Type of CALLs''.<br />
<br />
''Availability'' is about the exportation status of some method.<br />
For example, when a method is redefined, it's exportation status can be<br />
changed too.<br />
<br />
''Type of CALLs'' is about some possibly [[Glossary#Covariance|covariant]] redefinition.<br />
<br />
<div id="SCOOP"><br />
<br />
===What is SCOOP ?===<br />
</div><br />
<br />
In Eiffel, [[SCOOP]] refers to language support for distributed programming.<br />
In the Eiffel world, it is an acronym for ''Simple Concurrent Object-Oriented Programming''.<br />
SCOOP is not yet included in Liberty Eiffel and is certainly its most important missing feature.<br />
<br />
===Is there a style guide for Eiffel source code?===<br />
Yes. Source code in Liberty tools and libraries should conform to the [[Coding Style Guide]]. It seems reasonable to use this as a reference for your own project.<br />
<br />
==Questions about libraries which comes along with Liberty Eiffel==<br />
<br />
===How should I read a file?===<br />
In order to read a file, read a character and then use<br />
last_character ONLY if end_of_input has not been reached<br />
while reading the character.<br />
<BR><br />
Before each read (except the very first), you have to test<br />
end_of_input, because all read_* procedures require not<br />
end_of_input. But why? This require means that if some<br />
previous read failed because end of input has been reached,<br />
then it is not valid to try to read again.<br />
Example:<br />
file: TEXT_FILE_READ; file_name: STRING<br />
...<br />
-- ''Assumming here that'' `file' ''and'' `file_name' ''are not'' [[Void|<tt>Void</tt>]]:<br />
file.connect_to(file_name)<br />
if file.is_connected then<br />
from<br />
file.read_character<br />
until<br />
file.end_of_input<br />
loop<br />
io.put_character(file.last_character)<br />
file.read_character<br />
end<br />
file.disconnect<br />
end<br />
<br />
If you want to read the file line by line, then <tt>read_line</tt><br />
or <tt>read_line_in</tt> can be used. But the reading pattern<br />
<B>is different</B>. This is because after the last line of<br />
the file has been read, then the last line is in <tt>last_string</tt><br />
and has to be used.<br />
Example:<br />
file: TEXT_FILE_READ; file_name: STRING<br />
...<br />
-- ''Assumming here that'' `file' ''and'' `file_name' ''are not'' [[Void|<tt>Void</tt>]]:<br />
file.connect_to(file_name)<br />
if file.is_connected then<br />
from<br />
until<br />
file.end_of_input<br />
loop<br />
file.read_line<br />
if file.end_of_input then<br />
-- The last line of the file does not end with a new<br />
-- line character. Remove this test if you don't care.<br />
std_output.put_string(file.last_string)<br />
else<br />
std_output.put_line(tfr.last_string)<br />
end<br />
end<br />
file.disconnect<br />
end<br />
<br />
<B>Note: </B><tt>last_string</tt> always returns the same STRING object, it's up<br />
to you to make a copy if you need to keep the string value.<br />
<br />
You can read the examples in tutorial directory from the Liberty Eiffel distribution.<br />
<br />
==Questions about the tools of Liberty Eiffel==<br />
<br />
===Is it possible to do <B>incremental compilation</B> with Liberty Eiffel?===<br />
Because of the Liberty Eiffel type inference mechanism,<br />
Liberty Eiffel always produces all needed C files from scratch. As old C files<br />
are automatically saved, only modified C files are recompiled.<br />
See <TT>[http://SmartEiffel.loria.fr/man/compile.html man/compile]</TT> for details.<br />
<br />
===Is there a mechanism to <B>pre-compile</B> libraries?===<br />
No, there is no such mechanism in Liberty Eiffel. But if you're concerned<br />
about compilation speed, don't worry, pre-computed libraries are not the only way to be fast !<br />
Just try Liberty Eiffel, and you'll see :)<br />
<br />
<br />
===Is it possible to use the <B>Boehm-Demers-Weiser garbage collector</B> with Liberty Eiffel?===<br />
Yes.<br />
<BR>You just have to pass the compiler option -bdw_gc and this should it be.<br />
<br />
===How to customise the <B>Garbage Collector</B> for a new architecture?===<br />
</div><br />
If your architecture needs special handling to get the GC working<br />
(because the stack is not contiguous, because some registers are not<br />
written on the stack on `setjmp'...) then you need to implement function<br />
`mark_stack_and_registers' for your system in the file<br />
<TT>SmartEiffel/sys/runtime/c/gc_lib.c</TT>.<br />
<BR><br />
<br />
If you get some message telling you that the stack direction is wrong, then<br />
you should change macro definition to use the other generic code<br />
(there is one generic code for each stack order).<br />
<BR><br />
<br />
In order to check the GC, you should be able to run all files of<br />
the <TT>SmartEiffel/misc/benchmarks/gc</TT> directory.<br />
</TD><br />
</TR><br />
<br />
===How is Liberty Eiffel compiled?===<br />
With Eiffel optimisation options -boost and -no_gc. The garbage collector is<br />
indeed useless on the Liberty Eiffel commands: since Liberty Eiffel did not include a GC in its first versions, we were very careful about memory when we developed it.<br />
<br />
With C compilation optimisations turned on (it depends on the C compiler used;<br />
we generally use gcc).<br />
The resulting executables are stripped.<br />
<br />
<div id="External tools for Liberty Eiffel"><br />
<br />
==External tools for Liberty Eiffel==<br />
</div><br />
<br />
<div id="Syntax highlighting"><br />
===Are there editors with support for Liberty Eiffel?===<br />
<br />
* [https://www.gnu.org/s/emacs/ Emacs] has support for syntax highlighting, indenting, flymake mode, code templates and more. For installation see the article ''[http://www.berenddeboer.net/eiffel/eiffel_and_emacs.html Editing Eiffel code with Emacs]'' from Berend de Boer but you may use the distributed version of <code>[http://git.savannah.gnu.org/cgit/liberty-eiffel.git/plain/work/eiffel.el eiffel.el]</code> (in the work/ directory of the source distribution).<br />
<br />
* [http://www.vim.org Vim] also has similar support for Eiffel and [https://github.com/LibertyEiffel/vim-liberty-eiffel specific additions for Liberty Eiffel]<br />
<br />
* [https://atom.io/ Atom] has an [https://atom.io/packages/language-eiffel Eiffel package] available.<br />
<br />
* [http://www.macromates.com TextMate] has an [https://github.com/textmate/eiffel.tmbundle Eiffel bundle] available.<br />
<br />
* [https://wiki.gnome.org/Apps/Gedit Gedit] offers syntax highlighting.<br />
<br />
* [http://www.scintilla.org/SciTE.html SciTE] offers syntax highlighting and folding.<br />
<br />
* On Windows [https://notepad-plus-plus.org/ Notepad++] offers syntax highlighting as well.<br />
<br />
* [https://www.editpadpro.com/editeiffel.html EditPad Pro] supports several features for Eiffel.<br />
<br />
===Is there a GUI or IDE for Liberty Eiffel?===<br />
<br />
An [https://github.com/Imhotup/LibertyEiffel-Eclipse-Plugin Eclipse-based IDE] is currently under development as part of [[GSoC]] 2016.<br />
<br />
<div id="Liberty Eiffel debugger with GUI"><br />
<br />
===Is there a debugger for Liberty Eiffel with a GUI?===<br />
</div><br />
Currently not. There was a front end for the sedb (SmartEiffel debugger). It is called ''SmartEiffel Embedded Debugger Output Visualiser'' (sedbov). It maps the key command from the sedb to a GUI. You can find it at https://opensvn.csie.org/traccgi/sedbov/wiki/WikiStart. It use the script language TCL/TK with the extension expect. For information look at http://www.tcl.tk.<br />
<br />
<div id="LibertyEiffelWiki"><br />
<br />
==External information about Eiffel==<br />
</div><br />
<br />
<div id="Where can i find more information about Eiffel?"><br />
===Where can I find more information about Eiffel?===<br />
</div><br />
The news group news:comp.lang.eiffel has low post frequency.<br />
<br />
<div id="I am a beginner. Where can i find tutorials?"><br />
<br />
===I am a beginner. Where can I find tutorials?===<br />
</div><br />
You should study and compile the examples in the tutorials directory.<br />
<br />
Cetus contains links to tutorial papers (http://www.cetus-links.org/oo_eiffel.html).</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Build_your_library&diff=2451Build your library2016-06-16T11:46:51Z<p>Dkearns: Copy editing</p>
<hr />
<div>[[Category: Library]]<br />
We're not going to give a course in architectural concepts here, but we'll give the details of how the Liberty Eiffel utilities can help you write high quality libraries.<br />
<br />
The simplest case is that of a "100% Eiffel" library. In this case Liberty Eiffel provides its compiler and its [[Library interface|standard library]], which already contain a rich variety of features.<br />
<br />
Liberty Eiffel also provides a documentation utility: [[eiffeldoc|eiffeldoc]].<br />
<br />
In certain cases, a library must be able to interface with the underlying system, to get access to low level functions. One can imagine, for example, creating an audio library (sorry, these days one says "multimedia"), to make system calls to access the sound card.<br />
<br />
Liberty Eiffel provides a powerful utility: [[plugins]]. You can also use, even though it has been superseded, an older mechanism, [[externals|externals]].<br />
<br />
There are also two other mechanisms: [[inlining|inlining]] and [[cecil]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Build_your_library&diff=2450Build your library2016-06-16T11:44:51Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Library]]<br />
We're not going to give a course in architectural concepts here, but we'll give the details of how the Liberty Eiffel utilities can help you write high quality libraries.<br />
<br />
The simplest case is the case of a "100% Eiffel" library. In this case Liberty Eiffel provides its compiler and its [[Library interface|standard library]], which already contain a rich variety of features.<br />
<br />
Liberty Eiffel also provides a documentation utility: [[eiffeldoc|eiffeldoc]].<br />
<br />
In certain cases, a library must be able to interface with the underlying system, to get access to low level functions. One can imagine, for example, creating an audio library (sorry, these days one says "multimedia"), to make system calls to access the sound card...<br />
<br />
Liberty Eiffel provides a powerful utility: [[plugins]]. You can also, even though it has been superseded, use an older mechanism, [[externals|externals]].<br />
<br />
There are also two other mechanisms: [[inlining|inlining]] and [[cecil]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Lib/regular_expression&diff=2449Lib/regular expression2016-06-16T11:37:19Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Library]]<br />
== Regular expressions in Liberty Eiffel ==<br />
In Liberty Eiffel, a cluster is included that allows you to use either POSIX regular expressions or PERL5 regular expressions.<br />
<br />
Currently the regular expression cluster makes use of the backtracking cluster. <br />
<br />
The main restriction comes from the character set used; this is the ASCII character set.<br />
UNICODE characters are not supported at the moment.<br />
<br />
Another restriction is that most of the common character escapes do not work:<br />
\n is a literal n, not new line; \t is a literal t, not tab; etc.. The reason is that we thought that<br />
users could do such preprocessing themselves, and we had a schizophrenic conflict<br />
between %N and \n. Your opinion about that point is very welcome.<br />
<br />
Known problems:<br />
* The construct <TT>(a?b?)*</TT> causes an infinite loop and crashes with a stack overflow.<br />
* The construct <TT>(a+)+</TT> can use so much CPU that you believe that it is buggy.<br />
* The construct <TT>(a(b)?)*</TT> applied on <TT>aba</TT> will give you a group 2 not empty, beginning at 2 and finishing at 2.<br />
<br />
As always, see the tutorial to learn how to use regular expressions.<br />
<br />
== The POSIX regular expressions ==<br />
<br />
The POSIX regular expression are supported except for the [=...=] construct (same class that ...).<br />
<br />
See POSIX 1003.2, section 2.8 (Regular Expression Notation). [http://www.unix.org/ www.unix.org]<br />
<br />
On LINUX: man 7 regex.<br />
<br />
== The PERL 5 regular expressions ==<br />
<br />
With the main restriction that UNICODE is not handled, most of the PERL 5 regular expressions is implemented.<br />
See [http://perldoc.perl.org/perlre.html Perl Regular expressions].<br />
<br />
Missing things:<br />
* The experimental behaviours are not integrated <br />
* Some construct like [[:] that are well interpreted by perl produce an error. In these cases, you must write [:[].<br />
<br />
Added things:<br />
* The look behind (negative or positive) is not restricted to have a fixed length.<br />
* The POSIX constructs [:<:] and [:>:] are allowed (it stands for begin and end of words).<br />
<br />
== Coming soon? ==<br />
<br />
* The shell (bash) file matching (help wanted)<br />
* The basic regular expression (help wanted)<br />
* The JAVA regular expressions (help wanted, trick inherit PERL5 builder and make the hungry repetition)<br />
<br />
''If you want to look forwards, consider implementing Perl 6 regular expressions (now called Perl 6 rules, because they go so far beyond regexps). Perl 6 rules combine traditional regexps with parsing grammars, eliminating the use for tools such as lex/yacc. Here are some details:''<br />
<br />
* Larry Wall's explanation of the changes: http://dev.perl.org/perl6/doc/design/apo/A05.html<br><br />
<br />
* Damian Conway's specification of Perl 6 rules: http://dev.perl.org/perl6/doc/design/exe/E05.html<br />
<br />
* Patrick Michaud's tutorial (assumes knowledge of Perl 5 regexps): http://dev.perl.org/perl6/doc/design/syn/S05.html<br />
<br />
* IBM overview of Perl 6 Rules: http://www-128.ibm.com/developerworks/linux/library/l-cpregex.html?ca=dgr-lnxw01Perl6Gram<br />
<br />
[[User:Eiffel|Roger Browne]] 23:12, 4 Dec 2005 (CET)</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Versions_history&diff=2448Versions history2016-06-16T11:29:12Z<p>Dkearns: Typo</p>
<hr />
<div>[[Category: Releases]]<br />
== Liberty Eiffel (latest release first) ==<br />
For other upcoming releases see the [[upcoming releases|list of names]].<br />
=== Curtiss (2016.dev, to be named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===<br />
* not yet released (see next section for current release notes)<br />
* User-visible changes:<br />
** addition of a zsh completer for se<br />
** finally got rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND<br />
** removed support for some unused platforms (Amiga, Elate, BeOS, ...)<br />
** creation keyword now generates an error<br />
** C99 conforming C code generation (hopefully)<br />
* Developer changes:<br />
** RUN_FEATUREs now have clear names (hopefully)<br />
** to better support the more recent Windows versions, the config file is no longer written to a root directory but rather to %ALLUSERSPROFILE% or %USERPROFILE% <br />
* Known bugs:<br />
** see [https://savannah.gnu.org/bugs/?group=liberty-eiffel] for the full list<br />
<br />
=== Bell (2016.05, named after [https://en.wikipedia.org/wiki/Alexander_Graham_Bell Alexander Graham Bell]) ===<br />
* released in May 2016<br />
* first release since Liberty Eiffel has become the official GNU Eiffel compiler<br />
* User-visible changes:<br />
** changed Environment Variable name from SmartEiffel to LibertyEiffel (anyhow, normally it should not be necessary to set this one)<br />
** new tool [[Mock]]<br />
** removed linebreaks in compiler output<br />
** many bugfixes<br />
** GC call at exit is optional<br />
** generic creation<br />
** agents are now [https://en.wikipedia.org/wiki/Closure_(computer_programming) closures ]<br />
** finder now finds all classes in the universe with the given name, not only the first one<br />
** keyword '''is''' at the beginning of a feature is now deprecated<br />
** Added support for alias "[]" and alias "()"<br />
** constants are now visible in the eiffeldoc generated documentation<br />
* Known bugs:<br />
** there is still an issue in both GC implementations (classical SEGC and BDW), if it shows up, it often yields a "Bad target type" runtime error.<br />
** for the full list see [https://savannah.gnu.org/bugs/?group=liberty-eiffel]<br />
<br />
=== Adler (2013.11, named after [http://en.wikipedia.org/wiki/Charles_Adler,_Jr. Charles Adler, Jr.]) ===<br />
* First release as Liberty Eiffel<br />
* User-visible changes:<br />
** Added [[library_class:NATURAL_8|<tt>NATURAL_8</tt>]], [[library_class:NATURAL_16|<tt>NATURAL_16</tt>]], [[library_class:NATURAL_32|<tt>NATURAL_32</tt>]], and [[library_class:NATURAL_64|<tt>NATURAL_64</tt>]] classes. See <tt>tutorial/natural.e</tt> for examples.<br />
** Even low-level features (i.e. <tt>external "built_in"</tt>) are now checking their assertions. As an example, division by zero is now checked by assertions.<br />
** Inlined dynamic dispatch for better performance<br />
** A missing export clause is deprecated. Use <tt>{ANY}</tt> instead.<br />
** New core libraries: cli, json, log, parse (beware, these libraries are not yet tuned to be used without GC)<br />
** Improved libraries: string (with notably a new [[library_class:FIXED_STRING|<tt>FIXED_STRING</tt>]] class)<br />
** Wrapper libraries: gtk, gdk, readline, ffi...<br />
** A new tool that can generate mocks to help unit testing<br />
** [http://hboehm.info/gc/ BDW] GC support<br />
* Developer changes:<br />
** The web site now belongs to the repository<br />
** Automatic testing tools (ET on the web, and <tt>watch_eiffeltest.sh</tt> in the shell)<br />
** Automatic Debian packages generation<br />
* Known bugs:<br />
** BDW GC is not well tested; currently weak references seem not to work properly; and the GC is not run at program exit (it should run all finalizers)<br />
** Sometimes SmartEiffel's native GC behaves wrongly, analysis is welcome<br />
** Some of the newer core libraries do not work very well when there is no GC<br />
** See the [https://savannah.gnu.org/bugs/?group=liberty-eiffel bugs page]<br />
<br />
== SmartEiffel (all releases which are predecessors of Liberty) ==<br />
<br />
<br />
=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===<br />
<br />
Again, a lot of novelties for this release:<br />
<br />
* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.<br />
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Plugins&diff=2447Plugins2016-06-16T11:28:05Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Interfacing]]<br />
Plugins are a means to augment the capabilities of Liberty Eiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].<br />
<br />
The goal of plugins is independence from the [[Glossary#BackEnd|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd|back-ends]]. In this case, the plugin system will become more important.<br />
<br />
== How does it work&nbsp;? ==<br />
<br />
A plugin is made up of two interdependent parts&nbsp;:<br />
<br />
* the Eiffel side, which provides an interface usable by other Eiffel objects&nbsp;;<br />
* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd|back-ends]] (for example, C and Java).<br />
<br />
The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the Liberty Eiffel compiler which associates external functions with the ''external'' features using configuration files furnished by the plugin.<br />
<br />
== Eiffel Side ==<br />
<br />
The Eiffel side uses ''external'' features. The syntax is as follows:<br />
<br />
feature<br />
my_plugin_feature is<br />
external "plug_in"<br />
alias "{<br />
location: "/path/to/my/plugins"<br />
module_name: "my_plugin"<br />
feature_name: "feature"<br />
}"<br />
<br />
Of course, a feature can take arguments and return a result&nbsp;! (after all, it's an ''external'') ;-)<br />
<br />
'''Beware''' however, it is necessary to only pass and return only basic ''expanded'' base types&nbsp;:<br />
([[library_class:INTEGER|<TT>INTEGER</TT>]], [[library_class:BOOLEAN|<TT>BOOLEAN</TT>]], etc.) or use [[library_class:POINTER|<TT>POINTER</TT>]] (common usage: <TT>a_string.to_external</TT>).<br />
<br />
* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables defined in the <TT>[Environment]</TT> section of your [[Configuration file|configuration file]]).<br />
For example, the standard Liberty Eiffel libraries are defined by using the following ''location'':<br />
location: "${sys}plugins"<br />
<br />
* '''module_name''' contains the plugin name itself. This must be the name of a sub-directory of ''location'' that contains a directory for a specific [[Glossary#BackEnd|back-end]] (for example, <TT>c</TT> for the C generator, <TT>java</TT> for the Java generator). The content of each of these sub-repositories depends on the generator, and is specified below.<br />
<br />
* '''feature_name''' is the name of the feature, function, method etc. named by the [[Glossary#BackEnd|back-end]] (for example, C calls functions, Java calls methods). What they're called is not important&nbsp;: they're all features ;-)<br />
<br />
== Dark side ==<br />
<br />
=== C Generation ===<br />
<br />
The C [[Glossary#BackEnd|back-end]] uses a sub-directory of your plugin named <TT>c</TT>. the files used are:<br />
<br />
* all the <TT>.c</TT> files, which are included in the compiler-generated C files<br />
* all the <TT>.h</TT> files, which are included in the compiler-generated header file<br />
* the <TT>libs</TT> file, which contains a description of the native libraries to link<br />
* the <TT>paths</TT> file, which contains a description of the paths used to find the libraries<br />
* the <TT>includes</TT> file, which contains a description of the paths used to find header files<br />
* the <TT>auto_init</TT> file, which contains a description of a possible initialization function called at the very start of the program<br />
* the <TT>cecil.se</TT> file, which is a [[cecil]] description automatically taken into account<br />
* the <TT>compiler_options</TT> and the <TT>linker_options</TT> files which are passed verbatim to the underlying strata of compiling chain, usually a C compiler where they are parsed with a shell. They usually contains invocation of tools that gives the mutable correct flags to compile and link the library, i.e. pkg-config.<br />
<br />
The '''<TT>.c</TT> and <TT>.h</TT>''' files are included in alphabetic order.<br />
<br />
The '''<TT>includes</TT>, <TT>libs</TT> and <TT>paths</TT>''' files use an identical syntax to that of the [[configuration file]], but with different keys:<br />
* The sections carry the operating system name, the ''flavor'' from the configuration file and finally the C compiler used, in that order and separated by a period. If the plugin doesn't depend on one of these elements, it can be omitted.<br />
* The keys in these files are only informative; however, the values are used to generate command line calls to the C compiler.<br />
<br />
The '''<TT>auto_init</TT>''' file uses the same syntax as the [[configuration file]], but with yet other keys:<br />
* The default section (i.e. the first one, without a name between square brackets) contains one key, <TT>function</TT> which value gives the name of the initialization function to call at the start of the system<br />
* Any other section describes plugin dependencies. The must have two keys: <TT>location</TT> and <TT>module_name</TT> which have the same meaning as in the Eiffel alias. Those dependencies describe initialization order (initialize dependencies first).<br />
<br />
The '''<TT>cecil.se</TT>''' file is automatically included as it were specified by the <TT>-cecil</TT> option.<br />
<br />
For examples, you can examine the configurations files for Vision or ncurses. There is also a tutorial called '''mini_gtk''' (in the <TT>SmartEiffel/tutorial/plugin</TT> directory).<br />
<br />
'''Note''': when there are no arguments, names are generated without parentheses. This permits to attributes, variables and to macros. The absence of parentheses is not then a bug but a desired behavior. In the case where one wants access to a function without an argument, it suffices to use a macro to replace a name without parentheses with the name of the function to call.<br />
<br />
=== Java Generation===<br />
<br />
NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to the legacy<BR> SmartEiffel system, Liberty Eiffel's predecessor.<br />
<br />
For the Java [[Glossary#BackEnd|back-end]], the plugin sub-directory must be named <TT>java</TT>.<br />
The compiler uses the following files&nbsp;:<br />
<br />
* the <TT>.java</TT> files are compiled using the command line options and/or from the configuration file (see [[compile_to_jvm]] for more detail). The <TT>.class</TT> files so generated are automatically copied in the compilation directory of the program.<br />
* the <TT>.class</TT> files, if they are present and if they are more recent than the corresponding <TT>.java</TT> files are utilized in place of a compilation of the <TT>.java</TT> files, in the same manner as the <TT>make</TT> command under UNIX.<br />
<br />
To shorten the compilation time of a program dependent on plugins supplied with the compiler (like for example the <TT>io</TT> plugin), the installer will compile the <TT>.java</TT> plugin files during installation.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Plugins&diff=2446Plugins2016-06-16T11:26:38Z<p>Dkearns: Typos</p>
<hr />
<div>[[Category: Interfacing]]<br />
Plugins are a means to augment the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].<br />
<br />
The goal of plugins is independence from the [[Glossary#BackEnd|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd|back-ends]]. In this case, the plugin system will become more important.<br />
<br />
== How does it work&nbsp;? ==<br />
<br />
A plugin is made up of two interdependent parts&nbsp;:<br />
<br />
* the Eiffel side, which provides an interface usable by other Eiffel objects&nbsp;;<br />
* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd|back-ends]] (for example, C and Java).<br />
<br />
The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the LibertyEiffel compiler which associates external functions with the ''external'' features using configuration files furnished by the plugin.<br />
<br />
== Eiffel Side ==<br />
<br />
The Eiffel side uses ''external'' features. The syntax is as follows:<br />
<br />
feature<br />
my_plugin_feature is<br />
external "plug_in"<br />
alias "{<br />
location: "/path/to/my/plugins"<br />
module_name: "my_plugin"<br />
feature_name: "feature"<br />
}"<br />
<br />
Of course, a feature can take arguments and return a result&nbsp;! (after all, it's an ''external'') ;-)<br />
<br />
'''Beware''' however, it is necessary to only pass and return only basic ''expanded'' base types&nbsp;:<br />
([[library_class:INTEGER|<TT>INTEGER</TT>]], [[library_class:BOOLEAN|<TT>BOOLEAN</TT>]], etc.) or use [[library_class:POINTER|<TT>POINTER</TT>]] (common usage: <TT>a_string.to_external</TT>).<br />
<br />
* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables defined in the <TT>[Environment]</TT> section of your [[Configuration file|configuration file]]).<br />
For example, the standard LibertyEiffel libraries are defined by using the following ''location'':<br />
location: "${sys}plugins"<br />
<br />
* '''module_name''' contains the plugin name itself. This must be the name of a sub-directory of ''location'' that contains a directory for a specific [[Glossary#BackEnd|back-end]] (for example, <TT>c</TT> for the C generator, <TT>java</TT> for the Java generator). The content of each of these sub-repositories depends on the generator, and is specified below.<br />
<br />
* '''feature_name''' is the name of the feature, function, method etc. named by the [[Glossary#BackEnd|back-end]] (for example, C calls functions, Java calls methods). What they're called is not important&nbsp;: they're all features ;-)<br />
<br />
== Dark side ==<br />
<br />
=== C Generation ===<br />
<br />
The C [[Glossary#BackEnd|back-end]] uses a sub-directory of your plugin named <TT>c</TT>. the files used are:<br />
<br />
* all the <TT>.c</TT> files, which are included in the compiler-generated C files<br />
* all the <TT>.h</TT> files, which are included in the compiler-generated header file<br />
* the <TT>libs</TT> file, which contains a description of the native libraries to link<br />
* the <TT>paths</TT> file, which contains a description of the paths used to find the libraries<br />
* the <TT>includes</TT> file, which contains a description of the paths used to find header files<br />
* the <TT>auto_init</TT> file, which contains a description of a possible initialization function called at the very start of the program<br />
* the <TT>cecil.se</TT> file, which is a [[cecil]] description automatically taken into account<br />
* the <TT>compiler_options</TT> and the <TT>linker_options</TT> files which are passed verbatim to the underlying strata of compiling chain, usually a C compiler where they are parsed with a shell. They usually contains invocation of tools that gives the mutable correct flags to compile and link the library, i.e. pkg-config.<br />
<br />
The '''<TT>.c</TT> and <TT>.h</TT>''' files are included in alphabetic order.<br />
<br />
The '''<TT>includes</TT>, <TT>libs</TT> and <TT>paths</TT>''' files use an identical syntax to that of the [[configuration file]], but with different keys:<br />
* The sections carry the operating system name, the ''flavor'' from the configuration file and finally the C compiler used, in that order and separated by a period. If the plugin doesn't depend on one of these elements, it can be omitted.<br />
* The keys in these files are only informative; however, the values are used to generate command line calls to the C compiler.<br />
<br />
The '''<TT>auto_init</TT>''' file uses the same syntax as the [[configuration file]], but with yet other keys:<br />
* The default section (i.e. the first one, without a name between square brackets) contains one key, <TT>function</TT> which value gives the name of the initialization function to call at the start of the system<br />
* Any other section describes plugin dependencies. The must have two keys: <TT>location</TT> and <TT>module_name</TT> which have the same meaning as in the Eiffel alias. Those dependencies describe initialization order (initialize dependencies first).<br />
<br />
The '''<TT>cecil.se</TT>''' file is automatically included as it were specified by the <TT>-cecil</TT> option.<br />
<br />
For examples, you can examine the configurations files for Vision or ncurses. There is also a tutorial called '''mini_gtk''' (in the <TT>SmartEiffel/tutorial/plugin</TT> directory).<br />
<br />
'''Note''': when there are no arguments, names are generated without parentheses. This permits to attributes, variables and to macros. The absence of parentheses is not then a bug but a desired behavior. In the case where one wants access to a function without an argument, it suffices to use a macro to replace a name without parentheses with the name of the function to call.<br />
<br />
=== Java Generation===<br />
<br />
NB: LibertyEiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to the legacy<BR> SmartEiffel system, LibertyEiffel's predecessor.<br />
<br />
For the Java [[Glossary#BackEnd|back-end]], the plugin sub-directory must be named <TT>java</TT>.<br />
The compiler uses the following files&nbsp;:<br />
<br />
* the <TT>.java</TT> files are compiled using the command line options and/or from the configuration file (see [[compile_to_jvm]] for more detail). The <TT>.class</TT> files so generated are automatically copied in the compilation directory of the program.<br />
* the <TT>.class</TT> files, if they are present and if they are more recent than the corresponding <TT>.java</TT> files are utilized in place of a compilation of the <TT>.java</TT> files, in the same manner as the <TT>make</TT> command under UNIX.<br />
<br />
To shorten the compilation time of a program dependent on plugins supplied with the compiler (like for example the <TT>io</TT> plugin), the installer will compile the <TT>.java</TT> plugin files during installation.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Configuration_file&diff=2445Configuration file2016-06-16T11:05:27Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Most Liberty Eiffel tools need some kind of configuration which is stored in a unique file to allow the user not too have over-long command lines ;-)<br />
<br />
In particular it contains<br />
* general settings like system type, number of processes to start during compilation<br />
* paths to find tools, environment variables, [[short]] templates...<br />
* paths of the clusters that define all the classes available by default (the universe).<br />
* '''se''' shortcuts for the available tools<br />
* C-compiler options for each c_mode<br />
<br />
An initial version of this configuration is generated by [[install|the installation tool]] of Liberty Eiffel.<br />
<br />
== Where is this configuration ==<br />
It is possible to have several configuration files, which are treated by priority and more specific files can override the settings from the general ones. The lowest priority is attributed to system-wide files, while user-specific (e.g. <tt>~/.serc</tt>) and session-specific (the <tt>Liberty</tt> environment variable) get higher priority. In case a configuration location is a directory, all the entries of the directory are merged (or to be accurate: all entries are handled with priority defined via alphabetical sort of the names). All that because of some distributions like to add/remove files instead of grep'ing and sed'ing huge configuration file.<br />
Default configuration file locations:<br />
{|<br />
|-<br />
| Windows and DOS:<br />
| '''<TT>%ALLUSERSPROFILE%\Liberty-Eiffel</TT>''', <TT>%USERPROFILE%\SE.CFG</TT>, <TT>%USERPROFILE%\LIBERTY.CFG</TT>, '''<TT>%USERPROFILE%\Liberty-Eiffel</TT>''' (lookup in this order)<br />
|-<br />
| Unix and Cygwin:<br />
| <TT>/etc/serc</TT>, <TT>/etc/xdg/liberty-eiffel</TT>, '''<TT>/etc/liberty-eiffel</TT>''', <TT>/usr/local/etc/liberty-eiffel</TT>, '''<TT>~/.config/liberty-eiffel</TT>''', <TT>~/.serc</TT> <TT>~/.liberty-eiffel</TT> (look-up in this order, XDG_CONFIG_HOME is taken into account to adjust the paths)<br />
|-<br />
| Elate:<br />
| <TT>/lang/eiffel/serc</TT><br />
|}<br />
The suggested directories are '''bold'''.<br />
<br />
The other operating systems don't have a default value, the <tt>Liberty</tt> environment variable must be used. If you have such an operating system and you think there is a reasonable default value, '''thanks for telling us'''.<br />
<br />
== File syntax ==<br />
<br />
The file is written using a simple text format. It is split in sections that each begin with a word between square brackets on a single line. Each section is comprised of key-value pairs separated by a colon.<br />
<br />
Example:<br />
<br />
[General]<br />
bin: /home/cyril/Liberty/bin/<br />
sys: /home/cyril/Liberty/sys/<br />
short: /home/cyril/Liberty/short/<br />
os: UNIX<br />
flavor: Linux<br />
tag: 3<br />
jobs: 4<br />
<br />
=== The General section ===<br />
<br />
This section is named <TT>[General]</TT>. It must provide the following keys:<br />
<br />
{|<br />
|-<br />
| width="10%" valign="top" | <TT>bin</TT><br />
| the path to the compiler executables. This path is used in particular by the [[se]] tool (see below the Tools section) and [[compile]].<br />
|-<br />
| valign="top" | <TT>sys</TT><br />
| the path to the Liberty Eiffel system files. This path is used by [[compile_to_c]]. It contains all the basic files included by those compilers. They define the "basic bricks" of the generated Eiffel system.<br />
|-<br />
| valign="top" | <TT>short</TT><br />
| the path to the [[short]] templates (modes <TT>-html</TT>, <TT>-tex</TT>, etc.)<br />
|-<br />
| valign="top" | <TT>os</TT><br />
| the type of the operating system Liberty Eiffel is installed on. The recognized types are: UNIX, Windows, Cygwin, BeOS, Macintosh, Amiga, DOS, OS2, OpenVMS, Elate.<br />
|-<br />
| valign="top" | <TT>flavor</TT><br />
| allows a more accurate specification of the operating system type, useful for some plugins. For instance, if the <TT>os</TT> is UNIX, the <TT>flavor</TT> can be Linux. There is no predefined list of values; plugins must tell which are the supported <TT>flavor</TT>s.<br />
|-<br />
| valign="top" | <TT>tag</TT><br />
| normally only used by the [[install|installation tool]] to define the version of the configuration file. There should be ascending compatibility between versions but '''currently, if the tag is not the one of the installation tool, no data is kept'''. This behavior was changed in SmartEiffel 2.3, to keep as much data as possible.<br />
<br />
The tag value was '''3''' for SmartEiffel 2.2 and 2.3.<br />
|-<br />
| valign="top" | <TT>jobs</TT><br />
| if a tool has some tasks which may be done in parallel (e. g. calling the C compiler for generated C files) it creates at most the configured amount of processes. Performance-wise, it's likely best not to use hyperthreading, especially when compiling big systems. An example: if your system reports a quadcore processor, it might actually be equipped with a dualcore with hyperthreading activated. In that case it's likely best to set <TT>jobs</TT> to 2 and not to 4.<br />
|}<br />
<br />
=== The Environment section ===<br />
<br />
The environment section allows you to define ''environment variables'' specific to Liberty Eiffel. In particular these variables are available in the remaining of the configuration file, in the <tt>loadpath.se</tt> files, ACE files and some command line arguments.<br />
<br />
The [[install|installation tool]] installs the following default variables:<br />
<br />
[Environment]<br />
path_liberty: /home/cyril/Liberty/<br />
path_liberty_core: /home/cyril/Liberty/src/lib/<br />
path_liberty_extra: /home/cyril/Liberty/src/wrappers/<br />
path_smarteiffel: /home/cyril/Liberty/src/smarteiffel/<br />
path_tools: /home/cyril/Liberty/src/tools/<br />
path_tutorial: /home/cyril/Liberty/tutorial/<br />
<br />
Note that anyone can add their own variables.<br />
<br />
=== The universe ===<br />
<br />
The universe is the set of all known clusters. It is defined in the <TT>[Loadpath]</TT> section.<br />
<br />
The [[install|installation tool]] installs the following default universe:<br />
<br />
[Loadpath]<br />
liberty_core: ${path_liberty_core}loadpath.se<br />
liberty_extra: ${path_liberty_extra}loadpath.se<br />
test: ${path_liberty}test/loadpath.se<br />
smarteiffel: ${path_smarteiffel}loadpath.se<br />
tools: ${path_tools}loadpath.se<br />
tutorial: ${path_tutorial}loadpath.se<br />
<br />
Note that anyone can add their own tools to the libraries they use most.<br />
<br />
'''Caveat''': the universe is ''not'' used by the tools if an ACE file is given. In this case, the ACE file must describe the whole universe. On the other hand it is very simple to do so since just adding a single line or two to your ACE file will produce the desired effect:<br />
<br />
cluster<br />
standard: "${path_liberty_core}loadpath.se"<br />
<br />
=== Tools ===<br />
<br />
All the tools used by the [[se]] command are set here. These tools must be in the directory pointed to by the <tt>bin</tt> key of the <tt>[General]</tt> section. The key is used as first argument of [[se]].<br />
<br />
The [[install|installation tool]] installs the following default commands:<br />
<br />
[Tools]<br />
ace_check: ace_check<br />
c2c: compile_to_c<br />
c: compile<br />
class_check: class_check<br />
clean: clean<br />
doc: eiffeldoc<br />
find: finder<br />
make: se_make.sh<br />
mock: mocker<br />
pretty: pretty<br />
short: short<br />
test: eiffeltest<br />
test_ng: eiffeltest_ng<br />
test_server: eiffeltest_server<br />
wrap: wrappers_generator<br />
x_int: extract_internals<br />
<br />
Note that anyone can add their own tools, as long as the executable is in the directory pointed to by the <tt>bin</tt> key of the <tt>[General]</tt> section and an entry is added to the <tt>[Tools]</tt> section.<br />
<br />
=== C modes ===<br />
<br />
These modes are used by the C back-end: used C compiler, options... E. g.<br />
[boost]<br />
c_compiler_type: gcc<br />
c_compiler_path: gcc<br />
c_compiler_options: -pipe -O2 -fno-gcse<br />
c_linker_path: gcc<br />
c_linker_options: -Xlinker -no-as-needed<br />
cpp_compiler_type: g++<br />
cpp_compiler_path: g++<br />
cpp_compiler_options: -pipe -O2 -fno-gcse<br />
cpp_linker_path: gcc<br />
cpp_linker_options: -Xlinker -no-as-needed<br />
<br />
<br />
By default some C modes are automatically associated to the Eiffel compilation levels (<TT>-boost</TT>, <TT>-require_check</TT>, etc.). The C mode can also be explicitely set in the command line of [[compile_to_c|compile_to_c]] or [[compile|compile]] thanks to the <TT>-c_mode</TT> option.<br />
<br />
The following C modes are default for a standard installation: <TT>boost</TT>, <TT>no_check</TT>, <TT>require_check</TT>, <TT>ensure_check</TT>, <TT>invariant_check</TT>, <TT>loop_check</TT>, <TT>all_check</TT>, <TT>debug_check</TT> and <TT>release</TT>. Only the last one must be explicitely set; it is usually used to finalize a program (<TT>se c -boost -c_mode release ...</TT>)<br />
<br />
Usually the default C modes depend on the chosen C compiler and needs adaption if GCC is not used.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=ACE&diff=2439ACE2016-06-15T20:12:49Z<p>Dkearns: Update config file location</p>
<hr />
<div> * This page needs checking for accuracy and completeness.<br />
* safety_check (yes) needs to be documented<br />
<br />
== ACE File ==<br />
<br />
An ACE file defines the environment for a project, together with its root class and initial creation procedure.<br />
<br />
Use of an ACE file obviates the need for specifying many options on the<br />
command line and ensures consistency between successive compilations or <br />
other operations on the project. Such consistency makes it easier to test<br />
and debug, since changes from one compilation to the next are guaranteed to be<br />
limited to coding changes rather than to changes in the compilation environment.<br />
<br />
=== Naming ===<br />
<br />
An ace file must have a name ending with the suffix <TT>.ace</TT>.<br />
<br />
=== Structure of the ACE file ===<br />
<br />
The file is divided into sections, each introduced by a keyword. These are<br />
conventionally presented in an order laid out in the template ACE file, which<br />
is found under the Liberty Eiffel directory <TT>tutorial/ace/</TT>. These sections<br />
are: '''system''', '''root''', '''default''',<br />
'''cluster''', '''external''' and '''generate'''.<br />
<br />
==== System section ====<br />
<br />
The system section is introduced by the keyword '''system''' followed by the<br />
name to be given to the executable program which will be produced by a compilation.<br />
The system name should be enclosed in double quotes.<br />
<br />
Example:<br />
<br />
<TT><br />
system<br />
&nbsp;<br />
"my_system"<br />
</TT><br />
<br />
==== Root section ====<br />
<br />
The root section defines the root class of the system and the initial creation<br />
procedure. The creation procedure is the routine which is executed first<br />
when the executable program is run; it is equivalent to <TT>main()</TT> in<br />
a C program. This procedure must be a procedure in the root class and must be<br />
declared as a creation procedure in that class.<br />
<br />
Example:<br />
<br />
<TT><br />
root<br />
&nbsp;<br />
MY_SYSTEM: make<br />
</TT><br />
<br />
Here '''MY_SYSTEM''' is the root class and '''make''' is the initial creation<br />
procedure.<br />
<br />
==== Default section ====<br />
<br />
The default section defines the defaults which will apply to the whole<br />
compilation unless overridden for specific sections. It is introduced by<br />
the keyword '''default'''.<br />
<br />
Within the default section are listed various defaults and their settings.<br />
If any default is unlisted, it takes its value from the defaults compiled<br />
into Liberty Eiffel when it was installed.<br />
<br />
The syntax for setting a default is:<br />
<br />
<TT><br />
''setting_name'' (''setting'');<br />
</TT><br />
<br />
Do not forget the terminating semi-colon.<br />
<br />
These are the settings which may be included in the default section:<br />
<br />
* '''assertion'''<br />
This specifies the default level of assertion checking for the system.<br />
Choose the appropriate value as explained in the description of<br />
[[compile_to_c]]: '''boost''', '''no''', '''require''', '''ensure''',<br />
'''invariant''', '''loop''', '''check''' or '''all'''.<br />
<br />
* '''assertion_flat_check'''<br />
In flat mode each assertion will be executed in no_check mode.<br />
This means that while an assertion is being checked, no other assertion will<br />
be checked. This mode is only meaningful in assertion modes from<br />
require to debug. The possible values for this setting are '''yes''' or '''no'''.<br />
<br />
* '''debug'''<br />
This is the default debug level for the system. Choose '''yes''', '''no''',<br />
or any "key" you wish. When debugging is turned on, [[Syntax diagrams#Debug|<tt>debug</tt>]]<br />
sections in the source code are enabled.<br />
<br />
* '''trace'''<br />
This is the default trace mode for the system. Choose '''yes''' or '''no'''.<br />
When tracing is turned on, the [[sedb]] debugger is enabled when the<br />
executable is run.<br />
<br />
* '''collect'''<br />
Choose '''"bdw"''' here to add the Boehm-Demers-Weiser conservative collector linked into to your system.<br />
Choose '''yes''' here to add the native garbage collector support to your system.<br />
Choose '''no''' here to indicate that you don't want the garbage collector to be included in your system; '''no''' is the equivalent of the <TT>-no-gc</TT> flag in traditional command line mode.<br />
See [[Garbage collector]] for details.<br />
<br />
* '''no_style_warning'''<br />
If set to '''yes''', this will suppress the display of warning messages<br />
about non-compliance with Eiffel style rules (for example, <TT>ItEm</TT><br />
will not trigger a message). [This example is out of date as from<br />
2.2beta5 - this is now a fatal error.]<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
This setting is the equivalent of the -no_style_warning flag in traditional<br />
command line mode.<br />
<br />
* '''no_warning'''<br />
If set to '''yes''', this will suppress all warning messages.<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
'''Yes''' is the equivalent of the -no_warning flag in traditional<br />
command line mode.<br />
<br />
* '''verbose'''<br />
Set to '''yes''' to display (an enormous amount of) information during<br />
compilation: a complete trace of files loaded, type inference scores,<br />
generated files and so on. This is the equivalent of the -verbose flag<br />
in traditional command line mode. (Note too that the -verbose flag is<br />
still accepted in ACE file mode.)<br />
<br />
* '''manifest_string_trace'''<br />
Set to '''yes''' to include in your executable a trace of the creation<br />
of manifest strings. This can be useful for tracking down some memory errors.<br />
This is the equivalent of the -manifest_string_trace flag in traditional<br />
command line mode.<br />
<br />
* '''high_memory_compiler'''<br />
When set to '''yes''', this allows the compiler to use more memory.<br />
This can allow faster compilation, if you have enough RAM.<br />
This is the equivalent of the -high_memory_compiler flag in traditional<br />
command line mode.<br />
<br />
* '''profile'''<br />
When set to '''yes''', this allows you to include the [[profile|profiler]]<br />
in your executable.<br />
This is the equivalent of the -profile flag in traditional<br />
command line mode.<br />
<br />
* '''relax'''<br />
This is the equivalent of the -relax flag in traditional<br />
command line mode. ''[What the -relax flag actually does is not documented.]''<br />
<br />
Example:<br />
<br />
<TT><br />
default<br />
&nbsp;<br />
assertion (require);<br />
&nbsp;<br />
assertion_flat_check (no);<br />
&nbsp;<br />
debug (no);<br />
&nbsp;<br />
trace (no);<br />
&nbsp;<br />
collect (yes);<br />
&nbsp;<br />
no_style_warning (no);<br />
&nbsp;<br />
no_warning (no);<br />
&nbsp;<br />
verbose (no);<br />
&nbsp;<br />
manifest_string_trace (yes);<br />
&nbsp;<br />
high_memory_compiler (no);<br />
&nbsp;<br />
profile (yes);<br />
&nbsp;<br />
relax (yes);<br />
&nbsp;<br />
</TT><br />
<br />
==== Cluster section ====<br />
<br />
The cluster section is introduced by the keyword '''cluster'''<br />
and defines an ordered list of clusters. Roughly speaking,<br />
a cluster can be considered as a directory in which Eiffel source files<br />
are to be searched for. The order of this list of clusters is<br />
important because clusters are considered sequentially when<br />
searching for an Eiffel source file. The first class file found in the<br />
search is the one that will be used.<br />
<br />
Each cluster is described as follows:<br />
<br />
<TT><br />
optional_cluster_name: "cluster_path_using_system_file_notation_here"<br />
default -- at this cluster level<br />
assertion (require)<br />
debug (no);<br />
trace (no);<br />
option -- for this cluster<br />
assertion (loop) : CLASS_NAME1, CLASS_NAME2;<br />
assertion (all) : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
debug (yes) : CLASS_NAME1, CLASS_NAME2, ...;<br />
debug ("KEY") : CLASS_NAME1, CLASS_NAME2, ...;<br />
-- ...<br />
trace : CLASS_NAME1, CLASS_NAME2;<br />
trace : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
end -- of one cluster<br />
</TT><br />
<br />
The '''default''' subsection is used to set defaults that apply<br />
only to classes from this particular cluster. The settings that<br />
may be used are '''assertion''', '''debug''' and '''trace'''.<br />
<br />
The '''option''' subsection is used to modify the cluster or system<br />
defaults for particular classes in the cluster<br />
<br />
The following cluster definition can be used, after all the other cluster<br />
definitions, to pull in Liberty Eiffel's standard library. Always<br />
put this last so that you can override options for parts of the standard<br />
library by writing your own replacement class files and placing them in<br />
earlier clusters.<br />
<br />
<TT><br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Example:<br />
<br />
<TT><br />
cluster<br />
&nbsp;<br />
utilities: "../../utilities"<br />
default<br />
assertion (all)<br />
debug (yes);<br />
trace (no);<br />
end<br />
&nbsp;<br />
utilities_se: "../../utilities/se"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (yes);<br />
end<br />
&nbsp;<br />
dbmap: "../../system/dbmap"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (no);<br />
option<br />
trace : JOB_DB_MAP, PURCHASED_JOB_DB_MAP;<br />
end<br />
&nbsp;<br />
egtk: "${EGTK}/lib/glib";end<br />
&nbsp;<br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Notice that when the trace option is used in relation to a particular class,<br />
the setting is always turned on; the setting value is not specified.<br />
<br />
==== External section ====<br />
<br />
The next section is introduced by the keyword '''external'''; it defines<br />
how the C code generated from the Eiffel classes is to be linked with<br />
system libraries and code written in other languages to make a complete<br />
executable.<br />
<br />
The external section contains the following settings:<br />
<br />
* '''external_header_path'''<br />
This is a space-separated list of directories to be searched for C include<br />
files (which typically have <TT>.h</TT> as a suffix).<br />
<br />
* '''external_object_files'''<br />
This is a space-separated list of the path names of object modules to be linked into the<br />
executable. These are files output by a C compiler with the suffix <TT>.o</TT>.<br />
<br />
* '''external_c_files'''<br />
This is a space-separated list of C source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''external_c_plus_plus_files'''<br />
This is a space-separated list of C++ source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''cecil''' ("''my_cecil_file1.se''")<br />
This line appears once for each Cecil file that is to be included in the build<br />
(see [[cecil]] for details).<br />
<br />
* '''external_lib_path'''<br />
A space separated list of directories which are to be searched for system<br />
libraries. On a Unix system a directory name may optionally be prefixed<br />
by <TT>-L</TT> (this used to be required before release -0,74 of SmallEiffel).<br />
<br />
* '''external_lib'''<br />
A list of libraries to be supplied to the linker. The <TT>lib</TT> prefix<br />
of the library name is always omitted; the prefix <tt>-l</TT> may optionally<br />
be used for each library. Other linker options can be included.<br />
<br />
Example (abridged for convenient display):<br />
<br />
<TT><br />
<br />
external<br />
&nbsp;<br />
external_object_files: "/usr/local/lib/libutils.a /usr/local/libeifpq.a"<br />
&nbsp;<br />
external_header_path: "/usr/include/gtk-1.2 /usr/include/gdk-1.2 -I. "<br />
&nbsp;<br />
external_c_files: "/usr/local/src/eif_gtk_se.c"<br />
&nbsp;<br />
cecil ("/usr/local/src/cecil.se")<br />
&nbsp;<br />
external_lib_path: " -L/usr/lib/debug -L/usr/X11R6/lib"<br />
&nbsp;<br />
external_lib: "-rdynamic -lpq -lgnomeui -lart_lgpl -lX11 -lm"<br />
<br />
</TT><br />
<br />
<br />
==== Generate section ====<br />
<br />
This section, introduced by the keyword '''generate''', controls the<br />
generation of C code by [[compile_to_c]].<br />
<br />
The section contains the following possible settings:<br />
<br />
* '''no_strip'''<br />
When set to '''yes''', this suppresses the running of '''strip''' on the<br />
generated executable. This is the equivalent of the <tt>-no_strip</tt><br />
flag of the traditional command line mode. (If you want to use a C level<br />
debugger on your system, you should choose '''yes''' here).<br />
<br />
* '''no_split'''<br />
When set to '''yes''', this causes [[compile_to_c]] to produce a single,<br />
large C file for the entire system, instead of the many small C files<br />
produced by default (when this is set to '''no''').<br />
This setting may be useful for delivery of the most efficient version. (Some<br />
C compilers, including gcc, can then do better inlining.)<br />
<br />
* '''clean'''<br />
When set to '''yes''', this makes the [[compile|compiler]] remove all<br />
generated C files, all generated object files and other temporary files<br />
generated during the compilation process. (See the command [[clean]].)<br />
This ensures that all code is freshly generated and compiled, but will<br />
extend the time needed for recompilation.<br />
<br />
* '''cc'''<br />
The equivalent of the -cc flag of the traditional command line mode.<br />
This defaults to the value, '''gcc'''. To select a different C compiler<br />
from the default, set the option to the appropriate system command.<br />
<br />
* '''c_compiler_options'''<br />
Use this keyword to supply additional options to be passed to the<br />
C compiler, to control optimisation or the production of debugging symbols,<br />
for example.<br />
<br />
* '''linker_options'''<br />
This option can be used to set compiler options that are to be passed<br />
only to the linker.<br />
<br />
* '''no_main'''<br />
Set this to '''yes''' to suppress the generation of a <TT>main()</TT> <br />
C code routine. This is used for generating object libraries.<br />
<br />
* '''gc_info'''<br />
When this option is set to '''yes''', the garbage collector displays at<br />
run time some information about its use.<br />
<br />
* '''wedit'''<br />
To Include support for the Wedit debugger, set this option to '''yes'''.<br />
<br />
Example:<br />
<br />
<TT><br />
generate -- section<br />
&nbsp;<br />
no_strip(yes);<br />
&nbsp;<br />
no_split(no);<br />
&nbsp;<br />
clean(no);<br />
&nbsp;<br />
c_compiler_options : "-Wall -g -pipe -DNEED_GNOMESUPPORT_H "<br />
&nbsp;<br />
<br />
</TT><br />
<br />
=== Variables ===<br />
<br />
As in the cluster and external section examples above, environmental variables<br />
can be used to save typing (and also to enable a whole directory tree to be<br />
moved at the cost only of redefining the variable rather than rewriting every<br />
ace file.<br />
<br />
A variable is referenced by the construct <TT>${''variable_name''}</TT>.<br />
<br />
Some variables are defined in the system configuration file (e.g.<br />
<TT>/etc/liberty-eiffel/liberty.se</TT>); such are the variables ${path_lib} and ${path_tutorial}.<br />
Other variables can be set and exported in the system environment, as, for example, by<br />
the Bourne shell command:<br />
<br />
<TT><br />
$ export EGTK=/usr/local/lib/egtk<br />
</TT><br />
<br />
=== Using an ACE file ===<br />
<br />
An ACE file may be used by specifying it immediately after the command which<br />
is to use it, before any other options to that command.<br />
<br />
For example:<br />
<br />
<TT><br />
se compile my_system.ace<br />
&nbsp;<br />
se short my_system.ace my_system<br />
&nbsp;<br />
se finder my_system.ace some_class<br />
</TT><br />
<br />
<br />
=== ACE syntax checking ===<br />
<br />
The syntax of an ACE file may be checked by the [[ace_check]] command.<br />
<br />
This command will report any errors and will also expand any loadpath.se files<br />
that are included in the ACE file and list each component directory.<br />
<br />
Example:<br />
<br />
<TT><br />
se ace_check my_system.ace<br />
</TT></div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=ACE&diff=2438ACE2016-06-15T20:03:46Z<p>Dkearns: Typo</p>
<hr />
<div> * This page needs checking for accuracy and completeness.<br />
* safety_check (yes) needs to be documented<br />
<br />
== ACE File ==<br />
<br />
An ACE file defines the environment for a project, together with its root class and initial creation procedure.<br />
<br />
Use of an ACE file obviates the need for specifying many options on the<br />
command line and ensures consistency between successive compilations or <br />
other operations on the project. Such consistency makes it easier to test<br />
and debug, since changes from one compilation to the next are guaranteed to be<br />
limited to coding changes rather than to changes in the compilation environment.<br />
<br />
=== Naming ===<br />
<br />
An ace file must have a name ending with the suffix <TT>.ace</TT>.<br />
<br />
=== Structure of the ACE file ===<br />
<br />
The file is divided into sections, each introduced by a keyword. These are<br />
conventionally presented in an order laid out in the template ACE file, which<br />
is found under the Liberty Eiffel directory <TT>tutorial/ace/</TT>. These sections<br />
are: '''system''', '''root''', '''default''',<br />
'''cluster''', '''external''' and '''generate'''.<br />
<br />
==== System section ====<br />
<br />
The system section is introduced by the keyword '''system''' followed by the<br />
name to be given to the executable program which will be produced by a compilation.<br />
The system name should be enclosed in double quotes.<br />
<br />
Example:<br />
<br />
<TT><br />
system<br />
&nbsp;<br />
"my_system"<br />
</TT><br />
<br />
==== Root section ====<br />
<br />
The root section defines the root class of the system and the initial creation<br />
procedure. The creation procedure is the routine which is executed first<br />
when the executable program is run; it is equivalent to <TT>main()</TT> in<br />
a C program. This procedure must be a procedure in the root class and must be<br />
declared as a creation procedure in that class.<br />
<br />
Example:<br />
<br />
<TT><br />
root<br />
&nbsp;<br />
MY_SYSTEM: make<br />
</TT><br />
<br />
Here '''MY_SYSTEM''' is the root class and '''make''' is the initial creation<br />
procedure.<br />
<br />
==== Default section ====<br />
<br />
The default section defines the defaults which will apply to the whole<br />
compilation unless overridden for specific sections. It is introduced by<br />
the keyword '''default'''.<br />
<br />
Within the default section are listed various defaults and their settings.<br />
If any default is unlisted, it takes its value from the defaults compiled<br />
into Liberty Eiffel when it was installed.<br />
<br />
The syntax for setting a default is:<br />
<br />
<TT><br />
''setting_name'' (''setting'');<br />
</TT><br />
<br />
Do not forget the terminating semi-colon.<br />
<br />
These are the settings which may be included in the default section:<br />
<br />
* '''assertion'''<br />
This specifies the default level of assertion checking for the system.<br />
Choose the appropriate value as explained in the description of<br />
[[compile_to_c]]: '''boost''', '''no''', '''require''', '''ensure''',<br />
'''invariant''', '''loop''', '''check''' or '''all'''.<br />
<br />
* '''assertion_flat_check'''<br />
In flat mode each assertion will be executed in no_check mode.<br />
This means that while an assertion is being checked, no other assertion will<br />
be checked. This mode is only meaningful in assertion modes from<br />
require to debug. The possible values for this setting are '''yes''' or '''no'''.<br />
<br />
* '''debug'''<br />
This is the default debug level for the system. Choose '''yes''', '''no''',<br />
or any "key" you wish. When debugging is turned on, [[Syntax diagrams#Debug|<tt>debug</tt>]]<br />
sections in the source code are enabled.<br />
<br />
* '''trace'''<br />
This is the default trace mode for the system. Choose '''yes''' or '''no'''.<br />
When tracing is turned on, the [[sedb]] debugger is enabled when the<br />
executable is run.<br />
<br />
* '''collect'''<br />
Choose '''"bdw"''' here to add the Boehm-Demers-Weiser conservative collector linked into to your system.<br />
Choose '''yes''' here to add the native garbage collector support to your system.<br />
Choose '''no''' here to indicate that you don't want the garbage collector to be included in your system; '''no''' is the equivalent of the <TT>-no-gc</TT> flag in traditional command line mode.<br />
See [[Garbage collector]] for details.<br />
<br />
* '''no_style_warning'''<br />
If set to '''yes''', this will suppress the display of warning messages<br />
about non-compliance with Eiffel style rules (for example, <TT>ItEm</TT><br />
will not trigger a message). [This example is out of date as from<br />
2.2beta5 - this is now a fatal error.]<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
This setting is the equivalent of the -no_style_warning flag in traditional<br />
command line mode.<br />
<br />
* '''no_warning'''<br />
If set to '''yes''', this will suppress all warning messages.<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
'''Yes''' is the equivalent of the -no_warning flag in traditional<br />
command line mode.<br />
<br />
* '''verbose'''<br />
Set to '''yes''' to display (an enormous amount of) information during<br />
compilation: a complete trace of files loaded, type inference scores,<br />
generated files and so on. This is the equivalent of the -verbose flag<br />
in traditional command line mode. (Note too that the -verbose flag is<br />
still accepted in ACE file mode.)<br />
<br />
* '''manifest_string_trace'''<br />
Set to '''yes''' to include in your executable a trace of the creation<br />
of manifest strings. This can be useful for tracking down some memory errors.<br />
This is the equivalent of the -manifest_string_trace flag in traditional<br />
command line mode.<br />
<br />
* '''high_memory_compiler'''<br />
When set to '''yes''', this allows the compiler to use more memory.<br />
This can allow faster compilation, if you have enough RAM.<br />
This is the equivalent of the -high_memory_compiler flag in traditional<br />
command line mode.<br />
<br />
* '''profile'''<br />
When set to '''yes''', this allows you to include the [[profile|profiler]]<br />
in your executable.<br />
This is the equivalent of the -profile flag in traditional<br />
command line mode.<br />
<br />
* '''relax'''<br />
This is the equivalent of the -relax flag in traditional<br />
command line mode. ''[What the -relax flag actually does is not documented.]''<br />
<br />
Example:<br />
<br />
<TT><br />
default<br />
&nbsp;<br />
assertion (require);<br />
&nbsp;<br />
assertion_flat_check (no);<br />
&nbsp;<br />
debug (no);<br />
&nbsp;<br />
trace (no);<br />
&nbsp;<br />
collect (yes);<br />
&nbsp;<br />
no_style_warning (no);<br />
&nbsp;<br />
no_warning (no);<br />
&nbsp;<br />
verbose (no);<br />
&nbsp;<br />
manifest_string_trace (yes);<br />
&nbsp;<br />
high_memory_compiler (no);<br />
&nbsp;<br />
profile (yes);<br />
&nbsp;<br />
relax (yes);<br />
&nbsp;<br />
</TT><br />
<br />
==== Cluster section ====<br />
<br />
The cluster section is introduced by the keyword '''cluster'''<br />
and defines an ordered list of clusters. Roughly speaking,<br />
a cluster can be considered as a directory in which Eiffel source files<br />
are to be searched for. The order of this list of clusters is<br />
important because clusters are considered sequentially when<br />
searching for an Eiffel source file. The first class file found in the<br />
search is the one that will be used.<br />
<br />
Each cluster is described as follows:<br />
<br />
<TT><br />
optional_cluster_name: "cluster_path_using_system_file_notation_here"<br />
default -- at this cluster level<br />
assertion (require)<br />
debug (no);<br />
trace (no);<br />
option -- for this cluster<br />
assertion (loop) : CLASS_NAME1, CLASS_NAME2;<br />
assertion (all) : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
debug (yes) : CLASS_NAME1, CLASS_NAME2, ...;<br />
debug ("KEY") : CLASS_NAME1, CLASS_NAME2, ...;<br />
-- ...<br />
trace : CLASS_NAME1, CLASS_NAME2;<br />
trace : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
end -- of one cluster<br />
</TT><br />
<br />
The '''default''' subsection is used to set defaults that apply<br />
only to classes from this particular cluster. The settings that<br />
may be used are '''assertion''', '''debug''' and '''trace'''.<br />
<br />
The '''option''' subsection is used to modify the cluster or system<br />
defaults for particular classes in the cluster<br />
<br />
The following cluster definition can be used, after all the other cluster<br />
definitions, to pull in Liberty Eiffel's standard library. Always<br />
put this last so that you can override options for parts of the standard<br />
library by writing your own replacement class files and placing them in<br />
earlier clusters.<br />
<br />
<TT><br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Example:<br />
<br />
<TT><br />
cluster<br />
&nbsp;<br />
utilities: "../../utilities"<br />
default<br />
assertion (all)<br />
debug (yes);<br />
trace (no);<br />
end<br />
&nbsp;<br />
utilities_se: "../../utilities/se"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (yes);<br />
end<br />
&nbsp;<br />
dbmap: "../../system/dbmap"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (no);<br />
option<br />
trace : JOB_DB_MAP, PURCHASED_JOB_DB_MAP;<br />
end<br />
&nbsp;<br />
egtk: "${EGTK}/lib/glib";end<br />
&nbsp;<br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Notice that when the trace option is used in relation to a particular class,<br />
the setting is always turned on; the setting value is not specified.<br />
<br />
==== External section ====<br />
<br />
The next section is introduced by the keyword '''external'''; it defines<br />
how the C code generated from the Eiffel classes is to be linked with<br />
system libraries and code written in other languages to make a complete<br />
executable.<br />
<br />
The external section contains the following settings:<br />
<br />
* '''external_header_path'''<br />
This is a space-separated list of directories to be searched for C include<br />
files (which typically have <TT>.h</TT> as a suffix).<br />
<br />
* '''external_object_files'''<br />
This is a space-separated list of the path names of object modules to be linked into the<br />
executable. These are files output by a C compiler with the suffix <TT>.o</TT>.<br />
<br />
* '''external_c_files'''<br />
This is a space-separated list of C source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''external_c_plus_plus_files'''<br />
This is a space-separated list of C++ source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''cecil''' ("''my_cecil_file1.se''")<br />
This line appears once for each Cecil file that is to be included in the build<br />
(see [[cecil]] for details).<br />
<br />
* '''external_lib_path'''<br />
A space separated list of directories which are to be searched for system<br />
libraries. On a Unix system a directory name may optionally be prefixed<br />
by <TT>-L</TT> (this used to be required before release -0,74 of SmallEiffel).<br />
<br />
* '''external_lib'''<br />
A list of libraries to be supplied to the linker. The <TT>lib</TT> prefix<br />
of the library name is always omitted; the prefix <tt>-l</TT> may optionally<br />
be used for each library. Other linker options can be included.<br />
<br />
Example (abridged for convenient display):<br />
<br />
<TT><br />
<br />
external<br />
&nbsp;<br />
external_object_files: "/usr/local/lib/libutils.a /usr/local/libeifpq.a"<br />
&nbsp;<br />
external_header_path: "/usr/include/gtk-1.2 /usr/include/gdk-1.2 -I. "<br />
&nbsp;<br />
external_c_files: "/usr/local/src/eif_gtk_se.c"<br />
&nbsp;<br />
cecil ("/usr/local/src/cecil.se")<br />
&nbsp;<br />
external_lib_path: " -L/usr/lib/debug -L/usr/X11R6/lib"<br />
&nbsp;<br />
external_lib: "-rdynamic -lpq -lgnomeui -lart_lgpl -lX11 -lm"<br />
<br />
</TT><br />
<br />
<br />
==== Generate section ====<br />
<br />
This section, introduced by the keyword '''generate''', controls the<br />
generation of C code by [[compile_to_c]].<br />
<br />
The section contains the following possible settings:<br />
<br />
* '''no_strip'''<br />
When set to '''yes''', this suppresses the running of '''strip''' on the<br />
generated executable. This is the equivalent of the <tt>-no_strip</tt><br />
flag of the traditional command line mode. (If you want to use a C level<br />
debugger on your system, you should choose '''yes''' here).<br />
<br />
* '''no_split'''<br />
When set to '''yes''', this causes [[compile_to_c]] to produce a single,<br />
large C file for the entire system, instead of the many small C files<br />
produced by default (when this is set to '''no''').<br />
This setting may be useful for delivery of the most efficient version. (Some<br />
C compilers, including gcc, can then do better inlining.)<br />
<br />
* '''clean'''<br />
When set to '''yes''', this makes the [[compile|compiler]] remove all<br />
generated C files, all generated object files and other temporary files<br />
generated during the compilation process. (See the command [[clean]].)<br />
This ensures that all code is freshly generated and compiled, but will<br />
extend the time needed for recompilation.<br />
<br />
* '''cc'''<br />
The equivalent of the -cc flag of the traditional command line mode.<br />
This defaults to the value, '''gcc'''. To select a different C compiler<br />
from the default, set the option to the appropriate system command.<br />
<br />
* '''c_compiler_options'''<br />
Use this keyword to supply additional options to be passed to the<br />
C compiler, to control optimisation or the production of debugging symbols,<br />
for example.<br />
<br />
* '''linker_options'''<br />
This option can be used to set compiler options that are to be passed<br />
only to the linker.<br />
<br />
* '''no_main'''<br />
Set this to '''yes''' to suppress the generation of a <TT>main()</TT> <br />
C code routine. This is used for generating object libraries.<br />
<br />
* '''gc_info'''<br />
When this option is set to '''yes''', the garbage collector displays at<br />
run time some information about its use.<br />
<br />
* '''wedit'''<br />
To Include support for the Wedit debugger, set this option to '''yes'''.<br />
<br />
Example:<br />
<br />
<TT><br />
generate -- section<br />
&nbsp;<br />
no_strip(yes);<br />
&nbsp;<br />
no_split(no);<br />
&nbsp;<br />
clean(no);<br />
&nbsp;<br />
c_compiler_options : "-Wall -g -pipe -DNEED_GNOMESUPPORT_H "<br />
&nbsp;<br />
<br />
</TT><br />
<br />
=== Variables ===<br />
<br />
As in the cluster and external section examples above, environmental variables<br />
can be used to save typing (and also to enable a whole directory tree to be<br />
moved at the cost only of redefining the variable rather than rewriting every<br />
ace file.<br />
<br />
A variable is referenced by the construct <TT>${''variable_name''}</TT>.<br />
<br />
Some variables are defined in the system configuration file (e.g.<br />
<TT>/etc/serc</TT>); such are the variables ${path_lib} and ${path_tutorial}.<br />
Other variables can be set and exported in the system environment, as, for example, by<br />
the Bourne shell command:<br />
<br />
<TT><br />
$ export EGTK=/usr/local/lib/egtk<br />
</TT><br />
<br />
=== Using an ACE file ===<br />
<br />
An ACE file may be used by specifying it immediately after the command which<br />
is to use it, before any other options to that command.<br />
<br />
For example:<br />
<br />
<TT><br />
se compile my_system.ace<br />
&nbsp;<br />
se short my_system.ace my_system<br />
&nbsp;<br />
se finder my_system.ace some_class<br />
</TT><br />
<br />
<br />
=== ACE syntax checking ===<br />
<br />
The syntax of an ACE file may be checked by the [[ace_check]] command.<br />
<br />
This command will report any errors and will also expand any loadpath.se files<br />
that are included in the ACE file and list each component directory.<br />
<br />
Example:<br />
<br />
<TT><br />
se ace_check my_system.ace<br />
</TT></div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=ACE&diff=2427ACE2016-06-15T14:50:15Z<p>Dkearns: Rewording</p>
<hr />
<div> * This page needs checking for accuracy and completeness.<br />
* safety_check (yes) needs to be documented<br />
<br />
== ACE File ==<br />
<br />
An ACE file defines the environment for a project, together with its root class and initial creation procedure.<br />
<br />
Use of an ACE file obviates the need for specifying many options on the<br />
command line and ensures consistency between successive compilations or <br />
other operations on the project. Such consistency makes it easier to test<br />
and debug, since changes from one compilation to the next are guaranteed to be<br />
limited to coding changes rather than to changes in the compilation environment.<br />
<br />
=== Naming ===<br />
<br />
An ace file must have a name ending with the suffix <TT>.ace</TT>.<br />
<br />
=== Structure of the ACE file ===<br />
<br />
The file is divided into sections, each introduced by a keyword. These are<br />
conventionally presented in an order laid out in the template ACE file, which<br />
is found under the Liberty Eiffel directory <TT>tutorial/ace/</TT>. These sections<br />
are: '''system''', '''root''', '''default''',<br />
'''cluster''', '''external''' and '''generate'''.<br />
<br />
==== System section ====<br />
<br />
The system section is introduced by the keyword '''system''' followed by the<br />
name to be given to the executable program which will be produced by a compilation.<br />
The system name should be enclosed in double quotes.<br />
<br />
Example:<br />
<br />
<TT><br />
system<br />
&nbsp;<br />
"my_system"<br />
</TT><br />
<br />
==== Root section ====<br />
<br />
The root section defines the root class of the system and the initial creation<br />
procedure. The creation procedure is the routine which is executed first<br />
when the executable program is run; it is equivalent to <TT>main()</TT> in<br />
a C program. This procedure must be a procedure in the root class and must be<br />
declared as a creation procedure in that class.<br />
<br />
Example:<br />
<br />
<TT><br />
root<br />
&nbsp;<br />
MY_SYSTEM: make<br />
</TT><br />
<br />
Here '''MY_SYSTEM''' is the root class and '''make''' is the initial creation<br />
procedure.<br />
<br />
==== Default section ====<br />
<br />
The default section defines the defaults which will apply to the whole<br />
compilation unless overridden for specific sections. It is introduced by<br />
the keyword '''default'''.<br />
<br />
Within the default section are listed various defaults and their settings.<br />
If any default is unlisted, it takes its value from the defaults compiled<br />
into Liberty Eiffel when it was installed.<br />
<br />
The syntax for setting a default is:<br />
<br />
<TT><br />
''setting_name'' (''setting'');<br />
</TT><br />
<br />
Do not forget the terminating semi-colon.<br />
<br />
These are the settings which may be included in the default section:<br />
<br />
* '''assertion'''<br />
This specifies the default level of assertion checking for the system.<br />
Choose the appropriate value as explained in the description of<br />
[[compile_to_c]]: '''boost''', '''no''', '''require''', '''ensure''',<br />
'''invariant''', '''loop''', '''check''' or '''all'''.<br />
<br />
* '''assertion_flat_check'''<br />
In flat mode each assertion will be executed in no_check mode.<br />
This means that while an assertion is being checked, no other assertion will<br />
be checked. This mode is only meaningful in assertion modes from<br />
require to debug. The possible values for this setting are '''yes''' or '''no'''.<br />
<br />
* '''debug'''<br />
This is the default debug level for the system. Choose '''yes''', '''no''',<br />
or any "key" you wish. When debugging is turned on, [[Syntax diagrams#Debug|<tt>debug</tt>]]<br />
sections in the source code are enabled.<br />
<br />
* '''trace'''<br />
This is the default trace mode for the system. Choose '''yes''' or '''no'''.<br />
When tracing is turned on, the [[sedb]] debugger is enabled when the<br />
executable is run.<br />
<br />
* '''collect'''<br />
Choose '''"bdw"''' here to add the Boehm-Demers-Weiser conservative collector linked into to your system.<br />
Choose '''yes''' here to add the native garbage collector support to your system.<br />
Choose '''no''' here to indicate that you don't want the garbage collector to be included in your system; '''no''' is the equivalent of the <TT>-no-gc</TT> flag in traditional command line mode.<br />
See [[Garbage collector]] for details.<br />
<br />
* '''no_style_warning'''<br />
If set to '''yes''', this will suppress the display of warning messages<br />
about non-compliance with Eiffel style rules (for example, <TT>ItEm</TT><br />
will not trigger a message). [This example is out of date as from<br />
2.2beta5 - this is now a fatal error.]<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
This setting is the equivalent of the -no_style_warning flag in traditional<br />
command line mode.<br />
<br />
* '''no_warning'''<br />
If set to '''yes''', this will suppress all warning messages.<br />
The Liberty Eiffel Team's recommendation is that you should always set this<br />
to '''no'''.<br />
'''Yes''' is the equivalent of the -no_warning flag in traditional<br />
command line mode.<br />
<br />
* '''verbose'''<br />
Set to '''yes''' to display (an enormous amount of) information during<br />
compilation: a complete trace of files loaded, type inference scores,<br />
generated files and so on. This is the equivalent of the -verbose flag<br />
in traditional command line mode. (Note too that the -verbose flag is<br />
still accepted in ACE file mode.)<br />
<br />
* '''manifest_string_trace'''<br />
Set to '''yes''' to include in your executable a trace of the creation<br />
of manifest strings. This can be useful for tracking down some memory errors.<br />
This is the equivalent of the -manifest_string_trace flag in traditional<br />
command line mode.<br />
<br />
* '''high_memory_compiler'''<br />
When set to '''yes''', this allows the compiler to use more memory.<br />
This can allow faster compilation, if you have enough RAM.<br />
This is the equivalent of the -high_memory_compiler flag in traditional<br />
command line mode.<br />
<br />
* '''profile'''<br />
When set to '''yes''', this allows you to include the [[profile|profiler]]<br />
in your executable.<br />
This is the equivalent of the -profile flag in traditional<br />
command line mode.<br />
<br />
* '''relax'''<br />
This is the equivalent of the -relax flag in traditional<br />
command line mode. ''[What the -relax flag actually does is not documented.]''<br />
<br />
Example:<br />
<br />
<TT><br />
default<br />
&nbsp;<br />
assertion (require);<br />
&nbsp;<br />
assertion_flat_check (no);<br />
&nbsp;<br />
debug (no);<br />
&nbsp;<br />
trace (no);<br />
&nbsp;<br />
collect (yes);<br />
&nbsp;<br />
no_style_warning (no);<br />
&nbsp;<br />
no_warning (no);<br />
&nbsp;<br />
verbose (no);<br />
&nbsp;<br />
manifest_string_trace (yes);<br />
&nbsp;<br />
high_memory_compiler (no);<br />
&nbsp;<br />
profile (yes);<br />
&nbsp;<br />
relax (yes);<br />
&nbsp;<br />
</TT><br />
<br />
==== Cluster section ====<br />
<br />
The cluster section is introduced by the keyword '''cluster'''<br />
and defines an ordered list of clusters. Roughly speaking,<br />
a cluster can be considered as a directory in which Eiffel source files<br />
are to be searched for. The order of this list of clusters is<br />
important because clusters are considered sequentially when<br />
searching for an Eiffel source file. The first class file found in the<br />
search is the one that will be used.<br />
<br />
Each cluster is described as follows:<br />
<br />
<TT><br />
optional_cluster_name: "cluster_path_using_system_file_notation_here"<br />
default -- at this cluster level<br />
assertion (require)<br />
debug (no);<br />
trace (no);<br />
option -- for this cluster<br />
assertion (loop) : CLASS_NAME1, CLASS_NAME2;<br />
assertion (all) : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
debug (yes) : CLASS_NAME1, CLASS_NAME2, ...;<br />
debug ("KEY") : CLASS_NAME1, CLASS_NAME2, ...;<br />
-- ...<br />
trace : CLASS_NAME1, CLASS_NAME2;<br />
trace : CLASS_NAME3, CLASS_NAME4;<br />
-- ...<br />
end -- of one cluster<br />
</TT><br />
<br />
The '''default''' subsection is used to set defaults that apply<br />
only to classes from this particular cluster. The settings that<br />
may be used are '''assertion''', '''debug''' and '''trace'''.<br />
<br />
The '''option''' subsection is used to modify the cluster or system<br />
defaults for particular classes in the cluster<br />
<br />
The following cluster definition can be used, after all the other cluster<br />
definitions, to pull in Liberty Eiffel's standard library. Always<br />
put this last so that you can override options for parts of the standard<br />
library by writing your own replacement class files and placing them in<br />
earlier clusters.<br />
<br />
<TT><br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Example:]<br />
<br />
<TT><br />
cluster<br />
&nbsp;<br />
utilities: "../../utilities"<br />
default<br />
assertion (all)<br />
debug (yes);<br />
trace (no);<br />
end<br />
&nbsp;<br />
utilities_se: "../../utilities/se"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (yes);<br />
end<br />
&nbsp;<br />
dbmap: "../../system/dbmap"<br />
default<br />
assertion (all)<br />
debug (no);<br />
trace (no);<br />
option<br />
trace : JOB_DB_MAP, PURCHASED_JOB_DB_MAP;<br />
end<br />
&nbsp;<br />
egtk: "${EGTK}/lib/glib";end<br />
&nbsp;<br />
standard: "${path_lib}/loadpath.se"<br />
</TT><br />
<br />
Notice that when the trace option is used in relation to a particular class,<br />
the setting is always turned on; the setting value is not specified.<br />
<br />
==== External section ====<br />
<br />
The next section is introduced by the keyword '''external'''; it defines<br />
how the C code generated from the Eiffel classes is to be linked with<br />
system libraries and code written in other languages to make a complete<br />
executable.<br />
<br />
The external section contains the following settings:<br />
<br />
* '''external_header_path'''<br />
This is a space-separated list of directories to be searched for C include<br />
files (which typically have <TT>.h</TT> as a suffix).<br />
<br />
* '''external_object_files'''<br />
This is a space-separated list of the path names of object modules to be linked into the<br />
executable. These are files output by a C compiler with the suffix <TT>.o</TT>.<br />
<br />
* '''external_c_files'''<br />
This is a space-separated list of C source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''external_c_plus_plus_files'''<br />
This is a space-separated list of C++ source files which need to be compiled<br />
and whose object modules will be linked into the executable.<br />
<br />
* '''cecil''' ("''my_cecil_file1.se''")<br />
This line appears once for each Cecil file that is to be included in the build<br />
(see [[cecil]] for details).<br />
<br />
* '''external_lib_path'''<br />
A space separated list of directories which are to be searched for system<br />
libraries. On a Unix system a directory name may optionally be prefixed<br />
by <TT>-L</TT> (this used to be required before release -0,74 of SmallEiffel).<br />
<br />
* '''external_lib'''<br />
A list of libraries to be supplied to the linker. The <TT>lib</TT> prefix<br />
of the library name is always omitted; the prefix <tt>-l</TT> may optionally<br />
be used for each library. Other linker options can be included.<br />
<br />
Example (abridged for convenient display):<br />
<br />
<TT><br />
<br />
external<br />
&nbsp;<br />
external_object_files: "/usr/local/lib/libutils.a /usr/local/libeifpq.a"<br />
&nbsp;<br />
external_header_path: "/usr/include/gtk-1.2 /usr/include/gdk-1.2 -I. "<br />
&nbsp;<br />
external_c_files: "/usr/local/src/eif_gtk_se.c"<br />
&nbsp;<br />
cecil ("/usr/local/src/cecil.se")<br />
&nbsp;<br />
external_lib_path: " -L/usr/lib/debug -L/usr/X11R6/lib"<br />
&nbsp;<br />
external_lib: "-rdynamic -lpq -lgnomeui -lart_lgpl -lX11 -lm"<br />
<br />
</TT><br />
<br />
<br />
==== Generate section ====<br />
<br />
This section, introduced by the keyword '''generate''', controls the<br />
generation of C code by [[compile_to_c]].<br />
<br />
The section contains the following possible settings:<br />
<br />
* '''no_strip'''<br />
When set to '''yes''', this suppresses the running of '''strip''' on the<br />
generated executable. This is the equivalent of the <tt>-no_strip</tt><br />
flag of the traditional command line mode. (If you want to use a C level<br />
debugger on your system, you should choose '''yes''' here).<br />
<br />
* '''no_split'''<br />
When set to '''yes''', this causes [[compile_to_c]] to produce a single,<br />
large C file for the entire system, instead of the many small C files<br />
produced by default (when this is set to '''no''').<br />
This setting may be useful for delivery of the most efficient version. (Some<br />
C compilers, including gcc, can then do better inlining.)<br />
<br />
* '''clean'''<br />
When set to '''yes''', this makes the [[compile|compiler]] remove all<br />
generated C files, all generated object files and other temporary files<br />
generated during the compilation process. (See the command [[clean]].)<br />
This ensures that all code is freshly generated and compiled, but will<br />
extend the time needed for recompilation.<br />
<br />
* '''cc'''<br />
The equivalent of the -cc flag of the traditional command line mode.<br />
This defaults to the value, '''gcc'''. To select a different C compiler<br />
from the default, set the option to the appropriate system command.<br />
<br />
* '''c_compiler_options'''<br />
Use this keyword to supply additional options to be passed to the<br />
C compiler, to control optimisation or the production of debugging symbols,<br />
for example.<br />
<br />
* '''linker_options'''<br />
This option can be used to set compiler options that are to be passed<br />
only to the linker.<br />
<br />
* '''no_main'''<br />
Set this to '''yes''' to suppress the generation of a <TT>main()</TT> <br />
C code routine. This is used for generating object libraries.<br />
<br />
* '''gc_info'''<br />
When this option is set to '''yes''', the garbage collector displays at<br />
run time some information about its use.<br />
<br />
* '''wedit'''<br />
To Include support for the Wedit debugger, set this option to '''yes'''.<br />
<br />
Example:<br />
<br />
<TT><br />
generate -- section<br />
&nbsp;<br />
no_strip(yes);<br />
&nbsp;<br />
no_split(no);<br />
&nbsp;<br />
clean(no);<br />
&nbsp;<br />
c_compiler_options : "-Wall -g -pipe -DNEED_GNOMESUPPORT_H "<br />
&nbsp;<br />
<br />
</TT><br />
<br />
=== Variables ===<br />
<br />
As in the cluster and external section examples above, environmental variables<br />
can be used to save typing (and also to enable a whole directory tree to be<br />
moved at the cost only of redefining the variable rather than rewriting every<br />
ace file.<br />
<br />
A variable is referenced by the construct <TT>${''variable_name''}</TT>.<br />
<br />
Some variables are defined in the system configuration file (e.g.<br />
<TT>/etc/serc</TT>); such are the variables ${path_lib} and ${path_tutorial}.<br />
Other variables can be set and exported in the system environment, as, for example, by<br />
the Bourne shell command:<br />
<br />
<TT><br />
$ export EGTK=/usr/local/lib/egtk<br />
</TT><br />
<br />
=== Using an ACE file ===<br />
<br />
An ACE file may be used by specifying it immediately after the command which<br />
is to use it, before any other options to that command.<br />
<br />
For example:<br />
<br />
<TT><br />
se compile my_system.ace<br />
&nbsp;<br />
se short my_system.ace my_system<br />
&nbsp;<br />
se finder my_system.ace some_class<br />
</TT><br />
<br />
<br />
=== ACE syntax checking ===<br />
<br />
The syntax of an ACE file may be checked by the [[ace_check]] command.<br />
<br />
This command will report any errors and will also expand any loadpath.se files<br />
that are included in the ACE file and list each component directory.<br />
<br />
Example:<br />
<br />
<TT><br />
se ace_check my_system.ace<br />
</TT></div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Get_involved&diff=2416Get involved2016-06-14T20:37:18Z<p>Dkearns: Copy editing</p>
<hr />
<div>[[Category: Community]]<br />
<h2>Interested in the Eiffel language and the Liberty compiler?</h2><br />
<br />
First of all you are invited to use Liberty for developing your own applications. If you encounter any problem, just raise your voice and [[Get in touch|get in touch]] with us. We are here to fix your issues and support you in using the Liberty Eiffel compiler and its libraries. Our primary goal is to provide a working Eiffel compiler and a bunch of libraries for real life applications. Now you are in charge of coming up with a nice little program (or a new office suite), written with Liberty.<br />
<br />
Liberty is an open project, where anyone can clone the public repository from git://git.savannah.gnu.org/liberty-eiffel.git and dig into the code, improve it and get the changes into the master branch. You are welcome to provide patches, issue pull requests and to become a project member on Savannah.<br />
<br />
We are open to any bug fix or new feature in the libraries or tools. And if you don't want to get your hands dirty we are happy for you to create feature requests or bug reports in the [https://savannah.gnu.org/bugs/?func=additem&group=liberty-eiffel issue tracker on GNU Savannah].<br />
<br />
Please also feel free to improve the pages in this Wiki. - Although we disabled the anonymous account creation due to spamming it is simple to get an account by asking via [[Get in touch|email]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Glossary&diff=2415Glossary2016-06-14T20:33:20Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>'''Glossary of terms used in the Grand Book'''<br />
<br />
''Notice:'' when a term has several different meanings, priority is given to the term's meaning in the context we are interested in, that of Eiffel computing and object-oriented programming of objects using design by contract.<br />
<br />
<div align="center"><br />
[[#A|A]] | [[#B|B]] | [[#C|C]] | [[#D|D]] | <br />
[[#E|E]] | [[#F|F]] | [[#G|G]] | [[#H|H]] | <br />
[[#I|I]] | [[#J|J]] | [[#K|K]] | [[#L|L]] | <br />
[[#M|M]] | [[#N|N]] | [[#O|O]] | [[#P|P]] | <br />
[[#Q|Q]] | [[#R|R]] | [[#S|S]] | [[#T|T]] | <br />
[[#U|U]] | [[#V|V]] | [[#W|W]] | [[#X|X]] | <br />
[[#Y|Y]] | [[#Z|Z]]<br />
</div><br />
<br />
__NOTOC__<br />
<br />
== A ==<br />
<br />
<div id="Attribute"><br />
'''attribute:''' an attribute of an object is part of the memorized<br />
information of that object.<br />
In other words, using the attribute of some object does not involve <br />
computation. <br />
An attribute is either constant or variable. <br />
When not constant, attribute means exactly the same as <br />
[[#InstanceVariable|instance variable]]. <br />
</div> <br />
<br />
<div id="AnchoredType"><br />
'''anchored type:''' a type defined relative to another type. Anchored<br />
types are those which use the keyword<br />
[[Syntax diagrams#Type|<tt>like</tt>]].<br />
</div><br />
<br />
== B ==<br />
<br />
<div id="BackEnd"><br />
'''back-end:''' the last part of a compiler which, after each class has been analyzed and no error has been detected, builds the executable that runs all the operations described in the source program.<br />
<br />
Liberty Eiffel provides two back-ends: a [[compile_to_c|C back-end]] and in the near future possibly a [[compile_to_jvm|Java back-end]].<br />
</div><br />
<br />
== C ==<br />
<br />
<div id="Contravariance"><br />
'''contravariance:''' as opposed to [[#Covariance|covariance]]; we say that a language applies the contravariance rule<br />
if, when a [[#Method|method]] is redefined, the argument types or the result type can be replaced by a more general type.<br />
Eiffel does not apply the contravariance rule. Eiffel applies the [[#Covariance|covariance]] rule.<br />
</div><br />
<br />
<div id="Compiler"><br />
'''compiler:''' a program that can verify and then translate another program written in a computing [[#Language|language]].<br />
Before doing the translation, the compiler checks that the program to be translated conforms to the syntax and rules of the [[#Language|language]].<br />
</div><br />
<br />
<div id="Covariance"><br />
'''covariance:''' as opposed to [[#Contravariance|contravariance]]; we say that a [[#Language|language]] applies the covariance rule if, when an inherited [[#Method|method]] is redefined, the argument types or the result type can be replaced by a more specific type.<br />
For example, if the class <TT>APPLE</TT> inherits from <TT>FRUIT</TT>, the arguments (or the result) of the redefined methods can pass from <TT>FRUIT</TT> to <TT>APPLE</TT>.<br />
This type change is valid according to the covariance rule.<br />
So the scope for redefinition varies in the same direction as the inheritance relationship, hence the name '''co'''variance.<br />
Eiffel applies the covariance rule because that rule corresponds to the most useful way of using inheritance.<br />
</div><br />
<br />
== D ==<br />
<br />
<div id="DesignPattern"><br />
'''design pattern''': Solution or computing framework for a known problem.<br />
The ''Gang of Four'''s catalogue of design patterns [[Bibliography#GoF 1995|[GoF 1995]]] contains their version for Eiffel [[Bibliography#JMT 1999|[JMT 1999]]].<br />
See also the classes<br />
[[library_class:ITERATOR|<tt>ITERATOR</tt>]] and<br />
[[library_class:VISITOR|<tt>VISITOR</tt>]].<br />
</div><br />
<br />
<div id="DynamicDispatch"><br />
'''dynamic dispatch:''' runtime selection of the [[#Method|method]] best adapted to the [[#DynamicType|dynamic type]] of the object to which the operation is applied. Dynamic dispatch is an essential feature of object-oriented programming. For more details, refer to the [[Dynamic dispatch|detailed description of dynamic dispatch]].<br />
</div><br />
<br />
<div id="DynamicType"><br />
'''dynamic type:''' at runtime, the exact type of the object designated by an expression or by a variable. See also [[#StaticType|static type]].<br />
<br />
</div><br />
<br />
== E ==<br />
<br />
<div id="Expression"><br />
'''expression:''' as opposed to [[#Instruction|instruction]], an expression produces a return value.<br />
For example, an expression can be used on the right-hand side of an assignment.<br />
The constant <tt>True</tt> is an expression.<br />
The constant <tt>5</tt> is also an expression.<br />
The calculation <tt>i+1</tt> is one too.<br />
Without being too dogmatic about it, good programming habits lead us not to allow [[#SideEffect|side effects]] during the evaluation of expressions.<br />
See also the [[Syntax diagrams#Expression|syntax diagram for an expression]].<br />
</div><br />
<br />
== F ==<br />
<br />
<div id="Feature"><br />
'''feature:''' feature is used to denote either an <br />
[[#Attribute|attribute]], <br />
a [[#Function|function]] or <br />
a [[#Procedure|procedure]].<br />
Hence, feature also includes [[#Method|method]]. <br />
</div> <br />
<br />
<div id="Function"><br />
'''function:''' a function is a set of instructions that performs a certain task. With the exception of [[Current]], a function takes zero or several parameters and always returns a result. A function in computer science (and so in Eiffel) distinguishes itself from the mathematical function mainly by the fact that as well as calculating a result from its parameters, the Eiffel function can also have [[#SideEffect|side effects]].<br />
See also [[#Procedure|procedure]].<br />
<br />
</div><br />
<br />
== G ==<br />
<br />
== H ==<br />
<br />
<div id="Heap"><br />
'''heap''': area in the memory where objects are stored.<br />
</div><br />
<br />
== I ==<br />
<br />
<div id="Instance"><br />
'''instance''': synonym of object. An object or an instance of some class.<br />
</div><br />
<br />
<div id="InstanceVariable"><br />
'''instance variable:''' one memory field of some object.<br />
As indicated, this memory field can be accessed either for reading or for writing.<br />
The preferred Eiffel terminology is ''writable'' [[#Attribute|''attribute'']].<br />
</div><br />
<br />
<div id="Instruction"><br />
'''instruction:''' in contrast to an [[#Expression|expression]], an instruction does not produce a return value.<br />
In order to do anything useful, an instruction has to produce a lasting [[#SideEffect|side effect]].<br />
See also the [[Syntax diagrams#Instruction|syntax diagram for an instruction]].<br />
</div><br />
<br />
== J ==<br />
<br />
== K ==<br />
<br />
== L ==<br />
<br />
<div id="Language"><br />
'''language''': a computer language and a language used for interacting with or between computers.<br />
A programming language is a computer language.<br />
''[Did I misunderstand the French? This doesn't seem to say anything useful.]''<br />
Eiffel is a programming language.<br />
One should not confuse ''language'' with a [[#Compiler|compiler]] for that language.<br />
</div><br />
<br />
<div id="LateBinding"><br />
'''late binding''': see [[#DynamicDispatch|dynamic dispatch]].<br />
</div><br />
<br />
<div id="Library"><br />
'''library''': a software library is a collection of classes intended to facilitate a particular task<br />
or to provide objects of general usefulness. The library provided with Liberty Eiffel is very extensive<br />
and supplies all the usual primitive objects (INTEGER, CHARACTER, STRING, REAL, etc.), all the usual data structures<br />
(COLLECTION, SET, DICTIONARY, QUEUE, STACK, etc.) along with many other classes.<br />
</div><br />
<br />
<div id="LiveType"><br />
'''live type''': this phrase is used throughout the Liberty Eiffel documentation<br />
to refer to a type that is actually used<br />
in the program and which has C code generated for it. The phrase is a literal translation from<br />
French; a better expression in English might be '''Instantiated type'''.<br />
</div><br />
<br />
<div id="LocalVariable"><br />
'''local variable''': refers to a variable allocated on the stack during the execution of a routine.<br />
In Eiffel, local variables, like other variables, are automatically initialised to default values.<br />
See also the keyword '''local''' in the [[Syntax diagrams#Routine|routine definition of the syntax diagrams]].<br />
</div><br />
<br />
== M ==<br />
<br />
<div id="Method"><br />
'''method:''' is the equivalent of [[#Routine|routine]],<br />
that is to say, a method can be <br />
a [[#function|function]] or a [[#procedure|procedure]] as well. <br />
</div><br />
<br />
== N ==<br />
<br />
== O ==<br />
<br />
== P ==<br />
<br />
<div id="Procedure"><br />
'''procedure:''' a procedure is a set of instructions that performs a certain task. With the exception of [[Current]], which takes no parameters, a procedure takes zero or several parameters and returns no result. See also [[Glossary#function|function]].<br />
</div><br />
<br />
== Q ==<br />
<br />
== R ==<br />
<br />
<div id="Routine"><br />
'''routine:''' routine is short-hand for [[#Procedure|procedure]] or [[#Function|function]].<br />
Hence routine is also the equivalent of [[#Method|method]].<br />
</div><br />
<br />
== S ==<br />
<br />
<div id="SideEffect"><br />
'''side-effect:''' applies to a [[#Routine|routine]] which permanently modifies the<br />
environment in which it is called. For example: changing objects visible to the calling environment,<br />
writing to the screen, emitting a sound, or writing to a printer or a file.<br />
</div><br />
<br />
<div id="Stack"><br />
'''stack''': a data structure used on a first in, first out (FIFO) basis.<br />
In executing a program, a stack is used to store successive [[#Routine|routine]] calls while they<br />
are current. In fact, the stack contains the memory addresses that allow the program to return to <br />
the calling context at the end of each [[#Routine|routine's]] execution.<br />
The stack is also used to allocate the memory associated with [[#LocalVariable|local variables]].<br />
Note that memory management in the stack is very efficient. In particular, the time taken to allocate space<br />
for [[#LocalVariable|local variables]], even if there are many, is almost negligible.<br />
(See also [[#Heap|the heap]]).<br />
</div><br />
<br />
<div id="StaticType"><br />
'''static type:''' an [[#Expression|expression's]] declaration type. In contrast to<br />
[[#DynamicType|dynamic type]], no runtime information is taken into account in determining<br />
the static type of an object.<br />
An expression's static type does not depend on the exact nature of the object designated by the expression.<br />
The static type of [[Current|<tt>Current</tt>]] is that of the surrounding class.<br />
See also [[#DynamicType|dynamic type]].<br />
</div><br />
<br />
== T ==<br />
<br />
== U ==<br />
<br />
== V ==<br />
<br />
== W ==<br />
<br />
== X ==<br />
<br />
== Y ==<br />
<br />
== Z ==</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Liberty_Eiffel_Programming_Environment_FAQ&diff=2414Liberty Eiffel Programming Environment FAQ2016-06-14T20:32:24Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>'''Frequently Asked Questions'''<br />
==General purpose questions about the Liberty Eiffel project==<br />
<div id="LibertyName"><br />
===Where does the name "Liberty" come from?===<br />
<br />
As most Eiffel hackers know, Gustave Eiffel (for whom the language is named), also built the metallic structure of the Liberty Statue.<br />
<br />
More trivia:<br />
Some people may also know that I (Cyril) happen to live very near to Belfort, a town renowned for a sculpture of a lion by Auguste Bartholdi. Bartholdi sculpted the metallic sheets that make the Liberty Statue such an awesome sight.<br />
<br />
<div id="MailingList"><br />
<br />
===Is there a Liberty Eiffel '''mailing list'''?===<br />
</div><br />
Yes! Liberty Eiffel users and developers can share their experiences<br />
and ideas by subscribing to the<br />
[mailto:libertyeiffel@librelist.com Liberty Eiffel official mailing list] by just sending an empty email to this address.<br />
<br />
Please, note that this list is not moderated. <br />
Please, stay correct on that list.<br />
<br />
===Is it possible to have the complete '''Eiffel source code of Liberty Eiffel'''?===<br />
Since it is a free (as in freedom) Eiffel Compiler, the complete source<br />
code of Liberty Eiffel is of course in the distribution. <br />
The source code for additional libraries is also provided. <br />
See also this [[#CommercialApps|FAQ question]] which is related to [[License|licensing]].<br />
<br />
<div id="CommercialApps"><br />
<br />
===Is it possible to use Liberty Eiffel for '''large/commercial applications'''?===<br />
</div><br />
<br />
It is indeed possible to use Liberty Eiffel for a large application.<br />
An Eiffel compiler is a really big project and Liberty Eiffel itself is fully<br />
written in Eiffel.<br />
Liberty Eiffel is completely free and any private company can use<br />
it freely, and distribute (or sell) freely the products made with it.<br />
They do not have to pay royalties.<br />
<br />
Also note that <B>only classes which are closely related to the<br />
compiler itself are under GPL</B> (actually, only the classes of directory<br />
<TT>SmartEiffel/tools</TT> are under GPL).<br />
The other classes are <EM>not</EM> under GPL in order to let people completely<br />
free (i.e. all classes of <TT>lib</TT>).<br />
<br />
Always keep in mind that Liberty Eiffel doesn't come<br />
with any warranty (please read the COPYING file in the distribution).<br />
As explained in the header of non-GPL files, the only important thing<br />
is to keep the header unaltered when the corresponding source file<br />
is provided in your product.<br />
<br />
<!-- continue update to Liberty here --><br />
<br />
<div id="SmallEiffel"><br />
<br />
===What is <B>SmallEiffel</B> compared to <B>SmartEiffel</B>?===<br />
</div><br />
Sma<B>ll</B>Eiffel is the former name of the Sma<B>rt</B>Eiffel<br />
project. We changed because we thought the compiler had become smart<br />
enough ;) <br />
<br />
For a list of changes between the last version of<br />
SmallEiffel and the first one of SmartEiffel, have a look<br />
[http://SmartEiffel.loria.fr/misc/HISTORY.html#1.0 there].<br />
<br />
<div id="HowCanIHelp"><br />
===How can I help?===<br />
</div><br />
The best way to help Liberty Eiffel and its users is probably to <B>pick up<br />
some area you're interested in, and develop</B> your own code, libraries, tools or extensions with Liberty Eiffel,<br />
and then release them to other users.<br />
<br />
A very good way to help us is to follow the<br />
[[Get involved]] guidelines when you find some problem with Liberty Eiffel.<br />
<br />
===Why don't you <B>change this and add that</B>?! It would be much better/cooler/whatever!===<br />
People must understand that we can't always do everything. We simply<br />
can't. Because we don't have the time. Whether we like it or not, we<br />
also have other things to do than provide free stuff, modify our<br />
compiler and/or libraries to please everybody. We do as much as we<br />
can, but we don't do miracles, sorry.<br />
<br />
Since Liberty Eiffel is free of charge and open-source, people who do<br />
need things we don't provide can always implement them and have them<br />
benefit everybody. A good way to do this is to start working on it,<br />
and ask other people (i.e. not the Liberty Eiffel team ;) ) to join and<br />
help. See the [[#HowCanIHelp|How can I help?]] question.<br />
<br />
Alternatively, someone or some company who does need us to implement<br />
something may always consider funding a bit the development of<br />
Liberty Eiffel... After all, we've even heard that some people were<br />
selling software and making a bit of money with it... ;)))<br />
<br />
===How do I '''keep informed''' about Liberty Eiffel?===<br />
The best way is to keep an eye on our web pages,<br />
more especially on the [http://www.liberty-eiffel.org/ Liberty Eiffel main website].<br />
<br />
<br />
===What <B>documentation</B> is provided with Liberty Eiffel?===<br />
The documentation provided with Liberty Eiffel is a transcript of what<br />
you can find on the original Liberty Eiffel Web site, see the link to this wiki.<br />
It is related only to the use and internals of Liberty Eiffel (yes,<br />
we know we still have to improve it ;) ).<br />
<br />
For information and documentation about the Eiffel programming language, check<br />
the links on our<br />
[http://SmartEiffel.loria.fr/general/resources.html Internet resources page].<br />
Note that we are not aware of any complete Eiffel language manual<br />
freely available on the Web (yet?).<br />
<br />
===Why don't you <B>post more messages</B> in newsgroups and/or mailing lists?===<br />
First, because we strongly believe that too much information kills information.<br />
Scientists call this "cognitive overload". :)<br />
<br />
Second, because we don't have the time. It takes an awful amount of time to follow<br />
discussions, whatever their quality. We try to do that. But it's even more<br />
time-consuming to be part of them. So, we often have to choose between<br />
posting/mailing, and working directly on Liberty Eiffel. Since our mailboxes tend<br />
to overflood, we generally choose the latter :)<br />
<br />
===Is it difficult to switch from some commercial Eiffel compiler to Liberty Eiffel?===<br />
If your original Eiffel software only uses simple types like INTEGER,<br />
STRING, ARRAY, BOOLEAN, CHARACTER and DOUBLE, it is usually very simple<br />
to modify your code in order to use Liberty Eiffel.<br />
<br />
It is a little bit difficult for simple input/output (used with predefined<br />
''io'') because some features have different names. If your original software<br />
heavily relies for example on the EiffelBase library, it may be '''very difficult'''.<br />
For example, one must keep in mind that SmartEiffel.ARRAY inherit <br />
SmartEiffel.COLLECTION and that ISE library also have a class COLLECTION. <br />
By the way, subclasses of ISE.COLLECTION cannot be used. <br />
The ISE.LINKED_LIST can be used in conjunction with SmartEiffel.ARRAY because <br />
ISE.LINKED_LIST do not inherit ISE.COLLECTION (no clash).<br />
<br />
==Questions about Languages and/or Object-Oriented Programming==<br />
<br />
<div id="StaticVsDynamicType"><br />
===What is the difference between the Static and the Dynamic Type?===<br />
</div><br />
The static type of a variable is determined at compile-time, the dynamic type during run-time.<br />
The dynamic type must conform to the static type (it may and often will be the same as the static type).<br />
<br />
E.g.: A variable might be declared to refer to an instance of class FRUIT (a_fruit: FRUIT), so the static type is FRUIT, but might be assigned an object of class APPLE (a_fruit := an_apple), which becomes the dynamic type. Obviously, APPLE has to be a descendant of FRUIT in this example.<br />
<br />
<div id="DynamicTypePrediction"><br />
===What is type prediction?===<br />
</div><br />
Type prediction is when the compiler attempts to predict an expression's [[#StaticVsDynamicType|dynamic type]] at compile time.<br />
<br />
==Questions about the Eiffel language of the Liberty Eiffel project==<br />
<br />
<div id="CaseSensitivity"><br />
===Why is Liberty Eiffel case-sensitive?===<br />
</div><br />
<br />
In fact, like most computer languages, Eiffel does distinguish between upper and lower case. Our decision is simply guided by the goals of legibility, organisation and simplification.<br />
<br />
As far as keywords are concerned, it is easier to distinguish them when they are always written in the same way. Thus, we always write '''loop''', rather than '''Loop''' or even '''LoOp'''. We have to get into good habits from now on in other matters too: this rule is going to be generalised so as to be even stricter in future. From now on, lets all get into the habit of writing '''Current''', '''Void''' or '''True''', for example.<br />
<br />
Upper case is also used to distinguish class names from other names. Thus, we can know that '''FOO''' is a class name and '''foo''' is not, without having to look elsewhere in the source code.<br />
<br />
A final advantage of the upper/lower case distinction is that it allows more precise error messages. What makes work simpler for humans also simplifies it for compilers.<br />
<br />
===What is the semantics (meaning) of a <B>manifest string</B>?===<br />
It can certainly be important to know what really happens when you define<br />
a constant STRING attribute by writing, for example: <br />
Message: STRING is "abc"<br />
that constant attribute definition is in fact a compact way of writing:<br />
Message: STRING is<br />
once<br />
create Result.make(3)<br />
Result.extend('a')<br />
Result.extend('b')<br />
Result.extend('c')<br />
end<br />
You realise, of course, that that function definition is a <TT>once</TT> function and<br />
consequently one string and one string only will be created, whatever happens.<br />
When you are investigating performance, you also have to know the difference between:<br />
string := "abc"<br />
and<br />
string := once "abc"<br />
You have probably guessed that, if the instruction without <TT>once</TT><br />
is in a loop, a new string is created each time that the line in question is executed!<br />
<br />
The <TT>once</TT> expression form above is only valid for manifest STRINGs and UNICODE_STRINGs.<br />
Here is an example of a manifest UNICODE_STRING (note the capital U):<br />
unicode_string := once U"abc"<br />
<br />
The [[http://SmartEiffel.loria.fr/man/compile_to_c.html compile_to_c]] command's <br />
<TT>-manifest_string_trace</TT> option <br />
allows you to locate unwanted non-once manifest strings.<br />
<br />
<div id="ConformanceVsCovariance"><br />
<br />
===Can you explain again the difference between <b>conformance</b> and <b>covariance</b>?===<br />
</div><br />
Our paper [http://SmartEiffel.loria.fr/papers/papers.html#JOT2004" Conformance of agents in the Eiffel language]<br />
has a note p.137 that looks surprising.<br />
<br />
<blockquote><br />
<i>Note that the previous rules define conformance rules, this has<br />
nothing to do with covariance or contravariance.</i><br />
</blockquote><br />
<br />
The concepts are distinct, even though there is a relation between<br />
them.<br />
<br />
Covariance is defined in terms of conformance. But assignment is<br />
''also'' defined in terms of conformance.<br />
<br />
That's exactly, and only, what our paper defines: assignment<br />
rules. Those rules were <i>not</i> defined anywhere before. It's<br />
important: <b>it's not that we disagreed with any earlier position. We<br />
just filled a hole in the specification.</b><br />
<br />
Also note that, even if the agent types notation uses square<br />
brackets, it's totally unrelated to the generic classes type notation;<br />
therefore generic classes rules cannot apply (except if proved<br />
otherwise). An agent type is not a generic type, anymore than a tuple<br />
type is a generic type. Those are distinct concepts, only with a<br />
similar notation.<br />
<br />
<P>Conformance is fundamental in any typed language; on the other hand<br />
covariance is "just" an Eiffel extra. Important, sure, but not as<br />
fundamental as conformance. Our paper never speaks of covariance,<br />
except in the note quoted above, and explained further here. Maybe the<br />
paper should have explained the subtlety in so many words.</P><br />
<br />
<div id="CATCALL"><br />
===What is a CATCALL?===<br />
</div><br />
In the Eiffel world ''CATCALL'' is about type safety problems which are still present in <br />
the language.<br />
In Eiffel, CATCALL is a short-hand for ''Changing Availability or Type of CALLs''.<br />
<br />
''Availability'' is about the exportation status of some method.<br />
For example, when a method is redefined, it's exportation status can be<br />
changed too.<br />
<br />
''Type of CALLs'' is about some possibly [[Glossary#Covariance|covariant]] redefinition.<br />
<br />
<div id="SCOOP"><br />
<br />
===What is SCOOP ?===<br />
</div><br />
<br />
In Eiffel, [[SCOOP]] refers to language support for distributed programming.<br />
In the Eiffel world, it is an acronym for ''Simple Concurrent Object-Oriented Programming''.<br />
SCOOP is not yet included in Liberty Eiffel and is certainly its most important missing feature.<br />
<br />
===Is there a style guide for Eiffel source code?===<br />
Yes. Source code in Liberty tools and libraries should conform to the [[Coding Style Guide]]. It seems reasonable to use this as a reference for your own project.<br />
<br />
==Questions about libraries which comes along with Liberty Eiffel==<br />
<br />
===How should I read a file?===<br />
In order to read a file, read a character and then use<br />
last_character ONLY if end_of_input has not been reached<br />
while reading the character.<br />
<BR><br />
Before each read (except the very first), you have to test<br />
end_of_input, because all read_* procedures require not<br />
end_of_input. But why? This require means that if some<br />
previous read failed because end of input has been reached,<br />
then it is not valid to try to read again.<br />
Example:<br />
file: TEXT_FILE_READ; file_name: STRING<br />
...<br />
-- ''Assumming here that'' `file' ''and'' `file_name' ''are not'' [[Void|<tt>Void</tt>]]:<br />
file.connect_to(file_name)<br />
if file.is_connected then<br />
from<br />
file.read_character<br />
until<br />
file.end_of_input<br />
loop<br />
io.put_character(file.last_character)<br />
file.read_character<br />
end<br />
file.disconnect<br />
end<br />
<br />
If you want to read the file line by line, then <tt>read_line</tt><br />
or <tt>read_line_in</tt> can be used. But the reading pattern<br />
<B>is different</B>. This is because after the last line of<br />
the file has been read, then the last line is in <tt>last_string</tt><br />
and has to be used.<br />
Example:<br />
file: TEXT_FILE_READ; file_name: STRING<br />
...<br />
-- ''Assumming here that'' `file' ''and'' `file_name' ''are not'' [[Void|<tt>Void</tt>]]:<br />
file.connect_to(file_name)<br />
if file.is_connected then<br />
from<br />
until<br />
file.end_of_input<br />
loop<br />
file.read_line<br />
if file.end_of_input then<br />
-- The last line of the file does not end with a new<br />
-- line character. Remove this test if you don't care.<br />
std_output.put_string(file.last_string)<br />
else<br />
std_output.put_line(tfr.last_string)<br />
end<br />
end<br />
file.disconnect<br />
end<br />
<br />
<B>Note: </B><tt>last_string</tt> always returns the same STRING object, it's up<br />
to you to make a copy if you need to keep the string value.<br />
<br />
You can read the examples in tutorial directory from the Liberty Eiffel distribution.<br />
<br />
==Questions about the tools of Liberty Eiffel==<br />
<br />
===Is it possible to do <B>incremental compilation</B> with Liberty Eiffel?===<br />
Because of the Liberty Eiffel type inference mechanism,<br />
Liberty Eiffel always produces all needed C files from scratch. As old C files<br />
are automatically saved, only modified C files are recompiled.<br />
See <TT>[http://SmartEiffel.loria.fr/man/compile.html man/compile]</TT> for details.<br />
<br />
===Is there a mechanism to <B>pre-compile</B> libraries?===<br />
No, there is no such mechanism in Liberty Eiffel. But if you're concerned<br />
about compilation speed, don't worry, pre-computed libraries are not the only way to be fast !<br />
Just try Liberty Eiffel, and you'll see :)<br />
<br />
<br />
===Is it possible to use the <B>Boehm-Demers-Weiser garbage collector</B> with Liberty Eiffel?===<br />
Yes.<br />
<BR>You just have to pass the compiler option -bdw_gc and this should it be.<br />
<br />
===How to customise the <B>Garbage Collector</B> for a new architecture?===<br />
</div><br />
If your architecture needs special handling to get the GC working<br />
(because the stack is not contiguous, because some registers are not<br />
written on the stack on `setjmp'...) then you need to implement function<br />
`mark_stack_and_registers' for your system in the file<br />
<TT>SmartEiffel/sys/runtime/c/gc_lib.c</TT>.<br />
<BR><br />
<br />
If you get some message telling you that the stack direction is wrong, then<br />
you should change macro definition to use the other generic code<br />
(there is one generic code for each stack order).<br />
<BR><br />
<br />
In order to check the GC, you should be able to run all files of<br />
the <TT>SmartEiffel/misc/benchmarks/gc</TT> directory.<br />
</TD><br />
</TR><br />
<br />
===How is Liberty Eiffel compiled?===<br />
With Eiffel optimisation options -boost and -no_gc. The garbage collector is<br />
indeed useless on the Liberty Eiffel commands: since Liberty Eiffel did not include a GC in its first versions, we were very careful about memory when we developed it.<br />
<br />
With C compilation optimisations turned on (it depends on the C compiler used;<br />
we generally use gcc).<br />
The resulting executables are stripped.<br />
<br />
<div id="External tools for Liberty Eiffel"><br />
<br />
==External tools for Liberty Eiffel==<br />
</div><br />
<br />
<div id="Syntax highlighting"><br />
===Are there editors with support for Liberty Eiffel?===<br />
<br />
* [https://www.gnu.org/s/emacs/ Emacs] has support for syntax highlighting, indenting, flymake mode, code templates and more. For installation see the article ''[http://www.berenddeboer.net/eiffel/eiffel_and_emacs.html Editing Eiffel code with Emacs]'' from Berend de Boer but you may use the distributed version of <code>[http://git.savannah.gnu.org/cgit/liberty-eiffel.git/plain/work/eiffel.el eiffel.el]</code> (in the work/ directory of the source distribution).<br />
<br />
* [http://www.vim.org Vim] also has similar support for Eiffel and [https://github.com/LibertyEiffel/vim-liberty-eiffel specific additions for Liberty Eiffel]<br />
<br />
* [https://atom.io/ Atom] has an [https://atom.io/packages/language-eiffel Eiffel package] available.<br />
<br />
* [http://www.macromates.com TextMate] has an [https://github.com/textmate/eiffel.tmbundle Eiffel bundle] available.<br />
<br />
* [https://wiki.gnome.org/Apps/Gedit Gedit] offers syntax highlighting.<br />
<br />
* On Windows [https://notepad-plus-plus.org/ Notepad++] offers syntax highlighting as well.<br />
<br />
* [https://www.editpadpro.com/editeiffel.html EditPad Pro] supports several features for Eiffel.<br />
<br />
===Is there a GUI or IDE for Liberty Eiffel?===<br />
<br />
An [https://github.com/Imhotup/LibertyEiffel-Eclipse-Plugin Eclipse-based IDE] is currently under development as part of [[GSoC]] 2016.<br />
<br />
<div id="Liberty Eiffel debugger with GUI"><br />
<br />
===Is there a debugger for Liberty Eiffel with a GUI?===<br />
</div><br />
Currently not. There was a front end for the sedb (SmartEiffel debugger). It is called ''SmartEiffel Embedded Debugger Output Visualiser'' (sedbov). It maps the key command from the sedb to a GUI. You can find it at https://opensvn.csie.org/traccgi/sedbov/wiki/WikiStart. It use the script language TCL/TK with the extension expect. For information look at http://www.tcl.tk.<br />
<br />
<div id="LibertyEiffelWiki"><br />
<br />
==External information about Eiffel==<br />
</div><br />
<br />
<div id="Where can i find more information about Eiffel?"><br />
===Where can I find more information about Eiffel?===<br />
</div><br />
The news group news:comp.lang.eiffel has low post frequency.<br />
<br />
<div id="I am a beginner. Where can i find tutorials?"><br />
<br />
===I am a beginner. Where can I find tutorials?===<br />
</div><br />
You should study and compile the examples in the tutorials directory.<br />
<br />
Cetus contains links to tutorial papers (http://www.cetus-links.org/oo_eiffel.html).</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Getting_Started&diff=2413Getting Started2016-06-14T20:29:28Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>== Prepared Debian/Ubuntu packages ==<br />
On http://apt.liberty-eiffel.org/ we have prepared some Debian/Ubuntu packages. For the quick start using the last stable release do:<br />
<br />
* add the following repository (note: it is currently unsigned)<br />
<nowiki>deb http://apt.liberty-eiffel.org/ release main</nowiki><br />
<br />
* then install (as root or with sudo)<br />
apt-get install liberty-eiffel-all<br />
<br />
That's it, you now can run "se c" to [[Tutorial_tour|compile your first program.]]<br />
<br />
== Windows Installer ==<br />
So far we don't have an installer for windows, but a [[GSoC_-_Windows_Support|current GSoC project]] is working on that. In case of interest get in touch with us, maybe you can provide some input or help with testing.<br />
<br />
== Bootstrap from tarball ==<br />
Download the <release>.tar.gz from http://download.savannah.gnu.org/releases/liberty-eiffel<br />
unpack it with<br />
tar -zxvf <release>.tar.gz<br />
<br />
bootstrap Liberty with<br />
cd <release><br />
./install.sh -bootstrap<br />
<br />
This will create a default liberty configuration in ~/.config/liberty-eiffel/, bootstrap the compiler and compile all the tools. Afterwards you just need to add <LibertyHome>/target/bin to your path, e. g. in .bashrc:<br />
PATH=$PATH:~/<release>/target/bin<br />
export PATH<br />
<br />
== Bootstrap from git source ==<br />
On Linux (and most other Unix-like systems) installation of Liberty from source is simple:<br />
<br />
Check that the following Pre-requisites are available on your system:<br />
* git<br />
* GCC compiler<br />
* GCC-XML extension<br />
* Boehm-Demers-Weiser garbage collector dev-packages<br />
<br />
On debian-like systems you may install them with:<br />
sudo apt-get install git build-essential gccxml libgc-dev<br />
<br />
On Fedora you'll need gc-devel, rather than libgc-dev, gccxml and of course the basic packages for compiling like gcc, git etc.<br />
<br />
Now clone the repository:<br />
git clone git://git.sv.gnu.org/liberty-eiffel.git<br />
<br />
Change into the directory you created by this:<br />
cd liberty-eiffel<br />
<br />
and execute<br />
./install.sh -bootstrap<br />
<br />
This will create a default liberty configuration in ~/.config/liberty-eiffel/, bootstrap the compiler and compile all the tools. Afterwards you just need to add <LibertyHome>/target/bin to your path, e. g. in .bashrc:<br />
PATH=$PATH:~/liberty-eiffel/target/bin<br />
export PATH<br />
<br />
'''Please note that no legacy SmartEiffel system should be installed on your system. Particularily, any /etc/serc file will prevent you from installing Liberty Eiffel correctly.<br />
'''<br />
Now you can call [[Se|se]] as interface for all tools. For examples go to<br />
cd <LibertyHome>/tutorial<br />
and compile with<br />
se compile hello_world.e -o hello_world<br />
your first Liberty Eiffel program.<br />
<br />
After this great success, play with the [[Table of contents#Eiffel|language]], [[Tools|tools]] and [[Table of contents#Library|libraries]]. Develop cool applications and for any question, suggestion or complaint [[Get in touch|get in touch]] with us. We are also happy to receive pull requests and provide accounts to this wiki if you want to contribute code or documentation. Be welcome to [[Get involved| get involved]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Versions_history&diff=2412Versions history2016-06-14T20:28:31Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Releases]]<br />
== Liberty Eiffel (latest release first) ==<br />
For other upcoming releases see the [[upcoming releases|list of names]].<br />
=== Curtiss (2016.dev, to be named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===<br />
* not yet released (see next section for current release notes)<br />
* User-visible changes:<br />
** addition of a zsh completer for se<br />
** finally got rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND<br />
** removed support for some unused platforms (Amiga, Elate, ...)<br />
** creation keyword now generates an error<br />
** C99 conforming C code generation (hopefully)<br />
* Developer changes:<br />
** RUN_FEATUREs now have clear names (hopefully)<br />
** to better support the more recent Windows versions, the config file is no longer written to a root directory but rather to %ALLUSERSPROFILE% or %USERPROFILE% <br />
* Known bugs:<br />
** see [https://savannah.gnu.org/bugs/?group=liberty-eiffel] for the full list<br />
<br />
=== Bell (2016.05, named after [https://en.wikipedia.org/wiki/Alexander_Graham_Bell Alexander Graham Bell]) ===<br />
* released in May 2016<br />
* first release since Liberty Eiffel has become the official GNU Eiffel compiler<br />
* User-visible changes:<br />
** changed Environment Variable name from SmartEiffel to Liberty Eiffel (anyhow, normally it should not be necessary to set this one)<br />
** new tool [[Mock]]<br />
** removed linebreaks in compiler output<br />
** many bugfixes<br />
** GC call at exit is optional<br />
** generic creation<br />
** agents are now [https://en.wikipedia.org/wiki/Closure_(computer_programming) closures ]<br />
** finder now finds all classes in the universe with the given name, not only the first one<br />
** keyword '''is''' at the beginning of a feature is now deprecated<br />
** Added support for alias "[]" and alias "()"<br />
** constants are now visible in the eiffeldoc generated documentation<br />
* Known bugs:<br />
** there is still an issue in both GC implementations (classical SEGC and BDW), if it shows up, it often yields a "Bad target type" runtime error.<br />
** for the full list see [https://savannah.gnu.org/bugs/?group=liberty-eiffel]<br />
<br />
=== Adler (2013.11, named after [http://en.wikipedia.org/wiki/Charles_Adler,_Jr. Charles Adler, Jr.]) ===<br />
* First release as Liberty Eiffel<br />
* User-visible changes:<br />
** Added [[library_class:NATURAL_8|<tt>NATURAL_8</tt>]], [[library_class:NATURAL_16|<tt>NATURAL_16</tt>]], [[library_class:NATURAL_32|<tt>NATURAL_32</tt>]], and [[library_class:NATURAL_64|<tt>NATURAL_64</tt>]] classes. See <tt>tutorial/natural.e</tt> for examples.<br />
** Even low-level features (i.e. <tt>external "built_in"</tt>) are now checking their assertions. As an example, division by zero is now checked by assertions.<br />
** Inlined dynamic dispatch for better performance<br />
** A missing export clause is deprecated. Use <tt>{ANY}</tt> instead.<br />
** New core libraries: cli, json, log, parse (beware, these libraries are not yet tuned to be used without GC)<br />
** Improved libraries: string (with notably a new [[library_class:FIXED_STRING|<tt>FIXED_STRING</tt>]] class)<br />
** Wrapper libraries: gtk, gdk, readline, ffi...<br />
** A new tool that can generate mocks to help unit testing<br />
** [http://hboehm.info/gc/ BDW] GC support<br />
* Developer changes:<br />
** The web site now belongs to the repository<br />
** Automatic testing tools (ET on the web, and <tt>watch_eiffeltest.sh</tt> in the shell)<br />
** Automatic Debian packages generation<br />
* Known bugs:<br />
** BDW GC is not well tested; currently weak references seem not to work properly; and the GC is not run at program exit (it should run all finalizers)<br />
** Sometimes SmartEiffel's native GC behaves wrongly, analysis is welcome<br />
** Some of the newer core libraries do not work very well when there is no GC<br />
** See the [https://savannah.gnu.org/bugs/?group=liberty-eiffel bugs page]<br />
<br />
== SmartEiffel (all releases which are predecessors of Liberty) ==<br />
<br />
<br />
=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===<br />
<br />
Again, a lot of novelties for this release:<br />
<br />
* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.<br />
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Type_inference&diff=2411Type inference2016-06-14T20:27:42Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Type inference is an algorithm allowing Liberty Eiffel to statically compute the true type of the objects at run time.<br />
<br />
Usually this algorithm allows to simplify the generated code by deleting [[dynamic binding]] sites when the static type is computed to be reduced to a unique dynamic type. This simplification is summed up and displayed by the [[compile|compiler]] when using the <TT>-verbose</TT> flag. It's called ''type inference score''; it is the fraction of simplified binding sites over the total number of sites.<br />
<br />
One should note that a 100% score is usually not possible, nor desirable; else your project is not really written in an OO spirit...</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Tutorial_tour&diff=2410Tutorial tour2016-06-14T20:26:15Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>Welcome to the guided tour of the tutorial!<br />
<br />
All the classes in the tutorial are provided with your Liberty Eiffel installation, in the <code>tutorial</code> directory.<br />
<br />
=== Easy starting: Hello World! ===<br />
<br />
To compile the program, go to the <code>LibertyEiffel/tutorial</code> directory and execute the command:<br />
<br />
se c HELLO_WORLD make -o hello<br />
<br />
The meaning of the command is<br />
{|<br />
|-<br />
|<code>se</code><br />
|the front-end tool for the Liberty Eiffel compiler<br />
|-<br />
|<code>c</code><br />
|the tool invoked by <code>se</code> for compile into an executable<br />
|-<br />
|<code>HELLO_WORLD</code><br />
|the class of which an object is created (you may also write it in lower-case, or use its filename with the <code>.e</code> extension) we call it root class, as this is the root of the programs object tree<br />
|-<br />
|<code>make</code><br />
|the creation procedure of the <code>HELLO_WORLD</code> class to call<br />
|-<br />
|<code>-o hello</code><br />
|generates an executable with the name hello (linux) or hello.exe (windows)<br />
|}<br />
<br />
The command produces an executable, usually <code>hello</code> or <code>hello.exe</code> depending on the system. After compiling is finished, you can run the executable.<br />
<br />
This unavoidable program is in the file <code>hello_world.e</code> and lets you grasp the basic concepts of Eiffel. Those concepts are:<br />
* '''Everything is a class'''. In Eiffel, outside classes there is no salvation.<br />
* The program starts by '''creating an object''' (of the root class) and initializing it by execution of the given root creation procedure. Here, the <code>make</code> feature in the class <code>HELLO_WORLD</code>.<br />
* Each file is named after the name of the class it contains, in lower-case, with the <code>.e</code> extension.<br />
* Each class comes with a set of '''features''', all its attributes and methods which come in form of functions (if they return a result) or procedures (in case they just 'do' something)<br />
* Note the special object <code>io</code> that allows you to write text on the standard output. We will see that it also lets you read data.<br />
* For the Eiffel syntax, look [[Syntax_diagrams|here]].<br />
<br />
Please take a look at the following examples in the tutorial folder to see some classical example programs (some of them are in organized in folders for better overview)<br />
* fibonacci.e<br />
* knight.e<br />
* pyramide.e and pyramide2.e<br />
* hanoi<br />
* parking<br />
* triangle<br />
<br />
To compile the other samples you must obviously modify the compiler command to give another root class .<br />
<br />
== Some important concepts ==<br />
<br />
=== Comments ===<br />
As in every programming language there is the possibility to write comments into the source code, which do not have any effect for the final program, but are for the developer or reader of the source code to get an understanding of the ideas and algorithms behind the code.<br />
A comment in Eiffel starts with the sequence of a couple of minus signs and is terminated by a newline (RETURN).<br />
-- this is a comment in Eiffel<br />
a := b + 3 -- comments are also allowed after some code<br />
<br />
=== Manifest notations ===<br />
Liberty Eiffel comes with a big set of available datatypes. Famous examples as INTEGER, BOOLEAN, CHARACTER and STRING. For those (and also many collection types) there is the possibility to directly denote them in the program code, using the notations<br />
123<br />
True, False<br />
'a'<br />
"STRING"<br />
See tutorial file manifest_notation.e for an example with nearly all options to define objects by manifest notations.<br />
<br />
=== Everything is an Object ===<br />
As mentioned above, in Eiffel every useful thing is an object. There are two different kinds of objects: expanded objects and referenced object. Expanded objects are passed by value, while reference objects are - who guesses - passed by reference. In case you write 7 in the source code this is a shorthand for an instance of the expanded type INTEGER and therefore it is an expanded object. Whenever you assign it to a variable or pass it to another feature it gets copied. A STRING object - e. g. denoted by "Hello World!" in the source code is a reference object, created implicitly by the compiler, allocated on the heap and passed by reference.<br />
<br />
=== Local variables and Assignments ===<br />
Every routine may define variables in a "local block" before its body (which start with the keyword do):<br />
make<br />
local<br />
a: INTEGER<br />
s: STRING<br />
do<br />
a := 5<br />
a := a + 1<br />
s := "Hello World!"<br />
end<br />
<br />
The visibility of these variables is limited to the method they are defined in and they do not keep their value from one execution of that routine to another. Assignment is done by the assignment operator ":=" which changes the variable (or let's say writable entity) on the left side to the value of the expression on the right side. In case of the "Hello World!" assignment a new object of type STRING is created on the heap, initialized to the text "Hello World!" and a link to this object is stored in the local variable s.<br />
<br />
=== Loops ===<br />
In Eiffel we have exactly one construct to do something repeatedly, so no need to learn about for, do-while, while, anyhow, one is sufficient:<br />
from<br />
-- initialization<br />
invariant<br />
-- what shall stay true during repetition<br />
variant<br />
-- non-negative, but decreasing numeric value<br />
until<br />
-- termination condition<br />
loop<br />
-- what to do several times<br />
end<br />
<br />
Note, that the termination condition is an expression of type BOOLEAN and the loop body is executed until the condition evaluates to True, which differs in the logic from e. g. the loop constructs in C.<br />
<br />
The most strange things for newcomers are probably the [https://en.wikipedia.org/wiki/Loop_invariant invariant] and the [https://en.wikipedia.org/wiki/Loop_variant variant]. While the first is a BOOLEAN condition, that stays true for every iteration, the latter is an INTEGER value which decreases with every iteration and always stays positive and therefore shows that the loop terminates. Both are optional and are not used very often in practice, even though they are essential in case we want to prove a program to be totally correct (and therefore terminates). I fear, that these formal loop assertions stay more or less unused until a formal verification tool is able to take real benefit from them.<br />
<br />
See tutorial/loops.e for an example of the Greatest Common Divider algorithm to show the usage of the loop.<br />
<br />
=== Input-output ===<br />
<br />
==== io cluster ====<br />
<br />
The input-output cluster is made up of several parts. <br />
<br />
The io/basic subcluster contains the staples of <br />
<br />
* the definitions of standard input and output streams, [[library_class:STD_INPUT|STD_INPUT]] and [[library_class:STD_OUTPUT|STD_OUTPUT]] that are available to all classes. In fact [[library_class:ANY|ANY]] offers those features:<br />
** io: [[library_class:STD_INPUT_OUTPUT|STD_INPUT_OUTPUT]] -- Handle to standard file setup.<br />
** std_input: [[library_class:STD_INPUT|STD_INPUT]] -- The standard input stream<br />
** std_output: [[library_class:STD_OUTPUT|STD_OUTPUT]] -- The standard output stream<br />
** std_error: [[library_class:STD_ERROR|STD_ERROR]] -- The standard error stream<br />
** standard_streams: [[library_class:STANDARD_STREAMS|STANDARD_STREAMS]], a singleton that allows to redirect std_input_stream, std_output_stream as well as std_error_stream. <br />
<br />
Beyond this standards streams that are available to all processes you can get read files in the operative file system using an [[library_class:INPUT_STREAM|INPUT_STREAM]] using [[library_class:BINARY_FILE_READ|BINARY_FILE_READ]] to read a binary file or [[library_class:TEXT_FILE_READ|TEXT_FILE_READ]] to read a text file.<br />
Similarly, to write a file you use an [[library_class:OUTPUT_STREAM|OUTPUT_STREAM]] such as [[library_class:BINARY_FILE_WRITE|BINARY_FILE_WRITE]] for binary files or [[library_class:TEXT_FILE_WRITE|TEXT_FILE_WRITE]] for text files. <br />
<br />
[[library_class:READLINE_INPUT_STREAM|READLINE_INPUT_STREAM]] is an input stream where the data is read from Command Line Interface (CLI) using the GNU readline library. You probabily have already used this library without knowing as it is used by several programs as at the time this notes has been written almost nine hundred packages in Debian use a version of readline<br />
<br />
You may have noticed that Eiffel uses streams to access files. This is a much more flexible way to access data. In fact when you use an [[library_class:INPUT_STREAM|INPUT_STREAM]] the actual data can come from plain files, or from a string with [[library_class:STRING_INPUT_STREAM|STRING_INPUT_STREAM]] or any classes that conforms to and INPUT_STREAM, or more properly any live type that is a proper heir of INPUT_STREAM, such as BINARY_INPUT_STREAM, EZMQ_SOCKET_INPUT (a sockect messaging library), FILTER_INPUT_STREAM{ (put references to filters and explaiin BASE64_INPUT_STREAM, HTTP_CLIENT_INPUT_STREAM, MONITORED_INPUT_STREAM, QUOTED_PRINTABLE_INPUT_STREAM, TEMPLATE_INPUT_STREAM<br />
), TERMINAL_INPUT_STREAM.<br />
<br />
Mostly for testing purposes there are also [[library_class:NULL_INPUT_STREAM|NULL_INPUT_STREAM]], a "null" stream provides an unbroken sequence of zero, like /dev/zero does on Unix and <br />
[[library_class:NULL_OUTPUT_STREAM|NULL_OUTPUT_STREAM]] that swallows any character like /dev/null does on Unix. <br />
<br />
<br />
* directory<br />
* basic_directory?<br />
<br />
=== Arguments ===<br />
print_arguments.e<br />
<br />
=== Feature calls ===<br />
<br />
<br />
=== Contracts ===<br />
Contracts are the main reason why Eiffel is superior to many other languages...<br />
...<br />
<br />
=== Garbage collection ===<br />
Eiffel is garbage collected. That means, the objects created on the heap will automatically be freed after they lost reachability from the rest of the executing program.<br />
<br />
=== ACE files ===<br />
<br />
=== Collections ===<br />
including iterator and sorting<br />
<br />
=== Downcasting ===<br />
downcasting.e<br />
<br />
== To go further ==<br />
<br />
=== Agents ===<br />
... and tuples<br />
<br />
=== external ===<br />
<br />
=== cecil ===<br />
<br />
=== Memory management ===<br />
memory<br />
<br />
== Extension libraries ==<br />
<br />
=== Random ===<br />
<br />
=== Date & time ===<br />
<br />
=== Storable ===<br />
<br />
=== Sequencer ===<br />
<br />
=== Vision ===<br />
visiopn, signal<br />
<br />
=== Network ===<br />
<br />
=== Execution ===</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Table_of_contents&diff=2409Table of contents2016-06-14T20:21:38Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>'''Liberty Eiffel Wiki'''<br />
<br />
<div id="History"><br />
'''1''' History and goals of the Liberty Eiffel project<br />
<br />
<blockquote><br />
'''1.1''' [[Introduction]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''1.2''' [[Versions history|All Liberty Eiffel versions]]<br />
</blockquote><br />
</div><br />
<br />
<div id="Tutorial"><br />
'''2''' Build with Liberty Eiffel<br />
<br />
<blockquote><br />
'''2.1''' [[Getting_Started|Setup Liberty Eiffel on your computer]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''2.2''' [[Tutorial tour|Guided tour of the tutorial]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''2.3''' [[Build your library]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''2.4''' [[sedb|Debug your programs]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''2.5''' [[profile|Profile your programs]]<br />
</blockquote><br />
</div><br />
<br />
<div id="Lecture"><br />
'''3''' Lecture on object-oriented programming and design by contract in Eiffel<br />
<br />
<blockquote><br />
'''3.1''' [[Inheritance]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''3.2''' [[Dynamic dispatch]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''3.3''' [[Comparison of objects|Comparison of objects]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''3.4''' [[Cloning objects]]<br />
</blockquote><br />
</div><br />
<br />
<div id="Library"><br />
'''4''' The LibertEiffel general purpose library<br />
<br />
<blockquote><br />
'''4.1''' [[Library interface|How to use the library]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''4.2''' [[Library design|Design of the library]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''4.3''' [[Library Wrappers|How to use existing libraries in Liberty Eiffel (wrappers)]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''4.4''' [[Wrapping_C_libraries|How to create a wrapper for existing libraries]]<br />
</blockquote><br />
<br />
</div><br />
<br />
<div id="Tools"><br />
'''5''' [[Tools|Liberty Eiffel's tools documentation]]<br />
</div><br />
<br />
<div id="Eiffel"><br />
'''6''' The Eiffel language of Liberty Eiffel<br />
<br />
<blockquote><br />
'''6.1''' [[System defintion]] of Eiffel<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.2''' [[Syntax diagrams]] of Eiffel<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.3''' [[Expanded or reference|Expanded object or reference object]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.4''' [[Typing policy|Validity of assignments and feature redefinitions]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.5''' [[Current|What you need to know about <TT>Current</TT>]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.6''' [[Void|A definition of <TT>Void</TT>]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.7''' [[Once]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.8''' [[Tuple]]s<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.9''' [[Agent]]s<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.10''' [[Precursor]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.11''' [[Manifest storage notation]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.12''' [[Dynamic type testing]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.13''' [[Type of integer constants]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.14''' [[SCOOP]] - Concurrency in Liberty Eiffel<br />
</blockquote><br />
<br />
<blockquote><br />
'''6.15''' [[ECMA]] - The ECMA standard andLiberty<br />
</blockquote><br />
</div><br />
<br />
'''7''' [[FAQ|The Liberty Eiffel FAQ]]<br />
<br />
'''8''' [[Glossary]]<br />
<br />
'''9''' [[Papers]]<br />
<br />
'''10''' [[License]]<br />
<br />
<div id="Appendices"><br />
'''11''' Appendices<br />
<br />
<blockquote><br />
'''11.1''' [[Author guidelines]] for this wiki<br />
</blockquote><br />
<br />
<blockquote><br />
'''11.2''' Why there are [[no threads]]<br />
</blockquote><br />
<br />
<blockquote><br />
'''11.3''' [[Gc info|The output of the <tt>-gc_info</tt> option]].<br />
</blockquote><br />
</div><br />
<br />
'''12''' [[Bibliography]]<br />
<br />
'''13''' [[Manual index|Index]]</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Visitor&diff=2407Visitor2016-06-14T17:15:40Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category: Design Pattern]]<br />
Liberty Eiffel vistors are a mechanism that let you reuse the Liberty Eiffel kernel in order to build new applications.<br />
<br />
This is how [[eiffeldoc]], for example, was built without the need to touch the system kernel.<br />
<br />
The origin of visitors is a ''[[Glossary#DesignPattern|design pattern]]'', in fact the [http://www.objectmentor.com/resources/articles/acv.pdf acyclic visitor] developed by Robert C.&nbsp;Martin.<br />
<br />
This design pattern has been adopted and adapted by Liberty Eiffel. All the framework classes are in the <tt>SmartEiffel/tools/visitor</tt> directory.<br />
<br />
== Framework ==<br />
<br />
Every visitable class inherits from [[library_class:VISITABLE|<tt>VISITABLE</tt>]]. With it are associated: <br />
* a class derived from [[library_class:VISITOR|<tt>VISITOR</tt>]],<br />
* a [[Glossary#Feature|feature]] <tt>accept</tt> which has for its parameter an object of that class.<br />
<br />
== Visitable classes ==<br />
<br />
The visitable classes are all the classes of the syntactic and semantic tree. There we find in particular<br />
* [[tool_class:EXPRESSION|<tt>EXPRESSION</tt>]], [[tool_class:INSTRUCTION|<tt>INSTRUCTION</tt>]] (syntactic classes)<br />
* [[tool_class:TYPE|<tt>TYPE</tt>]], [[tool_class:FEATURE_STAMP|<tt>FEATURE_STAMP</tt>]], [[tool_class:LIVE_TYPE|<tt>LIVE_TYPE</tt>]]... (semantic classes)<br />
<br />
== Using visitors ==<br />
<br />
=== Simple cases ===<br />
<br />
Each visitor can be used separately, but you can also use several in the same class; this is the most common case.<br />
<br />
To use visitors, you have to create a '''visitor class'''. This class will have the following properties:<br />
* inherits all the visitor classes of the framework (conforming inheritance)<br />
* also inherits from the [[library_class:VISITOR|<tt>VISITOR</tt>]] class itself (conforming inheritance)<br />
* defines all the <tt>visit_*</tt> features of the visitor classes.<br />
<br />
Usually, such a class also provides a [[Glossary#Feature|feature]] which lets you start a search. If that does not exist, it is enough to run the <tt>accept</tt> [[Glossary#Feature|feature]] on a visitable object. Of course, that object must be visitable ''by that visitor'', in other words, that visitor must inherit from the framework visitor class which is able to visit the object.<br />
<br />
For some examples, see [[tool_class:AGENT_CREATION_HELPER|<tt>AGENT_CREATION_HELPER</tt>]] or again [[tool_class:HIDDEN_EXPRESSION_DETECTOR|<tt>HIDDEN_EXPRESSION_DETECTOR</tt>]].<br />
<br />
=== Using [[tool_class:IN_OUT_VISITOR|<tt>IN_OUT_VISITOR</tt>]] ===<br />
<br />
[[tool_class:IN_OUT_VISITOR|<tt>IN_OUT_VISITOR</tt>]] is a class that lets you do a complete search of a class's syntactic tree, depth-first.<br />
<br />
Each node is visited by the following algorithm (the NODE class is imaginary):<br />
feature {NODE}<br />
visit_node (a_node: NODE) is<br />
do<br />
if enter_node(a_node) then<br />
node.child.accept(Current);<br />
exit_node(a_node);<br />
end<br />
end<br />
<br />
feature {}<br />
enter_node (a_node: NODE): BOOLEAN is<br />
do<br />
Result := True<br />
end<br />
<br />
exit_node (a_node: NODE) is<br />
do<br />
end<br />
<br />
The interesting point is that a class inheriting from [[tool_class:IN_OUT_VISITOR|<tt>IN_OUT_VISITOR</tt>]] has to redefine only what is strictly necessary.<br />
<br />
See, for example, [[tool_class:EIFFELDOC_SHORTER_CLASSDOC|<tt>EIFFELDOC_SHORTER_CLASSDOC</tt>]] and [[tool_class:EIFFELDOC_SHORTER_FIND_CLIENTS|<tt>EIFFELDOC_SHORTER_FIND_CLIENTS</tt>]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Semantics&diff=2406Semantics2016-06-14T17:12:22Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>== Overview ==<br />
<br />
''Note:'' this page is still being written. Take the information with a grain of salt.<br />
<br />
Semantic analysis is strongly linked with the most important aspect of the Liberty Eiffel tools: '''code specialization'''. Liberty Eiffel does not use a syntax tree; but a ''semantics'' tree. Each node of that tree is a reflection of the syntax tree in the light of a particular type (think generic classes, inheritance). The original tree is provided by the parser.<br />
<br />
All the specialization phases are one pass over the whole code specialized by earlier phases. The usual algorithm is the following:<br />
* try to specialize every attribute<br />
* if any changed, twin Current and assign the specialized attributes<br />
* return either Current (if nothing changed) or the twin (i.e. specialized)<br />
<br />
Most specialization phases can run simultaneously for different types. Some phases (viz. collect) may even call again earlier phases. The only barrier is at the end of collect: at that time, all the types are ready to use (i.e. the whole system is known).<br />
<br />
The specialization phases are:<br />
* specialize_in<br />
* specialize_thru<br />
* specialize_and_check<br />
* collect<br />
* simplify<br />
* adapt<br />
<br />
Also of note:<br />
* resolve_in (not available before, including, specialize_2)<br />
* [[tool_class:FEATURE_ACCUMULATOR|<tt>FEATURE_ACCUMULATOR</tt>]]<br />
* [[tool_class:ANONYMOUS_FEATURE_MIXER|<tt>ANONYMOUS_FEATURE_MIXER</tt>]]<br />
<br />
== Specialization phases ==<br />
<br />
=== specialize_in ===<br />
<br />
* Type building<br />
<br />
The code to specialize comes directly from the parser. This code is used every time a new [[tool_class:TYPE|<tt>TYPE</tt>]] must be created: all the code coming from parents is specialized when the type of the target (i.e. Current) is the type being created.<br />
<br />
For instance, the code coming from [[library_class:ANY|<tt>ANY</tt>]] is specialized in every type, either directly of indirectly (barring redefines, of course).<br />
<br />
At the end of this phase, a [[tool_class:TYPE|<tt>TYPE</tt>]] is partially defined; only the features coming from its parents are specialized.<br />
<br />
* Feature collect<br />
<br />
At the end of feature collect (see below), the signatures of the features that are ''not'' inherited are specialized in the context of their target type.<br />
<br />
=== specialize_thru ===<br />
<br />
* Feature collect<br />
<br />
At the end of feature collect (see below), the signatures of the inherited features are specialized in the context of their target type, using their parent type.<br />
<br />
=== specialize_and_check ===<br />
<br />
When a type uses other types, those must have been collected first. In this phase, all the types used by the target type have been collected.<br />
<br />
Most semantics checks happen here. Code transformation may also happen (see e.g. [[issue:78]]).<br />
<br />
=== collect ===<br />
<br />
Feature collect is the phase where a type collects all its known features. To do so, it is helped by the [[tool_class:FEATURE_ACCUMULATOR|<tt>FEATURE_ACCUMULATOR</tt>]].<br />
<br />
At the end of this phase, a [[tool_class:TYPE|<tt>TYPE</tt>]] is considered completely built.<br />
<br />
During this phase, new types may be created, which will also be specialized.<br />
<br />
When no new type is created, the system is deemed whole.<br />
<br />
=== simplify ===<br />
<br />
This phase, only run in boost mode, tries to simplify the code: inlining, etc.<br />
<br />
=== adapt ===<br />
<br />
This phase transforms the code from the 2.x SmartEiffel core classes to the old 1.x SmartEiffel classes which are used by the generation back-end.</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Short&diff=2405Short2016-06-14T17:07:09Z<p>Dkearns: s/LibertyEiffel/Liberty Eiffel/</p>
<hr />
<div>[[Category:Tool]]<br />
<br />
The <tt>short</tt> command is the Liberty Eiffel interface generator. Using a plain Eiffel source file, the command prints the interface of this class to the standard output. It is also a good tool to perform many validity checks of a given class (syntax, exportation rules, inheritance, etc.).<br />
<br />
In a normal installation, the tool is invoked by the command <b><TT>[[se]]&nbsp;short</TT></b>.<br />
<br />
There are two ways of invoking it: the ''traditional'' mode and the ''ACE'' mode.<br />
* In the traditional mode, many options can be specified on the command line.<br />
* In the [[ACE]] mode ''(Assembly of Classes in Eiffel)'', most of its options are not allowed on the command line; they have their equivalents ''in'' the ACE file.<br />
<br />
<br />
== Synopsis ==<br />
<br />
* <code>se short [options] &lt;class&gt;</code><br />
* <code>se short [options] &lt;ace_file.ace&gt; &lt;class&gt;</code><br />
<br />
The first syntax is the traditional mode, the second is the ACE mode.<br />
<br />
In the ACE mode, the name of the [[ACE]] file provided must end with the suffix <TT>.ace</TT>.<br />
<br />
=== Options ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-help</code><br />
| Display a short summary of the command line syntax, as well as a complete list of the compiler's options.<br />
|-<br />
| valign="top" | <code>-verbose</code><br />
| Display (an enormous amount of) information during the compilation: a complete list of files loaded, the [[type inference]] scores, the generated files, and so on.<br />
|-<br />
| valign="top" | <code>-version</code><br />
| Display the Liberty Eiffel version number.<br />
|-<br />
| valign="top" | <code>-loadpath&nbsp;&lt;loadpath-file&gt;</code><br />
| Add a loadpath file for class lookup. See details in the [[finder]] page.<br />
|-<br />
| valign="top" | <code>-sort</code><br />
| Sort features alphabetically.<br />
|-<br />
| valign="top" | <code>-short</code><br />
| Show only locally defined features (do not consider purely inherited features).<br />
|-<br />
| valign="top" | <code>-style_warning</code><br />
| Display warning messages about non-compliance with Eiffel style rules.<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress all warning messages.<br />
|-<br />
| valign="top" | <code>-fly_make_mode</code><br />
| Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.<br />
|-<br />
| valign="top" | <code>-client&nbsp;&lt;client_class&gt;</code><br />
| Specify the class whose point of view is taken. This command shows all the features visible to ''<code>client_class</code>'' out of ''<code>class</code>''.<br />
<br />
''Note1:'' the default is equivalent to <code>-client&nbsp;ANY</code>.<br />
<br />
''Note2:'' <code>se short -client&nbsp;STRING STRING</code> does not show all features from STRING, but only those that are exported to STRING itself (callable via qualified calls).<br />
|-<br />
| valign="top" | <code>-all_clients</code><br />
| Display all the features, even those not exported at all (marked <code>feature&nbsp;{}</code>)<br />
|}<br />
<br />
=== Predefined Output Formats ===<br />
<br />
You can specify an output format, which will change some typographic details but not the content itself (see [[#Options | the options above]] to change the content.<br />
<br />
See also [[#Adding_a_new_format | Adding a new format]] below to know how to add a new output format.<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-plain</code><br />
| The default compact output format. No special character added.<br />
|-<br />
| valign="top" | <code>-pretty</code><br />
| The output is similar to that of <code>-plain</code> except that there are a couple of additional line-feeds (e.g. between features) that make the structure of the output easier to read. (It is similar to the output of the "pretty" printer).<br />
|-<br />
| valign="top" | <code>-tex1</code><br />
| Simple output mode for TeX.<br />
|-<br />
| valign="top" | <code>-tex2</code><br />
| Output mode for TeX. Uses a bold font for keywords, an italic font for comments and a fixed font for identifiers.<br />
|-<br />
| valign="top" | <code>-tex3</code><br />
| Output mode for TeX. Follows style guidelines given in ETL2 appendix&nbsp;A.<br />
|-<br />
| valign="top" | <code>-html1</code><br />
| A nice HTML output (provided by Matthias Klose).<br />
|-<br />
| valign="top" | <code>-html2</code><br />
| Another nice HTML output.<br />
|-<br />
| valign="top" | <code>-html_css</code><br />
| A nice HTML+CSS output (provided by John E. Perry). The CSS file must be called seshort.css.<br />
|}<br />
<br />
== Adding a new format ==<br />
<br />
To define a new output format, you have to add a new sub-directory in the <code>SmartEiffel/short</code> directory. In order to change the output, this new directory must contain ''hook files'', which contain the text used to replace the default output.<br />
<br />
Here is the current list of hook files.<br />
<br />
=== Changing the output for the class interface header ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook000''<br />
| If this hook file exists, the contents of this file are printed first of all.<br />
|-<br />
| valign="top" | ''hook010''<br />
| If this hook file exists, and if the processed class is an expanded one, the contents of this file are printed before the class name to replace the default string <code>"expanded&nbsp;class&nbsp;interface&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook011''<br />
| If this hook file exists, and if the processed class is an deferred one, the contents of this file are printed before the class name to replace the default string <code>"deferred&nbsp;class&nbsp;interface&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook012''<br />
| If this hook file exists, and if the processed class is an ordinary one (not deferred nor expanded) the contents of this file is printed before the class name to replace the default string <code>"class&nbsp;interface&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook013''<br />
| If this hook file exists, the contents of this file are printed before the class name (whatever the kind of class -- expanded, deferred or ordinary) to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook014''<br />
| If this hook exists, the contents of the file are printed after the class name to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook015''<br />
| If this hook file exists, and if a class header comment is present, this file is printed once before the heading class comment.<br />
|-<br />
| valign="top" | ''hook016''<br />
| If this hook file exists, and if a heading comment is present, the contents of this file are printed to replace the default string <code>"&nbsp;--"</code> at the beginning of each comment line.<br />
|-<br />
| valign="top" | ''hook017''<br />
| If this hook file exists, and if a heading comment is present, the contents of this file are printed to replace the default string <code>"%N"</code> at the end of each comment line.<br />
|-<br />
| valign="top" | ''hook018''<br />
| If this hook file exists, and if a class heading comment is present, the contents of this file are printed once after the heading comment.<br />
|-<br />
| valign="top" | ''hook019''<br />
| If this hook file exists, and if the processed class has no heading comment, this file is printed once.<br />
|}<br />
<br />
=== Changing the output for the creation list ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook100''<br />
| If it exists, this file is printed before the creation list to replace the default string <code>"creation%N"</code>.<br />
|-<br />
| valign="top" | ''hook101''<br />
| If it exists, this file is printed after the creation list to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook102''<br />
| If it exists, this file is printed when the class has no creation list.<br />
|}<br />
<br />
=== Changing the output for the feature list ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook200''<br />
| If it exists, this file is printed before the feature list, when the option <code>-sort</code> is selected, to replace the default string <code>"feature(s)%N"</code>.<br />
|-<br />
| valign="top" | ''hook201''<br />
| If it exists, this file is printed after the feature list, when the option <code>-sort</code> is selected, to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook202''<br />
| If it exists, this file is printed before each feature list with no heading comment to replace the default string <code>"feature(s)&nbsp;from&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook203''<br />
| If it exists, this file is printed after the class name introduced at ''hook202'' to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook204''<br />
| If it exists, this file is printed before a feature list with a heading comment to replace the default string <code>"feature(s)&nbsp;from&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook205''<br />
| If it exists, this file is printed after the class name introduced at ''hook204'' to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook206''<br />
| If it exists, this file is printed before each line of the feature list comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook207''<br />
| If it exists, this file is printed after each line of the feature list comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook208''<br />
| If it exists, this file is printed after a feature list comment to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output for a feature signature ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook300''<br />
| If it exists, this file is printed before each feature to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook301''<br />
| If it exists, this file is printed once when the feature has no arguments to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook302''<br />
| If it exists, this file is printed once when the feature has arguments to replace the default string <code>"&nbsp;("</code>.<br />
|-<br />
| valign="top" | ''hook303''<br />
| If it exists, this file is printed when the feature has arguments to replace the default string <code>";&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook304''<br />
| If it exists, this file is printed when the feature has arguments to replace the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook305''<br />
| If it exists, this file is printed when the feature has arguments to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook306''<br />
| If it exists, this file is printed once when the feature has arguments to replace the default string <code>")"</code>.<br />
|-<br />
| valign="top" | ''hook307''<br />
| If it exists, this file is printed once when the feature has no result to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook308''<br />
| If it exists, this file is printed once before the result type of the feature to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook309''<br />
| If it exists, this file is printed once after the result type of the feature to replace the default string <code>"%N"</code>.<br />
|}<br />
<br />
=== Changing the output for a feature comment ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook310''<br />
| If it exists, and if a feature has a heading comment, this file is printed once before the comment. <br />
|-<br />
| valign="top" | ''hook311''<br />
| If it exists, and if a feature has a heading comment, this file is printed to replace the default string <code>"&nbsp;--"</code> at the beginning of each comment line.<br />
|-<br />
| valign="top" | ''hook312''<br />
| If it exists, and if a feature has a heading comment, this file is printed to replace the default string <code>"%N"</code> at the end of each comment line. <br />
|-<br />
| valign="top" | ''hook313''<br />
| If it exists, and if a feature has a heading comment, this file is printed once after this comment. <br />
|-<br />
| valign="top" | ''hook314''<br />
| If it exists, and if a feature has no heading comment, this file is printed.<br />
|-<br />
| valign="top" | ''hook315''<br />
| If it exists, and if a feature is deferred, the contents of this file is printed.<br />
|}<br />
<br />
=== Changing the output for require clauses ===<br />
<br />
==== For the header of a require clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook400''<br />
| If it exists, and if a feature has no require assertion, this file is printed to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook401''<br />
| If it exists, and if a feature has one require assertion, this file is printed before the latest inherited assertion to replace the default string <code>"&nbsp;require%N"</code>.<br />
|-<br />
| valign="top" | ''hook402''<br />
| If it exists, and if a feature has more than one require assertion, this file is printed before the require assertion to replace the default string <code>"&nbsp;require&nbsp;else%N"</code>.<br />
|-<br />
| valign="top" | ''hook403''<br />
| If it exists, and if a feature has at least one require assertion, this file is printed to finish the job (once after the last printed require assertion) to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook412''<br />
| If it exists, this file is printed when a require clause has no heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook413''<br />
| If it exists, this file is printed once before the require clause heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook414''<br />
| If it exists, this file is printed before each line of the heading comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook415''<br />
| If it exists, this file is printed after each line of the heading comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook416''<br />
| If it exists, this file is printed once after the require clause heading comment.<br />
|-<br />
| valign="top" | ''hook417''<br />
| If it exists, this file is printed when a require clause has no assertion to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook418''<br />
| If it exists, this file is printed once before the first assertion of a require clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook433''<br />
| If it exists, this file is printed once after the last assertion of a require clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook434''<br />
| If it exists, this file is printed at the very end of a require clause to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For each assertion in a require clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook419''<br />
| If it exists, this file is printed before each assertion of a require clause to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook420''<br />
| If it exists, this file is printed when an assertion has no tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook421''<br />
| If it exists, this file is printed before a tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook422''<br />
| If it exists, this file is printed after a tag to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook423''<br />
| If it exists, this file is printed when the assertion has no expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook424''<br />
| If it exists, this file is printed before the expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook425''<br />
| If it exists, this file is printed after the expression (except for the last assertion) to replace the default string <code>";"</code>.<br />
|-<br />
| valign="top" | ''hook426''<br />
| If it exists, this file is printed when an assertion has no comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook427''<br />
| If it exists, this file is printed once before the assertion comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook428''<br />
| If it exists, this file is printed before each line of the expression comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook429''<br />
| If it exists, this file is printed after each line of the expression comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook430''<br />
| If it exists, this file is printed once after the assertion's comment to replace the default string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook431''<br />
| If it exists, this file is printed after the assertion to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For the last assertion in a require clause ====<br />
<br />
The same hook files list is used as is described in the previous section, except for ''hook425'' which is replaced by:<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook432''<br />
| If it exists, this file is printed after the last expression to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output for ensure clauses ===<br />
<br />
==== For the header of an ensure clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook500''<br />
| If it exists, and if a feature has no ensure assertion, this file is printed to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook501''<br />
| If it exists, and if a feature has one ensure assertion, this file is printed before the latest inherited assertion to replace the default string <code>"&nbsp;ensure%N"</code>.<br />
|-<br />
| valign="top" | ''hook502''<br />
| If it exists, and if a feature has more than one ensure assertion, this file is printed before the ensure assertion to replace the default string <code>"&nbsp;ensure&nbsp;else%N"</code>.<br />
|-<br />
| valign="top" | ''hook503''<br />
| If it exists, and if a feature has at least one ensure assertion, this file is printed to finish the job (once after the last printed ensure assertion) to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook512''<br />
| If it exists, this file is printed when an ensure clause has no heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook513''<br />
| If it exists, this file is printed once before the ensure clause heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook514''<br />
| If it exists, this file is printed before each line of the heading comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook515''<br />
| If it exists, this file is printed after each line of the heading comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook516''<br />
| If it exists, this file is printed once after the ensure clause heading comment.<br />
|-<br />
| valign="top" | ''hook517''<br />
| If it exists, this file is printed when an ensure clause has no assertion to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook518''<br />
| If it exists, this file is printed once before the first assertion of an ensure clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook533''<br />
| If it exists, this file is printed once after the last assertion of an ensure clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook534''<br />
| If it exists, this file is printed to finish an ensure clause to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For each assertion in an ensure clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook519''<br />
| If it exists, this file is printed before each assertion of an ensure clause to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook520''<br />
| If it exists, this file is printed when an assertion has no tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook521''<br />
| If it exists, this file is printed before a tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook522''<br />
| If it exists, this file is printed after a tag to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook523''<br />
| If it exists, this file is printed when the assertion has no expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook524''<br />
| If it exists, this file is printed before the expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook525''<br />
| If it exists, this file is printed after the expression (except for the last assertion) to replace the default string <code>";"</code>.<br />
|-<br />
| valign="top" | ''hook526''<br />
| If it exists, this file is printed when an assertion has no comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook527''<br />
| If it exists, this file is printed once before the assertion comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook528''<br />
| If it exists, this file is printed before each line of the expression comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook529''<br />
| If it exists, this file is printed after each line of the expression comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook530''<br />
| If it exists, this file is printed once after the assertion's comment to replace the default string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook531''<br />
| If it exists, this file is printed after the assertion to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For the last assertion in an ensure clause ====<br />
<br />
The same hook files list is used as is described in the previous section, except for ''hook525'' which is replaced by:<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook532''<br />
| If it exists, this file is printed after the last expression to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output after each feature ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook599''<br />
| If it exists, this file is printed after each feature to replace the default empty string <code>""</code>.<br />
|}<br />
=== Changing the output for the class invariant ===<br />
<br />
==== For the header of a ensure clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook800''<br />
| If it exists, and when no class invariant exists, this file is printed to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook811''<br />
| If it exists, this file is printed before the class invariant to replace the default string <code>"invariant%N"</code>.<br />
|-<br />
| valign="top" | ''hook812''<br />
| If it exists, this file is printed before the class invariant to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook813''<br />
| If it exists, this file is printed once before the class invariant heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook814''<br />
| If it exists, this file is printed before each line of the heading comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook815''<br />
| If it exists, this file is printed after each line of the heading comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook816''<br />
| If it exists, this file is printed once after the class invariant heading comment.<br />
|-<br />
| valign="top" | ''hook817''<br />
| If it exists, this file is printed when the class invariant has no assertion to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook818''<br />
| If it exists, this file is printed once before the first assertion of the class invariant to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook833''<br />
| If it exists, this file is printed once after the last assertion of the class invariant to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook834''<br />
| If it exists, this file is printed to finish the class invariant to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For each assertion in a class invariant ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook819''<br />
| If it exists, this file is printed before each assertion of the class invariant to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook820''<br />
| If it exists, this file is printed when an assertion has no tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook821''<br />
| If it exists, this file is printed before a tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook822''<br />
| If it exists, this file is printed after a tag to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook823''<br />
| If it exists, this file is printed when the assertion has no expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook824''<br />
| If it exists, this file is printed before the expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook825''<br />
| If it exists, this file is printed after the expression (except for the last assertion) to replace the default string <code>";"</code>.<br />
|-<br />
| valign="top" | ''hook826''<br />
| If it exists, this file is printed when an assertion has no comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook827''<br />
| If it exists, this file is printed once before the assertion comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook828''<br />
| If it exists, this file is printed before each line of the expression comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook829''<br />
| If it exists, this file is printed after each line of the expression comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook830''<br />
| If it exists, this file is printed once after the assertion's comment to replace the default string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook831''<br />
| If it exists, this file is printed after the assertion to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For the last assertion in the class invariant ====<br />
<br />
The same hook files list is used as is described in the previous section, except for ''hook825'' which is replaced by:<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook832''<br />
| If it exists, this file is printed after the last expression to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output for the class interface footer ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook900''<br />
| If it exists, this file is printed once before class footer to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook901''<br />
| If it exists, this file is printed once at the end of an expanded class before the class name to replace the default <code>"end&nbsp;of&nbsp;expanded&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook902''<br />
| If it exists, this file is printed once at the end of a deferred class before the class name to replace the default <code>"end&nbsp;of&nbsp;deferred&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook903''<br />
| If it exists, this file is printed once at the end of an ordinary (not expanded nor deferred) class, before the class name to replace the default string <code>"end&nbsp;of&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook904''<br />
| If it exists, this file is printed just before the class name to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook905''<br />
| If it exists, this file is printed after the class name to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook999''<br />
| If it exists, this file is printed once to finish the job.<br />
|}<br />
<br />
=== Class name and formal generic arguments ===<br />
<br />
==== Changing the output for class names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bcn''<br />
| If it exists, this file is printed before each class name.<br />
|-<br />
| valign="top" | ''Mcn''<br />
| If this file exists, the class name is printed once more (using lower case letters) followed by the contents of this file.<br />
|-<br />
| valign="top" | ''Acn''<br />
| If it exists, this file is printed after each class name.<br />
|-<br />
| valign="top" | ''Ucn''<br />
| If it exists, this file is printed to replace the underscore character in a class name.<br />
|}<br />
<br />
==== Changing the output for formal generic arguments ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bfga''<br />
| If it exists, this file is printed before each formal generic argument.<br />
|-<br />
| valign="top" | ''Mfga''<br />
| If this file exists, the formal generic argument is printed once more (using lower case letters) followed by the contents of this file.<br />
|-<br />
| valign="top" | ''Afga''<br />
| If it exists, this file is printed after each formal generic argument.<br />
|-<br />
| valign="top" | ''Ufga''<br />
| If it exists, this file is printed to replace the underscore character in a formal generic argument.<br />
|}<br />
<br />
=== Changing the output for a type mark ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Btm''<br />
| If it exists, this file is printed before each type mark.<br />
|-<br />
| valign="top" | ''Atm''<br />
| If it exists, this file is printed after each type mark.<br />
|-<br />
| valign="top" | ''open_sb''<br />
| If it exists, this file is printed instead of an opening bracket (<code>"["</code>).<br />
|-<br />
| valign="top" | ''close_sb''<br />
| If it exists, this file is printed instead of a closing bracket (<code>"]"</code>).<br />
|-<br />
| valign="top" | ''fgl_sep''<br />
| If it exists, this file is printed instead of the separating coma in a formal generic argument list (<code>",&nbsp;"</code>).<br />
|-<br />
| valign="top" | ''tm_blank''<br />
| If it exists, this file is printed instead of a white space in a type mark (<code>"&nbsp;"</code>).<br />
|-<br />
| valign="top" | ''tm_sep''<br />
| If it exists, this file is printed instead of the separating coma in a generic list (<code>",&nbsp;"</code>).<br />
|-<br />
| valign="top" | ''like''<br />
| If it exists, this file is printed instead of the default string <code>"like&nbsp;"</code><br />
|-<br />
| valign="top" | ''expanded''<br />
| If it exists, this file is printed instead of the default string <code>"expanded&nbsp;"</code> <br />
|}<br />
<br />
=== Changing the output for feature names ===<br />
<br />
==== Simple feature names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bsfn''<br />
| If it exists, this file is printed before each Simple Feature Name.<br />
|-<br />
| valign="top" | ''Asfn''<br />
| If it exists, this file is printed after each Simple Feature Name.<br />
|-<br />
| valign="top" | ''Usfn''<br />
| If it exists, this file is printed to replace the underscore character in a Simple Feature Name.<br />
|}<br />
<br />
==== Infix feature names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bifn''<br />
| If it exists, this file is printed before each infix feature definition name instead of the default string <code>"infix&nbsp;%""</code>.<br />
|-<br />
| valign="top" | ''Aifn''<br />
| If it exists, this file is printed after each infix feature definition name instead of the default string <code>"%""</code>.<br />
|-<br />
| valign="top" | ''Binfix''<br />
| If it exists, this file is printed before the infix name used in an expression instead of the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''Ainfix''<br />
| If it exists, this file is printed after the infix name used in an expression instead of the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''rem''<br />
| If it exists, this file is printed to replace the default string <code>"\\"</code>.<br />
|}<br />
<br />
==== Prefix feature names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bpfn''<br />
| If it exists, this file is printed before each prefix feature definition name instead of the default string <code>"infix&nbsp;%""</code>.<br />
|-<br />
| valign="top" | ''Apfn''<br />
| If it exists, this file is printed after each prefix feature definition name instead of the default string <code>"%""</code>.<br />
|}<br />
<br />
=== Changing the output for an argument name ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Ban''<br />
| If it exists, this file is printed before each Argument Name.<br />
|-<br />
| valign="top" | ''Aan''<br />
| If it exists, this file is printed after each Argument Name.<br />
|-<br />
| valign="top" | ''Uan''<br />
| If it exists, this file is printed to replace the underscore character in an Argument Name.<br />
|}<br />
<br />
=== Changing the output for a tag name ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Btag''<br />
| If it exists, this file is printed before each Tag Name.<br />
|-<br />
| valign="top" | ''Atag''<br />
| If it exists, this file is printed after each Tag Name.<br />
|-<br />
| valign="top" | ''Utag''<br />
| If it exists, this file is printed to replace the underscore character in an Tag Name.<br />
|}<br />
<br />
=== Changing the output for an effective argument list ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''op_eal''<br />
| If it exists, this file is printed to open an effective argument list instead of the default string <code>"("</code>.<br />
|-<br />
| valign="top" | ''eal_sep''<br />
| If it exists, this file is printed in an effective argument list instead of the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''cl_eal''<br />
| If it exists, this file is printed to close an effective argument list instead of the default string <code>")"</code>.<br />
|}<br />
<br />
=== Changing the output for manifest strings ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''open_ms''<br />
| If it exists, this file is printed to open a manifest string instead of the default string <code>"%""</code>.<br />
|-<br />
| valign="top" | ''close_ms''<br />
| If it exists, this file is printed to close a manifest string instead of the default string <code>"%""</code>.<br />
|-<br />
| valign="top" | ''Prcnt_ms''<br />
| If it exists, this file is printed in a manifest string instead of the default string <code>"%%"</code>.<br />
|-<br />
| valign="top" | ''Slash_ms''<br />
| If it exists, this file is printed to close a manifest string instead of the default string <code>"/"</code>.<br />
|}<br />
<br />
=== Changing the output for a manifest array ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''op_ma''<br />
| If it exists, this file is printed to open a manifest array instead of the default string <code>"&lt;&lt;"</code>.<br />
|-<br />
| valign="top" | ''ma_sep''<br />
| If it exists, this file is printed in a manifest array instead of the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''cl_ma''<br />
| If it exists, this file is printed to close a manifest array instead of the default string <code>"&gt;&gt;"</code>.<br />
|}<br />
<br />
=== Changing the output for comments lines ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''BECL''<br />
| Before Each Comment Line. This hook is applied to all comments whatever the kind of comment. If it exists, this file is printed at the beginning of each comment line instead of the default string <code>"--"</code>.<br />
|-<br />
| valign="top" | ''AECL''<br />
| After Each Comment Line. This hook is applied to all comments whatever the kind of comment. If it exists, this file is printed at the end of each comment line instead of the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''Ucomment''<br />
| If it exists, this file is printed to replace the underscore character in an comment line.<br />
|-<br />
| valign="top" | ''op_quote''<br />
| If it exists, this file is printed instead of the default string <code>"`"</code>.<br />
|-<br />
| valign="top" | ''cl_quote''<br />
| If it exists, this file is printed instead of the default string <code>"'"</code>.<br />
|}<br />
<br />
=== Miscellaneous tuning ===<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''open_b''<br />
| If it exists, this file is printed instead of the default opening parenthesis in expressions, replacing the default string <code>"("</code>.<br />
|-<br />
| valign="top" | ''close_b''<br />
| If it exists, this file is printed instead of the default closing parenthesis in expressions, replacing the default string <code>")"</code>.<br />
|-<br />
| valign="top" | ''dot''<br />
| If it exists, this file is printed instead of the dot in expressions, replacing the default string <code>"."</code>.<br />
|-<br />
| valign="top" | ''Current''<br />
| If it exists, this file is printed instead of the ''Current'' entity in expressions, replacing the default string <code>"Current"</code>.<br />
|-<br />
| valign="top" | ''Result''<br />
| If it exists, this file is printed instead of the ''Result'' entity in expressions, replacing the default string <code>"Result"</code>.<br />
|-<br />
| valign="top" | ''Void''<br />
| If it exists, this file is printed instead of the ''Void'' entity in expressions, replacing the default string <code>"Void"</code>.<br />
|-<br />
| valign="top" | ''once''<br />
| If it exists, this file is printed instead of the '''once''' keyword in expressions, replacing the default string <code>"once"</code>.<br />
|-<br />
| valign="top" | ''old''<br />
| If it exists, this file is printed instead of the '''old''' keyword in postcondition expressions, replacing the default string <code>"old"</code>.<br />
|-<br />
| valign="top" | ''create_open''<br />
| If it exists, this file is printed to replace the default string <code>"create&nbsp;{"</code>.<br />
|-<br />
| valign="top" | ''create_close''<br />
| If it exists, this file is printed to replace the default string <code>"}"</code> opened by ''create_open''.<br />
|-<br />
| valign="top" | ''fnl_sep''<br />
| If it exists, this file is printed in a feature name list instead of the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''arrow''<br />
| If it exists, this file is printed instead of the arrow in a formal generic list, replacing the default string <code>"-&gt;"</code>.<br />
|-<br />
| valign="top" | ''new_line''<br />
| If it exists, this file replaces the default string <code>"%N"</code>.<br />
|}</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Short&diff=2404Short2016-06-14T17:05:57Z<p>Dkearns: Document -flymake_mode</p>
<hr />
<div>[[Category:Tool]]<br />
<br />
The <tt>short</tt> command is the LibertyEiffel interface generator. Using a plain Eiffel source file, the command prints the interface of this class to the standard output. It is also a good tool to perform many validity checks of a given class (syntax, exportation rules, inheritance, etc.).<br />
<br />
In a normal installation, the tool is invoked by the command <b><TT>[[se]]&nbsp;short</TT></b>.<br />
<br />
There are two ways of invoking it: the ''traditional'' mode and the ''ACE'' mode.<br />
* In the traditional mode, many options can be specified on the command line.<br />
* In the [[ACE]] mode ''(Assembly of Classes in Eiffel)'', most of its options are not allowed on the command line; they have their equivalents ''in'' the ACE file.<br />
<br />
<br />
== Synopsis ==<br />
<br />
* <code>se short [options] &lt;class&gt;</code><br />
* <code>se short [options] &lt;ace_file.ace&gt; &lt;class&gt;</code><br />
<br />
The first syntax is the traditional mode, the second is the ACE mode.<br />
<br />
In the ACE mode, the name of the [[ACE]] file provided must end with the suffix <TT>.ace</TT>.<br />
<br />
=== Options ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-help</code><br />
| Display a short summary of the command line syntax, as well as a complete list of the compiler's options.<br />
|-<br />
| valign="top" | <code>-verbose</code><br />
| Display (an enormous amount of) information during the compilation: a complete list of files loaded, the [[type inference]] scores, the generated files, and so on.<br />
|-<br />
| valign="top" | <code>-version</code><br />
| Display the LibertyEiffel version number.<br />
|-<br />
| valign="top" | <code>-loadpath&nbsp;&lt;loadpath-file&gt;</code><br />
| Add a loadpath file for class lookup. See details in the [[finder]] page.<br />
|-<br />
| valign="top" | <code>-sort</code><br />
| Sort features alphabetically.<br />
|-<br />
| valign="top" | <code>-short</code><br />
| Show only locally defined features (do not consider purely inherited features).<br />
|-<br />
| valign="top" | <code>-style_warning</code><br />
| Display warning messages about non-compliance with Eiffel style rules.<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress all warning messages.<br />
|-<br />
| valign="top" | <code>-fly_make_mode</code><br />
| Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.<br />
|-<br />
| valign="top" | <code>-client&nbsp;&lt;client_class&gt;</code><br />
| Specify the class whose point of view is taken. This command shows all the features visible to ''<code>client_class</code>'' out of ''<code>class</code>''.<br />
<br />
''Note1:'' the default is equivalent to <code>-client&nbsp;ANY</code>.<br />
<br />
''Note2:'' <code>se short -client&nbsp;STRING STRING</code> does not show all features from STRING, but only those that are exported to STRING itself (callable via qualified calls).<br />
|-<br />
| valign="top" | <code>-all_clients</code><br />
| Display all the features, even those not exported at all (marked <code>feature&nbsp;{}</code>)<br />
|}<br />
<br />
=== Predefined Output Formats ===<br />
<br />
You can specify an output format, which will change some typographic details but not the content itself (see [[#Options | the options above]] to change the content.<br />
<br />
See also [[#Adding_a_new_format | Adding a new format]] below to know how to add a new output format.<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-plain</code><br />
| The default compact output format. No special character added.<br />
|-<br />
| valign="top" | <code>-pretty</code><br />
| The output is similar to that of <code>-plain</code> except that there are a couple of additional line-feeds (e.g. between features) that make the structure of the output easier to read. (It is similar to the output of the "pretty" printer).<br />
|-<br />
| valign="top" | <code>-tex1</code><br />
| Simple output mode for TeX.<br />
|-<br />
| valign="top" | <code>-tex2</code><br />
| Output mode for TeX. Uses a bold font for keywords, an italic font for comments and a fixed font for identifiers.<br />
|-<br />
| valign="top" | <code>-tex3</code><br />
| Output mode for TeX. Follows style guidelines given in ETL2 appendix&nbsp;A.<br />
|-<br />
| valign="top" | <code>-html1</code><br />
| A nice HTML output (provided by Matthias Klose).<br />
|-<br />
| valign="top" | <code>-html2</code><br />
| Another nice HTML output.<br />
|-<br />
| valign="top" | <code>-html_css</code><br />
| A nice HTML+CSS output (provided by John E. Perry). The CSS file must be called seshort.css.<br />
|}<br />
<br />
== Adding a new format ==<br />
<br />
To define a new output format, you have to add a new sub-directory in the <code>SmartEiffel/short</code> directory. In order to change the output, this new directory must contain ''hook files'', which contain the text used to replace the default output.<br />
<br />
Here is the current list of hook files.<br />
<br />
=== Changing the output for the class interface header ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook000''<br />
| If this hook file exists, the contents of this file are printed first of all.<br />
|-<br />
| valign="top" | ''hook010''<br />
| If this hook file exists, and if the processed class is an expanded one, the contents of this file are printed before the class name to replace the default string <code>"expanded&nbsp;class&nbsp;interface&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook011''<br />
| If this hook file exists, and if the processed class is an deferred one, the contents of this file are printed before the class name to replace the default string <code>"deferred&nbsp;class&nbsp;interface&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook012''<br />
| If this hook file exists, and if the processed class is an ordinary one (not deferred nor expanded) the contents of this file is printed before the class name to replace the default string <code>"class&nbsp;interface&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook013''<br />
| If this hook file exists, the contents of this file are printed before the class name (whatever the kind of class -- expanded, deferred or ordinary) to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook014''<br />
| If this hook exists, the contents of the file are printed after the class name to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook015''<br />
| If this hook file exists, and if a class header comment is present, this file is printed once before the heading class comment.<br />
|-<br />
| valign="top" | ''hook016''<br />
| If this hook file exists, and if a heading comment is present, the contents of this file are printed to replace the default string <code>"&nbsp;--"</code> at the beginning of each comment line.<br />
|-<br />
| valign="top" | ''hook017''<br />
| If this hook file exists, and if a heading comment is present, the contents of this file are printed to replace the default string <code>"%N"</code> at the end of each comment line.<br />
|-<br />
| valign="top" | ''hook018''<br />
| If this hook file exists, and if a class heading comment is present, the contents of this file are printed once after the heading comment.<br />
|-<br />
| valign="top" | ''hook019''<br />
| If this hook file exists, and if the processed class has no heading comment, this file is printed once.<br />
|}<br />
<br />
=== Changing the output for the creation list ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook100''<br />
| If it exists, this file is printed before the creation list to replace the default string <code>"creation%N"</code>.<br />
|-<br />
| valign="top" | ''hook101''<br />
| If it exists, this file is printed after the creation list to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook102''<br />
| If it exists, this file is printed when the class has no creation list.<br />
|}<br />
<br />
=== Changing the output for the feature list ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook200''<br />
| If it exists, this file is printed before the feature list, when the option <code>-sort</code> is selected, to replace the default string <code>"feature(s)%N"</code>.<br />
|-<br />
| valign="top" | ''hook201''<br />
| If it exists, this file is printed after the feature list, when the option <code>-sort</code> is selected, to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook202''<br />
| If it exists, this file is printed before each feature list with no heading comment to replace the default string <code>"feature(s)&nbsp;from&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook203''<br />
| If it exists, this file is printed after the class name introduced at ''hook202'' to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook204''<br />
| If it exists, this file is printed before a feature list with a heading comment to replace the default string <code>"feature(s)&nbsp;from&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook205''<br />
| If it exists, this file is printed after the class name introduced at ''hook204'' to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook206''<br />
| If it exists, this file is printed before each line of the feature list comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook207''<br />
| If it exists, this file is printed after each line of the feature list comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook208''<br />
| If it exists, this file is printed after a feature list comment to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output for a feature signature ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook300''<br />
| If it exists, this file is printed before each feature to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook301''<br />
| If it exists, this file is printed once when the feature has no arguments to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook302''<br />
| If it exists, this file is printed once when the feature has arguments to replace the default string <code>"&nbsp;("</code>.<br />
|-<br />
| valign="top" | ''hook303''<br />
| If it exists, this file is printed when the feature has arguments to replace the default string <code>";&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook304''<br />
| If it exists, this file is printed when the feature has arguments to replace the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook305''<br />
| If it exists, this file is printed when the feature has arguments to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook306''<br />
| If it exists, this file is printed once when the feature has arguments to replace the default string <code>")"</code>.<br />
|-<br />
| valign="top" | ''hook307''<br />
| If it exists, this file is printed once when the feature has no result to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook308''<br />
| If it exists, this file is printed once before the result type of the feature to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook309''<br />
| If it exists, this file is printed once after the result type of the feature to replace the default string <code>"%N"</code>.<br />
|}<br />
<br />
=== Changing the output for a feature comment ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook310''<br />
| If it exists, and if a feature has a heading comment, this file is printed once before the comment. <br />
|-<br />
| valign="top" | ''hook311''<br />
| If it exists, and if a feature has a heading comment, this file is printed to replace the default string <code>"&nbsp;--"</code> at the beginning of each comment line.<br />
|-<br />
| valign="top" | ''hook312''<br />
| If it exists, and if a feature has a heading comment, this file is printed to replace the default string <code>"%N"</code> at the end of each comment line. <br />
|-<br />
| valign="top" | ''hook313''<br />
| If it exists, and if a feature has a heading comment, this file is printed once after this comment. <br />
|-<br />
| valign="top" | ''hook314''<br />
| If it exists, and if a feature has no heading comment, this file is printed.<br />
|-<br />
| valign="top" | ''hook315''<br />
| If it exists, and if a feature is deferred, the contents of this file is printed.<br />
|}<br />
<br />
=== Changing the output for require clauses ===<br />
<br />
==== For the header of a require clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook400''<br />
| If it exists, and if a feature has no require assertion, this file is printed to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook401''<br />
| If it exists, and if a feature has one require assertion, this file is printed before the latest inherited assertion to replace the default string <code>"&nbsp;require%N"</code>.<br />
|-<br />
| valign="top" | ''hook402''<br />
| If it exists, and if a feature has more than one require assertion, this file is printed before the require assertion to replace the default string <code>"&nbsp;require&nbsp;else%N"</code>.<br />
|-<br />
| valign="top" | ''hook403''<br />
| If it exists, and if a feature has at least one require assertion, this file is printed to finish the job (once after the last printed require assertion) to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook412''<br />
| If it exists, this file is printed when a require clause has no heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook413''<br />
| If it exists, this file is printed once before the require clause heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook414''<br />
| If it exists, this file is printed before each line of the heading comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook415''<br />
| If it exists, this file is printed after each line of the heading comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook416''<br />
| If it exists, this file is printed once after the require clause heading comment.<br />
|-<br />
| valign="top" | ''hook417''<br />
| If it exists, this file is printed when a require clause has no assertion to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook418''<br />
| If it exists, this file is printed once before the first assertion of a require clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook433''<br />
| If it exists, this file is printed once after the last assertion of a require clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook434''<br />
| If it exists, this file is printed at the very end of a require clause to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For each assertion in a require clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook419''<br />
| If it exists, this file is printed before each assertion of a require clause to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook420''<br />
| If it exists, this file is printed when an assertion has no tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook421''<br />
| If it exists, this file is printed before a tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook422''<br />
| If it exists, this file is printed after a tag to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook423''<br />
| If it exists, this file is printed when the assertion has no expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook424''<br />
| If it exists, this file is printed before the expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook425''<br />
| If it exists, this file is printed after the expression (except for the last assertion) to replace the default string <code>";"</code>.<br />
|-<br />
| valign="top" | ''hook426''<br />
| If it exists, this file is printed when an assertion has no comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook427''<br />
| If it exists, this file is printed once before the assertion comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook428''<br />
| If it exists, this file is printed before each line of the expression comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook429''<br />
| If it exists, this file is printed after each line of the expression comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook430''<br />
| If it exists, this file is printed once after the assertion's comment to replace the default string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook431''<br />
| If it exists, this file is printed after the assertion to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For the last assertion in a require clause ====<br />
<br />
The same hook files list is used as is described in the previous section, except for ''hook425'' which is replaced by:<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook432''<br />
| If it exists, this file is printed after the last expression to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output for ensure clauses ===<br />
<br />
==== For the header of an ensure clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook500''<br />
| If it exists, and if a feature has no ensure assertion, this file is printed to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook501''<br />
| If it exists, and if a feature has one ensure assertion, this file is printed before the latest inherited assertion to replace the default string <code>"&nbsp;ensure%N"</code>.<br />
|-<br />
| valign="top" | ''hook502''<br />
| If it exists, and if a feature has more than one ensure assertion, this file is printed before the ensure assertion to replace the default string <code>"&nbsp;ensure&nbsp;else%N"</code>.<br />
|-<br />
| valign="top" | ''hook503''<br />
| If it exists, and if a feature has at least one ensure assertion, this file is printed to finish the job (once after the last printed ensure assertion) to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook512''<br />
| If it exists, this file is printed when an ensure clause has no heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook513''<br />
| If it exists, this file is printed once before the ensure clause heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook514''<br />
| If it exists, this file is printed before each line of the heading comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook515''<br />
| If it exists, this file is printed after each line of the heading comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook516''<br />
| If it exists, this file is printed once after the ensure clause heading comment.<br />
|-<br />
| valign="top" | ''hook517''<br />
| If it exists, this file is printed when an ensure clause has no assertion to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook518''<br />
| If it exists, this file is printed once before the first assertion of an ensure clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook533''<br />
| If it exists, this file is printed once after the last assertion of an ensure clause to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook534''<br />
| If it exists, this file is printed to finish an ensure clause to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For each assertion in an ensure clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook519''<br />
| If it exists, this file is printed before each assertion of an ensure clause to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook520''<br />
| If it exists, this file is printed when an assertion has no tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook521''<br />
| If it exists, this file is printed before a tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook522''<br />
| If it exists, this file is printed after a tag to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook523''<br />
| If it exists, this file is printed when the assertion has no expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook524''<br />
| If it exists, this file is printed before the expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook525''<br />
| If it exists, this file is printed after the expression (except for the last assertion) to replace the default string <code>";"</code>.<br />
|-<br />
| valign="top" | ''hook526''<br />
| If it exists, this file is printed when an assertion has no comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook527''<br />
| If it exists, this file is printed once before the assertion comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook528''<br />
| If it exists, this file is printed before each line of the expression comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook529''<br />
| If it exists, this file is printed after each line of the expression comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook530''<br />
| If it exists, this file is printed once after the assertion's comment to replace the default string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook531''<br />
| If it exists, this file is printed after the assertion to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For the last assertion in an ensure clause ====<br />
<br />
The same hook files list is used as is described in the previous section, except for ''hook525'' which is replaced by:<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook532''<br />
| If it exists, this file is printed after the last expression to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output after each feature ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook599''<br />
| If it exists, this file is printed after each feature to replace the default empty string <code>""</code>.<br />
|}<br />
=== Changing the output for the class invariant ===<br />
<br />
==== For the header of a ensure clause ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook800''<br />
| If it exists, and when no class invariant exists, this file is printed to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook811''<br />
| If it exists, this file is printed before the class invariant to replace the default string <code>"invariant%N"</code>.<br />
|-<br />
| valign="top" | ''hook812''<br />
| If it exists, this file is printed before the class invariant to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook813''<br />
| If it exists, this file is printed once before the class invariant heading comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook814''<br />
| If it exists, this file is printed before each line of the heading comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook815''<br />
| If it exists, this file is printed after each line of the heading comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook816''<br />
| If it exists, this file is printed once after the class invariant heading comment.<br />
|-<br />
| valign="top" | ''hook817''<br />
| If it exists, this file is printed when the class invariant has no assertion to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook818''<br />
| If it exists, this file is printed once before the first assertion of the class invariant to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook833''<br />
| If it exists, this file is printed once after the last assertion of the class invariant to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook834''<br />
| If it exists, this file is printed to finish the class invariant to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For each assertion in a class invariant ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook819''<br />
| If it exists, this file is printed before each assertion of the class invariant to replace the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook820''<br />
| If it exists, this file is printed when an assertion has no tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook821''<br />
| If it exists, this file is printed before a tag to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook822''<br />
| If it exists, this file is printed after a tag to replace the default string <code>":&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook823''<br />
| If it exists, this file is printed when the assertion has no expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook824''<br />
| If it exists, this file is printed before the expression to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook825''<br />
| If it exists, this file is printed after the expression (except for the last assertion) to replace the default string <code>";"</code>.<br />
|-<br />
| valign="top" | ''hook826''<br />
| If it exists, this file is printed when an assertion has no comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook827''<br />
| If it exists, this file is printed once before the assertion comment to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook828''<br />
| If it exists, this file is printed before each line of the expression comment to replace the default string <code>"&nbsp;--"</code>.<br />
|-<br />
| valign="top" | ''hook829''<br />
| If it exists, this file is printed after each line of the expression comment to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook830''<br />
| If it exists, this file is printed once after the assertion's comment to replace the default string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook831''<br />
| If it exists, this file is printed after the assertion to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
==== For the last assertion in the class invariant ====<br />
<br />
The same hook files list is used as is described in the previous section, except for ''hook825'' which is replaced by:<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook832''<br />
| If it exists, this file is printed after the last expression to replace the default empty string <code>""</code>.<br />
|}<br />
<br />
=== Changing the output for the class interface footer ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''hook900''<br />
| If it exists, this file is printed once before class footer to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook901''<br />
| If it exists, this file is printed once at the end of an expanded class before the class name to replace the default <code>"end&nbsp;of&nbsp;expanded&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook902''<br />
| If it exists, this file is printed once at the end of a deferred class before the class name to replace the default <code>"end&nbsp;of&nbsp;deferred&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook903''<br />
| If it exists, this file is printed once at the end of an ordinary (not expanded nor deferred) class, before the class name to replace the default string <code>"end&nbsp;of&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''hook904''<br />
| If it exists, this file is printed just before the class name to replace the default empty string <code>""</code>.<br />
|-<br />
| valign="top" | ''hook905''<br />
| If it exists, this file is printed after the class name to replace the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''hook999''<br />
| If it exists, this file is printed once to finish the job.<br />
|}<br />
<br />
=== Class name and formal generic arguments ===<br />
<br />
==== Changing the output for class names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bcn''<br />
| If it exists, this file is printed before each class name.<br />
|-<br />
| valign="top" | ''Mcn''<br />
| If this file exists, the class name is printed once more (using lower case letters) followed by the contents of this file.<br />
|-<br />
| valign="top" | ''Acn''<br />
| If it exists, this file is printed after each class name.<br />
|-<br />
| valign="top" | ''Ucn''<br />
| If it exists, this file is printed to replace the underscore character in a class name.<br />
|}<br />
<br />
==== Changing the output for formal generic arguments ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bfga''<br />
| If it exists, this file is printed before each formal generic argument.<br />
|-<br />
| valign="top" | ''Mfga''<br />
| If this file exists, the formal generic argument is printed once more (using lower case letters) followed by the contents of this file.<br />
|-<br />
| valign="top" | ''Afga''<br />
| If it exists, this file is printed after each formal generic argument.<br />
|-<br />
| valign="top" | ''Ufga''<br />
| If it exists, this file is printed to replace the underscore character in a formal generic argument.<br />
|}<br />
<br />
=== Changing the output for a type mark ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Btm''<br />
| If it exists, this file is printed before each type mark.<br />
|-<br />
| valign="top" | ''Atm''<br />
| If it exists, this file is printed after each type mark.<br />
|-<br />
| valign="top" | ''open_sb''<br />
| If it exists, this file is printed instead of an opening bracket (<code>"["</code>).<br />
|-<br />
| valign="top" | ''close_sb''<br />
| If it exists, this file is printed instead of a closing bracket (<code>"]"</code>).<br />
|-<br />
| valign="top" | ''fgl_sep''<br />
| If it exists, this file is printed instead of the separating coma in a formal generic argument list (<code>",&nbsp;"</code>).<br />
|-<br />
| valign="top" | ''tm_blank''<br />
| If it exists, this file is printed instead of a white space in a type mark (<code>"&nbsp;"</code>).<br />
|-<br />
| valign="top" | ''tm_sep''<br />
| If it exists, this file is printed instead of the separating coma in a generic list (<code>",&nbsp;"</code>).<br />
|-<br />
| valign="top" | ''like''<br />
| If it exists, this file is printed instead of the default string <code>"like&nbsp;"</code><br />
|-<br />
| valign="top" | ''expanded''<br />
| If it exists, this file is printed instead of the default string <code>"expanded&nbsp;"</code> <br />
|}<br />
<br />
=== Changing the output for feature names ===<br />
<br />
==== Simple feature names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bsfn''<br />
| If it exists, this file is printed before each Simple Feature Name.<br />
|-<br />
| valign="top" | ''Asfn''<br />
| If it exists, this file is printed after each Simple Feature Name.<br />
|-<br />
| valign="top" | ''Usfn''<br />
| If it exists, this file is printed to replace the underscore character in a Simple Feature Name.<br />
|}<br />
<br />
==== Infix feature names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bifn''<br />
| If it exists, this file is printed before each infix feature definition name instead of the default string <code>"infix&nbsp;%""</code>.<br />
|-<br />
| valign="top" | ''Aifn''<br />
| If it exists, this file is printed after each infix feature definition name instead of the default string <code>"%""</code>.<br />
|-<br />
| valign="top" | ''Binfix''<br />
| If it exists, this file is printed before the infix name used in an expression instead of the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''Ainfix''<br />
| If it exists, this file is printed after the infix name used in an expression instead of the default string <code>"&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''rem''<br />
| If it exists, this file is printed to replace the default string <code>"\\"</code>.<br />
|}<br />
<br />
==== Prefix feature names ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Bpfn''<br />
| If it exists, this file is printed before each prefix feature definition name instead of the default string <code>"infix&nbsp;%""</code>.<br />
|-<br />
| valign="top" | ''Apfn''<br />
| If it exists, this file is printed after each prefix feature definition name instead of the default string <code>"%""</code>.<br />
|}<br />
<br />
=== Changing the output for an argument name ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Ban''<br />
| If it exists, this file is printed before each Argument Name.<br />
|-<br />
| valign="top" | ''Aan''<br />
| If it exists, this file is printed after each Argument Name.<br />
|-<br />
| valign="top" | ''Uan''<br />
| If it exists, this file is printed to replace the underscore character in an Argument Name.<br />
|}<br />
<br />
=== Changing the output for a tag name ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''Btag''<br />
| If it exists, this file is printed before each Tag Name.<br />
|-<br />
| valign="top" | ''Atag''<br />
| If it exists, this file is printed after each Tag Name.<br />
|-<br />
| valign="top" | ''Utag''<br />
| If it exists, this file is printed to replace the underscore character in an Tag Name.<br />
|}<br />
<br />
=== Changing the output for an effective argument list ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''op_eal''<br />
| If it exists, this file is printed to open an effective argument list instead of the default string <code>"("</code>.<br />
|-<br />
| valign="top" | ''eal_sep''<br />
| If it exists, this file is printed in an effective argument list instead of the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''cl_eal''<br />
| If it exists, this file is printed to close an effective argument list instead of the default string <code>")"</code>.<br />
|}<br />
<br />
=== Changing the output for manifest strings ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''open_ms''<br />
| If it exists, this file is printed to open a manifest string instead of the default string <code>"%""</code>.<br />
|-<br />
| valign="top" | ''close_ms''<br />
| If it exists, this file is printed to close a manifest string instead of the default string <code>"%""</code>.<br />
|-<br />
| valign="top" | ''Prcnt_ms''<br />
| If it exists, this file is printed in a manifest string instead of the default string <code>"%%"</code>.<br />
|-<br />
| valign="top" | ''Slash_ms''<br />
| If it exists, this file is printed to close a manifest string instead of the default string <code>"/"</code>.<br />
|}<br />
<br />
=== Changing the output for a manifest array ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''op_ma''<br />
| If it exists, this file is printed to open a manifest array instead of the default string <code>"&lt;&lt;"</code>.<br />
|-<br />
| valign="top" | ''ma_sep''<br />
| If it exists, this file is printed in a manifest array instead of the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''cl_ma''<br />
| If it exists, this file is printed to close a manifest array instead of the default string <code>"&gt;&gt;"</code>.<br />
|}<br />
<br />
=== Changing the output for comments lines ===<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''BECL''<br />
| Before Each Comment Line. This hook is applied to all comments whatever the kind of comment. If it exists, this file is printed at the beginning of each comment line instead of the default string <code>"--"</code>.<br />
|-<br />
| valign="top" | ''AECL''<br />
| After Each Comment Line. This hook is applied to all comments whatever the kind of comment. If it exists, this file is printed at the end of each comment line instead of the default string <code>"%N"</code>.<br />
|-<br />
| valign="top" | ''Ucomment''<br />
| If it exists, this file is printed to replace the underscore character in an comment line.<br />
|-<br />
| valign="top" | ''op_quote''<br />
| If it exists, this file is printed instead of the default string <code>"`"</code>.<br />
|-<br />
| valign="top" | ''cl_quote''<br />
| If it exists, this file is printed instead of the default string <code>"'"</code>.<br />
|}<br />
<br />
=== Miscellaneous tuning ===<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="10%" valign="top" | ''open_b''<br />
| If it exists, this file is printed instead of the default opening parenthesis in expressions, replacing the default string <code>"("</code>.<br />
|-<br />
| valign="top" | ''close_b''<br />
| If it exists, this file is printed instead of the default closing parenthesis in expressions, replacing the default string <code>")"</code>.<br />
|-<br />
| valign="top" | ''dot''<br />
| If it exists, this file is printed instead of the dot in expressions, replacing the default string <code>"."</code>.<br />
|-<br />
| valign="top" | ''Current''<br />
| If it exists, this file is printed instead of the ''Current'' entity in expressions, replacing the default string <code>"Current"</code>.<br />
|-<br />
| valign="top" | ''Result''<br />
| If it exists, this file is printed instead of the ''Result'' entity in expressions, replacing the default string <code>"Result"</code>.<br />
|-<br />
| valign="top" | ''Void''<br />
| If it exists, this file is printed instead of the ''Void'' entity in expressions, replacing the default string <code>"Void"</code>.<br />
|-<br />
| valign="top" | ''once''<br />
| If it exists, this file is printed instead of the '''once''' keyword in expressions, replacing the default string <code>"once"</code>.<br />
|-<br />
| valign="top" | ''old''<br />
| If it exists, this file is printed instead of the '''old''' keyword in postcondition expressions, replacing the default string <code>"old"</code>.<br />
|-<br />
| valign="top" | ''create_open''<br />
| If it exists, this file is printed to replace the default string <code>"create&nbsp;{"</code>.<br />
|-<br />
| valign="top" | ''create_close''<br />
| If it exists, this file is printed to replace the default string <code>"}"</code> opened by ''create_open''.<br />
|-<br />
| valign="top" | ''fnl_sep''<br />
| If it exists, this file is printed in a feature name list instead of the default string <code>",&nbsp;"</code>.<br />
|-<br />
| valign="top" | ''arrow''<br />
| If it exists, this file is printed instead of the arrow in a formal generic list, replacing the default string <code>"-&gt;"</code>.<br />
|-<br />
| valign="top" | ''new_line''<br />
| If it exists, this file replaces the default string <code>"%N"</code>.<br />
|}</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Extract_internals&diff=2403Extract internals2016-06-14T17:01:43Z<p>Dkearns: </p>
<hr />
<div>[[Category:Tool]]<br />
The <tt>extract_internals</tt> program was written in an attempt to fix a common problem when using object persistence: if two programs are going to send objects to each other, how do they know what objects to expect to receive? The <tt>extract_internals</tt> program analyses a program and outputs the list of object types that this program can send. The list is written in a format that can easily be used by the program that receives the objects.<br />
<br />
==The problem==<br />
Three problems, actually:<br />
# When compiling a program, Liberty Eiffel only generates code to support classes of which instances are <tt>create</tt>d in that program. Receiving objects through the STORABLE interface does not count as creating for this matter, so we need to cheat Liberty Eiffel into believing that all those types that can be received through the STORABLE interface can also be created locally (that is, mark those types as <i>live</i>).<br />
# The compiler also needs to know that we want to do introspection on types that we want to receive through the STORABLE interface, since STORABLE relies on introspection. Mainly, this means marking TYPED_INTERNALS[<i>the type that we want to receive</i>] as live.<br />
# Actually, Liberty Eiffel even strips unused attributes off classes (at least so in -boost mode). If two different programs use the same class, there is no guarantee that the same attributes will be stripped for both programs. That is unfortunate if those progams exchange objects.<br />
<br />
==Installing the tool==<br />
The first version of the extracting tool was bundled with SmartEiffel 2.2 final, Liberty Eiffel's predecessor.<br />
<br />
Now, go to some directory in your path (for instance, <tt>SmartEiffel/bin</tt>) and compile the extractor tool:<br />
<br />
se c -boost -no_gc -no_split -clean -o extract_internals extract_internals<br />
<br />
You may also want to add <tt>extract_internals</tt> to the [[Configuration file#Tools|<tt>[tools]</tt> section of your SmartEiffel configuration file]] to be able to use extract_internals through the se front-end. The configuration file is [[Configuration file#Where_is_this_file|often named <tt>.serc</tt>, <tt>se.cfg</tt> or <tt>system.se</tt>]].<br />
<br />
''Update:'' 2.3's installer automatically installs this tool.<br />
<br />
==One-way sending==<br />
Let's see how to use the <tt>extract_internals</tt> tool. We have two programs, WRITER and READER. We want the WRITER to send DATA objects to the READER through an xml file called <tt>data.xml</tt>. Here's the source code of the WRITER (programs courtesy of Damian Dobroczy&#324;ski):<br />
<br />
class WRITER<br />
<br />
creation<br />
make<br />
<br />
feature<br />
make is<br />
local<br />
r: XML_REPOSITORY[DATA]<br />
x: DATA<br />
do<br />
create r.make<br />
create x.make<br />
r.put (x, "qoocku")<br />
r.commit_to_file ("data.xml")<br />
end<br />
<br />
end<br />
<br />
And now for the READER. Unfortunately, this code does not work because the compiler does not know yet that objects of type DATA can be <tt>create</tt>d by READER (through the repository).<br />
<br />
class READER<br />
<br />
creation<br />
make<br />
<br />
feature<br />
make is<br />
local<br />
r: XML_REPOSITORY[DATA]<br />
x: DATA<br />
do<br />
create r.from_file ("data.xml")<br />
x := r.at ("qoocku")<br />
check<br />
x /= Void<br />
end<br />
print (x.a)<br />
end<br />
<br />
end<br />
<br />
For the sake of completeness, here is the code of DATA (it is not important for this discussion)<br />
<br />
class DATA<br />
<br />
inherit<br />
STORABLE<br />
<br />
creation<br />
make<br />
<br />
feature<br />
a: STRING<br />
<br />
make is<br />
do<br />
a := "Qoocku"<br />
end<br />
<br />
end<br />
<br />
Now the fun stuff begins: we use <tt>extract_internals</tt> to get the list of objects that can be created by the WRITER:<br />
extract_internals writer<br />
<br />
This will generate two files:<br />
* <tt>writer_internals_helper.e</tt> does not need to be used anymore,<br />
* <tt>writer_internals_helper.se</tt> is the list of live classes that WRITER can export and the list of live attributes of those classes. This list is written as a [[Cecil]] file.<br />
<br />
To use the information we obtained, we have to compile READER using the cecil file writer_internals_helper.se.<br />
<br />
Now we can compile the WRITER and the READER. Remember to use the cecil file when compiling the READER.<br />
<br />
se c -o writer writer<br />
se c -o reader reader <span style="color: #ff0000">-cecil writer_internals_helper.se</span><br />
<br />
Now we can enjoy the result of our work and run the writer, followed by the reader...<br />
<br />
./writer<br />
./reader<br />
<br />
...and enjoy the output, namely "Qoocku" (By the way does that <i>mean</i> anything?)<br />
<br />
==N-way sharing==<br />
If you have several programs sharing data through the STORABLE interface, you could arguably call <tt>extract_internals</tt> for each of them, and add calls to all the <tt>xxx_INTERNALS_HELPER.storable_quit</tt> at the end of all of then. Quite possibly, you would have to run <tt>extract_internals</tt> several times until the helpers stabilise. But there's an easier way.<br />
<br />
Let's assume we have three communicating programs, and their root classes/root procedures are <tt>PROGRAM_1.make</tt>, <tt>PROGRAM_2.make</tt> and <tt>PROGRAM_3.make</tt>. Now, we create a virtual common root:<br />
<br />
class COMMON_ROOT<br />
<br />
creation<br />
make<br />
<br />
feature<br />
make is<br />
do<br />
create PROGRAM_1.make<br />
create PROGRAM_2.make<br />
create PROGRAM_3.make<br />
end<br />
<br />
end<br />
<br />
Now, we run <tt>extract_internals</tt> on common_root.e.<br />
<br />
We can then compile <tt>PROGRAM_1</tt>, <tt>PROGRAM_2</tt> and <tt>PROGRAM_3</tt> as usual, just adding the <tt>-cecil common_root_internals_helper.se</tt> parameter.<br />
<br />
=== Options ===<br />
<br />
==== Information ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-help</code><br />
| Display a short summary of the command line syntax, with a complete list of the compiler options.<br />
|-<br />
| valign="top" | <code>-verbose</code><br />
| Display (an enormous amount of) information during compilation: a complete trace of files loaded, [[type inference]] scores, generated files and so on.<br />
|-<br />
| valign="top" | <code>-version</code><br />
| Display the SmartEiffel version number.<br />
|}<br />
<br />
==== Warnings ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-style_warning</code><br />
| Display warning messages about non-compliance with Eiffel style rules.<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress all warning messages.<br />
|}<br />
<br />
==== Message Styles ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-flymake_mode</code><br />
| Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.<br />
|}<br />
<br />
==FAQ==<br />
===You suggest to only initialise introspection at the end of the program. Isn't that a little late?===<br />
No, because the important action of storable_quit is performed at compile-time, not at run-time.<br />
<div id="SideEffects"><br />
===Some of the creation procedures used by xxx_INTROSPECTION_HELPER have nasty side-effects===<br />
</div><br />
That's no problem, because those creation instructions never actually get executed (see the "die" instruction above). We only want the compiler to believe that those instructions <i>could</i> could possibly get executed one day.<br />
===Some of the creation instructions in xxx_INTROSPECTION_HELPER will crash at run time because they have invalid parameters===<br />
No, because those instructions [[#SideEffects|won't get executed]].</div>Dkearnshttps://wiki.liberty-eiffel.org/index.php?title=Pretty&diff=2402Pretty2016-06-14T17:00:01Z<p>Dkearns: Document -flymake_mode</p>
<hr />
<div>[[Category:Tool]]<br />
<br />
<TT>pretty</TT> is the LibertyEiffel pretty-printer (code beautifier) for Eiffel source files. In a normal installation, it is invoked by the command <b><TT>[[se]]&nbsp;pretty</TT></b>.<br />
<br />
== Synopsis ==<br />
<br />
* <code>se pretty [options] &lt;source_file&gt;</code><br />
<br />
The <code>source_file</code> argument must be some existing Eiffel source file path as for example <code>"integer.e"</code> or <code>"lib/kernel/integer.e"</code>.<br />
<br />
One can specify more than one file name at a time in order to apply the pretty command to all the specified files. All the corresponding files are rewritten in a pretty way.<br />
<br />
There are four modes of pretty reformatting: ''-zen'', ''-default'', ''-end'' and ''-parano'' mode. Only one mode can be selected and ''-default'' is the default mode.<br />
<br />
=== Options ===<br />
<br />
==== Information ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-help</code><br />
| Display a short summary of the command line syntax, as well as a complete list of <code>pretty</code>'s options.<br />
|-<br />
| valign="top" | <code>-verbose</code><br />
| Display (an enormous amount of) information during the process: a complete list of files loaded, and so on.<br />
|-<br />
| valign="top" | <code>-version</code><br />
| Display the LibertyEiffel version number.<br />
|}<br />
<br />
==== Warnings ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-style_warning</code><br />
| Display warning messages about non-compliance with Eiffel style rules.<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress all warning messages.<br />
|}<br />
<br />
==== Message Styles ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
|-<br />
| width="20%" valign="top" | <code>-flymake_mode</code><br />
| Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.<br />
|}<br />
<br />
==== Style ====<br />
<br />
{| cellspacing="4" cellpadding="0" width="100%"<br />
| valign="top" | <code>-zen</code><br />
| Produce as little as possible (i.e. very compact output). No end mark comment for routines, no end comments for statements (if, inspect, debug, ...).<br />
|-<br />
| valign="top" | <code>-default</code><br />
| The default mode. This is close to what we are using for our library.<br />
|-<br />
| valign="top" | <code>-end</code><br />
| The same format as <code>-default</code> but add end mark comments for all routines.<br />
|-<br />
| valign="top" | <code>-parano</code><br />
| Same format as <code>-end</code> but add end mark comments for all statements (if, inspect, debug, ...).<br />
|-<br />
| valign="top" | <code>-no_warning</code><br />
| Suppress output for all warning messages (error messages are still printed).<br />
|}<br />
<br />
== Security and Backup File ==<br />
<br />
For the security of your sources files, a backup file is created before writing the new file. The backup file name is <code>"foo.bak"</code> when source file name is <code>"foo.e"</code>. The backup file is written in the same directory as the source file.<br />
<br />
If an old backup file already exists before pretty printing, the pretty command exits with an error message.<br />
<br />
To be sure that the pretty-printing is correct, the output file is parsed again. Even if the second parsing gives no errors, backup file is '''not''' removed. Thus you can recompile and test your Eiffel program to check that the beautified files did not break anything, before removing the backup files yourself.</div>Dkearns