Liberty Eiffel Wiki - User contributions [en]

Bibliography

2024-10-30T11:13:58Z

Hzwakenberg:

[[Category: Literature]]
__NOTOC__ 
==ETL 1992==
Bertrand Meyer.
''Eiffel: The Language''.
Prentice Hall, 1993, ISBN 0-13-247925-7.

==GC book==
Richar Jones and Rafael Lins.
''Garbage Collection. Algorithms for Automatic Dynamic Memory Management''.
John Wiley & Sons, ISBN 0-471-941484-4.

==GoF 1995==
Erich Gamma, Richard Helm and Ralph Johnson and John Vlissides.
''Design Patterns: Elements of Reusable Object-Oriented Software''.
Addisson-Wesley, Reading Massachusetts, 1995, ISBN 0201633612.

==Goldberg 1984==
Adele Goldberg.
''Smalltalk-80, The Interactive Programming Environment''.
Addisson-Wesley, Reading Massachusetts, 1984, ISBN 0-201-11372-4.

==GR 1983==
Adele Goldberg and David Robson.
''Smalltalk-80: The Language and its Implementation''.
Addison-Wesley, 1983, ISBN 0-201-11371-6.

==JMJ 1996==
Jean-Marc Jézéquel.
''Object-Oriented Software Engineering with Eiffel''.
Addison-Wesley, 1999, ISBN 0-201-63381-7. This book is a gentle introduction to Eiffel programming, without the academic verbosity of many of the other titles in this list.

==JTM 1999==
Jean-Marc Jézéquel, Michel Train and Christine Mingins.
''Design Patterns and Contracts''.
Addison-Wesley, 1999, ISBN 0-201-30959-9.

==MNCLT 1989==
Gérald Masini, Amédéo Napoli, Dominique Colnet, Daniel Léonard et Karl Tombre.
''Les langages à objets''.
InterEditions", Paris", 1989, ISBN 2-7296-0275-5.

==MNCLT 1991==
Gérald Masini and Amédéo Napoli and Dominique Colnet and Daniel Léonard and Karl Tombre.
''Object-Oriented Languages''.
Academic Press, New York, 1991, ISBN 0-12-477390-7.

==OOSC 1997==
Bertrand Meyer.
[https://github.com/gg-daddy/ebooks/blob/master/Object%20Oriented%20Software%20Construction-Meyer.pdf Object-oriented Software Construction, 2nd Ed.].
Prentice Hall 1997, 1254 pages, ISBN 0-13-629155-4.

==RMJM 2002==
Richard Mitchel and Jim McKim.
''Design by Contract, by Example''.
Adison-Wesley 2002, 238 pages, ISBN 0-201-63460-0. This title introduces a well structured and very thorough method of using DbC.

==TOCBM 2009==
Bertrand Meyer.
''TOUCH OF CLASS - Learning to program well with Objects and Contracts''.
Springer Verlag 2009, 876 pages, ISBN 978-81-322-0374-2. Unfortunately, this title assumes that you download supporting code and libraries, but the URL in the book is no longer valid.

==RS 1994==
Bertrand Meyer.
''Reusable Software: The Base Object-Oriented Component Libraries''.
Prentice Hall, 1994, 514 pages, ISBN-10: 013-245-499-8 ISBN-13: 978-013-245-499-5

==ECMA 367 / 2006==
ECMA International 2006.
''Eiffel: Analysis, Design and Programming Language''.
https://www.ecma-international.org/wp-content/uploads/ECMA-367_2nd_edition_june_2006.pdf

==SOOSA 2015==
Kim Waldén and Jean-Marc Nelson.
[https://www.bon-method.com/book_print_a4.pdf Seamless Object-Oriented Software Architecture].
Prentice Hall, 2015, 438 pages, ISBN 0-13-031303-3. This title is about BON (Business Object Notation), less so about the Eiffel language. BON as a method was developed by the authors of this book. BON is perceived to be simpler than the UML method.

==FUNCPTRN 1999==
Thomas Kühne.
[https://www.dbooks.org/d/3860647709-1730286407-41d4001e70927a44/ A Functional Pattern System for Object-Oriented Design].
Verlag Dr. Kovac, 1999, 346 pages, ISBN 9783860647707. The thesis of this book is that design patterns inspired by functional programming concepts can advance object-oriented design. The code examples given are implemented with Eiffel. Some of the design patterns presented here are not current any more after the Eiffel language adopted 'agents', but the discussions about it are an excellent read nonetheless.

Bibliography

2024-10-30T11:11:20Z

Hzwakenberg:

[[Category: Literature]]
__NOTOC__ 
==ETL 1992==
Bertrand Meyer.
''Eiffel: The Language''.
Prentice Hall, 1993, ISBN 0-13-247925-7.

==GC book==
Richar Jones and Rafael Lins.
''Garbage Collection. Algorithms for Automatic Dynamic Memory Management''.
John Wiley & Sons, ISBN 0-471-941484-4.

==GoF 1995==
Erich Gamma, Richard Helm and Ralph Johnson and John Vlissides.
''Design Patterns: Elements of Reusable Object-Oriented Software''.
Addisson-Wesley, Reading Massachusetts, 1995, ISBN 0201633612.

==Goldberg 1984==
Adele Goldberg.
''Smalltalk-80, The Interactive Programming Environment''.
Addisson-Wesley, Reading Massachusetts, 1984, ISBN 0-201-11372-4.

==GR 1983==
Adele Goldberg and David Robson.
''Smalltalk-80: The Language and its Implementation''.
Addison-Wesley, 1983, ISBN 0-201-11371-6.

==JMJ 1996==
Jean-Marc Jézéquel.
''Object-Oriented Software Engineering with Eiffel''.
Addison-Wesley, 1999, ISBN 0-201-63381-7. This book is a gentle introduction to Eiffel programming, without the academic verbosity of many of the other titles in this list.

==JTM 1999==
Jean-Marc Jézéquel, Michel Train and Christine Mingins.
''Design Patterns and Contracts''.
Addison-Wesley, 1999, ISBN 0-201-30959-9.

==MNCLT 1989==
Gérald Masini, Amédéo Napoli, Dominique Colnet, Daniel Léonard et Karl Tombre.
''Les langages à objets''.
InterEditions", Paris", 1989, ISBN 2-7296-0275-5.

==MNCLT 1991==
Gérald Masini and Amédéo Napoli and Dominique Colnet and Daniel Léonard and Karl Tombre.
''Object-Oriented Languages''.
Academic Press, New York, 1991, ISBN 0-12-477390-7.

==OOSC 1997==
Bertrand Meyer.
''Object-oriented Software Construction, 2nd Ed.''.
Prentice Hall 1997, 1254 pages, ISBN 0-13-629155-4.

==RMJM 2002==
Richard Mitchel and Jim McKim.
''Design by Contract, by Example''.
Adison-Wesley 2002, 238 pages, ISBN 0-201-63460-0. This title introduces a well structured and very thorough method of using DbC.

==TOCBM 2009==
Bertrand Meyer.
''TOUCH OF CLASS - Learning to program well with Objects and Contracts''.
Springer Verlag 2009, 876 pages, ISBN 978-81-322-0374-2. Unfortunately, this title assumes that you download supporting code and libraries, but the URL in the book is no longer valid.

==RS 1994==
Bertrand Meyer.
''Reusable Software: The Base Object-Oriented Component Libraries''.
Prentice Hall, 1994, 514 pages, ISBN-10: 013-245-499-8 ISBN-13: 978-013-245-499-5

==ECMA 367 / 2006==
ECMA International 2006.
''Eiffel: Analysis, Design and Programming Language''.
https://www.ecma-international.org/wp-content/uploads/ECMA-367_2nd_edition_june_2006.pdf

==SOOSA 2015==
Kim Waldén and Jean-Marc Nelson.
[https://www.bon-method.com/book_print_a4.pdf Seamless Object-Oriented Software Architecture].
Prentice Hall, 2015, 438 pages, ISBN 0-13-031303-3. This title is about BON (Business Object Notation), less so about the Eiffel language. BON as a method was developed by the authors of this book. BON is perceived to be simpler than the UML method.

==FUNCPTRN 1999==
Thomas Kühne.
[https://www.dbooks.org/d/3860647709-1730286407-41d4001e70927a44/ A Functional Pattern System for Object-Oriented Design].
Verlag Dr. Kovac, 1999, 346 pages, ISBN 9783860647707. The thesis of this book is that design patterns inspired by functional programming concepts can advance object-oriented design. The code examples given are implemented with Eiffel. Some of the design patterns presented here are not current any more after the Eiffel language adopted 'agents', but the discussions about it are an excellent read nonetheless.

Bibliography

2024-10-30T11:09:25Z

Hzwakenberg:

[[Category: Literature]]
__NOTOC__ 
==ETL 1992==
Bertrand Meyer.
''Eiffel: The Language''.
Prentice Hall, 1993, ISBN 0-13-247925-7.

==GC book==
Richar Jones and Rafael Lins.
''Garbage Collection. Algorithms for Automatic Dynamic Memory Management''.
John Wiley & Sons, ISBN 0-471-941484-4.

==GoF 1995==
Erich Gamma, Richard Helm and Ralph Johnson and John Vlissides.
''Design Patterns: Elements of Reusable Object-Oriented Software''.
Addisson-Wesley, Reading Massachusetts, 1995, ISBN 0201633612.

==Goldberg 1984==
Adele Goldberg.
''Smalltalk-80, The Interactive Programming Environment''.
Addisson-Wesley, Reading Massachusetts, 1984, ISBN 0-201-11372-4.

==GR 1983==
Adele Goldberg and David Robson.
''Smalltalk-80: The Language and its Implementation''.
Addison-Wesley, 1983, ISBN 0-201-11371-6.

==JMJ 1996==
Jean-Marc Jézéquel.
''Object-Oriented Software Engineering with Eiffel''.
Addison-Wesley, 1999, ISBN 0-201-63381-7. This book is a gentle introduction to Eiffel programming, without the academic verbosity of many of the other titles in this list.

==JTM 1999==
Jean-Marc Jézéquel, Michel Train and Christine Mingins.
''Design Patterns and Contracts''.
Addison-Wesley, 1999, ISBN 0-201-30959-9.

==MNCLT 1989==
Gérald Masini, Amédéo Napoli, Dominique Colnet, Daniel Léonard et Karl Tombre.
''Les langages à objets''.
InterEditions", Paris", 1989, ISBN 2-7296-0275-5.

==MNCLT 1991==
Gérald Masini and Amédéo Napoli and Dominique Colnet and Daniel Léonard and Karl Tombre.
''Object-Oriented Languages''.
Academic Press, New York, 1991, ISBN 0-12-477390-7.

==OOSC 1997==
Bertrand Meyer.
''Object-oriented Software Construction, 2nd Ed.''.
Prentice Hall 1997, 1254 pages, ISBN 0-13-629155-4.

==RMJM 2002==
Richard Mitchel and Jim McKim.
''Design by Contract, by Example''.
Adison-Wesley 2002, 238 pages, ISBN 0-201-63460-0. This title introduces a well structured and very thorough method of using DbC.

==TOCBM 2009==
Bertrand Meyer.
''TOUCH OF CLASS - Learning to program well with Objects and Contracts''.
Springer Verlag 2009, 876 pages, ISBN 978-81-322-0374-2. Unfortunately, this title assumes that you download supporting code and libraries, but the URL in the book is no longer valid.

==RS 1994==
Bertrand Meyer.
''Reusable Software: The Base Object-Oriented Component Libraries''.
Prentice Hall, 1994, 514 pages, ISBN-10: 013-245-499-8 ISBN-13: 978-013-245-499-5

==ECMA 367 / 2006==
ECMA International 2006.
''Eiffel: Analysis, Design and Programming Language''.
https://www.ecma-international.org/wp-content/uploads/ECMA-367_2nd_edition_june_2006.pdf

==SOOSA 2015==
Kim Waldén and Jean-Marc Nelson.
''Seamless Object-Oriented Software Architecture''.
Prentice Hall, 2015, 438 pages, ISBN 0-13-031303-3. This title is about BON (Business Object Notation), less so about the Eiffel language. BON as a method was developed by the authors of this book. BON is perceived to be simpler than the UML method.

==FUNCPTRN 1999==
Thomas Kühne.
[https://www.dbooks.org/d/3860647709-1730286407-41d4001e70927a44/ A Functional Pattern System for Object-Oriented Design].
Verlag Dr. Kovac, 1999, 346 pages, ISBN 9783860647707. The thesis of this book is that design patterns inspired by functional programming concepts can advance object-oriented design. The code examples given are implemented with Eiffel. Some of the design patterns presented here are not current any more after the Eiffel language adopted 'agents', but the discussions about it are an excellent read nonetheless.

Template:MainPageCommunity

2024-10-28T21:29:54Z

Hzwakenberg:

* The [[Sandbox]] for all your experimentations
* [[Getting Started]] by bootstrapping Liberty from its source
* [[Get in touch]] with the Liberty development team and with other users
* [[Get involved]] with Liberty Eiffel
* The day-to-day [[Grand blackboard]]
* Register to the [[Liberty Eiffel users list]]
* The [https://savannah.gnu.org/projects/liberty-eiffel/ GNU Savannah Project site] ...

'''Bleeding edge'''
* [[Installing on Windows using the Tiny-C compiler]]
* [[GSoC|Google Summer of Code Portal]]
* Share your Liberty Eiffel [[Coding patterns|tricks and tips]]!
* Automatic testing of current GIT HEAD by [http://et.liberty-eiffel.org ET]
* How to create a [[Release_Checklist|LibertyEiffel release]]
* [[ToDo|What we should improve in this wiki]]

'''Related projects'''
* [https://sourceforge.net/projects/ese/ Enterprise SmartEiffel]
* [http://notabug.org/GermanGT/eiffel-iup eiffel-iup]

Release Notes (Versions history)

2024-10-28T10:40:06Z

Hzwakenberg:

[[Category: Releases]]
== Liberty Eiffel (latest release first) ==
For other upcoming releases see the [[upcoming releases|list of names]].
=== Curtiss (2024.dev, to be named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===
* not yet released (see next section for current release notes)
* User-visible changes:
** added installation script: [[Installing on Windows using the Tiny-C compiler]]
** added support for assign (note: it applies to the setter, while ISE version applies to the getter)
** redesign of eiffeldoc generated HTML to reduce its size dramatically
** addition of a zsh completer for se
** updated dependency of BDW GC to version 8.x
** installation script (install.sh) now supports the latest libgc-dev library (external garbage collector)
** finally removed the obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused legacy platforms (OpenVMS, Amiga, Elate, BeOS, OS/2, Macintosh, HP RISC, IBM370, NS32000, MIPS, Pyramid 9810, SPARC, VAX, Motorola 68000) - in case you have a real use case for those we are happy to readd it
** removed support for some unused backend C-compilers (i.e. Watcom-C)
** removed obsolete feature "is_basic_expanded_type" from class ANY
** obsolete keyword 'creation' now generates an error
** obsolete class READY_DESCRIPTION removed from sequencer cluster
** 'is_prime' feature added to class INTEGER_GENERAL
** 'is_fibonacci' feature added to class INTEGER_GENERAL
** constants 'Tau', 'Sqr_tau' and 'Inv_tau' added to math_constants.e
** C-runtime now C99 compliant
** C-runtime now thread-safe
** C-code generator does not yet generate C99 compliant C-code, currently being worked on (likely for the Dennis-release).
** RUN_FEATUREs now have clear names (hopefully)
** to better support the user access rights model of the current Windows versions, the config file is no longer written to a root directory but rather to %ALLUSERSPROFILE% or %USERPROFILE%
* Known bugs:
** see [https://savannah.gnu.org/bugs/?group=liberty-eiffel] for the full list

=== Bell (2016.05, named after [https://en.wikipedia.org/wiki/Alexander_Graham_Bell Alexander Graham Bell]) ===
* released in May 2016
* first release since Liberty Eiffel has become the official GNU Eiffel compiler
* User-visible changes:
** changed Environment Variable name from SmartEiffel to LibertyEiffel (anyhow, normally it should not be necessary to set this one)
** new tool [[Mock]]
** removed linebreaks in compiler output
** many bugfixes
** GC call at exit is optional
** generic creation
** agents are now [https://en.wikipedia.org/wiki/Closure_(computer_programming) closures ]
** finder now finds all classes in the universe with the given name, not only the first one
** keyword '''is''' at the beginning of a feature is now deprecated
** Added support for alias "[]" and alias "()"
** constants are now visible in the eiffeldoc generated documentation
* Known bugs:
** 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.
** for the full list see [https://savannah.gnu.org/bugs/?group=liberty-eiffel]

=== Adler (2013.11, named after [http://en.wikipedia.org/wiki/Charles_Adler,_Jr. Charles Adler, Jr.]) ===
* First release as Liberty Eiffel
* User-visible changes:
** 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.
** 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.
** Inlined dynamic dispatch for better performance
** A missing export clause is deprecated. Use <tt>{ANY}</tt> instead.
** New core libraries: cli, json, log, parse (beware, these libraries are not yet tuned to be used without GC)
** Improved libraries: string (with notably a new [[library_class:FIXED_STRING|<tt>FIXED_STRING</tt>]] class)
** Wrapper libraries: gtk, gdk, readline, ffi...
** A new tool that can generate mocks to help unit testing
** [http://hboehm.info/gc/ BDW] GC support
** Collections implementation of is_equal changed to compare the contained objects using their is_equal functions instead of = (which was formerly the functionality of is_equal_map). The old functionality of is_equal is available by fast_is_equal.
* Developer changes:
** The web site now belongs to the repository
** Automatic testing tools (ET on the web, and <tt>watch_eiffeltest.sh</tt> in the shell)
** Automatic Debian packages generation
* Known bugs:
** 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)
** Sometimes SmartEiffel's native GC behaves wrongly, analysis is welcome
** Some of the newer core libraries do not work very well when there is no GC
** See the [https://savannah.gnu.org/bugs/?group=liberty-eiffel bugs page]

Installing on Windows using the Tiny-C compiler

2024-10-28T10:35:46Z

Hzwakenberg:

= Installing Liberty Eiffel on Windows using the Tiny-C compiler =

== Prerequisites ==

=== Liberty Eiffel repository ===
The complete Liberty Eiffel source code repository can be downloaded from gnu’s git server. Install git on your machine if you haven’t done so already and simply use:

“git clone git://git.sv.gnu.org/liberty-eiffel.git”

This will create a directory called ‘liberty-eiffel’ and replicate the entire repository into it. Personally, I prefer directory names to be a bit shorter, so for my case I renamed it to just ‘liberty’, see the screenshot that follows further below.
For those of you who don’t want to install ‘git’: it is possible to visit the mirrored Liberty Eiffel repository at GitHub and download the entire repository as a ZIP-file as well.

=== Tiny-C compiler ===
The installation script assumes that a working Tiny-C compiler (tcc) is installed and that your ‘path’ environment variable points to the tcc installation directory as well. If you think this is the case, simply open a command prompt and check whether tcc.exe can indeed be found, like I did for the following screenshot. Note that my current directory was C:\Liberty, which is where I copied the Liberty Eiffel repository to:

[[File:tcc-check-0.png|center|Is Tiny-C installed properly?]]

As you can see, tcc could be found and it reported back that it is version 0.9.27 (x86_64 Windows). This also means that the ‘path’ environment variable points to the correct Tiny-C installation directory, otherwise the compiler would not have been found.

=== Installation ===
Open a new command window and navigate to Liberty Eiffel's root installation directory.
This directory contains a cmd-file named '''win-install-tcc.cmd'''. Type this command into a CMD-window, like in the following screenshot:

[[File:tcc-check.png|center|Starting the installation cmd file]]

And then press the enter-key. The following screenshot documents what will happen on your machine:

[[File:Liberty-install-Windows.png|center|Installation process using Tiny-C]]

Note the time stamps on the output… Now is the time to grab a cup of coffee, or even a few, and then come back to read the remaining part of this document 😊
I’ll get back to the time stamps later on….

=== What does this installation script do? ===
'''The big picture?''' This script creates your Liberty Eiffel executables by compiling them from the original source code!

* First it verifies the installation prerequisites and creates a number of temporary files. Then it searches for your Tiny-C installation, which is why it was important to have your installation and your ‘path’ settings checked beforehand, as described above.

* Next, a configuration file is created. This ‘liberty.cfg’ file is used by the Eiffel compiler and other commands in the tool set. It is created in %USERPROFILE%. If you want ‘liberty.cfg’ to be readable for all users, you have to copy it manually to %ALLUSERSPROFILE% as well. You’ll need admin credentials to do this.

* Up next is the first real compilation: bootstrapping ‘compile_to_c’, the command used by most of the other Liberty Eiffel commands. As the name implies, this command takes an Eiffel source file or files and creates C-files from them. The C-sources for ‘compile_to_c’ itself are compiled into an initial version of ‘compile_to_c.exe’. I had Tiny-C emit some statistics about the size of the sources and the time it took to create an executable from it.

* This initial executable is then used to compile itself again from the original Eiffel sources. ‘compile_to_c.exe’ creates C-files, and these are again compiled by Tiny-C, resulting in yet another version of ‘compile_to_c.exe’. This bootstrapping cycle is repeated three times. The installation script provides a short message about each of these cycles, named T1, T2 and T3.

* The script continues with comparing the ‘compile_to_c.exe’ files from the T2 and T3 cycles. If they are binary equivalents, the T3-version is moved to the ..\bin directory. This is how the core compiler is bootstrapped and later used to compile the rest of the Liberty Eiffel commands. But before that, the script removes all temporary files and directories that were created for the bootstrapping process.

* Using the now stable version of ‘compile_to_c.exe’, the remaining commands are compiled. The corresponding executables are moved to ..\bin as well. Any temporary file created by the compilation process is removed (Liberty Eiffel provides the ‘clean’ command for that, which is used after that executable got created).

'''Now back to the time stamps I alluded to before:'''

Liberty Eiffel (and its predecessor too) were predominantly developed on Linux and a number of other Unix-derived operating systems. On these operating systems, the compilation tasks share multiple processor cores, making the installation rather swift. On Windows, we still need to work on the Eiffel code for ‘exec’ and a few other features to spawn separate processes. Until that is finished, it is not yet possible to have parallel compilation to create a single application.

'''The bottom line''': this installation script for Windows is a single-core sequential processing job, which is why it takes three to four times as long as on a comparable Linux machine. On my quad-core Xeon @ 4 GHz, it takes about an hour, but then again, only a single core is used for this job and my machine had other compute intensive tasks running in the background as well…

If your installation process shows the ‘Finish:’ time stamp, you should have a working Liberty Eiffel environment on your Windows pc.

=== Looking for a small footprint code editor as well? ===
If you’re looking for a minimal footprint editor for your Eiffel endeavours on Windows as well, I recommend using Notepad++.

In your Liberty Eiffel ..\work directory, you’ll find a subdirectory called ‘notepad++_syntax-highlighting’. Within that directory, you’ll find a Liberty-Eiffel.xml file that can be imported into notepad++. It loosely implements the Eiffel formatting rules proposed by Bertrand Meyer in OOSC-2. In this directory, I also uploaded a pdf-file to show what that looks like.

Good luck and happy Eiffeling….! 😉

Installing on Windows using the Tiny-C compiler

2024-10-28T10:32:00Z

Hzwakenberg:

= Installing Liberty Eiffel on Windows using the Tiny-C compiler =

== Prerequisites ==

=== Liberty Eiffel repository ===
The complete Liberty Eiffel source code repository can be downloaded from gnu’s git server. Install git on your machine if you haven’t done so already and simply use:

“git clone git://git.sv.gnu.org/liberty-eiffel.git”

This will create a directory called ‘liberty-eiffel’ and replicate the entire repository into it. Personally, I prefer directory names to be a bit shorter, so for my case I renamed it to just ‘liberty’, see the screenshot that follows further below.
For those of you who don’t want to install ‘git’: it is possible to visit the mirrored Liberty Eiffel repository at GitHub and download the entire repository as a ZIP-file as well.

=== Tiny-C compiler ===
The installation script assumes that a working Tiny-C compiler (tcc) is installed and that your ‘path’ environment variable points to the tcc installation directory as well. If you think this is the case, simply open a command prompt and check whether tcc.exe can indeed be found, like I did for the following screenshot. Note that my current directory was C:\Liberty, which is where I copied the Liberty Eiffel repository to:

[[File:tcc-check-0.png|center|Is Tiny-C installed properly?]]

As you can see, tcc could be found and it reported back that it is version 0.9.27 (x86_64 Windows). This also means that the ‘path’ environment variable points to the correct Tiny-C installation directory, otherwise the compiler would not have been found.

=== Installation ===
Open a new command window and navigate to Liberty Eiffel's root installation directory.
This directory contains a cmd-file named '''win-install-tcc.cmd'''. Type this command into a CMD-window, like in the following screenshot:

[[File:tcc-check.png|center|Starting the installation cmd file]]

And then press the enter-key. The following screenshot documents what will happen on your machine:

[[File:Liberty-install-Windows.png|center|Installation process using Tiny-C]]

Note the time stamps on the output… Now is the time to grab a cup of coffee, or even a few, and then come back to read the remaining part of this document 😊
I’ll get back to the time stamps later on….

=== What does this installation script do? ===
'''The big picture?''' This script creates your Liberty Eiffel executables by compiling them from the original source code!

* First it verifies the installation prerequisites and creates a number of temporary files. Then it searches for your Tiny-C installation, which is why it was important to have your installation and your ‘path’ settings checked beforehand, as described above.

* Next, a configuration file is created. This ‘liberty.cfg’ file is used by the Eiffel compiler and other commands in the tool set. It is created in %USERPROFILE%. If you want ‘liberty.cfg’ to be readable for all users, you have to copy it manually to %ALLUSERSPROFILE% as well. You’ll need admin credentials to do this.

* Up next is the first real compilation: bootstrapping ‘compile_to_c’, the command used by most of the other Liberty Eiffel commands. As the name implies, this command takes an Eiffel source file or files and creates C-files from them. The C-sources for ‘compile_to_c’ itself are compiled into an initial version of ‘compile_to_c.exe’. I had Tiny-C emit some statistics about the size of the sources and the time it took to create an executable from it.

* This initial executable is then used to compile itself again from the original Eiffel sources. ‘compile_to_c.exe’ creates C-files, and these are again compiled by Tiny-C, resulting in yet another version of ‘compile_to_c.exe’. This bootstrapping cycle is repeated three times. The installation script provides a short message about each of these cycles, named T1, T2 and T3.

* The script continues with comparing the ‘compile_to_c.exe’ files from the T2 and T3 cycles. If they are binary equivalents, the T3-version is moved to the ..\bin directory. This is how the core compiler is bootstrapped and later used to compile the rest of the Liberty Eiffel commands. But before that, the script removes all temporary files and directories that were created for the bootstrapping process.

* Using the now stable version of ‘compile_to_c.exe’, the remaining commands are compiled. The corresponding executables are moved to ..\bin as well. Any temporary file created by the compilation process is removed (Liberty Eiffel provides the ‘clean’ command for that, which is used after that executable got created).

'''Now back to the time stamps I alluded to before:'''

Liberty Eiffel (and its predecessor too) were predominantly developed on Linux and a number of other Unix-derived operating systems. On these operating systems, the compilation tasks share multiple processor cores, making the installation rather swift. On Windows, we still need to work on the Eiffel code for ‘exec’ and a few other features to spawn separate processes. Until that is finished, it is not yet possible to have parallel compilation to create a single application.

'''The bottom line''': this installation script for Windows is a single-core sequential processing job, which is why it takes three to four times as long as on a comparable Linux machine. On my quad-core Xeon @ 4 GHz, it takes about an hour, but then again, only a single core is used for this job and my machine had other compute intensive tasks in the background as well…

If your installation process shows the ‘Finish:’ time stamp, you should have a working Liberty Eiffel environment on your Windows pc.

=== Looking for a small footprint code editor as well? ===
If you’re looking for a minimal footprint editor for your Eiffel endeavours on Windows as well, I recommend using Notepad++.

In your Liberty Eiffel ..\work directory, you’ll find a subdirectory called ‘notepad++_syntax-highlighting’. Within that directory, you’ll find a Liberty-Eiffel.xml file that can be imported into notepad++. It loosely implements the Eiffel formatting rules proposed by Bertrand Meyer in OOSC-2. In this directory, I also uploaded a pdf-file to show what that looks like.

Good luck and happy Eiffeling….! 😉

Installing on Windows using the Tiny-C compiler

2024-10-28T10:23:45Z

Hzwakenberg:

= Installing Liberty Eiffel on Windows using the Tiny-C compiler =

== Prerequisites ==

=== Liberty Eiffel repository ===
The complete Liberty Eiffel source code repository can be downloaded from gnu’s git server. Install git on your machine if you haven’t done so already and simply use:

“git clone git://git.sv.gnu.org/liberty-eiffel.git”

This will create a directory called ‘liberty-eiffel’ and replicate the entire repository into it. Personally, I prefer directory names to be a bit shorter, so for my case I renamed it to just ‘liberty’, see the screenshot that follows further below.
For those of you who don’t want to install ‘git’: it is possible to visit the mirrored Liberty Eiffel repository at GitHub and download the entire repository as a ZIP-file as well.

=== Tiny-C compiler ===
The installation script assumes that a working Tiny-C compiler (tcc) is installed and that your ‘path’ environment variable points to the tcc installation directory as well. If you think this is the case, simply open a command prompt and check whether tcc.exe can indeed be found, like I did for the following screenshot. Note that my current directory was C:\Liberty, which is where I copied the Liberty Eiffel repository to:

[[File:tcc-check-0.png|center|Is Tiny-C installed properly?]]

As you can see, tcc could be found and it reported back that it is version 0.9.27 (x86_64 Windows). This also means that the ‘path’ environment variable points to the correct Tiny-C installation directory, otherwise the compiler would not have been found.

=== Installation ===
Open a new command window and navigate to Liberty Eiffel's root installation directory.
This directory contains a cmd-file named '''win-install-tcc.cmd'''. Type this command into a CMD-window, like in the following screenshot:

[[File:tcc-check.png|center|Starting the installation cmd file]]

And then press the enter-key. The following screenshot documents what will happen on your machine:

[[File:Liberty-install-Windows.png|center|Installation process using Tiny-C]]

Note the time stamps on the output… Now is the time to grab a cup of coffee, or even a few, and then come back to read the remaining part of this document 😊
I’ll get back to the time stamps later on….

=== What does this installation script do? ===
'''The big picture?''' This script creates your Liberty Eiffel executables by compiling them from the original source code!

* First it verifies the installation prerequisites by creating a number of temporary files. Then it searches for your Tiny-C installation, which is why it was important to have your installation and your ‘path’ settings checked beforehand, as described above.

* Next, a configuration file is created. This ‘liberty.cfg’ file is used by the Eiffel compiler and other commands in the tool set. It is created in %USERPROFILE%. If you want ‘liberty.cfg’ to be readable for all users, you have to copy it manually to %ALLUSERSPROFILE% as well. You’ll need admin credentials to do this.

* Up next is the first real compilation: bootstrapping ‘compile_to_c’, the command used by most of the other Liberty Eiffel commands. As the name implies, this command takes an Eiffel source file or files and creates C-files from them. The C-sources for ‘compile_to_c’ itself are compiled into an initial version of ‘compile_to_c.exe’. I had Tiny-C emit some statistics about the size of the sources and the time it took to create an executable from it.

* This initial executable is then used to compile itself again from the original Eiffel sources. ‘compile_to_c.exe’ creates C-files, and these are again compiled by Tiny-C, resulting in yet another version of ‘compile_to_c.exe’. This bootstrapping cycle is repeated three times. The installation script provides a short message about each of these cycles, named T1, T2 and T3.

* The script continues with comparing the ‘compile_to_c.exe’ files from the T2 and T3 cycles. If they are binary equivalents, the T3-version is moved to the ..\bin directory. This is how the core compiler is bootstrapped and later used to compile the rest of the Liberty Eiffel commands. But before that, the script removes all temporary files and directories that were created for the bootstrapping process.

* Using the now stable version of ‘compile_to_c.exe’, the remaining commands are compiled. The corresponding executables are moved to ..\bin as well. Any temporary file created by the compilation process is removed (Liberty Eiffel provides the ‘clean’ command for that, which is used after that executable got created).

'''Now back to the time stamps I alluded to before:'''

Liberty Eiffel (and its predecessor too) were predominantly developed on Linux and a number of other Unix-derived operating systems. On these operating systems, the compilation tasks share multiple processor cores, making the installation rather swift. On Windows, we still need to work on the Eiffel code for ‘exec’ and a few other features to spawn separate processes. Until that is finished, it is not yet possible to have parallel compilation to create a single application.

'''The bottom line''': this installation script for Windows is a single-core sequential processing job, which is why it takes three to four times as long as on a comparable Linux machine. On my quad-core Xeon @ 4 GHz, it takes appr. an hour, but then again, only a single core is used for this job and my machine had other compute intensive tasks in the background as well…

If your installation process shows the ‘Finish:’ time stamp, you should have a working Liberty Eiffel environment on your Windows pc.

=== Looking for a small footprint code editor as well? ===
If you’re looking for a minimal footprint editor for your Eiffel endeavours on Windows as well, I recommend using Notepad++.

In your Liberty Eiffel ..\work directory, you’ll find a subdirectory called ‘notepad++_syntax-highlighting’. Within that directory, you’ll find a Liberty-Eiffel.xml file that can be imported in notepad++. It loosely implements the Eiffel formatting rules proposed by Bertrand Meyer. In this directory I also put a pdf-file to show what that looks like.

Good luck and happy Eiffeling….! 😉

Getting Started

2024-10-28T10:21:51Z

Hzwakenberg: /* Windows Installer */

== Prepared Debian/Ubuntu packages ==
On http://apt.liberty-eiffel.org/ we have prepared some Debian/Ubuntu packages. For the quick start using the last stable release do:

* add the following repository (note: it is currently unsigned)
<nowiki>deb http://apt.liberty-eiffel.org/ release main</nowiki>

* then install (as root or with sudo)
apt-get install liberty-eiffel-all

That's it, you now can run "se c" to [[Tutorial_tour|compile your first program.]]

== Windows Installer ==
In a 2016 [[GSoC_-_Windows_Support|GSoC project]] Petru Gurita worked on a Windows installer using NSIS. His [https://github.com/petr00/Liberty-Eiffel-Windows repository] is hosted on GitHub.

Since October 2024, an installation script exists that loosely mimics the 'install.sh' script that is used on Linux based machines. The installation process is documented on a separate page: [[Installing on Windows using the Tiny-C compiler]]
This Windows cmd-script only assumes that you have a Tiny-C compiler installed - no need to download and run external installation packages.

== Bootstrap from tarball ==
Download the <release>.tar.gz from http://download.savannah.gnu.org/releases/liberty-eiffel
unpack it with
tar -zxvf <release>.tar.gz

bootstrap Liberty with
cd <release>
./install.sh -bootstrap

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:
PATH=$PATH:~/<release>/target/bin
export PATH

== Bootstrap from git source ==
On Linux (and most other Unix-like systems) installation of Liberty from source is simple:

Check that the following Pre-requisites are available on your system:
* git
* GCC compiler
* castxml (or GCC-XML)
* Boehm-Demers-Weiser garbage collector dev-packages

On debian-like systems you may install them with:
sudo apt-get install git build-essential castxml libgc-dev

On Fedora you'll need gc-devel, rather than libgc-dev, castxml and of course the basic packages for compiling like gcc, git etc.

Now clone the repository:
git clone git://git.sv.gnu.org/liberty-eiffel.git

Change into the directory you created by this:
cd liberty-eiffel

and execute
./install.sh -bootstrap

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:
PATH=$PATH:~/liberty-eiffel/target/bin
export PATH

'''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.
'''
Now you can call [[Se|se]] as interface for all tools. For examples go to
cd <LibertyHome>/tutorial
and compile with
se compile hello_world.e -o hello_world
your first Liberty Eiffel program.

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]].

Release Notes (Versions history)

2024-10-28T09:33:27Z

Hzwakenberg: /* Curtiss (2022.dev, to be named after Glenn Curtiss) */

[[Category: Releases]]
== Liberty Eiffel (latest release first) ==
For other upcoming releases see the [[upcoming releases|list of names]].
=== Curtiss (2022.dev, to be named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===
* not yet released (see next section for current release notes)
* User-visible changes:#
** added installation script: [[Installing on Windows using the Tiny-C compiler]]
** added support for assign (note: it applies to the setter, while ISE version applies to the getter)
** redesign of eiffeldoc generated HTML to reduce its size dramatically
** addition of a zsh completer for se
** updated dependency of BDW GC to version 8.x
** installation script (install.sh) now supports the latest libgc-dev library (external garbage collector)
** finally removed the obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused legacy platforms (OpenVMS, Amiga, Elate, BeOS, OS/2, Macintosh, HP RISC, IBM370, NS32000, MIPS, Pyramid 9810, SPARC, VAX, Motorola 68000) - in case you have a real use case for those we are happy to readd it
** removed support for some unused backend C-compilers (i.e. Watcom-C)
** removed obsolete feature "is_basic_expanded_type" from class ANY
** obsolete keyword 'creation' now generates an error
** obsolete class READY_DESCRIPTION removed from sequencer cluster
** 'is_prime' feature added to class INTEGER_GENERAL
** 'is_fibonacci' feature added to class INTEGER_GENERAL
** constants 'Tau', 'Sqr_tau' and 'Inv_tau' added to math_constants.e
** C-runtime now C99 compliant
** C-runtime now thread-safe
** C-code generator does not yet generate C99 compliant C-code, currently being worked on (likely for the Dennis-release).
** RUN_FEATUREs now have clear names (hopefully)
** to better support the user access rights model of the current Windows versions, the config file is no longer written to a root directory but rather to %ALLUSERSPROFILE% or %USERPROFILE%
* Known bugs:
** see [https://savannah.gnu.org/bugs/?group=liberty-eiffel] for the full list

=== Bell (2016.05, named after [https://en.wikipedia.org/wiki/Alexander_Graham_Bell Alexander Graham Bell]) ===
* released in May 2016
* first release since Liberty Eiffel has become the official GNU Eiffel compiler
* User-visible changes:
** changed Environment Variable name from SmartEiffel to LibertyEiffel (anyhow, normally it should not be necessary to set this one)
** new tool [[Mock]]
** removed linebreaks in compiler output
** many bugfixes
** GC call at exit is optional
** generic creation
** agents are now [https://en.wikipedia.org/wiki/Closure_(computer_programming) closures ]
** finder now finds all classes in the universe with the given name, not only the first one
** keyword '''is''' at the beginning of a feature is now deprecated
** Added support for alias "[]" and alias "()"
** constants are now visible in the eiffeldoc generated documentation
* Known bugs:
** 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.
** for the full list see [https://savannah.gnu.org/bugs/?group=liberty-eiffel]

=== Adler (2013.11, named after [http://en.wikipedia.org/wiki/Charles_Adler,_Jr. Charles Adler, Jr.]) ===
* First release as Liberty Eiffel
* User-visible changes:
** 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.
** 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.
** Inlined dynamic dispatch for better performance
** A missing export clause is deprecated. Use <tt>{ANY}</tt> instead.
** New core libraries: cli, json, log, parse (beware, these libraries are not yet tuned to be used without GC)
** Improved libraries: string (with notably a new [[library_class:FIXED_STRING|<tt>FIXED_STRING</tt>]] class)
** Wrapper libraries: gtk, gdk, readline, ffi...
** A new tool that can generate mocks to help unit testing
** [http://hboehm.info/gc/ BDW] GC support
** Collections implementation of is_equal changed to compare the contained objects using their is_equal functions instead of = (which was formerly the functionality of is_equal_map). The old functionality of is_equal is available by fast_is_equal.
* Developer changes:
** The web site now belongs to the repository
** Automatic testing tools (ET on the web, and <tt>watch_eiffeltest.sh</tt> in the shell)
** Automatic Debian packages generation
* Known bugs:
** 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)
** Sometimes SmartEiffel's native GC behaves wrongly, analysis is welcome
** Some of the newer core libraries do not work very well when there is no GC
** See the [https://savannah.gnu.org/bugs/?group=liberty-eiffel bugs page]

GSoC - Windows Support

2024-10-28T09:27:32Z

Hzwakenberg:

== Liberty Eiffel meets Windows ==

=== New small footprint installation method using Tiny-C ===
Since October 2024, an installation script exists that loosely mimics the 'install.sh' script that is used on Linux based machines. The installation process is documented on a separate page: [[Installing on Windows using the Tiny-C compiler]]
This Windows cmd-script only assumes that you have a Tiny-C compiler installed - no need to download and run external installation packages.

=== 2016 GSOC effort: ===

* [https://github.com/petr00/Liberty-Eiffel-Windows Link to repository]

----

'''Final Goal '''

Bootstrap the Liberty-Eiffel programming language (compiler,classes, functions etc.)
from the UNIX/LINUX environment to the WINDOWS environment and wrap it into a nice installer.

----

== '''Progress''' ==

I've created a working installer application that replicates all the facilities, but one, that Liberty Eiffel offers in POSIX systems,
in Windows Environment. The only facility that I didn't reproduce, '''net cluster''', caused the eiffeltest_server tool to be inoperable.

----

The other tools (se, clean, ace_check, eiffeltest, mock, eiffeltest_ng, pretty, short, class_check, finder, eiffeldoc, extract_internals) work just fine together will all the other plugins and all functionalities.

----

== What I coded: ==

* [https://github.com/petr00/Liberty-Eiffel-Windows/blob/master/nsis-installer/liberty/install.bat install.bat], which creates the "T stages" and compiles *almost* all the tools, creates the configuration file and the binaries from the tools.

* [https://github.com/petr00/Liberty-Eiffel-Windows/blob/master/nsis-installer/liberty/install.bat\set_path.cmd set_path.cmd], simple utility used to create the Liberty Eiffel configuration file, called by installer.nsi .

* [https://github.com/petr00/Liberty-Eiffel-Windows/tree/master/nsis-installer/installer.nsi installer.nsi], a nicely wrapped NSIS installer + uninstaller, that follows the best practices : required executionlevel, write/delete registers, function to create/delete environment variable for the binaries created from the compiled Liberty Eiffel tools, has a function that reads the product version of the Liberty Eiffel install application and downloads from it's official website documentation regarding that patch( at the moment the site's structure does not allow that, but the function will be used in the near future, the installers now is only downloading from a plain link), an option for downloading mingw-w64, custom images etc.

* A part of liberty/[https://github.com/petr00/Liberty-Eiffel-Windows/blob/master/nsis-installer/liberty/se_make.bat se_make.bat](inspired from [https://github.com/LibertyEiffel/Liberty/blob/master/work/se_make.sh /work/se_make.sh]), no longer needed for this patch, therefore I did not completed all of it.

-----

== '''General''' ==

The original main goal was to create two versions of an installer application: one that assumes that the end-user already has mingw-w64 installed,
and one that installs mingw-w64 for the user.

The reason was flexibility: the installer with mingw attached would be bigger with around 300mb.
After searching, I found out that there are not offline installers for mingw available, but online versions of only around 200kb.
Therefore I only created one version of Liberty Eiffel installer that offers the user the ability to download mingw via calling mingw's online installer.

----

The "T stages" refers to compiling Liberty Eiffel's base code (currently 136 C-files created by the Liberty Eiffel compiler) and create a binary from these, and with that binary the same
136 C-files (that represent the core of smarteiffel) get compiled again, and so on for three times. After three such processes, if the resulting applications are binary indentical to the previous compile, the installer proceeds further to the [[http://wiki.liberty-eiffel.org/index.php/GSoC_-_Windows_Support#Progress tools compilation]].

----

The NSIS installer does just as mentioned [[http://wiki.liberty-eiffel.org/index.php/GSoC_-_Windows_Support#Progress above]] and has incorporated an uninstaller that uninstalls exactly what the installer created.

== '''Repository structure''' ==

Please note that I did not want to create a very long post about all the details of installer.nsi, but you can check some of those [https://github.com/petr00/Liberty-Eiffel-Windows/blob/master/nsis-installer/readme.md here].

----

From this repository only the files mentioned [[http://wiki.liberty-eiffel.org/index.php?title=GSoC_-_Windows_Support&action=submit#Progress above]], 'What I coded' paragraph were made by me, plus the images.
The other files are duplicates from Liberty Eiffel's core structure(only the most relevant files) to create an ease of use of the installer script for testing purposes.

Getting Started

2024-10-28T09:24:10Z

Hzwakenberg: /* Windows Installer */

== Prepared Debian/Ubuntu packages ==
On http://apt.liberty-eiffel.org/ we have prepared some Debian/Ubuntu packages. For the quick start using the last stable release do:

* add the following repository (note: it is currently unsigned)
<nowiki>deb http://apt.liberty-eiffel.org/ release main</nowiki>

* then install (as root or with sudo)
apt-get install liberty-eiffel-all

That's it, you now can run "se c" to [[Tutorial_tour|compile your first program.]]

== Windows Installer ==
In the 2016 [[GSoC_-_Windows_Support|GSoC project]] Petru Gurita worked on a Windows installer using NSIS. His [https://github.com/petr00/Liberty-Eiffel-Windows repository] is hosted on GitHub.

Since October 2024, an installation script exists that loosely mimics the 'install.sh' script that is used on Linux based machines. The installation process is documented on a separate page: [[Installing on Windows using the Tiny-C compiler]]
This Windows cmd-script only assumes that you have a Tiny-C compiler installed - no need to download and run external installation packages.

== Bootstrap from tarball ==
Download the <release>.tar.gz from http://download.savannah.gnu.org/releases/liberty-eiffel
unpack it with
tar -zxvf <release>.tar.gz

bootstrap Liberty with
cd <release>
./install.sh -bootstrap

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:
PATH=$PATH:~/<release>/target/bin
export PATH

== Bootstrap from git source ==
On Linux (and most other Unix-like systems) installation of Liberty from source is simple:

Check that the following Pre-requisites are available on your system:
* git
* GCC compiler
* castxml (or GCC-XML)
* Boehm-Demers-Weiser garbage collector dev-packages

On debian-like systems you may install them with:
sudo apt-get install git build-essential castxml libgc-dev

On Fedora you'll need gc-devel, rather than libgc-dev, castxml and of course the basic packages for compiling like gcc, git etc.

Now clone the repository:
git clone git://git.sv.gnu.org/liberty-eiffel.git

Change into the directory you created by this:
cd liberty-eiffel

and execute
./install.sh -bootstrap

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:
PATH=$PATH:~/liberty-eiffel/target/bin
export PATH

'''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.
'''
Now you can call [[Se|se]] as interface for all tools. For examples go to
cd <LibertyHome>/tutorial
and compile with
se compile hello_world.e -o hello_world
your first Liberty Eiffel program.

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]].

Installing on Windows using the Tiny-C compiler

2024-10-28T09:15:31Z

Hzwakenberg: Created page with "= Installing Liberty Eiffel on Windows using the Tiny-C compiler = == Prerequisites == === Liberty Eiffel repository === The complete Liberty Eiffel source code repository can be downloaded from gnu’s git server. Install git on your machine if you haven’t done so already and simply use: “git clone git://git.sv.gnu.org/liberty-eiffel.git” This will create a directory called ‘liberty-eiffel’ and replicate the entire repository into it. Personally, I prefe..."

= Installing Liberty Eiffel on Windows using the Tiny-C compiler =

== Prerequisites ==

=== Liberty Eiffel repository ===
The complete Liberty Eiffel source code repository can be downloaded from gnu’s git server. Install git on your machine if you haven’t done so already and simply use:

“git clone git://git.sv.gnu.org/liberty-eiffel.git”

This will create a directory called ‘liberty-eiffel’ and replicate the entire repository into it. Personally, I prefer directory names to be a bit shorter, so for my case I renamed it to just ‘liberty’, see the screenshot that follows further below.
For those of you who don’t want to install ‘git’: it is possible to visit the mirrored Liberty Eiffel repository at GitHub and download the entire repository as a ZIP-file as well.

=== Tiny-C compiler ===
The installation script assumes that a working Tiny-C compiler (tcc) is installed and that your ‘path’ environment variable points to the tcc installation directory as well. If you think this is the case, simply open a command prompt and check whether tcc.exe can indeed be found, like I did for the following screenshot. Note that my current directory was C:\Liberty, where I copied the Liberty Eiffel repository to:

[[File:tcc-check-0.png|center|Is Tiny-C installed properly?]]

As you can see, tcc could be found and it reported back that it is version 0.9.27 (x86_64 Windows). This also means that the ‘path’ environment variable points to the correct Tiny-C installation directory, otherwise the compiler would not have been found.

=== Installation ===
Open a new command window and navigate to Liberty Eiffel's root installation directory.
This directory contains a cmd-file named '''win-install-tcc.cmd'''. Type this command into a CMD-window, like in the following screenshot:

[[File:tcc-check.png|center|Starting the installation cmd file]]

And then press the enter-key. The following screenshot documents what will happen on your machine:

[[File:Liberty-install-Windows.png|center|Installation process using Tiny-C]]

Note the time stamps on the output… Now is the time to grab a cup of coffee, or even a few, and then come back to read the remaining part of this document 😊
I’ll get back to the time stamps later on….

=== What does this installation script do? ===
'''The big picture?''' This script creates your Liberty Eiffel executables by compiling them from the original source code!

* First it verifies the installation prerequisites by creating a number of temporary files. Then it searches for your Tiny-C installation, which is why it was important to have your installation and your ‘path’ settings checked beforehand, as described above.

* Next, a configuration file is created. This ‘liberty.cfg’ file is used by the Eiffel compiler and other commands in the tool set. It is created in %USERPROFILE%. If you want ‘liberty.cfg’ to be readable for all users, you have to copy it manually to %ALLUSERSPROFILE% as well. You’ll need admin credentials to do this.

* Up next is the first real compilation: bootstrapping ‘compile_to_c’, the command used by most of the other Liberty Eiffel commands. As the name implies, this command takes an Eiffel source file or files and creates C-files from them. The C-sources for ‘compile_to_c’ itself are compiled into an initial version of ‘compile_to_c.exe’. I had Tiny-C emit some statistics about the size of the sources and the time it took to create an executable from it.

* This initial executable is then used to compile itself again from the original Eiffel sources. ‘compile_to_c.exe’ creates C-files, and these are again compiled by Tiny-C, resulting in yet another version of ‘compile_to_c.exe’. This bootstrapping cycle is repeated three times. The installation script provides a short message about each of these cycles, named T1, T2 and T3.

* The script continues with comparing the ‘compile_to_c.exe’ files from the T2 and T3 cycles. If they are binary equivalents, the T3-version is moved to the ..\bin directory. This is how the core compiler is bootstrapped and later used to compile the rest of the Liberty Eiffel commands. But before that, the script removes all temporary files and directories that were created for the bootstrapping process.

* Using the now stable version of ‘compile_to_c.exe’, the remaining commands are compiled. The corresponding executables are moved to ..\bin as well. Any temporary file created by the compilation process is removed (Liberty Eiffel provides the ‘clean’ command for that, which is used after that executable got created).

'''Now back to the time stamps I alluded to before:'''

Liberty Eiffel (and its predecessor too) were predominantly developed on Linux and a number of other Unix-derived operating systems. On these operating systems, the compilation tasks share multiple processor cores, making the installation rather swift. On Windows, we still need to work on the Eiffel code for ‘exec’ and a few other features to spawn separate processes. Until that is finished, it is not yet possible to have parallel compilation to create a single application.

'''The bottom line''': this installation script for Windows is a single-core sequential processing job, which is why it takes three to four times as long as on a comparable Linux machine. On my quad-core Xeon @ 4 GHz, it takes appr. an hour, but then again, only a single core is used for this job and my machine had other compute intensive tasks in the background as well…

If your installation process shows the ‘Finish:’ time stamp, you should have a working Liberty Eiffel environment on your Windows pc.

=== Looking for a small footprint code editor as well? ===
If you’re looking for a minimal footprint editor for your Eiffel endeavours on Windows as well, I recommend using Notepad++.

In your Liberty Eiffel ..\work directory, you’ll find a subdirectory called ‘notepad++_syntax-highlighting’. Within that directory, you’ll find a Liberty-Eiffel.xml file that can be imported in notepad++. It loosely implements the Eiffel formatting rules proposed by Bertrand Meyer. In this directory I also put a pdf-file to show what that looks like.

Good luck and happy Eiffeling….! 😉

File:Tcc-check-0.png

2024-10-28T09:08:47Z

Hzwakenberg:

File:Tcc-check.png

2024-10-28T09:03:49Z

Hzwakenberg:

File:Liberty-install-Windows.png

2024-10-28T08:58:54Z

Hzwakenberg:

Getting Started

2024-10-28T08:28:15Z

Hzwakenberg: /* Windows Installer */

== Prepared Debian/Ubuntu packages ==
On http://apt.liberty-eiffel.org/ we have prepared some Debian/Ubuntu packages. For the quick start using the last stable release do:

* add the following repository (note: it is currently unsigned)
<nowiki>deb http://apt.liberty-eiffel.org/ release main</nowiki>

* then install (as root or with sudo)
apt-get install liberty-eiffel-all

That's it, you now can run "se c" to [[Tutorial_tour|compile your first program.]]

== Windows Installer ==
In the 2016 [[GSoC_-_Windows_Support|GSoC project]] Petru Gurita worked on a Windows installer using NSIS. His [https://github.com/petr00/Liberty-Eiffel-Windows repository] is hosted on GitHub.

== Bootstrap from tarball ==
Download the <release>.tar.gz from http://download.savannah.gnu.org/releases/liberty-eiffel
unpack it with
tar -zxvf <release>.tar.gz

bootstrap Liberty with
cd <release>
./install.sh -bootstrap

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:
PATH=$PATH:~/<release>/target/bin
export PATH

== Bootstrap from git source ==
On Linux (and most other Unix-like systems) installation of Liberty from source is simple:

Check that the following Pre-requisites are available on your system:
* git
* GCC compiler
* castxml (or GCC-XML)
* Boehm-Demers-Weiser garbage collector dev-packages

On debian-like systems you may install them with:
sudo apt-get install git build-essential castxml libgc-dev

On Fedora you'll need gc-devel, rather than libgc-dev, castxml and of course the basic packages for compiling like gcc, git etc.

Now clone the repository:
git clone git://git.sv.gnu.org/liberty-eiffel.git

Change into the directory you created by this:
cd liberty-eiffel

and execute
./install.sh -bootstrap

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:
PATH=$PATH:~/liberty-eiffel/target/bin
export PATH

'''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.
'''
Now you can call [[Se|se]] as interface for all tools. For examples go to
cd <LibertyHome>/tutorial
and compile with
se compile hello_world.e -o hello_world
your first Liberty Eiffel program.

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]].

Bibliography

2024-09-05T12:18:05Z

Hzwakenberg: Added title to list

[[Category: Literature]]
__NOTOC__ 
==ETL 1992==
Bertrand Meyer.
''Eiffel: The Language''.
Prentice Hall, 1993, ISBN 0-13-247925-7.

==GC book==
Richar Jones and Rafael Lins.
''Garbage Collection. Algorithms for Automatic Dynamic Memory Management''.
John Wiley & Sons, ISBN 0-471-941484-4.

==GoF 1995==
Erich Gamma, Richard Helm and Ralph Johnson and John Vlissides.
''Design Patterns: Elements of Reusable Object-Oriented Software''.
Addisson-Wesley, Reading Massachusetts, 1995, ISBN 0201633612.

==Goldberg 1984==
Adele Goldberg.
''Smalltalk-80, The Interactive Programming Environment''.
Addisson-Wesley, Reading Massachusetts, 1984, ISBN 0-201-11372-4.

==GR 1983==
Adele Goldberg and David Robson.
''Smalltalk-80: The Language and its Implementation''.
Addison-Wesley, 1983, ISBN 0-201-11371-6.

==JMJ 1996==
Jean-Marc Jézéquel.
''Object-Oriented Software Engineering with Eiffel''.
Addison-Wesley, 1999, ISBN 0-201-63381-7. This book is a gentle introduction to Eiffel programming, without the academic verbosity of many of the other titles in this list.

==JTM 1999==
Jean-Marc Jézéquel, Michel Train and Christine Mingins.
''Design Patterns and Contracts''.
Addison-Wesley, 1999, ISBN 0-201-30959-9.

==MNCLT 1989==
Gérald Masini, Amédéo Napoli, Dominique Colnet, Daniel Léonard et Karl Tombre.
''Les langages à objets''.
InterEditions", Paris", 1989, ISBN 2-7296-0275-5.

==MNCLT 1991==
Gérald Masini and Amédéo Napoli and Dominique Colnet and Daniel Léonard and Karl Tombre.
''Object-Oriented Languages''.
Academic Press, New York, 1991, ISBN 0-12-477390-7.

==OOSC 1997==
Bertrand Meyer.
''Object-oriented Software Construction, 2nd Ed.''.
Prentice Hall 1997, 1254 pages, ISBN 0-13-629155-4.

==RMJM 2002==
Richard Mitchel and Jim McKim.
''Design by Contract, by Example''.
Adison-Wesley 2002, 238 pages, ISBN 0-201-63460-0. This title introduces a well structured and very thorough method of using DbC.

==TOCBM 2009==
Bertrand Meyer.
''TOUCH OF CLASS - Learning to program well with Objects and Contracts''.
Springer Verlag 2009, 876 pages, ISBN 978-81-322-0374-2. Unfortunately, this title assumes that you download supporting code and libraries, but the URL in the book is no longer valid.

==RS 1994==
Bertrand Meyer.
''Reusable Software: The Base Object-Oriented Component Libraries''.
Prentice Hall, 1994, 514 pages, ISBN-10: 013-245-499-8 ISBN-13: 978-013-245-499-5

==ECMA 367 / 2006==
ECMA International 2006.
''Eiffel: Analysis, Design and Programming Language''.
https://www.ecma-international.org/wp-content/uploads/ECMA-367_2nd_edition_june_2006.pdf

==SOOSA 2015==
Kim Waldén and Jean-Marc Nelson.
''Seamless Object-Oriented Software Architecture''.
Prentice Hall, 2015, 438 pages, ISBN 0-13-031303-3. This title is about BON (Business Object Notation), less so about the Eiffel language. BON as a method was developed by the authors of this book. BON is perceived to be simpler than the UML method.

==FUNCPTRN 1999==
Thomas Kühne.
''A Functional Pattern System for Object-Oriented Design''.
Verlag Dr. Kovac, 1999, 346 pages, ISBN 9783860647707. The thesis of this book is that design patterns inspired by functional programming concepts can advance object-oriented design. The code examples given are implemented with Eiffel. Some of the design patterns presented here are not current any more after the Eiffel language adopted 'agents', but the discussions about it are an excellent read nonetheless.

Related Projects

2024-08-06T20:53:14Z

Hzwakenberg: changed URL to LE-specific repository

Here a list of related projects with Liberty Eiffel:

= eiffel-iup =

A wrapper for the IUP toolkit. IUP is a multi-platform toolkit for building graphical user interfaces. IUP's purpose is to allow a program source code to be compiled in different systems without any modification. Its main advantages are:

* High performance, due to the fact that it uses native interface elements.
* Fast learning by the user, due to the simplicity of its API.

This wrapper is still under development, but is almost complete and we encourage you to use it and send feedback.

The project website is: [https://notabug.org/GermanGT/eiffel-iup/src/liberty-eiffel]

Tecgraf's IUP (currently in version 3.31) site: [https://www.tecgraf.puc-rio.br/iup/ Tecgraf IUP]

This package is released under the MIT license.

Introduction

2024-07-30T16:43:54Z

Hzwakenberg:

__NOTOC__
Liberty Eiffel is a free compiler for the Eiffel programming language

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.

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.

Eiffel is an advanced object-oriented programming language that emphasizes the design and construction of high-quality and reusable software.

If you are impatient hop over to [[Getting Started]] directly, otherwise read a few words about Liberty Eiffel's history:

= Liberty's roots =

== Etymology ==

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.

The origins of the language is [http://www.eiffel.com Eiffel] and more specifically [http://smarteiffel.loria.fr SmartEiffel], hereafter called '''SE'''. At one point in time one could consider Liberty Eiffel a direct [http://en.wikipedia.org/wiki/Fork_(software_development) fork] of the legacy SE code base. Since then Liberty Eiffel has evolved quite significantly beyond the original code base in multiple areas.

== Manifesto ==

We want to retain from SE its rigour, but not its rigidity. Think of Liberty as ''SE liberated from its academic constraints''.

Liberty Eiffel is free as in ''freedom''. We want people to contribute to Liberty from the start. So please, do join us to give Eiffel the leading position it should have won twenty years ago :-)

== Foundation documents ==

The following documents were published by the SmartEiffel team:

* [http://www.jot.fm/issues/issue_2004_04/article7/ Conformance of agents in the Eiffel language]
* Reconciling Subtyping and Code Reuse in Object-Oriented Languages

= Liberty Eiffel's future =
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].

== Release names ==
See [[Versions history|list of released versions]] and [[Upcoming releases]].

== Liberty Eiffel Community ==
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.

==Origins of Liberty Eiffel's predecessor==

During the course of his work on his thesis, [[User:Colnet|Dominique Colnet]], principal author of the legacy SmartEiffel system, discovered the Eiffel language while editing an encyclopedic work on object oriented languages
([[Bibliography#MNCLT 1989|[MNCLT 1989]]], [[Bibliography#MNCLT 1991|[MNCLT 1991]]]).

Holding the post of Assistant Professor of Computer Science in 1989, the Powers That Be at his educational institution at the time (1990) decided to use the Eiffel language for introductory computer science.
It is amusing to mention here that Dominique Colnet was at the time a fervent defender of Smalltalk.
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.
So, it is amusing to note that Dominique Colnet was forced to use Eiffel against his will in 1990!

In order to reconcile his teaching and research work on the compilation of object oriented languages, Dominique Colnet decided 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 - which actually started in 1994 when he decided to write his own Eiffel compiler.

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]]],
[[Bibliography#Goldberg 1984|[Goldberg 1984]]]).
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.
The new compiler was named ''SmallEiffel'' to make reference to both Smalltalk
and Eiffel ([[Bibliography#OOSC 1988|[OOSC 1988]]], [[Bibliography#ETL 1992|[ETL 1992]]]).
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
[[versions_history|thirty versions]] have seen the light of day.

==Little SmartEiffel developing into something bigger?==
Starting out as simple research prototype and teaching aid in 1995, SE saw its capabilities steadily increase from version to version.

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.

<div id="EcmaEiffel">
From 2002 and up to 2005, Dominique Colnet participated actively in meetings with the initial objective of standardizing the Eiffel language
('''ECMA''' standards committee TC39-TG4, ECMA standard number 367).
Of course it goes without saying that the entire SE-team was associated with the standards work and its many long discussions...

Finally, in May 2005, the SE-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 had diverged from what was conventionally called Eiffel. ECMA-Eiffel is a very different language, and above all, not yet experimented. The SE-team decided to never implement ECMA TC39-TG4.
'''Note:''' In this respect the Liberty Eiffel development team is<br> not as strict as the original SE-developers used to be.<br> See [[ECMA]] about Liberty's attitude to ECMA.
</div>

In July 2005, at the time when these lines got written, after more than 10 years of work not only on the compiler but also on the Eiffel language itself, the SE-team considered that the Eiffel language as they knew it contained nearly all desirable features.
Therefore, version 2.2 of SE marked the debut of a new level of stability and corresponded to what the team thought of as being the ''true Eiffel language''.

Comparison of objects

2024-07-30T15:41:57Z

Hzwakenberg:

==Comparing two objects==
How to compare two objects is a problem that has to be mastered fairly quickly, for it is a very common problem posed in many, if not '''almost all applications'''.

In Eiffel, as in most object-oriented languages, there are several ways to compare two objects, whether by comparing their respective addresses or by comparing the information contained in each of the two objects. In other words, using Eiffel terminology, one must choose whether to use [[#EqNeq|the predefined = operator]] or the redefinable [[#is_equal|<TT>is_equal</TT>]] routine.

Because the Eiffel language aims, as far as possible, to prevent careless mistakes, it is not possible to compare just any type of expression with any other type of expression. The [[#ValidComparison|validity of a comparison]] will be explained in detail below.

Finally, just for completeness, this part will also discuss the possibility of carrying out a third sort of comparison, [[#is_deep_equal|deep equality]], a comparison reserved only for a very rare family of applications.
<div id="EqNeq">

==Comparison using the operators <TT>=</TT> or <TT>/=</TT>==
</div>
Let there be two variables <TT>point_a</TT> and <TT>point_b</TT>,
both of type <TT>POINT</TT>.
Let us suppose that these two variables have been initialised with
something other than [[Void|<tt>Void</tt>]].
The following code fragment shows a possible usage of the
predefined <tt>=</tt> comparison operator:
if point_a = point_b then
io.put_string("We have a single, unique POINT !")
else
io.put_string("We have two POINTs at different memory locations.")
end
The <TT>=</TT> operator is the fundamental building block for
comparison.
In the case of a reference type, it corresponds simply to the direct comparison of
the two addresses;
what the two addresses point to is not considered.
If our two variables <TT>point_a</TT> and <TT>point_b</TT> actually designate
a single, unique <TT>POINT</TT> in memory, then the test above evaluates to true.
Once there are two distinct <TT>POINT</TT>s in memory,
then the test is false even if the two <TT>POINT</TT>s seem exactly identical,
in the debugger, for example, or when printed.

Note that we also have the <TT>/=</TT> operator, which corresponds to the
negation of the <TT>=</TT> operator.
The <TT>/=</TT> operator is also predefined and is simply a shortcut to avoid
having to use <TT>not</TT> for negation.
So to test whether a reference variable refers to an object, the usage is:
if point /= Void then
io.put_string("The variable point refers to a POINT!")
else
io.put_string("The variable point does not refer to any object.")
end
When comparing variables of an expanded type, the effect of the <TT>=</TT> and
<TT>/=</TT> operators is simply to compare the values in question.
For two variables of type <TT>INTEGER</TT>, that boils down to comparing the two numbers:
if integer_a = integer_b then
io.put_string("integer_a is the same value as integer_b!")
else
io.put_string("The two values are different.")
end

The essential details about the <TT>=</TT> and <TT>/=</TT> predefined operators have
now been clearly explained above, at least, so we hope.
If you are reading this to find out about comparison methods, go straight to the
section on [[#is_equal|<TT>is_equal</TT>]].
Otherwise, continue to the next section for additional information about
these two predefined operators.

<div id="EqNeqOnExpanded">

==The <TT>=</TT> and <TT>/=</TT> operators with expanded types==
</div>
The <TT>=</TT> and <TT>/=</TT> operators, apart from being predefined, are '''non-redefinable''' operators. The effect of <TT>=</TT> and <TT>/=</TT> is completely fixed in the compiler's internals.

When comparing two expressions of a reference type with the <TT>=</TT> or <TT>/=</TT> operators, as has already been mentioned above, only the two addresses are compared. Now let us see what happens when the two compared expressions are of an expanded type.

Comparing two expanded expressions using <TT>=</TT> simply comes down to comparing, at the lowest level, bit by bit, the two areas of memory corresponding to the two objects. Of course, the expanded type used on the left of the <TT>=</TT> operator must be compatible with the expanded type used on the right. Indeed, apart from some [[#ExceptionalRules|rare exceptions]] which we will go into later, a comparison is accepted only when the two expanded types are exactly the same. It is obviously possible to compare two expressions of type
[[library_class:CHARACTER|<tt>CHARACTER</tt>]] with each other; and, for example, to compare two expressions of type [[library_class:INTEGER|<tt>INTEGER</tt>]] with each other. In order to avoid any careless mistakes, however, directly comparing a [[library_class:CHARACTER|<tt>CHARACTER</tt>]] with an [[library_class:INTEGER|<tt>INTEGER</tt>]] is forbidden. In the latter case, it is up to the program's designer to make a call to the appropriate conversion routine. There are multiple possibilities, perhaps to convert the <tt>INTEGER</tt> expression into a <tt>CHARACTER</tt>, or, contrariwise,
to convert the <tt>CHARACTER</tt> expression into an <tt>INTEGER</tt>. In both cases there are many possible conversion routines. Several routines exist, for example, to convert from <tt>CHARACTER</tt> to <tt>INTEGER</tt>. Here are two such examples, among many others:
if my_character.to_integer = my_integer then
io.put_string("Conversion with possible sign extension.")
end
and again:
if my_character.decimal_value = my_integer then
io.put_string("Conversion using the value of the corresponding number.")
end
Thus, it seems completely impossible to automate the choice of conversion that should be applied before the comparison. It depends entirely on the context of the comparison, on the problem being dealt with, and this choice must be made manually by the program's designer. The strict rule, to allow the comparison of two expanded objects only when they have exactly the same type, is indeed the simplest and safest. Thus, if the compiler rejects your comparison expression, read the error message carefully and choose the most appropriate conversion with care. That being said, two exceptions to this very strict rule remain, probably for historical reasons.

<div id="ExceptionalRules">
The two exceptions concern two special cases that '''leave no doubt''' thanks to the fact that the expanded objects concerned are very elementary. The first exception to the strict rule, requiring two expanded types to be identical, concerns the case of two objects taken from the set <tt>{</tt>[[library_class:INTEGER_8|<tt>INTEGER_8</tt>]], [[library_class:INTEGER_16|<tt>INTEGER_16</tt>]], [[library_class:INTEGER_32|<tt>INTEGER_32</tt>]], [[library_class:INTEGER|<tt>INTEGER</tt>]], [[library_class:INTEGER_64|<tt>INTEGER_64</tt>]]<tt>}</tt>. Comparison using <tt>=</tt> is true if and only if the two values correspond to exactly the same integer value. In fact, without any loss of information, it is always possible to represent in 16 bits any number that is represented in 8 bits; and so on and so forth. This exception to the ''hard and fast rule'' therefore lets us write simply and without risk:
if my_integer_8 = my_integer_16 then ...
Knowing that, it is as if we had written:
if my_integer_8.to_integer_16 = my_integer_16 then ...
</div>

The second and last exception is similar to the preceding one and concerns the following set of expanded types: <tt>{</tt>[[library_class:REAL_32|<tt>REAL_32</tt>]], [[library_class:REAL_64|<tt>REAL_64</tt>]], [[library_class:REAL|<tt>REAL</tt>]], [[library_class:REAL_80|<tt>REAL_80</tt>]], [[library_class:REAL_128|<tt>REAL_128</tt>]], [[library_class:REAL_EXTENDED|<tt>REAL_EXTENDED</tt>]]<tt>}</tt>. Like the integers, for the set of floating point numbers in question, it is always possible to convert a given floating point number to a bigger number of bits without any loss of information. Thus, a comparison expression using <tt>=</tt> or <tt>/=</tt> can mix two types taken from the <tt>REAL_*</tt> family.

Note, finally, that it is forbidden to compare directly any object from the <tt>REAL_*</tt> family with any object from the <tt>INTEGER_*</tt> family. If you find yourself having to make such a comparison, which is not illogical, it is up to you to decide which conversion routine is appropriate to your needs. The Eiffel language has no rule that could decide this for you.

<div id="is_equal">

==The redefinable <tt>is_equal</tt> routine==
</div>
The redefinable <tt>is_equal</tt> routine provides a more sophisticated comparison than using [[#EqNeq|the predefined = operator]]. Consider once again our example of comparing two variables of type <tt>POINT</tt>, but this time let us use <tt>is_equal</tt>. As in the case above, let us suppose for the moment that the two variables <tt>point_a</tt> and <tt>point_b</tt> are initialised with something other than [[Void|<tt>Void</tt>]]:
if point_a.is_equal(point_b) then
io.put_string("Either they are both the same POINT or else they are 2 identical POINTs.")
else
io.put_string("They are two different POINTs.")
end
In a given class, if the <tt>is_equal</tt> routine has not been redefined by the user, the behaviour of <tt>is_equal</tt> is to compare all attributes of the two objects with each other. That means, for the <tt>POINT</tt> example, successively comparing the two <tt>x</tt> attributes and then the two <tt>y</tt> attributes. In other words, it is as if we had written:
if (point_a.x = point_b.x) and (point_a.y = point_b.y) then
io.put_string("Either they are both the same POINT or else they are 2 identical POINTs.")
else
io.put_string("They are two different POINTs.")
end
See how the comparison between attributes does not use <tt>is_equal</tt>, but the basic fixed <tt>=</tt> operator. The following diagram presents a picture of the possible memory contents during comparison of <tt>point_a</tt> and <tt>point_b</tt>. Note that in the following case, these two <tt>POINT</tt>s situated in two memory locations are identical and, consequently, comparison using <tt>is_equal</tt> will return <tt>True</tt>:

[[Image:IsEqualPoints.png|is_equal with some POINTs]]

In the example above, the two objects that are being compared are both instances of the <tt>POINT</tt> class: very simple objects. As the diagram shows, a <tt>POINT</tt> is composed of two expanded attributes, or, more precisely, the attributes <tt>x</tt> and <tt>y</tt> of type [[library_class:REAL|<tt>REAL</tt>]], a primitive expanded type (i.e. without an intermediate pointer). In this case the default definition of the <tt>is_equal</tt> function fits perfectly.

Before describing <tt>is_equal</tt> any further, let us make it clear that <tt>is_equal</tt> can be used when the type of the two compared
objects is expanded. For example, with [[library_class:INTEGER|<tt>INTEGER</tt>]]s, the result of a comparison using the predefined <tt>=</tt> operator has exactly the same effect as using the <tt>is_equal</tt> routine. Note however that using <tt>is_equal</tt> is quite unusual when the two operands are expanded, especially if it is a basic expanded type like [[library_class:INTEGER|<tt>INTEGER</tt>]], [[library_class:CHARACTER|<tt>CHARACTER</tt>]], [[library_class:REAL|<tt>REAL</tt>]] or [[library_class:BOOLEAN|<tt>BOOLEAN</tt>]]. In general, by convention and especially for the sake of simplicity, <tt>=</tt> and <tt>/=</tt> are preferred for primitive expanded types.

As soon as the objects are more complex, with for example some attributes that themselves point towards other objects, it is necessary to pay attention to the predefined behaviour of the <tt>is_equal</tt> function. Consider for example the case of comparing two <tt>TRIANGLE</tt>s, as in the following diagram:

[[Image:IsEqualTriangles.png|is_equal with some TRIANGLEs]]

Both objects of class <tt>TRIANGLE</tt> in the diagram above are identical but if one proceeds to compare them using the predefined <tt>is_equal</tt> routine the result will be <tt>False</tt>! In fact, let us emphasise that <tt>triangle_a</tt> and <tt>triangle_b</tt> designate, even if they are similar, two distinct objects in memory. Indeed, if the <tt>is_equal</tt> function has not been redefined in the <tt>TRIANGLE</tt> class, the comparison of <tt>triangle_a</tt> and <tt>triangle_b</tt> using <tt>is_equal</tt>, in other words the [[Glossary#Expression|expression]]:

triangle_a.is_equal(triangle_b)

is equivalent to the expression:

(triangle_a.p1 = triangle_b.p1) and (triangle_a.p2 = triangle_b.p2) and (triangle_a.p3 = triangle_b.p3)

The expression above corresponds to the predefined behaviour of <tt>is_equal</tt>. In order to obtain a more useful comparison function, it is up to the designer of the <tt>TRIANGLE</tt> class to think of how to alter the predefined definition by redefining <tt>TRIANGLE</tt>'s <tt>is_equal</tt> function like this:

is_equal (other: TRIANGLE): BOOLEAN is
do
Result := p1.is_equal(other.p1) and p2.is_equal(other.p2) and p3.is_equal(other.p3)
end

It is very hard to imagine how a ''good function'' for comparison could be defined automatically. In particular, it is not always enough to call <tt>is_equal</tt> again on the attributes, as in the <tt>TRIANGLE</tt> case, rather than using <tt>=</tt>. (To convince youself of this, see the [[library_class:STRING|<tt>STRING</tt>]] and [[library_class:ARRAY|<tt>ARRAY</tt>]] classes as examples.) Thus, since we do not know how to automate this task with a language rule or by adding a strong dose of intelligence to the compiler, the job belongs solely to the designer of the class. The conscientious class designer must ensure that the <tt>is_equal</tt> function behaves properly for objects of that class. The default behaviour described above has been chosen for its simplicity, because it is is for the most part suitable as a ''good'' comparison function and also because it is implemented easily in low level machine instructions that are very fast (comparison instructions for two memory blocks).

<div id="ValidComparison">

==Comparison validity==
</div>
Do not look for the definition of the [[#EqNeq|<tt>=</tt> and <tt>/=</tt>]]
comparison operators in the Eiffel classes' source
code, because these two operators are predefined and their definition is deliberately fixed in the compiler's internals.
Since one of the goals of the Eiffel language is to limit the possibility of careless errors,
it would not be reasonable to allow just any comparison (that is, to allow all mixtures, like
comparing a <tt>LORRY</tt> with a
<tt>FLOWER</tt>, to take an extreme example).
The [[Glossary#StaticType|static types]] of two [[Glossary#Expression|expressions]] to be
compared must conform to certain constraints.
Of course -- and this is the usual case -- when the two expressions are of the same
[[Glossary#StaticType|static type]], the comparison is obviously allowed.
It is always possible to compare two expressions with the same static type using the comparison operators [[#EqNeq|<tt>=</tt> and <tt>/=</tt>]].

As soon as the two expressioms are not of the same static type, they have to conform to the following general rule.
A comparison of the form:
x = y
or again:
x /= y
is valid if it is possible to assign <tt>x</tt> to <tt>y</tt> or vice versa.
More precisely, seeing that <tt>x</tt> and <tt>y</tt> are not necessarily variables, either the static type of <tt>x</tt> is acceptable for an assignment to the static type of <tt>y</tt> or else the static type of <tt>y</tt> is acceptable for an assignment to the static type of <tt>x</tt>.

The foregoing validity rule helps to check whether the program designer is writing a ''reasonable comparison''.
From experience, we have established that this rule, guided by common sense, is crucial for detecting upstream errors,
which are often careless mistakes.

In a few ''uncommon and often obscure'' cases, this rule can perhaps be found to be too restrictive.
If you should find yourself in the situation where the compiler is rejecting your comparison but nevertheless you genuinely think that comparing the two expressions is desirable, you can achieve your ends by using two local variables with a more general static type (ultimately, you can use type [[library_class:ANY|<tt>ANY</tt>]]).

To conclude this section on the general verification rule for comparisons with the
[[#EqNeq|<tt>=</tt> and <tt>/=</tt>]] operators,
let us remember that the rule just declared above also includes the [[#ExceptionalRules|previously mentioned case]] concerning the comparison of two expressions of type <tt>INTEGER_*</tt> or of type <tt>REAL_*</tt>.
For example, it is possible to assign an expression of type
[[library_class:INTEGER_16|<tt>INTEGER_16</tt>]] to a variable of type [[library_class:INTEGER_32|<tt>INTEGER_32</tt>]].
A comparison between an expression of type
[[library_class:INTEGER_16|<tt>INTEGER_16</tt>]] and one of type
[[library_class:INTEGER_32|<tt>INTEGER_32</tt>]] is therefore valid.

<div id="is_deep_equal">

==Comparison using <tt>is_deep_equal</tt>, the fixed method==
</div>
Just for the sake of completeness in this section on comparing objects, let us finally be aware that the [[library_class:ANY|<tt>ANY</tt>]] class offers the possibility of a deep comparison of two objects: the <tt>is_deep_equal</tt> function.
The attributes of the two objects to be compared are themselves compared with the <tt>is_deep_equal</tt> function and so on recursively.
This function recursively checks that the two objects are structurally identical.
Note that it is sometimes possible to have an endless loop in the object graph, for example when comparing two linked lists with a circular structure.
In order to be considered identical by <tt>is_deep_equal</tt>, it must be possible to superimpose the graph of the two objects.

The definition of the <tt>is_deep_equal</tt> function is fixed in the [[library_class:ANY|<tt>ANY</tt>]] class.
The <tt>is_deep_equal</tt> function must be used with care because it depends entirely on the implementation of the objects which it is comparing.
In fact, as a general rule, it is always preferable to avoid using the <tt>is_deep_equal</tt> function.

Clean

2024-07-30T15:39:58Z

Hzwakenberg:

[[Category:Tool]]

= Usage =
se clean [options] <Root-Name> ...
Command clean removes all intermediate files produced by previous compile, or compile_to_c runs.
Names (<Root-Name> ...) can have the Eiffel suffix, no suffix at all, or the suffix used for Liberty Eiffel command files on your system (.make on UNIX or .BAT on Windows, for example).

= Options =
-help:

Display a brief summary of the command-line syntax and a complete list of finder options.

-no_remove:

Print the name of files that would be removed, but do not remove them.e.

-verbose:

Print system information during the compilation (full path of loaded files, type inference score, removed files, etc.).

-version:

Show the number of the version of Liberty Eiffel you're using.

= Examples =
== Example 1 ==
To remove intermediate files produced for the HELLO_WORLD program.
Type: clean hello_world
You can also type: clean hello_world.e
or you can also type: clean HELLO_WORLD
on Unix, you can type: clean hello_world.make
on Windows, you can do: clean hello_world.BAT

== Example 2 ==
Under Unix or Windows, remove all intermediates files in the current directory : clean *.e

If the root class file is not in the current directory, you can type (for Unix) : clean *.make

Option -verbose can be used to see which files are removed.

Clean

2024-07-30T15:39:31Z

Hzwakenberg:

[[Category:Tool]]

= Usage =
se clean [options] <Root-Name> ...
Command clean removes all intermediate files produced by previous compile, or compile_to_c runs.
Names (<Root-Name> ...) can have the Eiffel suffix, no suffix at all, or the suffix used for Liberty Eiffel command files on your system (.make on UNIX or .BAT on Windows, for example).

= Options =
-help:

Display a brief summary of the command-line syntax and a complete list of finder options.

-no_remove:

Print the name of files that would be removed, but do not remove them.e.

-verbose:

Print system information during the compilation (full path of loaded files, type inference score, removed files, etc.).

-version:

Show the number of the version of LibertyEiffel you're using.

= Examples =
== Example 1 ==
To remove intermediate files produced for the HELLO_WORLD program.
Type: clean hello_world
You can also type: clean hello_world.e
or you can also type: clean HELLO_WORLD
on Unix, you can type: clean hello_world.make
on Windows, you can do: clean hello_world.BAT

== Example 2 ==
Under Unix or Windows, remove all intermediates files in the current directory : clean *.e

If the root class file is not in the current directory, you can type (for Unix) : clean *.make

Option -verbose can be used to see which files are removed.

Lib/xml

2024-07-30T15:38:55Z

Hzwakenberg:

[[Category: Library]]
== XML parsing ==

XML is used a lot these days, even by the library itself (the [[library_class:STORABLE|storable]] [[library_class:REPOSITORY|repository]] uses it, see [[lib/storage]]).

=== The parser ===

To use the XML parser, you need to proceed in two steps:
# Connect the parser to an [[library_class:OUTPUT_STREAM|output stream]], using the <tt>[[library_class:XML_PARSER|XML_PARSER]].connect_to</tt> feature;
# 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).

=== Events interface ("SAX") ===

[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.

In this case, you have to inherit from [[library_class:XML_CALLBACKS|<tt>XML_CALLBACKS</tt>]] and implement its many deferred features.

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.

=== Tree interface ("DOM") ===

[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.

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.

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>]].

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.

=== Small Comparison SAX vs. DOM ===

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.

{| cellspacing="10px" width="100%"
|- style="background-color: #fff3f3"
|valign="top" align="center"| Topic
|valign="top" align="center"| '''DOM'''
|valign="top" align="center"| '''SAX'''
|-
|valign="center" align="center" style="background-color: #fff3f3"| Simplicity
|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.
|valign="top"|Less simple: the parser provides a stream of events that have to be dealt with.
On the other hand you have more control over which events are important and what you actually ''do'' with them.
|-
|valign="center" align="center" style="background-color: #fff3f3"| Memory
|valign="top"|Memory hungry since objects are built to represent the whole tree
|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.
|-
|valign="center" align="center" style="background-color: #fff3f3"| Performance
|valign="top"|The XML document is used in two passes:
# create the tree (parse the whole document)
# use the tree (navigate in the tree to find nodes of interest)
|valign="top"|The XML document may be exploited in one pass since you have first-hand access to the events during the parsing.
|}

== Validation ==

To validate an XML file, Liberty Eiffel provides a DTD parser. The XML parser may parse the provided DTD and validate your file.

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>]]).

== Namespaces and other advanced features ==

Namespaces are not yet natively implemented in Liberty Eiffel, but they will be added later ('''contributions welcome!!''')

The idea is to implement some new kind of XML_CALLBACK that takes the semicolon in nodes names into account.

Schema validation (therefore using namespaces) may be set by calling <tt>[[library_class:XML_CALLBACKS|XML_CALLBACKS]].set_validator</tt>.

Path parsing has to be implemented.

Lib/xml

2024-07-30T15:37:21Z

Hzwakenberg:

[[Category: Library]]
== XML parsing ==

XML is used a lot these days, even by the library itself (the [[library_class:STORABLE|storable]] [[library_class:REPOSITORY|repository]] uses it, see [[lib/storage]]).

=== The parser ===

To use the XML parser, you need to proceed in two steps:
# Connect the parser to an [[library_class:OUTPUT_STREAM|output stream]], using the <tt>[[library_class:XML_PARSER|XML_PARSER]].connect_to</tt> feature;
# 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).

=== Events interface ("SAX") ===

[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.

In this case, you have to inherit from [[library_class:XML_CALLBACKS|<tt>XML_CALLBACKS</tt>]] and implement its many deferred features.

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.

=== Tree interface ("DOM") ===

[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.

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.

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>]].

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.

=== Small Comparison SAX vs. DOM ===

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.

{| cellspacing="10px" width="100%"
|- style="background-color: #fff3f3"
|valign="top" align="center"| Topic
|valign="top" align="center"| '''DOM'''
|valign="top" align="center"| '''SAX'''
|-
|valign="center" align="center" style="background-color: #fff3f3"| Simplicity
|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.
|valign="top"|Less simple: the parser provides a stream of events that have to be dealt with.
On the other hand you have more control over which events are important and what you actually ''do'' with them.
|-
|valign="center" align="center" style="background-color: #fff3f3"| Memory
|valign="top"|Memory hungry since objects are built to represent the whole tree
|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.
|-
|valign="center" align="center" style="background-color: #fff3f3"| Performance
|valign="top"|The XML document is used in two passes:
# create the tree (parse the whole document)
# use the tree (navigate in the tree to find nodes of interest)
|valign="top"|The XML document may be exploited in one pass since you have first-hand access to the events during the parsing.
|}

== Validation ==

To validate an XML file, Liberty Eiffel provides a DTD parser. The XML parser may parse the provided DTD and validate your file.

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>]]).

== Namespaces and other advanced features ==

Namespaces are not yet natively implemented in Liberty Eiffel, but they will be added later ('''contributions welcome!!''')

The idea is to implement some new kind of XML_CALLBACK that takes the semi-colon in nodes names into account.

Schema validation (therefore using namespaces) may be set by calling <tt>[[library_class:XML_CALLBACKS|XML_CALLBACKS]].set_validator</tt>.

Path parsing has to be implemented.

Tools

2024-07-30T12:29:01Z

Hzwakenberg:

[[Category: Tool]]
Liberty Eiffel provides many tools besides the [[compile|compiler]].

All these tools use the [[configuration file]].

== The tools ==

=== Toolbox ===

* [[se]]: a facade to all those tools

=== Compiling ===

* [[clean]]: remove temporary C files after compilation
* [[compile]]: the compiler (calls [[compile_to_c]])
* [[compile_to_c]]: the C compiler core
* [[extract_internals]]: the tentative inter-program object sharing tool
* [[Wrapping_C_libraries|wrappers_generator]]: a tools to generate low-level Eiffel wrappers for C code

=== Searching and documenting ===

* [[eiffeldoc]]: generates the whole documentation of a project
* [[finder]]: finds a class
* [[pretty]]: makes your source file pretty
* [[short]]: generates the interface documentation of a single class

=== Testing ===

* [[ace_check]]: checks an [[ACE|ACE file]]
* [[class_check]]: checks the [[parsing|syntax]] and the [[semantics]] of a source code
* [[eiffeltest]]: the Liberty Eiffel testing tool
* [[mock]]: the Liberty Eiffel mock tool

=== Installing ===

* [[install]]: installs the Liberty Eiffel tools

== The system core ==

If you are interested in how the system works, either by sheer curiosity, or because you want to modify it, here are some explanations.

If you want to create a new Liberty Eiffel-oriented tool, this information is important too; also look at [[tool_class:EXTERNAL_TOOL|<tt>EXTERNAL_TOOL</tt>]].

* [[class loading]]
* [[parsing|syntactic analysis]]
* [[semantics|semantic analysis]]
* the [[optimizer]]
* the [[visitor|visitors]]
* code generation
** [[compile_to_c#Generation|compile_to_c]]
** [[compile_to_jvm#Generation|compile_to_jvm (obsolete)]]

Lib/sequencer offers Multitasking

2024-07-30T12:28:00Z

Hzwakenberg:

[[Category: Library]]
The <tt>lib/sequencer</tt> library implements an event-driven, priority-based, cooperative multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative multitasking, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. The sequencer library does it this way to retain conformance to Eiffel principles.

The sequencer library concepts:

* the class [[library_class:LOOP_STACK|<tt>LOOP_STACK</tt>]] manages the multitasking;
* the class [[library_class:JOB|<tt>JOB</TT>]] represents a task. The task core is the <tt>continue</tt> feature, during the execution of which the task controls the whole system;
* the class [[library_class:EVENTS_SET|<tt>EVENTS_SET</tt>]] describes the condition(s) in which a task can be executed.

We will successively document each of these concepts:

== The multitasking manager ==
The class [[library_class:LOOP_STACK|<tt>LOOP_STACK</tt>]] is in charge of managing the multitasking. It is used in two steps:
* initialization: creation of the <tt>LOOP_STACK</tt> object and adding the task(s) to be executed
* execution: execution of the <tt>run</tt> feature

Of course, additional tasks can be added during the execution. The manager can also be stopped, thanks to the <tt>break</tt> feature.

Note that the loop stack contains many execution loops ([[library_class:LOOP_ITEM|<tt>LOOP_ITEM</tt>]]). This allows, for instance, the implementation of a kind of ''modality'' (e.g. the modal windows in [[lib/vision|Vision]]).

== Tasks ==

A task has a life cycle represented by the features executed by the manager (indeed a [[library_class:LOOP_ITEM|<tt>LOOP_ITEM</tt>]] hence the export clauses of those features).

# <tt>prepare</tt> allows preparing the task; in this phase, the task sets the events upon which it wants to be activated. The [[library_class:EVENTS_SET|<tt>EVENTS_SET</tt>]] object is an object upon which one can set conditions (thanks to its <tt>expect</tt> feature).
# <tt>is_ready</tt> allows testing if the task has really been activated. The [[library_class:EVENTS_SET|<tt>EVENTS_SET</tt>]] object is an object upon which one can test conditions (thanks to its <tt>event_occurred</tt> feature).
# <tt>continue</tt> contains the execution body of the task, and is executed upon task activation.
# <tt>done</tt> tells if the task has finished its execution. If so, it will be removed from the execution loop. Otherwise, the cycle begins again.
# <tt>restart</tt> allows reinserting a task in the execution loop.

The <tt>restart</tt> feature is seldom useful. See [[lib/vision|Vision]] for some use cases.

== Execution conditions ==

The class [[library_class:EVENTS_SET|<tt>EVENTS_SET</tt>]] allows setting and test conditions ([[library_class:EVENT_DESCRIPTOR|<tt>EVENT_DESCRIPTOR</tt>]]s).

The possible conditions are:

* '''Time''': this allows to create periodic tasks. See the classes [[library_class:PERIODIC_JOB|<tt>PERIODIC_JOB</tt>]], [[library_class:BACKGROUND_JOB|<tt>BACKGROUND_JOB</tt>]], and [[library_class:TIME_EVENTS|<tt>TIME_EVENTS</tt>]];
* '''Input-output''':
** ''Data on an input stream'': this allows to build tasks that wait for input data to be available (feature [[library_class:INPUT_STREAM|<tt>INPUT_STREAM</tt>]]<tt>.event_can_read</tt>),
** ''Data on an output stream'': this allows to build tasks that wait until they can write on an output stream (feature [[library_class:OUTPUT_STREAM|<tt>OUTPUT_STREAM</tt>]]<tt>.event_can_write</tt>);
* '''Network''': this allows to build tasks waiting network connections (feature [[library_class:SOCKET_SERVER|<tt>SOCKET_SERVER</tt>]]<tt>.event_connection</tt>).

== Tasks scheduling ==

The manager implements the following cycle:

* call to the feature [[library_class:EVENTS_SET|<tt>EVENTS_SET</tt>]]<tt>.reset</tt>;
* call to the feature [[library_class:JOB|<tt>JOB</tt>]]<tt>.prepare</tt> on each task;
* call to the feature [[library_class:EVENTS_SET|<tt>EVENTS_SET</tt>]]<tt>.wait</tt> to wait for at least one condition to happen;
* call to the feature [[library_class:JOB|<tt>JOB</tt>]]<tt>.is_ready</tt> on each task;
* for all the ready tasks, call to the feature [[library_class:JOB|<tt>JOB</tt>]]<tt>.continue</tt>;
* for those tasks, call to the feature [[library_class:JOB|<tt>JOB</tt>]]<tt>.done</tt> and if relevant, remove the task;
* and back to the beginning.

== Priorities ==

Tasks execution is by priority order. Only the ready task with the ''lowest'' priority is executed. All other tasks, even if ready, will have to wait until no other task with a lower priority is ready.

-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Apparently '''not''' by evaluating the duration of the<br> wait for next execution, see the '''LOOP_ITEM.run''' method. /HZ

== Libraries using the sequencer ==

* [[lib/net]]: servers usually allow many simultaneous connections. This is implemented with the sequencer library.

* [[lib/vision]]: the event manager loop is implemented with a sequencer.

Comparison of objects

2024-07-30T12:26:34Z

Hzwakenberg:

==Comparing two objects==
How to compare two objects is a problem that has to be mastered fairly quickly, for it is a very common problem posed in many, if not '''almost all applications'''.

In Eiffel, as in most object-oriented languages, there are several ways to compare two objects, whether by comparing their respective addresses or by comparing the information contained in each of the two objects. In other words, using Eiffel terminology, one must choose whether to use [[#EqNeq|the predefined = operator]] or the redefinable [[#is_equal|<TT>is_equal</TT>]] routine.

Because the Eiffel language aims, as far as possible, to prevent careless mistakes, it is not possible to compare just any type of expression with any other type of expression. The [[#ValidComparison|validity of a comparison]] will be explained in detail below.

Finally, just for completeness, this part will also discuss the possibility of carrying out a third sort of comparison, [[#is_deep_equal|deep equality]], a comparison reserved only for a very rare family of applications.
<div id="EqNeq">

==Comparison using the operators <TT>=</TT> or <TT>/=</TT>==
</div>
Let there be two variables <TT>point_a</TT> and <TT>point_b</TT>,
both of type <TT>POINT</TT>.
Let us suppose that these two variables have been initialised with
something other than [[Void|<tt>Void</tt>]].
The following code fragment shows a possible usage of the
predefined <tt>=</tt> comparison operator:
if point_a = point_b then
io.put_string("We have a single, unique POINT !")
else
io.put_string("We have two POINTs at different memory locations.")
end
The <TT>=</TT> operator is the fundamental building block for
comparison.
In the case of a reference type, it corresponds simply to the direct comparison of
the two addresses;
what the two addresses point to is not considered.
If our two variables <TT>point_a</TT> and <TT>point_b</TT> actually designate
a single, unique <TT>POINT</TT> in memory, then the test above evaluates to true.
Once there are two distinct <TT>POINT</TT>s in memory,
then the test is false even if the two <TT>POINT</TT>s seem exactly identical,
in the debugger for example, or when printed.

Note that we also have the <TT>/=</TT> operator, which corresponds to the
negation of the <TT>=</TT> operator.
The <TT>/=</TT> operator is also predefined and is simply a shortcut to avoid
having to use <TT>not</TT> for negation.
So to test whether a reference variable refers to an object, the usage is:
if point /= Void then
io.put_string("The variable point refers to a POINT!")
else
io.put_string("The variable point does not refer to any object.")
end
When comparing variables of an expanded type, the effect of the <TT>=</TT> and
<TT>/=</TT> operators is simply to compare the values in question.
For two variables of type <TT>INTEGER</TT>, that boils down to comparing the two numbers:
if integer_a = integer_b then
io.put_string("integer_a is the same value as integer_b!")
else
io.put_string("The two values are different.")
end

The essential details about the <TT>=</TT> and <TT>/=</TT> predefined operators have
now been clearly explained above, at least, so we hope.
If you are reading this to find out about comparison methods, go straight to the
section on [[#is_equal|<TT>is_equal</TT>]].
Otherwise, continue to the next section for additional information about
these two predefined operators.

<div id="EqNeqOnExpanded">

==The <TT>=</TT> and <TT>/=</TT> operators with expanded types==
</div>
The <TT>=</TT> and <TT>/=</TT> operators, apart from being predefined, are '''non-redefinable''' operators. The effect of <TT>=</TT> and <TT>/=</TT> is completely fixed in the compiler's internals.

When comparing two expressions of a reference type with the <TT>=</TT> or <TT>/=</TT> operators, as has already been mentioned above, only the two addresses are compared. Now let us see what happens when the two compared expressions are of an expanded type.

Comparing two expanded expressions using <TT>=</TT> simply comes down to comparing, at the lowest level, bit by bit, the two areas of memory corresponding to the two objects. Of course, the expanded type used on the left of the <TT>=</TT> operator must be compatible with the expanded type used on the right. Indeed, apart from some [[#ExceptionalRules|rare exceptions]] which we will go into later, a comparison is accepted only when the two expanded types are exactly the same. It is obviously possible to compare two expressions of type
[[library_class:CHARACTER|<tt>CHARACTER</tt>]] with each other; and, for example, to compare two expressions of type [[library_class:INTEGER|<tt>INTEGER</tt>]] with each other. In order to avoid any careless mistakes, however, directly comparing a [[library_class:CHARACTER|<tt>CHARACTER</tt>]] with an [[library_class:INTEGER|<tt>INTEGER</tt>]] is forbidden. In the latter case, it is up to the program's designer to make a call to the appropriate conversion routine. There are multiple possibilities, perhaps to convert the <tt>INTEGER</tt> expression into a <tt>CHARACTER</tt>, or, contrariwise,
to convert the <tt>CHARACTER</tt> expression into an <tt>INTEGER</tt>. In both cases there are many possible conversion routines. Several routines exist, for example, to convert from <tt>CHARACTER</tt> to <tt>INTEGER</tt>. Here are two such examples, among many others:
if my_character.to_integer = my_integer then
io.put_string("Conversion with possible sign extension.")
end
and again:
if my_character.decimal_value = my_integer then
io.put_string("Conversion using the value of the corresponding number.")
end
Thus, it seems completely impossible to automate the choice of conversion that should be applied before the comparison. It depends entirely on the context of the comparison, on the problem being dealt with, and this choice must be made manually by the program's designer. The strict rule, to allow the comparison of two expanded objects only when they have exactly the same type, is indeed the simplest and safest. Thus, if the compiler rejects your comparison expression, read the error message carefully and choose the most appropriate conversion with care. That being said, two exceptions to this very strict rule remain, probably for historical reasons.

<div id="ExceptionalRules">
The two exceptions concern two special cases that '''leave no doubt''' thanks to the fact that the expanded objects concerned are very elementary. The first exception to the strict rule, requiring two expanded types to be identical, concerns the case of two objects taken from the set <tt>{</tt>[[library_class:INTEGER_8|<tt>INTEGER_8</tt>]], [[library_class:INTEGER_16|<tt>INTEGER_16</tt>]], [[library_class:INTEGER_32|<tt>INTEGER_32</tt>]], [[library_class:INTEGER|<tt>INTEGER</tt>]], [[library_class:INTEGER_64|<tt>INTEGER_64</tt>]]<tt>}</tt>. Comparison using <tt>=</tt> is true if and only if the two values correspond to exactly the same integer value. In fact, without any loss of information, it is always possible to represent in 16 bits any number that is represented in 8 bits; and so on and so forth. This exception to the ''hard and fast rule'' therefore lets us write simply and without risk:
if my_integer_8 = my_integer_16 then ...
Knowing that, it is as if we had written:
if my_integer_8.to_integer_16 = my_integer_16 then ...
</div>

The second and last exception is similar to the preceding one and concerns the following set of expanded types: <tt>{</tt>[[library_class:REAL_32|<tt>REAL_32</tt>]], [[library_class:REAL_64|<tt>REAL_64</tt>]], [[library_class:REAL|<tt>REAL</tt>]], [[library_class:REAL_80|<tt>REAL_80</tt>]], [[library_class:REAL_128|<tt>REAL_128</tt>]], [[library_class:REAL_EXTENDED|<tt>REAL_EXTENDED</tt>]]<tt>}</tt>. Like the integers, for the set of floating point numbers in question, it is always possible to convert a given floating point number to a bigger number of bits without any loss of information. Thus, a comparison expression using <tt>=</tt> or <tt>/=</tt> can mix two types taken from the <tt>REAL_*</tt> family.

Note, finally, that it is forbidden to compare directly any object from the <tt>REAL_*</tt> family with any object from the <tt>INTEGER_*</tt> family. If you find yourself having to make such a comparison, which is not illogical, it is up to you to decide which conversion routine is appropriate to your needs. The Eiffel language has no rule that could decide this for you.

<div id="is_equal">

==The redefinable <tt>is_equal</tt> routine==
</div>
The redefinable <tt>is_equal</tt> routine provides a more sophisticated comparison than using [[#EqNeq|the predefined = operator]]. Consider once again our example of comparing two variables of type <tt>POINT</tt>, but this time let us use <tt>is_equal</tt>. As in the case above, let us suppose for the moment that the two variables <tt>point_a</tt> and <tt>point_b</tt> are initialised with something other than [[Void|<tt>Void</tt>]]:
if point_a.is_equal(point_b) then
io.put_string("Either they are both the same POINT or else they are 2 identical POINTs.")
else
io.put_string("They are two different POINTs.")
end
In a given class, if the <tt>is_equal</tt> routine has not been redefined by the user, the behaviour of <tt>is_equal</tt> is to compare all attributes of the two objects with each other. That means, for the <tt>POINT</tt> example, successively comparing the two <tt>x</tt> attributes and then the two <tt>y</tt> attributes. In other words, it is as if we had written:
if (point_a.x = point_b.x) and (point_a.y = point_b.y) then
io.put_string("Either they are both the same POINT or else they are 2 identical POINTs.")
else
io.put_string("They are two different POINTs.")
end
See how the comparison between attributes does not use <tt>is_equal</tt>, but the basic fixed <tt>=</tt> operator. The following diagram presents a picture of the possible memory contents during comparison of <tt>point_a</tt> and <tt>point_b</tt>. Note that in the following case, these two <tt>POINT</tt>s situated in two memory locations are identical and, consequently, comparison using <tt>is_equal</tt> will return <tt>True</tt>:

[[Image:IsEqualPoints.png|is_equal with some POINTs]]

In the example above, the two objects that are being compared are both instances of the <tt>POINT</tt> class: very simple objects. As the diagram shows, a <tt>POINT</tt> is composed of two expanded attributes, or, more precisely, the attributes <tt>x</tt> and <tt>y</tt> of type [[library_class:REAL|<tt>REAL</tt>]], a primitive expanded type (i.e. without an intermediate pointer). In this case the default definition of the <tt>is_equal</tt> function fits perfectly.

Before describing <tt>is_equal</tt> any further, let us make it clear that <tt>is_equal</tt> can be used when the type of the two compared
objects is expanded. For example, with [[library_class:INTEGER|<tt>INTEGER</tt>]]s, the result of a comparison using the predefined <tt>=</tt> operator has exactly the same effect as using the <tt>is_equal</tt> routine. Note however that using <tt>is_equal</tt> is quite unusual when the two operands are expanded, especially if it is a basic expanded type like [[library_class:INTEGER|<tt>INTEGER</tt>]], [[library_class:CHARACTER|<tt>CHARACTER</tt>]], [[library_class:REAL|<tt>REAL</tt>]] or [[library_class:BOOLEAN|<tt>BOOLEAN</tt>]]. In general, by convention and especially for the sake of simplicity, <tt>=</tt> and <tt>/=</tt> are preferred for primitive expanded types.

As soon as the objects are more complex, with for example some attributes that themselves point towards other objects, it is necessary to pay attention to the predefined behaviour of the <tt>is_equal</tt> function. Consider for example the case of comparing two <tt>TRIANGLE</tt>s, as in the following diagram:

[[Image:IsEqualTriangles.png|is_equal with some TRIANGLEs]]

Both objects of class <tt>TRIANGLE</tt> in the diagram above are identical but if one proceeds to compare them using the predefined <tt>is_equal</tt> routine the result will be <tt>False</tt>! In fact, let us emphasise that <tt>triangle_a</tt> and <tt>triangle_b</tt> designate, even if they are similar, two distinct objects in memory. Indeed, if the <tt>is_equal</tt> function has not been redefined in the <tt>TRIANGLE</tt> class, the comparison of <tt>triangle_a</tt> and <tt>triangle_b</tt> using <tt>is_equal</tt>, in other words the [[Glossary#Expression|expression]]:

triangle_a.is_equal(triangle_b)

is equivalent to the expression:

(triangle_a.p1 = triangle_b.p1) and (triangle_a.p2 = triangle_b.p2) and (triangle_a.p3 = triangle_b.p3)

The expression above corresponds to the predefined behaviour of <tt>is_equal</tt>. In order to obtain a more useful comparison function, it is up to the designer of the <tt>TRIANGLE</tt> class to think of how to alter the predefined definition by redefining <tt>TRIANGLE</tt>'s <tt>is_equal</tt> function like this:

is_equal (other: TRIANGLE): BOOLEAN is
do
Result := p1.is_equal(other.p1) and p2.is_equal(other.p2) and p3.is_equal(other.p3)
end

It is very hard to imagine how a ''good function'' for comparison could be defined automatically. In particular, it is not always enough to call <tt>is_equal</tt> again on the attributes, as in the <tt>TRIANGLE</tt> case, rather than using <tt>=</tt>. (To convince youself of this, see the [[library_class:STRING|<tt>STRING</tt>]] and [[library_class:ARRAY|<tt>ARRAY</tt>]] classes as examples.) Thus, since we do not know how to automate this task with a language rule or by adding a strong dose of intelligence to the compiler, the job belongs solely to the designer of the class. The conscientious class designer must ensure that the <tt>is_equal</tt> function behaves properly for objects of that class. The default behaviour described above has been chosen for its simplicity, because it is is for the most part suitable as a ''good'' comparison function and also because it is implemented easily in low level machine instructions that are very fast (comparison instructions for two memory blocks).

<div id="ValidComparison">

==Comparison validity==
</div>
Do not look for the definition of the [[#EqNeq|<tt>=</tt> and <tt>/=</tt>]]
comparison operators in the Eiffel classes' source
code, because these two operators are predefined and their definition is deliberately fixed in the compiler's internals.
Since one of the goals of the Eiffel language is to limit the possibility of careless errors,
it would not be reasonable to allow just any comparison (that is, to allow all mixtures, like
comparing a <tt>LORRY</tt> with a
<tt>FLOWER</tt>, to take an extreme example).
The [[Glossary#StaticType|static types]] of two [[Glossary#Expression|expressions]] to be
compared must conform to certain constraints.
Of course -- and this is the usual case -- when the two expressions are of the same
[[Glossary#StaticType|static type]], the comparison is obviously allowed.
It is always possible to compare two expressions with the same static type using the comparison operators [[#EqNeq|<tt>=</tt> and <tt>/=</tt>]].

As soon as the two expressioms are not of the same static type, they have to conform to the following general rule.
A comparison of the form:
x = y
or again:
x /= y
is valid if it is possible to assign <tt>x</tt> to <tt>y</tt> or vice versa.
More precisely, seeing that <tt>x</tt> and <tt>y</tt> are not necessarily variables, either the static type of <tt>x</tt> is acceptable for an assignment to the static type of <tt>y</tt> or else the static type of <tt>y</tt> is acceptable for an assignment to the static type of <tt>x</tt>.

The foregoing validity rule helps to check whether the program designer is writing a ''reasonable comparison''.
From experience, we have established that this rule, guided by common sense, is crucial for detecting upstream errors,
which are often careless mistakes.

In a few ''uncommon and often obscure'' cases, this rule can perhaps be found to be too restrictive.
If you should find yourself in the situation where the compiler is rejecting your comparison but nevertheless you genuinely think that comparing the two expressions is desirable, you can achieve your ends by using two local variables with a more general static type (ultimately, you can use type [[library_class:ANY|<tt>ANY</tt>]]).

To conclude this section on the general verification rule for comparisons with the
[[#EqNeq|<tt>=</tt> and <tt>/=</tt>]] operators,
let us remember that the rule just declared above also includes the [[#ExceptionalRules|previously mentioned case]] concerning the comparison of two expressions of type <tt>INTEGER_*</tt> or of type <tt>REAL_*</tt>.
For example, it is possible to assign an expression of type
[[library_class:INTEGER_16|<tt>INTEGER_16</tt>]] to a variable of type [[library_class:INTEGER_32|<tt>INTEGER_32</tt>]].
A comparison between an expression of type
[[library_class:INTEGER_16|<tt>INTEGER_16</tt>]] and one of type
[[library_class:INTEGER_32|<tt>INTEGER_32</tt>]] is therefore valid.

<div id="is_deep_equal">

==Comparison using <tt>is_deep_equal</tt>, the fixed method==
</div>
Just for the sake of completeness in this section on comparing objects, let us finally be aware that the [[library_class:ANY|<tt>ANY</tt>]] class offers the possibility of a deep comparison of two objects: the <tt>is_deep_equal</tt> function.
The attributes of the two objects to be compared are themselves compared with the <tt>is_deep_equal</tt> function and so on recursively.
This function recursively checks that the two objects are structurally identical.
Note that it is sometimes possible to have an endless loop in the object graph, for example when comparing two linked lists with a circular structure.
In order to be considered identical by <tt>is_deep_equal</tt>, it must be possible to superimpose the graph of the two objects.

The definition of the <tt>is_deep_equal</tt> function is fixed in the [[library_class:ANY|<tt>ANY</tt>]] class.
The <tt>is_deep_equal</tt> function must be used with care because it depends entirely on the implementation of the objects which it is comparing.
In fact, as a general rule, it is always preferable to avoid using the <tt>is_deep_equal</tt> function.

Class loading

2024-07-30T12:24:49Z

Hzwakenberg:

= The class loading algorithm =

== How must the source files be named? ==

The algorithm used by Liberty to look for an Eiffel source file is the following:
# Lower case filenames - Liberty looks all along the loading path (see below) using the class name in lower case as prefix. If needed, the Eiffel suffix (".e") is added automatically. Liberty only looks for suffixed files on the disk. Only the first file encountered according to the order of the path is taken in account. An Eiffel file is always supposed to have the same name as the inside class definition.
# Upper case filenames - When the previous step did not find the required Eiffel class file, Liberty looks along the loading path (see below) for a file bearing the class name upper in upper case letters. If needed, the Eiffel suffix ".e" is added automatically. One must note that the overhead to find an upper case file name is not negligible at all, and that a lower case file name may hide some upper case name.

== How is the loading path built? ==

As described above, Liberty looks for classes in <code>.e</code> files. But where should those files be situated? The answer is, in the loading path. The thing is, how is the loading path built, what are the default values, and how can it be changed?

Liberty builds a "universe" where it looks for all the classes. This "universe" is a tree of clusters. The root of the tree is the universe. This universe is either made of clusters and <code>loadpath.se</code> files provided by:
* either the ACE file
* or a combination of the following:
** the command line (<code>-loadpath</code> arguments)
** the current directory (a <code>loadpath.se</code> file in the current directory if it exists, the cluster represented by the current directory otherwise)
** the [[configuration file]]

Each <code>loadpath.se</code> file is a node of the tree. It contains other nodes (referenced <code>loadpath.se</code> files), and clusters (directories). Note that ''all the clusters in a <code>loadpath.se</code> file are direct children of the node''. It means that, even if directories are arborescent this is not reflected in Liberty's universe.

To look for a supplier class, Liberty starts from its client. It tries to look for the "closest" class with the good name. It allows one to have many classes with the same name in the system. The algorithm is the following:
# try to look for a class with the good name in a sub-cluster of the client. The less deep, the better.
# try again, starting from the parent cluster of the client.
# and so on, until the universe (the tree root) is reached.

If there is no client (e.g. a class given on the command line) the universe is searched and the class nearest to the root is selected.

If more than one class have the smallest distance, the compiler will bail because it cannot decide which to use. In the future, an extension to ACE files will allow someone to provide custom distances (a "distance" is the amount of depth to add from a cluster to a child; it defaults to 1)

'''For example:'''

<code>/my/loadpath.se</code>
<pre>
./
internal/
</pre>

This <code>loadpath.se</code> file represents a node with two children: the cluster in the directory of the <code>loadpath.se</code> file, and the cluster in the directory named "internal" in the former directory. Both have a distance equal to one, meaning that if there are two classes named <code>FOO</code> in both <code>./</code> and <code>internal/</code> then the compiler will emit an error.

The tree will be the following:
<pre>
+ <Universe>
+ "/my/loadpath.se"
| + /my/
| + /my/internal/
+ . . .
|
</pre>

== <code>loadpath.se</code> files ==

Those files contain directories (clusters: the leaves of the "universe" tree) and references to other <code>loadpath.se</code> files (nodes of the "universe" tree).

Those path names may be written using
- either a POSIX notation
- or your local system notation

Note that for a library to be portable, you should prefer the POSIX notation.

= Internals =

Here are the gory details on how the "universe" tree is managed:

The tree itself is a bunch of classes situated in the <code>smarteiffel/tools/ace</code> cluster. It is a Composite which abstract class is [[tool class:CLASSES|<code>CLASSES</code>]]; most of the parent-children handling is done by concrete features in the [[tool class:CLUSTERS|<code>CLUSTERS</code>]] class.

<pre>
*
.--- CLASSES <--.
| ^ | children
parent | | |
`--> CLUSTERS ---'
0-1 ^
|
+----------+-------------+
| | |
ACE --> UNIVERSE LOADPATH CLASSES_TREE --> CLUSTER
(singleton)
</pre>

* [[tool class:LOADPATH|<code>LOADPATH</code>]] is a node of the tree. It references a <code>loadpath.se</code> file
* [[tool class:UNIVERSE|<code>UNIVERSE</code>]] is a singleton object held by [[tool class:ACE|<code>ACE</code>]]
* [[tool class:CLASSES_TREE|<code>CLASSES_TREE</code>]] is a leaf of the tree. It is a facade to the old [[tool class:CLUSTER|<code>CLUSTER</code>]] class
* [[tool class:CLASSES_TREE_FACTORY|<code>CLASSES_TREE_FACTORY</code>]] is used to create a node or a leaf depending on whether the given path is a directory or a plain file. It creates [[tool class:CLASSES|<code>CLASSES</code>]] objects
* [[tool class:CLUSTER|<code>CLUSTER</code>]] holds references to the known and loaded classes in that cluster
* [[tool class:ACE|<code>ACE</code>]] stays the Universe facade for the remaining of the Liberty system and dispatches request to the [[tool class:CLASSES|<code>CLASSES</code>]] tree (via the [[tool class:UNIVERSE|<code>UNIVERSE</code>]])

Class loading

2024-07-30T12:24:12Z

Hzwakenberg:

= The class loading algorithm =

== How must the source files be named? ==

The algorithm used by Liberty to look for an Eiffel source file is the following:
# Lower case filenames - Liberty looks all along the loading path (see below) using the class name in lower case as prefix. If needed, the Eiffel suffix (".e") is added automatically. Liberty only looks for suffixed files on the disk. Only the first file encountered according to the order of the path is taken in account. An Eiffel file is always supposed to have the same name as the inside class definition.
# Upper case filenames - When the previous step did not find the required Eiffel class file, Liberty looks along the loading path (see below) for a file bearing the class name upper in upper case letters. If needed, the Eiffel suffix ".e" is added automatically. One must note that the overhead to find an upper case file name is not negligible at all, and that a lower case file name may hide some upper case name.

== How is the loading path built? ==

As described above, Liberty looks for classes in <code>.e</code> files. But where should those files be situated? The answer is, in the loading path. The thing is, how is the loading path built, what are the default values, and how can it be changed?

Liberty builds a "universe" where it looks for all the classes. This "universe" is a tree of clusters. The root of the tree is the universe. This universe is either made of clusters and <code>loadpath.se</code> files provided by:
* either the ACE file
* or a combination of the following:
** the command line (<code>-loadpath</code> arguments)
** the current directory (a <code>loadpath.se</code> file in the current directory if it exists, the cluster represented by the current directory otherwise)
** the [[configuration file]]

Each <code>loadpath.se</code> file is a node of the tree. It contains other nodes (referenced <code>loadpath.se</code> files), and clusters (directories). Note that ''all the clusters in a <code>loadpath.se</code> file are direct children of the node''. It means that, even if directories are arborescent this is not reflected in Liberty's universe.

To look for a supplier class, Liberty starts from its client. It tries to look for the "closest" class with the good name. It allows one to have many classes with the same name in the system. The algorithm is the following:
# try to look for a class with the good name in a sub-cluster of the client. The less deep, the better.
# try again starting from the parent cluster of the client.
# and so on, until the universe (the tree root) is reached.

If there is no client (e.g. a class given on the command line) the universe is searched and the class nearest to the root is selected.

If more than one class have the smallest distance, the compiler will bail because it cannot decide which to use. In the future, an extension to ACE files will allow someone to provide custom distances (a "distance" is the amount of depth to add from a cluster to a child; it defaults to 1)

'''For example:'''

<code>/my/loadpath.se</code>
<pre>
./
internal/
</pre>

This <code>loadpath.se</code> file represents a node with two children: the cluster in the directory of the <code>loadpath.se</code> file, and the cluster in the directory named "internal" in the former directory. Both have a distance equal to one, meaning that if there are two classes named <code>FOO</code> in both <code>./</code> and <code>internal/</code> then the compiler will emit an error.

The tree will be the following:
<pre>
+ <Universe>
+ "/my/loadpath.se"
| + /my/
| + /my/internal/
+ . . .
|
</pre>

== <code>loadpath.se</code> files ==

Those files contain directories (clusters: the leaves of the "universe" tree) and references to other <code>loadpath.se</code> files (nodes of the "universe" tree).

Those path names may be written using
- either a POSIX notation
- or your local system notation

Note that for a library to be portable, you should prefer the POSIX notation.

= Internals =

Here are the gory details on how the "universe" tree is managed:

The tree itself is a bunch of classes situated in the <code>smarteiffel/tools/ace</code> cluster. It is a Composite which abstract class is [[tool class:CLASSES|<code>CLASSES</code>]]; most of the parent-children handling is done by concrete features in the [[tool class:CLUSTERS|<code>CLUSTERS</code>]] class.

<pre>
*
.--- CLASSES <--.
| ^ | children
parent | | |
`--> CLUSTERS ---'
0-1 ^
|
+----------+-------------+
| | |
ACE --> UNIVERSE LOADPATH CLASSES_TREE --> CLUSTER
(singleton)
</pre>

* [[tool class:LOADPATH|<code>LOADPATH</code>]] is a node of the tree. It references a <code>loadpath.se</code> file
* [[tool class:UNIVERSE|<code>UNIVERSE</code>]] is a singleton object held by [[tool class:ACE|<code>ACE</code>]]
* [[tool class:CLASSES_TREE|<code>CLASSES_TREE</code>]] is a leaf of the tree. It is a facade to the old [[tool class:CLUSTER|<code>CLUSTER</code>]] class
* [[tool class:CLASSES_TREE_FACTORY|<code>CLASSES_TREE_FACTORY</code>]] is used to create a node or a leaf depending on whether the given path is a directory or a plain file. It creates [[tool class:CLASSES|<code>CLASSES</code>]] objects
* [[tool class:CLUSTER|<code>CLUSTER</code>]] holds references to the known and loaded classes in that cluster
* [[tool class:ACE|<code>ACE</code>]] stays the Universe facade for the remaining of the Liberty system and dispatches request to the [[tool class:CLASSES|<code>CLASSES</code>]] tree (via the [[tool class:UNIVERSE|<code>UNIVERSE</code>]])

Finder

2024-07-30T12:23:24Z

Hzwakenberg:

[[Category:Tool]]
== Usage ==
se find [options] [<ACEfile.ace>] <Class>
The find command tells you which file the compiler loads when searching for an Eiffel <Class>.

When an Eiffel file is found, find prints the full path name on standard output.

The exit status is set to GENERAL.exit_success_code only when an existing file is found (thus allowing usage of the find command in shell scripts).
As for other commands, when the ACE file mode is used, only the content of the <ACEfile.ace> file is used to search the source file.
To see the loading path used by Liberty Eiffel, you can for example type the find command using a bad (non-existent) class name.
In ACE file mode, the loading path can be updated by modifying the ACE file itself. In traditional mode (i.e. no ACE file), the default loading path may also be tailored (see below).

== Options ==
-help:
Display a brief summary of the command-line syntax and a complete list of find options.

-version:
Show the number of the version of Liberty Eiffel you're using.

-verbose:
Print system information during the compilation (full path of loaded files, type inference score, removed files, etc.).

-loadpath <loadpath_file>:
Adds a loadpath file for class lookup. See below for details on the loading path constitution.

-raw:
Does not display the cluster name. Its only output is usually the path name of the class, so it is useful in scripts.

== Where does Find search? ==

This is explained in detail in the [[class loading]] section. Note that finder will find all classes with a given name.

Plugins

2024-07-30T12:20:56Z

Hzwakenberg:

[[Category: Interfacing]]
Plugins are a means to augment the capabilities of Liberty Eiffel, by incorporating libraries which have the colour, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

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.

== How does it work ? ==

A plugin is made up of two interdependent parts :

* the Eiffel side, which provides an interface usable by other Eiffel objects ;
* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd|back-ends]] (for example, C and Java).

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.

== Eiffel Side ==

The Eiffel side uses ''external'' features. The syntax is as follows:

feature
my_plugin_feature is
external "plug_in"
alias "{
location: "/path/to/my/plugins"
module_name: "my_plugin"
feature_name: "feature"
}"

Of course, a feature can take arguments and return a result ! (after all, it's an ''external'') ;-)

'''Beware''' however, it is necessary to only pass and return only basic ''expanded'' base types :
([[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>).

* '''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]]).
For example, the standard Liberty Eiffel libraries are defined by using the following ''location'':
location: "${sys}plugins"

* '''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.

* '''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 : they're all features ;-)

== Dark side ==

=== C Generation ===

The C [[Glossary#BackEnd|back-end]] uses a subdirectory of your plugin named <TT>c</TT>. The files used are:

* all the <TT>.c</TT> files, which are included in the compiler-generated C files
* all the <TT>.h</TT> files, which are included in the compiler-generated header file
* the <TT>libs</TT> file, which contains a description of the native libraries to link
* the <TT>paths</TT> file, which contains a description of the paths used to find the libraries
* the <TT>includes</TT> file, which contains a description of the paths used to find header files
* the <TT>auto_init</TT> file, which contains a description of a possible initialization function called at the very start of the program
* the <TT>cecil.se</TT> file, which is a [[cecil]] description automatically taken into account
* 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 contain invocation of tools that gives the mutable correct flags to compile and link the library, i.e. pkg-config.

The '''<TT>.c</TT> and <TT>.h</TT>''' files are included in alphabetic order.

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:
* 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.
* The keys in these files are only informative; however, the values are used to generate command line calls to the C compiler.

The '''<TT>auto_init</TT>''' file uses the same syntax as the [[configuration file]], but with yet other keys:
* 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
* Any other section describes plugin dependencies. These 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).

The '''<TT>cecil.se</TT>''' file is automatically included as it were specified by the <TT>-cecil</TT> option.

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).

'''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 behaviour. 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.

=== Java Generation===

NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to Liberty Eiffel's legacy predecessor.

For the Java [[Glossary#BackEnd|back-end]], the plugin subdirectory must be named <TT>java</TT>.
The compiler uses the following files :

* 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.
* 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.

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.

Eiffeldoc

2024-07-30T12:18:04Z

Hzwakenberg:

[[Category:Tool]]

<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.

== Synopsis ==

* <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>

{| cellspacing="4" cellpadding="0" width="100%"
|-
| valign="top" width="20%" | <code>-title</code>
| The title of the generated documentation
|-
| valign="top" | <code>-home_address</code>
| 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.
|-
| valign="top" | <code>-home_image_address</code>
| The address of the ''go home'' image
|-
| valign="top" | <code>-nav_css</code>
| The stylesheet to use in the navigation bar (i.e. the left frames)
|-
| valign="top" | <code>-doc_css</code>
| The stylesheet to use in the cluster documentation (i.e. on the right frames)
|-
| valign="top" | <code>-class_css</code>
| The stylesheet to use in the class documentation (i.e. on the right frames)
|-
| valign="top" | <code>-arrow_address</code>
| 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.
|-
| valign="top" | <code>-separator_address</code>
| 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.
|-
| valign="top" | <code>-prune</code>
| 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.
|
|-
| valign="top" | <code>-remote</code>
| 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>

As a special case, <tt>-prune cwd</tt> allows not to take the current working directory into account.

Example:
se doc -prune 'lib/scoop'
|-
| valign="top" | <code>-depends</code>
| Generate dependant classes even if their cluster is pruned. This helps avoiding dangling links.
|-
| valign="top" | <code>-verbose</code>
| Output a lot of information about what eiffeldoc is doing.
|-
| valign="top" | <code>-wiki_prefix</code>
| Generate links to wiki URLs (in square brackets)
|}

== Stylesheets ==

The stylesheets are heavily used to customize the output of Eiffeldoc. The known classes are:

{|
|-
| A.home
| for the home link
|-
| A.title
| for the titles
|-
| A.cluster
| for the clusters
|-
| A.class
| for the classes
|-
| A.client
| for the upper-right clients frame
|-
| A.description
| for the one-sentence description in the cluster summary
|-
| TD.home
| for the home link
|-
| TD.title
| for the titles
|-
| TD.cluster
| for the clusters
|-
| TD.class
| for the classes (except in the short proper)
|-
| TD.client
| for the upper-right clients frame
|-
| TD.description
| for the one-sentence description in the cluster summary
|-
| B.obsolete
| for the obsolete header
|-
| I.obsolete
| for the obsolete message
|-
| TD.comment
| for a class comment
|-
| PRE.comment
| for a class comment
|-
| B.comment
| for a feature clause comment
|-
| I.comment
| for a feature comment
|-
| LI.summary
| for a feature in the summary
|-
| A.summary
| for the feature link in the summary
|-
| TD.details
| for a feature definition in the details section
|-
| B.details
| for the feature name in the details section
|-
| B.assertion
| for the assertion tags
|-
| TT.assertion
| for the assertion expressions
|-
| I.assertion
| for the assertion comments
|-
| A.link
| for a class link in the class documentation
|-
| U.wiki_entity
| for a link to a field in a comment, not anchored ''?Is 'anchor' the correct translation of 'lier' here?''
|-
| A.wiki_entity
| for a link to a field in a comment, anchored
|-
| B.wiki_bold
| for bold elements in a comment (wiki syntax)
|-
| I.wiki_italics
| for italic elements in a comment (wiki syntax)
|-
| TT.wiki_class_name
| for class names in a comment
|-
| TT.wiki_string
| for character strings in a comment
|-
| TT.wiki_character
| for characters in a comment
|-
| UL.wiki_bullet_list
| for bullet-point lists
|-
| LI.wiki_bullet_list
| for bullet-point list items
|-
| OL.wiki_numbered_list
| for numbered lists
|-
| LI.wiki_numbered_list
| for numbered list items
|-
| A.wiki_url
| for URLs (between <nowiki>[...]</nowiki>)
|-
| A.wiki_word
| for wiki words (between <nowiki>[[...]]</nowiki>)
|}

== Usage ==

=== Project ===

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.

Eiffeldoc has been designed to generate the documentation for a whole '''project'''. But what is a project?

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.

Eiffeldoc defines the project by the set of class search paths. It uses the same method as <TT>[[finder]]</TT>:
using the ACE file or else <TT>loadpath.se</TT> and the paths from the system [[Configuration file|configuration file]].

=== Documentation ===

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.

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.

==== Comments ====

Eiffeldoc makes full use of comments. There is a convention about the ''position'' of comments.

'''For classes''', the ''class comment'' is the comment placed just after the class declaration. For example:
class MY_CLASS
-- this is the class comment
end
''The convention'' is to describe the overall purpose of the class, what it is used for, in what context, and so on.

'''For groups of features''', the ''feature group comment'' is the comment placed just after the <TT>'''feature'''</TT> clause. For example:
feature {ANY} -- Consultation:
''The convention'' is to use short comments, because they are used as feature group headings.

'''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:
my_routine (i: INTEGER): INTEGER is
-- a function that depends on the argument `i'
''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.

==== cluster.html ====

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 <body> and </body>. Here, too, it extracts the first sentence to use in the page that describes the whole group of clusters.

----
<DIV id="note1">1. Other output formats are expected to be possible in the future.</DIV>

<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>

Build your library

2024-07-30T12:16:47Z

Hzwakenberg:

[[Category: Library]]
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.

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 contains a rich variety of features.

Liberty Eiffel also provides a documentation utility: [[eiffeldoc|eiffeldoc]].

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.

Liberty Eiffel provides a powerful utility: [[plugins]]. You can also use, even though it has been superseded, an older mechanism, [[externals|externals]].

There are also two other mechanisms: [[inlining|inlining]] and [[cecil]].

For more in-depth background information about building reusable software components and libraries, check out reference "RS 1994" on the [[Bibliography]] page.

Build your library

2024-07-30T12:15:33Z

Hzwakenberg:

[[Category: Library]]
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.

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 contains a rich variety of features.

Liberty Eiffel also provides a documentation utility: [[eiffeldoc|eiffeldoc]].

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.

Liberty Eiffel provides a powerful utility: [[plugins]]. You can also use , even though it has been superseded, an older mechanism, [[externals|externals]].

There are also two other mechanisms: [[inlining|inlining]] and [[cecil]].

For more in-depth background information about building reusable software components and libraries, check out reference "RS 1994" on the [[Bibliography]] page.

Externals

2024-07-30T11:35:16Z

Hzwakenberg:

[[Category: Interfacing]]
See "External Types".

''Externals'' build on top of a standard Eiffel mechanism. This mechanism permits calling code in a language different from Eiffel.

You will find below the current list of ''external'' specifications supported by Liberty.

== external "C" ==

This specification permits calling C code from Eiffel. This mechanism is described in [[Bibliography#ETL_1992|''Eiffel: The Language'']].

Some examples are available in the tutorial, <TT>tutorial/external/C</TT>.

This mechanism is only available with [[compile_to_c]].

This mechanism has since been supplanted with [[plugins]] (see below).

== external "C++" ==

This specification permits calling C++ code from Eiffel. This mechanism is described in [[Bibliography#ETL_1992|''Eiffel: The Language'']].

Some examples are available in the tutorial, <TT>tutorial/external/C++</TT>.

This mechanism is only available with [[compile_to_c]].

This mechanism has since been supplanted with [[plugins]] (see below).

== external "plug_in" ==

This specification is particularly utilized by the Liberty standard libraries. This form is preferred to ''external "C"'' and ''external "Java"''.

Examples are available throughout the standard library.

A [[plugins|dedicated page]] is devoted to this functionality.

== external "built_in" ==

This specification is reserved for the compiler and its base libraries. It is not usable outside of very specific cases, unique to [[compile_to_c]] and [[compile_to_jvm]]. These cases are the "building blocks" that produce specialized output code depending on the code generator being used.

For example, <TT>infix "#+"</TT> in the class [[library_class:INTEGER|<TT>INTEGER</TT>]] is directly translated in C by a <TT>+</TT>, and in Java by the <TT>iadd</TT> bytecode.

== external types ==

A mechanism for embedding [[external types]] from the underlying language is being designed for a future release.

== external "Java" - currently not supported ==

This specification would permit calling Java code from Eiffel. Some examples used to be available in the tutorial, <TT>tutorial/external/Java</TT>. This mechanism would only be available with [[compile_to_jvm]], which currently is not supported.

This mechanism has since been supplanted with [[plugins]] (see below).

Compile to jvm

2024-07-30T11:29:38Z

Hzwakenberg:

[[Category:Obsolete]]
In the old days of Liberty Eiffel's predecessor, there existed a backend <code>compile_to_jvm</code> - an alternative compiler that produced Java byte-code. It generated a subdirectory named from the main class of a project that was suitable for either direct execution or JAR generation.

'''This backend is no longer supported, as no one seems to<br>care about it or use it for any interesting project.'''

We will keep this for some time, but for the time being there are no plans to continue compile_to_jvm. If you think it would be worth resurrecting this backend, please [[Get_in_touch|let use know]].

== Synopsis ==

* <code>compile_to_jvm [options] <Root-Class> <Root-Procedure></code>
* <code>compile_to_jvm [options] <ACEfilename></code>
* <code>compile_to_jvm -help</code>

This tool works similarly to the standard [[compile_to_c|'''compile_to_c''']] compiler and thus shares many options: assertion control, path loading...

Current (2.2) specific options are:

* -jar: tell the compiler to also produce a .jar file of the project
* -run: tell the compiler to automatically run the project after successful compilation
* -use_jar <jar>: use <jar> application to generate the .jar file instead of the default one (implies -jar)
* -use_jvm <jvm>: use <jvm> to run the program instead of the default one (implies -run)
* -extern_compiler <compiler>: Use the Java <compiler> compiler to compile plugins and runtime
* -ss <size>: Set the maximum stack size to <size> (implies -run)
* -mx <size>: Set the maximum heap size to <size> (implies -run)
* -ms <size>: Set the initial heap size to <size> (implies -run)
* -classpath <path>: Set the path which is search for compiled classes (implies -run)

Finder

2024-07-30T10:00:08Z

Hzwakenberg:

[[Category:Tool]]
== Usage ==
se find [options] [<ACEfile.ace>] <Class>
The find command tells you which file the compiler loads when searching for an Eiffel <Class>.

When an Eiffel file is found, find prints the full path name on standard output.

The exit status is set to GENERAL.exit_success_code only when an existing file is found (thus allowing usage of the find command in shell scripts).
As for other commands, when the ACE file mode is used, only the content of the <ACEfile.ace> file is used to search the source file.
To see the loading path used by Liberty Eiffel, you can for example type the find command using a bad (non-existent) class name.
In ACE file mode, the loading path can be updated by modifying the ACE file itself. In traditional mode (i.e. no ACE file), the default loading path may also be tailored (see below).

== Options ==
-help:
Display a brief summary of the command-line syntax and a complete list of find options.

-version:
Show the number of the version of Liberty Eiffel you're using.

-verbose:
Print system information during the compilation (full path of loaded files, type inference score, removed files, etc.).

-loadpath <loadpath_file>:
Adds a loadpath file for class lookup. See below for details on the loading path constitution.

-raw:
Does not display the cluster name. Its only output is usually the path name of the class so it is useful in scripts.

== Where does Find search? ==

This is explained in detail in the [[class loading]] section. Note that finder will find all classes with a given name.

Related Projects

2024-07-12T17:21:22Z

Hzwakenberg:

Here a list of related projects with Liberty Eiffel:

= eiffel-iup =

A wrapper for the IUP toolkit. IUP is a multi-platform toolkit for building graphical user interfaces. IUP's purpose is to allow a program source code to be compiled in different systems without any modification. Its main advantages are:

* High performance, due to the fact that it uses native interface elements.
* Fast learning by the user, due to the simplicity of its API.

This wrapper is still under development, but is almost complete and we encourage you to use it and send feedback.

The project website is: [https://notabug.org/GermanGT/eiffel-iup eiffel-iup]

Tecgraf's IUP (currently in version 3.31) site: [https://www.tecgraf.puc-rio.br/iup/ Tecgraf IUP]

This package is released under the MIT license.

Related Projects

2024-07-12T17:18:09Z

Hzwakenberg:

Here a list of related projects with Liberty Eiffel:

= eiffel-iup =

A wrapper for the IUP toolkit. IUP is a multi-platform toolkit for building graphical user interfaces. IUP's purpose is to allow a program source code to be compiled in different systems without any modification. Its main advantages are:

* High performance, due to the fact that it uses native interface elements.
* Fast learning by the user, due to the simplicity of its API.

This wrapper is still under development, but is almost complete and we encourage you to use it and send feedback.

The project website is: [https://notabug.org/GermanGT/eiffel-iup eiffel-iup]

Tecgraf's IUP (currently in version 3.30) site: [https://www.tecgraf.puc-rio.br/iup/ Tecgraf IUP]

This package is released under the MIT license.

Related Projects

2024-07-12T17:16:50Z

Hzwakenberg: updated Tecgraf IUP link

Here a list of related projects with Liberty Eiffel:

= eiffel-iup =

A wrapper for the IUP toolkit. IUP is a multi-platform toolkit for building graphical user interfaces. IUP's purpose is to allow a program source code to be compiled in different systems without any modification. Its main advantages are:

* High performance, due to the fact that it uses native interface elements.
* Fast learning by the user, due to the simplicity of its API.

This wrapper is still under development, but is almost complete and we encourage you to use it and send feedback.

The project website is: [https://notabug.org/GermanGT/eiffel-iup eiffel-iup]

Tecgraph's IUP (currently in version 3.30) site: [https://www.tecgraf.puc-rio.br/iup/ Tecgraf IUP]

This package is released under the MIT license.

Bibliography

2024-07-12T09:28:59Z

Hzwakenberg: Added book title

[[Category: Literature]]
__NOTOC__ 
==ETL 1992==
Bertrand Meyer.
''Eiffel: The Language''.
Prentice Hall, 1993, ISBN 0-13-247925-7.

==GC book==
Richar Jones and Rafael Lins.
''Garbage Collection. Algorithms for Automatic Dynamic Memory Management''.
John Wiley & Sons, ISBN 0-471-941484-4.

==GoF 1995==
Erich Gamma, Richard Helm and Ralph Johnson and John Vlissides.
''Design Patterns: Elements of Reusable Object-Oriented Software''.
Addisson-Wesley, Reading Massachusetts, 1995, ISBN 0201633612.

==Goldberg 1984==
Adele Goldberg.
''Smalltalk-80, The Interactive Programming Environment''.
Addisson-Wesley, Reading Massachusetts, 1984, ISBN 0-201-11372-4.

==GR 1983==
Adele Goldberg and David Robson.
''Smalltalk-80: The Language and its Implementation''.
Addison-Wesley, 1983, ISBN 0-201-11371-6.

==JMJ 1996==
Jean-Marc Jézéquel.
''Object-Oriented Software Engineering with Eiffel''.
Addison-Wesley, 1999, ISBN 0-201-63381-7. This book is a gentle introduction to Eiffel programming, without the academic verbosity of many of the other titles in this list.

==JTM 1999==
Jean-Marc Jézéquel, Michel Train and Christine Mingins.
''Design Patterns and Contracts''.
Addison-Wesley, 1999, ISBN 0-201-30959-9.

==MNCLT 1989==
Gérald Masini, Amédéo Napoli, Dominique Colnet, Daniel Léonard et Karl Tombre.
''Les langages à objets''.
InterEditions", Paris", 1989, ISBN 2-7296-0275-5.

==MNCLT 1991==
Gérald Masini and Amédéo Napoli and Dominique Colnet and Daniel Léonard and Karl Tombre.
''Object-Oriented Languages''.
Academic Press, New York, 1991, ISBN 0-12-477390-7.

==OOSC 1997==
Bertrand Meyer.
''Object-oriented Software Construction, 2nd Ed.''.
Prentice Hall 1997, 1254 pages, ISBN 0-13-629155-4.

==RMJM 2002==
Richard Mitchel and Jim McKim.
''Design by Contract, by Example''.
Adison-Wesley 2002, 238 pages, ISBN 0-201-63460-0. This title introduces a well structured and very thorough method of using DbC.

==TOCBM 2009==
Bertrand Meyer.
''TOUCH OF CLASS - Learning to program well with Objects and Contracts''.
Springer Verlag 2009, 876 pages, ISBN 978-81-322-0374-2. Unfortunately, this title assumes that you download supporting code and libraries, but the URL in the book is no longer valid.

==RS 1994==
Bertrand Meyer.
''Reusable Software: The Base Object-Oriented Component Libraries''.
Prentice Hall, 1994, 514 pages, ISBN-10: 013-245-499-8 ISBN-13: 978-013-245-499-5

==ECMA 367 / 2006==
ECMA International 2006.
''Eiffel: Analysis, Design and Programming Language''.
https://www.ecma-international.org/wp-content/uploads/ECMA-367_2nd_edition_june_2006.pdf

==SOOSA 2015==
Kim Waldén and Jean-Marc Nelson.
''Seamless Object-Oriented Software Architecture''.
Prentice Hall, 2015, 438 pages, ISBN 0-13-031303-3. This title is about BON (Business Object Notation), less so about the Eiffel language. BON as a method was developed by the authors of this book. BON is perceived to be simpler than the UML method.

Coding Style Guide

2024-07-10T11:33:28Z

Hzwakenberg: spelling

Some proposals on how to format and comment code; usual common Eiffel practices are recommended of course.

* try to choose feature names that would make code read (as much as) the English language.
* boolean queries should be named <code>is_....</code>, e.g. <code>is_empty</code>
* Describe each feature. Do not leave any feature without a description; while it is surely obvious for the feature writer it may not be so manifest to another person. What does a command do? What's the meaning of a query? Avoid phrasing like "This feature opens a window", write instead "Opens a window"; instead of "This function returns the number of acorns in tree-hole" write "Number of acorns in the tree-hole".
* try to name feature argument prefixing them with generic English preposition (a_, an_, some_); this make code-reading more fluent.
* omit feature comments in case the feature name fully explains the feature
* use correct indentation
* <code>feature</code> and <code>creation</code> clauses should always have an explicit client list (Liberty will raise a warning otherwise). Of course it may be <code>{ANY}</code>. An empty list i.e. <code>{}</code> means that only unqualified calls are possible (i. e. the *implicit* <code>Current</code> target, not the explicit <code>Current</code>! may use it); <code>{NONE}</code> is discouraged as the NONE adds no information at all.
* use 3 spaces for indentation, no TAB

Feel free to make any proposal and improvements.

Liberty Eiffel users list

2024-07-10T08:59:03Z

Hzwakenberg:

[[Category:Community]]
<div id="LibertyEiffelUsersList">
'''List of Liberty Eiffel users'''. You may register yourself in the list below.
<div>
<HR>

==Schools or universities==
Empty slot.
----
Empty slot.
----

==Projects or individuals==
[[User:Ramack|Raphael Mack]]
----
[[User:Cadrian|Cyril Adrian]]
----
[[User:Hzwakenberg|Hans Zwakenberg]]
----
Empty slot
----

Compatibility

2024-07-10T08:06:56Z

Hzwakenberg: lingual correction

This page is about language compatibility for Liberty Eiffel. Here you find 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 significant differences.

See also [[ECMA]].

== Unique peculiarities of Liberty Eiffel ==

Liberty Eiffel has some features not implemented by any other implementation:

* Case sensitivity: "abc", "Abc" and "ABC" are different identifiers
* Compiler-enforced casing rules: Class names must be all-uppercase; camelCase is not allowed.
* ANY is the root of the inheritance tree, but not of the conformance tree.
* Conformance rules related to expanded types.
* Non-conforming inheritance. See [[Conforming and non-conforming inheritance]]
* The notation for non-conforming inheritance is "insert <Type_Class>".
* New operators for run-time type checking. See [[Dynamic type testing]]
* Removed the danger of automatic boxing (object allocation on assignment of expanded types to reference entities)
* Lots of additional tools in the library. See [[Table of contents#Library|The Liberty Eiffel general purpose library]]
* Notation for [[Manifest storage notation|manifest collections]]. The old <code><<...>></code> is still supported for simple arrays.
* Unicode strings manifest notation.
* 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].

== Differences between ETL2 and the former SmartEiffel ==

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)

* The "Precursor" mechanism (proposed at OOSC2). see [[Precursor]]
* Agents and tuples. see [[Agent]] and [[Tuple]]

== Differences between the former SmartEiffel and ECMA Eiffel ==

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 always had been called "Eiffel". The following aspects of ECMA Eiffel will not be implemented in SmartEiffel:

* Conversions (implemented in ISE Eiffel)
* Feature aliases (implemented in ISE Eiffel)
* Bracket indexing (implemented in ISE Eiffel)
* No-variant agent arguments.

On the other hand, the following features were taken from the ECMA specification process:

* Non-conforming inheritance (although the notation is different)

Precursor

2024-07-09T10:57:49Z

Hzwakenberg:

== Precursor ==

Precursor was introduced in OOSC (second edition), page 523:

"The construct 'Precursor' may be used in lieu of a feature name, but only in the body of a redefined routine.
A call to this feature, with arguments if required, is a call to the parent’s version of the routine (the precursor)."

Precursor

2024-07-09T10:29:03Z

Hzwakenberg: Created page with "== Precursor == Precursor was introduces in OOSC (second edition), page 523: "The construct 'Precursor' may be used in lieu of a feature name, but only in the body of a redefined routine. A call to this feature, with arguments if required, is a call to the parent’s version of the routine (the precursor).""

== Precursor ==

Precursor was introduces in OOSC (second edition), page 523:

"The construct 'Precursor' may be used in lieu of a feature name, but only in the body of a redefined routine.
A call to this feature, with arguments if required, is a call to the parent’s version of the routine (the precursor)."

Wish list

2024-07-08T07:58:55Z

Hzwakenberg: Removed items that were done already, even if this list is obsolete.

[[Category:Obsolete]]
This whish list is obsolete, please use the ticket system for [https://savannah.gnu.org/bugs/?func=additem&group=liberty-eiffel bugs] and [https://savannah.gnu.org/task/?func=additem&group=liberty-eiffel tasks] on [https://savannah.gnu.org/projects/liberty-eiffel/ savannah].

==COMMAND_LINE_TOOLS==
I don't think this is worth a task, as [[eiffeldoc]] already is an example for [[tool_class:EXTERNAL_TOOL|<tt>EXTERNAL_TOOL</tt>]].
--[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]])

==Class TREE==
Is it worth a ticket? -> I don't think so. it's too unspecific what TREE should be good for.
--[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]])

==Incremental Eiffel compilation==
On C level the code is "incrementally" compiled ;-) But no, there will not be a redesign in near future. So we should better drop this request.
--[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]])

== Finally implementing SCOOP? ==
==> [[task:13317]]

== Make generated C code thread-safe? ==
==> [[task:13320]]

Liberty Eiffel Wiki:About

2024-07-07T16:18:40Z

Hzwakenberg:

This wiki provides documentation for the [http://www.liberty-eiffel.org/ LibertyEiffel] compiler, libraries, wrappers and tools.

If you want to contribute, please feel free to request a user account on [[Get in touch#Mailing list|mailing list]] [mailto:liberty-eiffel@gnu.org liberty-eiffel@gnu.org] and please take note of a few simple [[Author guidelines]].

Liberty Eiffel Wiki:About

2024-07-07T16:18:09Z

Hzwakenberg: