Liberty Eiffel Wiki - User contributions [en]

Versions history

2024-11-10T09:17:14Z

Ramack: Ramack moved page Versions history to Release Notes (Versions history): Release Notes seems the more common name for this kind of info

#REDIRECT [[Release Notes (Versions history)]]

Release Notes (Versions history)

2024-11-10T09:17:13Z

Ramack: Ramack moved page Versions history to Release Notes (Versions history): Release Notes seems the more common name for this kind of info

[[Category: Releases]]
== Liberty Eiffel (latest release first) ==
For other upcoming releases see the [[upcoming release names|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%
** support for NetBSD, FreeBSD and OpenBSD added (Thanks to KOIZUMI Satoru)
* 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]

Release Notes (Versions history)

2024-11-10T09:16:18Z

Ramack: document added BSD support

Release Notes (Versions history)

2024-11-10T09:14:33Z

Ramack: /* Liberty Eiffel (latest release first) */

[[Category: Releases]]
== Liberty Eiffel (latest release first) ==
For other upcoming releases see the [[upcoming release names|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]

Talk:Upcoming releases

2024-11-10T09:13:44Z

Ramack: Ramack moved page Talk:Upcoming releases to Talk:Upcoming release names

#REDIRECT [[Talk:Upcoming release names]]

Talk:Upcoming release names

2024-11-10T09:13:44Z

Ramack: Ramack moved page Talk:Upcoming releases to Talk:Upcoming release names

I think an '''"eiffel"''' release of Liberty Eiffel may, indeed, be just a little too much of a good thing. --[[User:Dkearns|Dkearns]] ([[User talk:Dkearns|talk]]) 14:26, 27 May 2016 (CEST)

Yes, I share this opinion - What about [https://en.wikipedia.org/wiki/Thomas_Edison Thomas Alva Edison]. For G, I favor Dennis Gabor. --[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]]) 18:49, 27 May 2016 (CEST)

Upcoming releases

2024-11-10T09:13:44Z

Ramack: Ramack moved page Upcoming releases to Upcoming release names

#REDIRECT [[Upcoming release names]]

Upcoming release names

2024-11-10T09:13:43Z

Ramack: Ramack moved page Upcoming releases to Upcoming release names

The Liberty releases are named after famous engineers names starting by A for the first release, B for the second, and so on.
Here is a list of name suggestions for future releases:
* [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss] ('''"curtiss"''', currently being worked on)
* [https://en.wikipedia.org/wiki/Jack_Dennis Jack Dennis] ('''"dennis"''')
* [https://en.wikipedia.org/wiki/Thomas_Edison Thomas Edison] ('''"edison"''')
* [https://en.wikipedia.org/wiki/John_Ambrose_Fleming John Ambrose Fleming] ('''"fleming"''')
* [https://en.wikipedia.org/wiki/Dennis_Gabor Dennis Gabor] ('''"gabor"'''), [https://en.wikipedia.org/wiki/Robert_H._Goddard Robert Goddard] ('''"goddard"''') or [https://en.wikipedia.org/wiki/Gustave_Eiffel Gustave Eiffel]('''"gustave"''') (@ramacks preference is Gabor)
* [https://en.wikipedia.org/wiki/Grace_Hopper Grace Hopper] ('''"hopper"''')
* [https://en.wikipedia.org/wiki/Heinz_Isler Heinz Isler] ('''"isler"''')
* [https://en.wikipedia.org/wiki/Robert_Thomas_Jones_(engineer) Robert Thomas Jones] ('''"jones"''')
* [https://en.wikipedia.org/wiki/Jack_Kilby Jack Kilby] ('''"kilby"''')
* [https://en.wikipedia.org/wiki/Cornelis_Lely Cornelis Lely] ('''"lely"''')
* [https://en.wikipedia.org/wiki/James_Clerk_Maxwell James Clerk Maxwell] ('''"maxwell"''')

Feel free to suggest any further names. You may read the lists of engineers on WikiPedia:

* [https://en.wikipedia.org/wiki/Lists_of_engineers Lists of engineers]
* [https://en.wikipedia.org/wiki/List_of_civil_engineers List of civil engineers]
* [https://en.wikipedia.org/wiki/List_of_structural_engineers List of structural engineers]

Each published final release will also have a numeric tag in the form of "year.month" which is more simple to remember.

Already released versions are listed in [[Versions history]].

Release Notes (Versions history)

2022-04-16T20:06:44Z

Ramack: /* Curtiss (2018.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:
** 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
** C99 conforming C code generation (hopefully)
* Developer changes:
** 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]

Release Notes (Versions history)

2022-02-18T21:24:10Z

Ramack: /* Curtiss (2018.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 (2018.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:
** redesign of eiffeldoc generated HTML to reduce its size dramatically
** addition of a zsh completer for se
** installation script (install.sh) now supports the latest libgc-dev library (external garbage collector)
** finally got rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused legacy platforms (Amiga, Elate, BeOS, OS/2, Macintosh, HP RISC, IBM370, NS32000, MIPS, Pyramid 9810, SPARC, VAX) - in case you have a real use case for those we are happy to readd it
** 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
** C99 conforming C code generation (hopefully)
* Developer changes:
** RUN_FEATUREs now have clear names (hopefully)
** to better support the user access rights model of the more recent 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]

Wrapping C libraries

2018-09-15T18:08:54Z

Ramack: /* Low-level access to functions */

[[Category: Interfacing]]
== Developer's guidelines ==
=== or how to write GNU-Eiffel wrappers for a C library ===

<cite>
"longum iter est per praecepta, breve et efficax per exempla"<br/>
"The path of precept is long, that of example short and effectual."<br/>
Seneca the Elder<br/>
</cite>

So instead of giving rules I guide you on my path of wrapping the ZLib library, one of the most widespread compression libraries.

I deliberately chose a "low-level" library with very precise and narrow aims which lets me show basic wrapping techniques: a wider, properly designed library has infrastructures and details that requires to know some tricks from the beginning of the work, otherwise the resulting wrapper should be heavily re-worked many times.

I usually work with Debian and Ubuntu GNU/Linux, so all the system commands and the package names listed in this tutorial/how-to should apply without changes on Debian and Debian-derived machines. Other distributions, like Fedora, RedHat, Suse, Mandriva shall have similarly named packages. People using BSD OSes could have those libraries available in their package manager. As a last resort you can always download the sources, compile and install them manually. I hope you know how to do it, otherwise the rest of this document would be quite useless for you.

==== Prerequites ====

You should be proficient with:

* the C language,
* the Eiffel language,
* the C library you want to wrap; you should known how to use it in a C program; take some time to read the library documentation and to study the example provided in order to make yourself familiar with the style required to use the library. You will need them to provide extensive, readable documentation of your classes.

==== Software prerequisites ====

Make sure you have access on your machine to:

* Liberty Eiffel, you may download the Debian packages from
* The C headers of the library to wrap; you should be able to compile the examples of the library you're wrapping; so I issued

sudo apt-get install zlib1g-dev

* Documentation of the library. Even if it is not absolutely necessary to make working wrappers they are indeed necessary to provide properly documented, therefore usable classes; (GNU) Eiffel has standard rules on how to document code and we shall abide to that; adapting the original C documentation while we wrap various features is a good style to handle documentation. Please do not leave any part of your code undocumented. Spend some time reading the documentation. It is always worth the effort.

I would like to repeat the concept: even if source-code in general is intented to be read by a compiler to produce binary modules, its readability and understandability for people is of the utmost importance. Code is not meant to be written-once and never re-read. It actually happens that good code will be read again and again by many people. The fact that programs are covered and protected by copyright laws is not incidental. It means that source code is the expression of an author, like a novel or poetry; I like to think that this fact includes in itself, in-nuce that source text will be read by people several times. And this reading does occour when the source-code text is well-written, well-documentated, useful for study and reuse if its license does allow it.

This approach does resemble Knuth's Literate Programming and indeed many design choices made by Bertrand Meyer during the conception of Eiffel regarding readability and understandability of source-code, expecially those exposed in Object-Oriented Software Construction are strikingly similar to Knut's ideas.

Let's return to our wrapping/binding work after a due phylosophical digression

=== Preliminares ===

Most data structure in C are usually handled by reference, i.e. using pointers.

Passing objects by value is currently requires "expanded external classes" and will no be covered in this guide. Therefore if your library extensively pass structures around by value and not by reference (with a pointer), for example (TODO: put links to online example of passing structure by value) in function calls or contained in other structures our life will be quite hard. Fortunately enought most libraries handles most of its data structures by reference and zlib is no exception: in fact its basic functions takes pointers as first argument.

----
== Identifying types and classes ==

Now you will wonder how to identify the types used in Zlib. This is quite an extensive argument that people smarter than me already handled in great details here.

A simplicistic rule-of-thumb specifically fitted to wrap libraries written in C is that when we have several functions that takes a pointer to a struct this struct is a good candidate for a class and those functions are good candidates to be wrapped as features usable by an Eiffel program.

Zlib has many functions taking a z_streamp which is nothing more than a typedef-fed pointer to structure z_stream_s. We will wrap those facilities in the Eiffel's (non-expanded) class ZLIB_STREAM.

=== Code organization and class hierarchy. ===

Before diving into code writing let's spend some words on how to cleanly organize our work. We want to provide the user of our library a pretty object-oriented API; since he/she will look at the sources directly soon-or-later it is useful to separate the high-level features and classes, those that will be used directly in other Eiffel projects from the low-level details, like external features or plugins.

We usually place each wrapper library in its own directory following this organization:

* zlib/
** examples -- Examples on how to use the Zlib wrappers
** library -- Contains the high-level classes, those used directly in Eiffel programs
*** externals -- Contains the low-level classes to interface with C (externals, macros, enumeration and so on)
**** generated -- Contains the low-level classes automatically generated with a tool such as wrappers_generator
*** loadpath.se -- Lists the clusters of the library itself, i.e. which directories contains its classes
** loadpath.se -- Lists the clusters used by the library, i.e. its dependencies
** tests -- Contains the tests to be used with eiffeltest tool

If the library is conceptually separated into different areas, subsystems or if it is simple too wide to put cleanly every public class into a single directory we can split the content of the directory library into several sub-directory, like GLib wrapper. See its directory layout:

* eiffel-glib/library/
** core
** data_types
** externals
*** generated
** fundamentals
** utilities

Let's fill <code>zlib/library/loadpath.se</code>. It lists two directories: those containing the high-level classes, the same of the loadpath.se file itself, i.e. the current directory (.) and the ./externals directory which will contain deferred classes that provide access to external features.

<pre>
./
./externals/
</pre>

zlib/loadpath.se will list the clusters used by the library itself, i.e. its dependencies. Like the previous it is a plain text file containing directories or other loadpaths file (Ok... I'm not assuming proficiency with GNU-Eiffel here). Zlib is quite a "plain" library and does not have dependencies - here we are speaking of dependencies of the Eiffel wrappers - so he only shall list only the base cluster of a wrapper library, ../common/loadpath.se and the soad-path of the library itself <./library/loadpath.se/code>:

<pre>
../common/loadpath.se
./library/loadpath.se
</pre>

=== Low-level access to functions ===

Writing the Eiffel source code to access external C code is an extremely long, tedious and verbose process so a tool named '''wrappers_generator''' has been created.

It was not included in binary form in the adler release since it was not ready for prime time.
Now it isn't robust as I would like but at least it processes sources like Gtk3, Glib, &slasho;mq and other libraries without crashing.

It will be included into bell and later releases; before it's relase I would suggest to rebuild the compiler and work from the Git repository.

You can get the sources from https://savannah.gnu.org/projects/liberty-eiffel/ or from https://github.com/LibertyEiffel/Liberty and build it with install.sh script which also build wrappers_generator.

wrappers_generator does not parses C code directly but reads the output of gccxml or its successor, castxml. Those tools provides an XML description of the source code analyzed that greatly ease the task of generating glue code. In fact they were created for that purpose.

<pre>gccxml</pre> is available in Debian oldstable while <pre>castxml</pre> is available in Debian stable. Both are also available for Ubuntu, Redhat et cetera.

Given an XML file and a list of C files (headers or sources) to wrap wrappers_generator:

* for each source file create a deferred class containing all the wrappable functions found in that file; functions in foo.h are wrapped into FOO_EXTERNALS
* for each struct creates a deferred class containing queries and setters feature to manipulate all members which have an Eiffel wrapper type;
* the same is made for unions
* creates a deferred Eiffel class named like the xml file containing wrappers for all typedefs, so when you have to refer to C "long" which is notorious for change size on various platform you can use "like long" in Eiffel
* each enumeration is wrapped into expanded classes with proper queries and setters. That way they are as efficient as plain integers values but they can't assume arbitrary values; enum foobar is wrapped into FOOBAR_ENUM
* when the values of an enumeration are actually flags, i.e. they all are diffent powers of 2, it's wrapped as a "flag" enumeration with commands to set and unset each flag of the enum.
* C++ classes, namespaces and all its fineries are currently ignored
* macros, #defines and all cannot be handled since they are "preprocessed away" and their text is not preseted to gccxml or castxml
* variadic functions can't be wrapped in Eiffel
* it transform CamelCase into CAMEL_CASE for classes, camel_case for features (queries, commands and so on)
* if it doesn't exist it creates a directory plugin/c that will contain all the C code that will be compiled by liberty eiffel when using the library

It does not try to give high-level, directly usable wrappers but it writes fairly verbose low-level wrappers that hopefully will save you quite a lot of typing.

=== The rest of this document still needs to be adapted. ===

Let's write some low-level classes. We will put the functions found in the include file /usr/include/zlib.h in the class ZLIB_EXTERNALS and the low-level getters and setters features for the structure z_stream structure in the class Z_STREAM_STRUCT (this scheme is also used by eiffel-gcc-xml tool; I know it is simplicistic and that it could produce name-clashes but it has worked fine until now. ). Here's some examples
C function Eiffel feature
const char * zlibVersion (void); zlib_version: POINTER
int deflateInit (z_streamp strm, int level); deflate_init (a_stream: POINTER; a_level: INTEGER_32): INTEGER_32
int deflate (z_streamp strm, int flush); deflate (a_stream: POINTER;a_flush: INTEGER_32): INTEGER
int deflateEnd (z_streamp strm); deflate_end (a_stream: POINTER): INTEGER
int inflateInit (z_streamp strm); inflate_init (a_stream: POINTER): INTEGER
int inflate (z_streamp strm, int flush); inflate (a_stream: POINTER; a_flush: INTEGER): INTEGER
int inflateEnd (z_streamp strm); inflate_end (a_stream: POINTER): INTEGER

As you can see I have turned camelCaseFunction into camel_case_function which is far more in tune with Eiffel style. Int is actually an INTEGER_32 or only INTEGER (it still don't matter, even if I suspect that it will do soon: world is already filled with 64-bit machines and literally billion of devices with 4,8,16 bit CPU are in use today, not counting GPGPU)

Let's take a look at ZLIB_EXTERNALS. You'll see many entries like

inflate_init (a_stream: POINTER): INTEGER is -- int inflateInit (z_streamp strm);
external "plug_in"
alias "{
location: "${eiffel_libraries}/plugins"
module_name: "zlib"
feature_name: "inflateInit"
}"
end

this entry tells us that the Eiffel feature "inflate_init" refers to the symbol "inflateInit" in the module "zlib" of the plugins found in the directory.

Entries like this are the only "esoteric" Eiffel code you will see. All the details required to interface to C, to link to the actualy library and how to compile the code written in other languages is handled by the plugin part.

Without using plugins every Eiffel program should know all the details required to compile a C application with zlib. It would require to always use ACE files - even for simple examples - because you need to provide proper "c_compiler_options" and "linker_options"; for a single, simple library like Zlib it looks a tame task, only requiring to add -lzlib to the "linker_options" but when you start building real-world application things will get complicated really fast.

See SmartEiffel documentation on plugins.

All those functions returns an integer with standardized values #defined in the C header. We will wrap them in the deferred class ZLIB_CONSTANTS.

Deferred? Why deferred? We want to avoid the Eiffel programmer the burden to deal with all the details that C requires - otherwise we would have used plain C - so we do not want him/her to directly use that libraries. Deferred classes cannot have creation clauses so we are sure that no objects of type ZLIB_EXTERNALS and ZLIB_CONSTANTS will be created. They are helper classes that will be either inherited from or - more properly - inserted into ZLIB_STREAM and its effective heirs, ZLIB_INPUT_STREAM and ZLIB_OUTPUT_STREAM.

Making sure that the Eiffel developer will not use low-level features directly is the main reason why all the external features are not exported to anyone else, using the syntax feature {} -- External calls. This way only heirs - conforming or not - of that class can use them; for people coming from C++ it's like having private functions members.
C types

Here's a quick conversion table for various C types
C type Eiffel type
int INTEGER;
short int INTEGER_16
long int INTEGER_32 or 64
long long int INTEGER_64
int8_t (defined at stdint.h, ISO C 99) INTEGER_8
int16_t INTEGER_16
int32_t INTEGER_32
int64_t INTEGER_64
unsigned int NATURAL
unsigned short int NATURAL_16
unsigned long int NATURAL_32 on 32-bit, NATURAL_64 on 64.bit. See long int
unsigned long long int NATURAL_64
signed/unsigned char CHARACTER
float REAL_32
double REAL_64
long double REAL_EXTENDED
char BOOLEAN
void* or any other pointer POINTER

Some notes:

intXX_t are defined in GNU systems (Linux Glibc, CygWin and similar).
Currently INTEGER is mere alias for INTEGER_32 but this is bound to change in future version of SmartEiffel. Personally I think that it should be "the integer type with the same bit-lenght of C int".
A nice feature of long int is that is could be longer that int. So we can't really be sure whenever it is 32 or 64 bit. Usually it is an INTEGER_32 on 32-bit machines and INTEGER_64 on 64-bit machines. See this post on the SmartEiffel mailing list.
The same problem applies for long unsigned int: NATURAL_32 on 32-bits and NATURAL_64 on 64-bit. This mismatch can be quite problematic and it will be discussed-addressed later.
At the time of writing of this document SmartEiffel has some know issues regarding NATURALs types. If they actually do cause bugs there is an (unsatisfactory) workaround: use a bigger INTEGER. This implies a hidden conversion at C level and bargains correctness with a little waste of space and worse performance. Do not use an INTEGER of same size: it "usually" works nicely but this is a known source of nasty bugs since you will soon or later it will silently overflow.

An enlighting explanation about C variable types and declarations can be read on Wikipedia (I find particurarly confusing - expecially for the novice - that char is at the same time an 8-bit integer and an encoding for ASCII characters. Most programmers could always end up thinking about it only as a character. After more than 30 years they could have called it "byte". Yet this behaviour is fit the spirit of C very well. ).

The resulting ZLIB_CONSTANTS class is almost boring and undocumented. I maintained the documentation level found in the original documentation, since those are values that will be handled only by the implementation of the wrapper.

Have a look at WRAPPER_HANDLER. Eiffel has the ability to selectively export Any class that needs to access some of the
Access to structure field

Let's wrap the z_stream structure (the structure name is actually struct z_stream_s typedeffed to z_stream during its definition); the wrapper will have a similar two layer design: the low-level Z_STREAM_STRUCT will be a deferred class, with feature {} -- Hidden, low-level getters and setters. This class will also have a feature struct_size: INTEGER that will be the value of sizeof(z_stream)

Field named FooBar in the struct my_struct will be read with the Eiffel query my_struct_get_foo_bar and set with the command my_struct_set_foo_bar. Remember that those are low-level features; references to other objects will be pointers and its signature will be one of an external function: the first argument will be always the address of - a POINTER to - the wrapped struct.
Naming of placeholder arguments

Placeholder names should be chosen in a way that makes the documentation of the feature in English as smooth as possible for a proper argument placeholder for the Gnu-Eiffel language. "CamelCase" will be translated into "a_camel_case", "ENOO" is translated into "an_enoo". Eventual underscores in front of `a_name' are removed: "__foo" becomes "a_foo". The prefixed preposition is added to make clearer that the name refers to a generic value, not to a particular one. Always tries to use a placeholder that can be directly put in the feature's documentation without paraphrase.
ZLIB_STREAM, at last.

So let's write something that will be used in an actual Eiffel program! We start writing ZLIB_STREAM from file common/skeleton that provides us the usual LGPL-2.1-or-later headers. It inserts ZLIB_EXTERNALS and Z_STREAM_STRUCT.

TODO: finish this
The "common" cluster

The basic building blocks of a wrapper library have been put in the common cluster.

The WRAPPER class it the "fundamental" one even if embarassingly simple. Its only effective field (i.e.: stored, non-computed) is the handle POINTER. It shall handle the allocation and deallocation of the memory referred by handle so it is an heir of DISPOSABLE but it doesn't define dispose because there is no such a thing like a default memory handling in C.

C_STRUCT inherits from WRAPPER and provides default implementations for copy, is_equal and from_external_pointer features; it introduces the deferred "struct_size" query which should give the same result of C operator sizeof(MyStruct).

Note that there are - at least conceptually - other potentially heirs of WRAPPER, like pointers to functions

Many C libraries often return const char* strings. Those strings shall not be modified and their memory will be handled by the library; by all other means they actually are plain strings. A correct behaviour is to write foo: STRING is do create Result.from_external_copy(a_function_returning_a_const_char_pointer(handle)) end; a STRING is meant to be manipulated and changed and has control on the memory of its content. Here we are instead given a piece of memory holding some text that is "mostly read-only" whose control is held by the library. To provide correct behaviour STRING must copy the buffer, from_external can't be used. CONST_STRING is an effective heir of STRING that provides efficient wrapping of "const strings". It is usable like any other STRING but all the changes are made to a separe buffer preserving the original content - we are actually not allowed to change it. No further memory is allocated when a CONST_STRING is created: the buffer returned by the C library is used directly. For example, GTK+ has many calls like const gchar* gtk_entry_get_text (GtkEntry *entry); Memory efficiency is achieved making changing features slower. If you need to change its content consider using its feature string to get a new (non-const) STRING with the same content.

TODO: add proper description about:
CACHING_FACTORY
C_ARRAY
COMPARABLE_C_STRUCT
COMPARABLE_WRAPPER
CONST_STRING
C_OWNED
C_STRUCT
EIFFEL_OWNED
ENUM
EXPANDED_WRAPPER
GLOBAL_CACHE
GLOBALLY_CACHED
HASHABLE_WRAPPER
ITERATOR_ON_C_ARRAY
LINKED_STRING
MIXED_MEMORY_HANDLING
NULL_TERMINATED_C_ARRAY
NULL_TERMINATED_STRING_ARRAY
POINTER_HANDLING
REFERENCE_COUNTED
SHARED
STRING_ARRAY
STRING_ARRAY_ITERATOR
WRAPPER_COLLECTION
WRAPPER_DICTIONARY
WRAPPER
WRAPPER_FACTORY
WRAPPER_HANDLER
WRAPPERS_CACHE
Enumerations

There are two general tecnique to wrap an enum.

Put all the possible values of enumerations into a class as INTEGER constants accessibile to the user of your library. This is mostly similar to the actual usage of an enumeration. Each and every feature that accept an enum value as argument will need a precondition like is_valid_foo (a_foo_value)
Create a new type. In fact an enumeration is an INTEGER that can assume only precise and prestabilited values, so that its value is correct and consistent all the times. Class ENUM provides some facilities to achieve this. It shall be used in classes like this:

-- This file have been created by eiffel-gcc-xml.
-- Any change will be lost by the next execution of the tool.

expanded class PANGO_WEIGHT

insert ENUM

creation default_create
feature -- Validity
is_valid_value (a_value: INTEGER): BOOLEAN is
do
Result := ((a_value = pango_weight_ultralight) or else
(a_value = pango_weight_light) or else
(a_value = pango_weight_normal) or else
(a_value = pango_weight_semibold) or else
(a_value = pango_weight_bold) or else
(a_value = pango_weight_ultrabold) or else
(a_value = pango_weight_heavy))
end

feature -- Setters
default_create, set_ultralight is
do
value := pango_weight_ultralight
end

set_light is
do
value := pango_weight_light
end

set_normal is
do
value := pango_weight_normal
end

set_semibold is
do
value := pango_weight_semibold
end

set_bold is
do
value := pango_weight_bold
end

set_ultrabold is
do
value := pango_weight_ultrabold
end

set_heavy is
do
value := pango_weight_heavy
end

feature -- Queries
is_ultralight: BOOLEAN is
do
Result := (value=pango_weight_ultralight)
end

is_light: BOOLEAN is
do
Result := (value=pango_weight_light)
end

is_normal: BOOLEAN is
do
Result := (value=pango_weight_normal)
end

is_semibold: BOOLEAN is
do
Result := (value=pango_weight_semibold)
end

is_bold: BOOLEAN is
do
Result := (value=pango_weight_bold)
end

is_ultrabold: BOOLEAN is
do
Result := (value=pango_weight_ultrabold)
end

is_heavy: BOOLEAN is
do
Result := (value=pango_weight_heavy)
end

feature {WRAPPER, WRAPPER_HANDLER} -- Low level values
pango_weight_ultralight: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_ULTRALIGHT"
}"
end

pango_weight_light: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_LIGHT"
}"
end

pango_weight_normal: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_NORMAL"
}"
end

pango_weight_semibold: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_SEMIBOLD"
}"
end

pango_weight_bold: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_BOLD"
}"
end

pango_weight_ultrabold: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_ULTRABOLD"
}"
end

pango_weight_heavy: INTEGER is
external "plug_in"
alias "{
location: "foo"
module: "bar"
feature_name: "PANGO_WEIGHT_HEAVY"
}"
end

end

As you can see each possible value has a setter command<br>(set_light, set_normal and so on) and a boolean<br>query (is_light, is_normal). As usual low-level values are accessible<br>only by a WRAPPER or a WRAPPER_HANDLER.

Using eiffel-gcc-xml

Have a look at the manually written ZLIB_EXTERNALS. Eiffel is a language that is meant to be easy to the reader at the cost of being verbose. All that text of source to access a bunch of C functions. Think about serious libraries that have literally thousands of functions, structures, and enumeration! Writing the low level side of those wrappers is a really long, tedious task, the kind of task that people usually would leave to an unfaticable, astonishgly fast yet quite dumb worker, a computer. Andreas Leitner - who is surely quite smarter than myself - wrote a C parser for his Eiffel Wrapper Generator. I do not have neither the time neither the abilities of Andreas but it seems that I'm more lucky than him. In fact by the time I got serious with this project, people with the same problem, requiring tons of wrappers for Python, produced gcc-xml. These days parsing XML is a considered a common task, a task to be left to standard libraries, so SmartEiffel have an XML parser. So I wrote a little tool name "eiffel-gcc-xml" that takes the output of gcc-xml as input to produce the low-level "external" classes that we need to access functions, structures and enumerations.

Well, it actually requires a little more work since it breaks very often.
Memory handling
C_STRUCT is a wrapper for a data structure implemented in C programming language using a structure.
It does not make any assumption about memory handling; the developer of a SmartEiffel wrapper of a C library has to inherit to create a proper wrapper for it the developer shall inherit both from this class and from classes providing memory handling behavior, depending on how structure's memory shall be handled. This is decided case-by-case by C library.
Currently available memory handling classes are:

C_OWNED: memory is always handled by the underlying C library.
EIFFEL_OWNED: once created memory is fully handled by Eiffel runtime, usually with the Garbage Collector.
GLOBALLY_CACHED: Until disposed by Eiffel the wrapper registered in wrappers dictionary will be the unique wrapper used on the Eiffel side.
MIXED_MEMORY_HANDLING: whose memory can either by handled by the Eiffel library or by the underlying C code. Who handles memory is decided on a per-object based on the value of the flag `is_shared': handle will not be freed on dispose of the Eiffel wrapper object, when `is_shared' is true.
REFERENCE_COUNTED: memory is handled thought reference counting, i.e.GObject

Add proper examples of the various memory handling classes.
Implementing collections
Quite often objects are stored into containers or collections like arrays, linked lists, dictionaries, hashed-tables and so on. Many C libraries provides their own implementation of the classic containers, for example the GLib library provides GList, GSList, GHashTable and many others.
A WRAPPER_COLLECTION is a COLLECTION implemented wrapping some facilities offered by the wrapped C library, like GLib's linked list GList.
When you wrap those data structures you will encounter two kinds of problems:

Pointer returned by C containers could be newly allocated, not already wrapped by the Eiffel wrapper or already wrapper by the Eiffel wrapper. You can't naively create a new WRAPPER every time. Beside the obvious waste of memory and the stress you put on the garbage collector you will break most postconditions and invariant of a COLLECTION, since things that seems obvious like

do_stuff (my_collection: WRAPPER_COLLECTION[ITEM]) is require
my_collection/=Void not my_collection.is_empty local a,b: ITEM do a :=
my_collection.first b := my_collection.first check will_fail: a = b end end

In fact a and b will be different wrappers referring to the same underlying C structure. A WRAPPER_COLLECTION shall avoid this repeated, unnecessary and wrong creation of WRAPPERs, that will breaks invariants and post-conditions of a COLLECTION.
A solution is to inherit from WRAPPERS_CACHE, initializing cache at creation time and keeping it updated during usage. Cache's key is the address (pointer) to the wrapped C structure, value is the corresponding Eiffel wrapper. This way you can get back an already-created Eiffel wrapper.
Classes can implement different scheme; for example G_OBJECT_LIST retrieve the reference to the eventual WRAPPER directly from underlying GObject.

The container has no means to know how it shall create the wrapper for it, since C does not have the notion of generic, strongly typed container. The effective type of the containee is either not know by WRAPPER_COLLECTION or worse its conteinees could actually belong to different classes, sharing a common ancestor.
Since each library has its own idea on how the programmer shall handle �memory when dealing with containers an effective, non-deferred heir of WRAPPER_COLLECTION shall implement `wrapper' feature that given a pointer creates or retrieve a WRAPPER of the fittest class. Usually "plain" usage could return a fixed type; more elaborate type systems like GObject could provide the facilities necessary to pick a useful Eiffel type.

TODO: finish it.
Comparability and hashability
Some collections does not require anything in particular to their containee, like arrays or linked lists. Other collections needs either to compare their containee or to obtain an hash value from it. Therefore wrapper classes that are conceptually comparable or hashable shall inherit from COMPARABLE_WRAPPER and HASHABLE_WRAPPER respectively so they could be stored into collections that requires such abilities.
How to adapt old wrappers
(This is almost obsolete) Previous design was a black-or-white design: a class was either Eiffel-owned or not; C_STRUCT's are "owned" by the Eiffel code, and the Eiffel side should keep then longest lived reference to this struct; SHARED_C_STRUCT modelled the non-Eiffel-owned.
This approach is overly simplicistic since real-life libraries implement a wide spectrum of memory handling policies. One solutions does not fit all needs. Study the documentation of the library and pick the right memory handling Eiffel class.
The long int problem

Shortly it could be solved having two separate clusters one for 32bit, one for 64 bit where a deferred class defines a parameterless query for anchored declaration like

long_int: INTEGER_32 is do end

long_int: INTEGER_64 is do end

but this looks like an unfeasible hack to me, at least now. Currently it is the only available answer; a "proper" solution would require changes in both the compiler and the standard library. I would like to know how ISE solved this.

GObject-based libraries

Nowadays many libraries are based on the GLib Object System also known as Gobject. This library "provides a portable object system and transparent cross-language interoperability". It is used as the basic building block for literally hundeds of libraries and applications; in fact the command apt-cache rdepends libglib2.0-0 |wc -l told me that more than 2200 applications and libraries depend on either GLib or GObject.

GObject implement its own classed type system. With the exception of basic types (and some other subtleties I will write later) all objects are structures referred by pointer, i.e. non-expanded classes in Eiffellese; the type of each object is identified by a number, a GType which has an associated structure to describe the class - the type - itself. During startup of the Eiffel application the wrapper library will register for each type name (i.e. GtkWindow, GtkButton....) it wraps an agent that given a pointer creates an Eiffel wrapper object for the creation_agents dictionary, with a call similar to creation_agents.put (agent create_gtk_window, "GtkWindow"), given the feature create_gtk_window (p: POINTER): GTK_WINDOW is do create Result.from_external_pointer(p) end.

A Gobject can store arbitrary properties into itself. We use this to store a reference pointer to its Eiffel wrapper.

When we receive a pointer to a Gobject the G_OBJECT_FACTORY first looks if this Gobject already has an attacked wrapper (an effective heir of G_OBJECT). Otherwise it ask the Gobject its GType and the associated class-name. It this class-name has a creation agent the wrapper is created invoking the retrieved creation agent; otherwise we recursively look at its parent class until we find a type that has a corresponding creation agent.

When an effective G_OBJECT heir is actually created either explicitly because we know for sure its type or throught a creation agent the address of the wrapper is stored in the property "eiffel-wrapper" using the C function g_object_set_qdata (see store_eiffel_wrapper in G_OBJECT).

As usual this approach is both correct, memory efficient and collection-friendly (see "Implementing collections" earlier) at the cost of being computing intensive. There are times when the wrapper library has to create transient wrappers for shortly lived objects. Here enters secondary wrappers, or G_OBJECTs that are not referred-by the GOBject they refer to. Letting code speak: having a_gtk_window_ptr: POINTER; my_window: GTK_WINDOW; factory: G_OBJECT_EXPANDED_FACTORY check create my_window.secondary_wrapper_from(a_gtk_window_ptr) /= factory.wrapper(a_gtk_window_ptr) end will hold and also create my_window.main_wrapper_from(a_gtk_window_ptr); check my_window = factory.wrapper(a_gtk_window_ptr) end will be successfully passed. The difference is that the first is only an allocation of a smallish object (few bytes) while the latter could potentially require several looks-up into a dictionary plus an O(n) search into the GObject properties (during g_object_get_qdata used to see if a wrapper does actually exist)

TODO: show how to wrap a typical GObject-using library, like Gnome's GConf configuration system.
Commit's policy

There is no strict rule...
Ideally each commit should provide compilable code and working examples.
Provided examples and classes can be unfinished and uncomplete, can contain warnings, empty features and so on. My motto is "something is better than nothing".
it is nice to tell other developers what are you working on; anemail on eiffel-libraries-devel@gna.org suffice.
I promise I won't track you with a 9-tail cat to bash you if you commit uncompilable code.
Code that compiles is a good thing. Wisely designed code that compiles is better, since it has better performances; but I prefer published, working code even if has no state-of-the-art performances instead of

Various very old notes
Those notes are left here to be worked on.

Suggested
Start copying original documentation into an Eiffel class and comment it out entirely.
Add proper indexing clauses, then progressively convert it into Eiffel from top to bottom.
Sketch difficult features into comments.
This behaviour is not meant to pile rubbish, but to quickly know how much work we still have to do.
This means that the resulting Eiffel classes will be a derivative work of the original documentation of the library. This is usally not a problem these days because documentation is often automatically extracted from sources, so the Eiffel wrapper will end up having the same license of the wrapper library; for example our GTK+ wrapper being a derivative work of the actual GTK+ C library must abide its LGPL license.
All the infrastructure of GTK+, including GObject are - in my humble opinion - explicitly designed to make the life easy for people writing wrappers for loosely-typed languages such as Python, Perl and other scriptiong languages. This (sadly) means that life for heavily/strongly-typed languages such as Eiffel are made annoying.
Objects like closures and other amenities like that won't be wrapped until the rest is done and working.

=== Incoming tools ===

Libraries using gobject-introspection and typelib provides much more information to write wrappers and binding for other languages.

The metadata of a typelib file allows to directly produce high-level wrappers.

This will give us support for Gtk3, Glib, Cairo and many many other libraries in a much faster way that manually wrapping each one.

The tool that will generate such binding will be named '''leggow''', acronym for '''Liberty Eiffel Generator of GObject Wrappers''' and it currently lies in the leggow branch in repository https://github.com/tybor/Liberty but it is currently only an idea.

Getting Started

2018-09-15T18:08:03Z

Ramack: /* Bootstrap from git source */

== 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 ==
So far we don't have an installer for windows, but a [[GSoC_-_Windows_Support|current GSoC project]] is working on that. In case of interest get in touch with us, maybe you can provide some input or help with testing.

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

ECMA

2018-09-07T18:50:24Z

Ramack: add is_equal comment

In [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf ECMA-367] the ECMA committee TC39-TG4 defines an Eiffel standard. Liberty is not committed to fully implement this standard, but it will adopt many more of the improvements than SmartEiffel did at the time. Liberty will implement those parts of ECMA that match the effective, efficient and simple design of previous versions of Eiffel. The parts requiring an extensive run-time model will not be currently implemented; those that needlessly complicate the language to comply to widespread programming conventions will be evaluated case-by-case.

==Liberty Eiffel offers these ECMA features already:==
* '''attribute''' keyword may be used to define an attribute including self-initialization with contracts checking.

With small deviations:
* Non-conforming inheritance (but using '''insert''' instead of '''inherit {NONE}'''); see [[Typing policy]]
* [https://github.com/LibertyEiffel/Liberty/issues/78 Assigners] with the following deviations:
** VFAC (ECMA §8.5.22) is not enforced (let the standard rules of the replacing procedure call play instead)
** assigners are inherited with proper renames (ECMA does not explicitly specify the rules either way)
* [[task:12666|Cosmetic syntax changes]]:
** '''is''' is now optional
** '''alias''' is implemented, including '''alias "[]"'''
** '''note''' replaces '''indexing''' and can be placed at the start and end of a class, and at the start of a feature
** '''create''' replaces '''creation'''
* [[task:12661|generic creation]]

==These ISE features are also implemented:==

[[task:13103|These features]] are not (yet) in the ECMA standard:
* the newer '''alias "()"'''
* its companion implicit tuples
* '''if-then-else''' expressions

==These features are planned:==
* [[task:12662|generic inheritance]]
* [[task:12660|conversions]] - maybe with a slightly stricter interpretation
* [[task:12653|named TUPLE elements]]
* [[task:12664|void-safety]] (Liberty implementation will probably differ from ECMA)
* '''attached''' vs '''detached'''
* '''across'''

==These ECMA features are not planned in Liberty:==
* No-variant agent arguments.

==These features are not in ECMA but implemented in Liberty:==
* [[task:12671|inline agents are closures]]
* explicit agent conformance rules (see [http://www.jot.fm/issues/issue_2004_04/article7/ this JOT paper])

==Not yet decided:==
* <code><nowiki>TYPE[G]</nowiki></code> and explicit conversion
* postcondition of is_equal: same_type: Result implies same_type(other)
** this essentially forbids any equal objects with different types and is inconsistent to the current implementation in Liberty. It has some nice background (e. g. symmetry is not easy to guarantee without that), but we also do not want to brake existing code

See also [[Compatibility]].

Upcoming release names

2018-09-04T21:07:38Z

Ramack: resort future names

The Liberty releases are named after famous engineers names starting by A for the first release, B for the second, and so on.
Here is a list of name suggestions for future releases:
* [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss] ('''"curtiss"''', currently being worked on)
* [https://en.wikipedia.org/wiki/Jack_Dennis Jack Dennis] ('''"dennis"''')
* [https://en.wikipedia.org/wiki/Thomas_Edison Thomas Edison] ('''"edison"''')
* [https://en.wikipedia.org/wiki/John_Ambrose_Fleming John Ambrose Fleming] ('''"fleming"''')
* [https://en.wikipedia.org/wiki/Dennis_Gabor Dennis Gabor] ('''"gabor"'''), [https://en.wikipedia.org/wiki/Robert_H._Goddard Robert Goddard] ('''"goddard"''') or [https://en.wikipedia.org/wiki/Gustave_Eiffel Gustave Eiffel]('''"gustave"''') (@ramacks preference is Gabor)
* [https://en.wikipedia.org/wiki/Grace_Hopper Grace Hopper] ('''"hopper"''')
* I?
* J?
* [https://en.wikipedia.org/wiki/Jack_Kilby Jack Kilby] ('''"kilby"''')
* [https://en.wikipedia.org/wiki/Cornelis_Lely Cornelis Lely] ('''"lely"''')
* [https://en.wikipedia.org/wiki/James_Clerk_Maxwell James Clerk Maxwell] ('''"maxwell"''')

Feel free to suggest any further names. You may read the lists of engineers on WikiPedia:

* [https://en.wikipedia.org/wiki/Lists_of_engineers Lists of engineers]
* [https://en.wikipedia.org/wiki/List_of_civil_engineers List of civil engineers]
* [https://en.wikipedia.org/wiki/List_of_structural_engineers List of structural engineers]

Each published final release will also have a numeric tag in the form of "year.month" which is more simple to remember.

Already released versions are listed in [[Versions history]].

Configuration file

2017-02-17T19:34:26Z

Ramack:

Most Liberty Eiffel tools need some kind of configuration which is stored in a unique file to allow the user not too have over-long command lines. This is named '''liberty.cfg''' on windows systems and '''liberty.se''' on unix-like systems.

In particular it contains
* general settings like system type, number of processes to start during compilation
* paths to find tools, environment variables, [[short]] templates...
* paths of the clusters that define all the classes available by default (the universe).
* '''se''' shortcuts for the available tools
* C-compiler options for each c_mode

An initial version of this configuration is generated by [[install|the installation tool]] of Liberty Eiffel.

== Where is this configuration ==
It is possible to have several configuration files, which are treated by priority and more specific files can override the settings from the general ones. The lowest priority is attributed to system-wide files, while user-specific (e.g. <tt>~/.serc</tt>) and session-specific (the <tt>Liberty</tt> environment variable) get higher priority. In case a configuration location is a directory, all the entries of the directory are merged (or to be accurate: all entries are handled with priority defined via alphabetical sort of the names). All that because of some distributions like to add/remove files instead of grep'ing and sed'ing huge configuration file.
Default configuration file locations:
{|
|-
| Windows and DOS:
| '''<TT>%ALLUSERSPROFILE%\Liberty-Eiffel</TT>''', <TT>%USERPROFILE%\SE.CFG</TT>, <TT>%USERPROFILE%\LIBERTY.CFG</TT>, '''<TT>%USERPROFILE%\Liberty-Eiffel</TT>''' (lookup in this order)
|-
| Unix and Cygwin:
| <TT>/etc/serc</TT>, <TT>/etc/xdg/liberty-eiffel</TT>, '''<TT>/etc/liberty-eiffel</TT>''', <TT>/usr/local/etc/liberty-eiffel</TT>, '''<TT>~/.config/liberty-eiffel</TT>''', <TT>~/.serc</TT> <TT>~/.liberty-eiffel</TT> (look-up in this order, XDG_CONFIG_HOME is taken into account to adjust the paths)
|-
| Elate:
| <TT>/lang/eiffel/serc</TT>
|}
The suggested directories are '''bold'''.

The other operating systems don't have a default value, the <tt>Liberty</tt> environment variable must be used. If you have such an operating system and you think there is a reasonable default value, '''thanks for telling us'''.

== File syntax ==

The file is written using a simple text format. It is split in sections that each begin with a word between square brackets on a single line. Each section is comprised of key-value pairs separated by a colon.

Example:

[General]
bin: /home/cyril/Liberty/bin/
sys: /home/cyril/Liberty/sys/
short: /home/cyril/Liberty/short/
os: UNIX
flavor: Linux
tag: 3
jobs: 4

=== The General section ===

This section is named <TT>[General]</TT>. It must provide the following keys:

{|
|-
| width="10%" valign="top" | <TT>bin</TT>
| the path to the compiler executables. This path is used in particular by the [[se]] tool (see below the Tools section) and [[compile]].
|-
| valign="top" | <TT>sys</TT>
| the path to the Liberty Eiffel system files. This path is used by [[compile_to_c]]. It contains all the basic files included by those compilers. They define the "basic bricks" of the generated Eiffel system.
|-
| valign="top" | <TT>short</TT>
| the path to the [[short]] templates (modes <TT>-html</TT>, <TT>-tex</TT>, etc.)
|-
| valign="top" | <TT>os</TT>
| the type of the operating system Liberty Eiffel is installed on. The recognized types are: UNIX, Windows, Cygwin, BeOS, Macintosh, Amiga, DOS, OS2, OpenVMS, Elate.
|-
| valign="top" | <TT>flavor</TT>
| allows a more accurate specification of the operating system type, useful for some plugins. For instance, if the <TT>os</TT> is UNIX, the <TT>flavor</TT> can be Linux. There is no predefined list of values; plugins must tell which are the supported <TT>flavor</TT>s.
|-
| valign="top" | <TT>tag</TT>
| normally only used by the [[install|installation tool]] to define the version of the configuration file. There should be ascending compatibility between versions but '''currently, if the tag is not the one of the installation tool, no data is kept'''. This behavior was changed in SmartEiffel 2.3, to keep as much data as possible.

The tag value was '''3''' for SmartEiffel 2.2 and 2.3.
|-
| valign="top" | <TT>jobs</TT>
| if a tool has some tasks which may be done in parallel (e. g. calling the C compiler for generated C files) it creates at most the configured amount of processes. Performance-wise, it's likely best not to use hyperthreading, especially when compiling big systems. An example: if your system reports a quadcore processor, it might actually be equipped with a dualcore with hyperthreading activated. In that case it's likely best to set <TT>jobs</TT> to 2 and not to 4.
|}

=== The Environment section ===

The environment section allows you to define ''environment variables'' specific to Liberty Eiffel. In particular these variables are available in the remaining of the configuration file, in the <tt>loadpath.se</tt> files, ACE files and some command line arguments.

The [[install|installation tool]] installs the following default variables:

[Environment]
path_liberty: /home/cyril/Liberty/
path_liberty_core: /home/cyril/Liberty/src/lib/
path_liberty_extra: /home/cyril/Liberty/src/wrappers/
path_smarteiffel: /home/cyril/Liberty/src/smarteiffel/
path_tools: /home/cyril/Liberty/src/tools/
path_tutorial: /home/cyril/Liberty/tutorial/

Note that anyone can add their own variables.

=== The universe ===

The universe is the set of all known clusters. It is defined in the <TT>[Loadpath]</TT> section.

The [[install|installation tool]] installs the following default universe:

[Loadpath]
liberty_core: ${path_liberty_core}loadpath.se
liberty_extra: ${path_liberty_extra}loadpath.se
test: ${path_liberty}test/loadpath.se
smarteiffel: ${path_smarteiffel}loadpath.se
tools: ${path_tools}loadpath.se
tutorial: ${path_tutorial}loadpath.se

Note that anyone can add their own tools to the libraries they use most.

'''Caveat''': the universe is ''not'' used by the tools if an ACE file is given. In this case, the ACE file must describe the whole universe. On the other hand it is very simple to do so since just adding a single line or two to your ACE file will produce the desired effect:

cluster
standard: "${path_liberty_core}loadpath.se"

=== Tools ===

All the tools used by the [[se]] command are set here. These tools must be in the directory pointed to by the <tt>bin</tt> key of the <tt>[General]</tt> section. The key is used as first argument of [[se]].

The [[install|installation tool]] installs the following default commands:

[Tools]
ace_check: ace_check
c2c: compile_to_c
c: compile
class_check: class_check
clean: clean
doc: eiffeldoc
find: finder
make: se_make.sh
mock: mocker
pretty: pretty
short: short
test: eiffeltest
test_ng: eiffeltest_ng
test_server: eiffeltest_server
wrap: wrappers_generator
x_int: extract_internals

Note that anyone can add their own tools, as long as the executable is in the directory pointed to by the <tt>bin</tt> key of the <tt>[General]</tt> section and an entry is added to the <tt>[Tools]</tt> section.

=== C modes ===

These modes are used by the C back-end: used C compiler, options... E. g.
[boost]
c_compiler_type: gcc
c_compiler_path: gcc
c_compiler_options: -pipe -O2 -fno-gcse
c_linker_path: gcc
c_linker_options: -Xlinker -no-as-needed
cpp_compiler_type: g++
cpp_compiler_path: g++
cpp_compiler_options: -pipe -O2 -fno-gcse
cpp_linker_path: gcc
cpp_linker_options: -Xlinker -no-as-needed

By default some C modes are automatically associated to the Eiffel compilation levels (<TT>-boost</TT>, <TT>-require_check</TT>, etc.). The C mode can also be explicitely set in the command line of [[compile_to_c|compile_to_c]] or [[compile|compile]] thanks to the <TT>-c_mode</TT> option.

The following C modes are default for a standard installation: <TT>boost</TT>, <TT>no_check</TT>, <TT>require_check</TT>, <TT>ensure_check</TT>, <TT>invariant_check</TT>, <TT>loop_check</TT>, <TT>all_check</TT>, <TT>debug_check</TT> and <TT>release</TT>. Only the last one must be explicitely set; it is usually used to finalize a program (<TT>se c -boost -c_mode release ...</TT>)

Usually the default C modes depend on the chosen C compiler and needs adaption if GCC is not used.

Configuration file - liberty.cfg

2017-02-17T19:34:05Z

Ramack: Ramack moved page Configuration file - liberty.cfg to Configuration file

#REDIRECT [[Configuration file]]

Configuration file

2017-02-17T19:34:05Z

Ramack: Ramack moved page Configuration file - liberty.cfg to Configuration file

Most Liberty Eiffel tools need some kind of configuration which is stored in a unique file to allow the user not too have over-long command lines. This is named liberty.cfg on windows systems and liberty.se on unix-like systems.

In particular it contains
* general settings like system type, number of processes to start during compilation
* paths to find tools, environment variables, [[short]] templates...
* paths of the clusters that define all the classes available by default (the universe).
* '''se''' shortcuts for the available tools
* C-compiler options for each c_mode

An initial version of this configuration is generated by [[install|the installation tool]] of Liberty Eiffel.

== Where is this configuration ==
It is possible to have several configuration files, which are treated by priority and more specific files can override the settings from the general ones. The lowest priority is attributed to system-wide files, while user-specific (e.g. <tt>~/.serc</tt>) and session-specific (the <tt>Liberty</tt> environment variable) get higher priority. In case a configuration location is a directory, all the entries of the directory are merged (or to be accurate: all entries are handled with priority defined via alphabetical sort of the names). All that because of some distributions like to add/remove files instead of grep'ing and sed'ing huge configuration file.
Default configuration file locations:
{|
|-
| Windows and DOS:
| '''<TT>%ALLUSERSPROFILE%\Liberty-Eiffel</TT>''', <TT>%USERPROFILE%\SE.CFG</TT>, <TT>%USERPROFILE%\LIBERTY.CFG</TT>, '''<TT>%USERPROFILE%\Liberty-Eiffel</TT>''' (lookup in this order)
|-
| Unix and Cygwin:
| <TT>/etc/serc</TT>, <TT>/etc/xdg/liberty-eiffel</TT>, '''<TT>/etc/liberty-eiffel</TT>''', <TT>/usr/local/etc/liberty-eiffel</TT>, '''<TT>~/.config/liberty-eiffel</TT>''', <TT>~/.serc</TT> <TT>~/.liberty-eiffel</TT> (look-up in this order, XDG_CONFIG_HOME is taken into account to adjust the paths)
|-
| Elate:
| <TT>/lang/eiffel/serc</TT>
|}
The suggested directories are '''bold'''.

The other operating systems don't have a default value, the <tt>Liberty</tt> environment variable must be used. If you have such an operating system and you think there is a reasonable default value, '''thanks for telling us'''.

== File syntax ==

The file is written using a simple text format. It is split in sections that each begin with a word between square brackets on a single line. Each section is comprised of key-value pairs separated by a colon.

Example:

[General]
bin: /home/cyril/Liberty/bin/
sys: /home/cyril/Liberty/sys/
short: /home/cyril/Liberty/short/
os: UNIX
flavor: Linux
tag: 3
jobs: 4

=== The General section ===

This section is named <TT>[General]</TT>. It must provide the following keys:

{|
|-
| width="10%" valign="top" | <TT>bin</TT>
| the path to the compiler executables. This path is used in particular by the [[se]] tool (see below the Tools section) and [[compile]].
|-
| valign="top" | <TT>sys</TT>
| the path to the Liberty Eiffel system files. This path is used by [[compile_to_c]]. It contains all the basic files included by those compilers. They define the "basic bricks" of the generated Eiffel system.
|-
| valign="top" | <TT>short</TT>
| the path to the [[short]] templates (modes <TT>-html</TT>, <TT>-tex</TT>, etc.)
|-
| valign="top" | <TT>os</TT>
| the type of the operating system Liberty Eiffel is installed on. The recognized types are: UNIX, Windows, Cygwin, BeOS, Macintosh, Amiga, DOS, OS2, OpenVMS, Elate.
|-
| valign="top" | <TT>flavor</TT>
| allows a more accurate specification of the operating system type, useful for some plugins. For instance, if the <TT>os</TT> is UNIX, the <TT>flavor</TT> can be Linux. There is no predefined list of values; plugins must tell which are the supported <TT>flavor</TT>s.
|-
| valign="top" | <TT>tag</TT>
| normally only used by the [[install|installation tool]] to define the version of the configuration file. There should be ascending compatibility between versions but '''currently, if the tag is not the one of the installation tool, no data is kept'''. This behavior was changed in SmartEiffel 2.3, to keep as much data as possible.

The tag value was '''3''' for SmartEiffel 2.2 and 2.3.
|-
| valign="top" | <TT>jobs</TT>
| if a tool has some tasks which may be done in parallel (e. g. calling the C compiler for generated C files) it creates at most the configured amount of processes. Performance-wise, it's likely best not to use hyperthreading, especially when compiling big systems. An example: if your system reports a quadcore processor, it might actually be equipped with a dualcore with hyperthreading activated. In that case it's likely best to set <TT>jobs</TT> to 2 and not to 4.
|}

=== The Environment section ===

The environment section allows you to define ''environment variables'' specific to Liberty Eiffel. In particular these variables are available in the remaining of the configuration file, in the <tt>loadpath.se</tt> files, ACE files and some command line arguments.

The [[install|installation tool]] installs the following default variables:

[Environment]
path_liberty: /home/cyril/Liberty/
path_liberty_core: /home/cyril/Liberty/src/lib/
path_liberty_extra: /home/cyril/Liberty/src/wrappers/
path_smarteiffel: /home/cyril/Liberty/src/smarteiffel/
path_tools: /home/cyril/Liberty/src/tools/
path_tutorial: /home/cyril/Liberty/tutorial/

Note that anyone can add their own variables.

=== The universe ===

The universe is the set of all known clusters. It is defined in the <TT>[Loadpath]</TT> section.

The [[install|installation tool]] installs the following default universe:

[Loadpath]
liberty_core: ${path_liberty_core}loadpath.se
liberty_extra: ${path_liberty_extra}loadpath.se
test: ${path_liberty}test/loadpath.se
smarteiffel: ${path_smarteiffel}loadpath.se
tools: ${path_tools}loadpath.se
tutorial: ${path_tutorial}loadpath.se

Note that anyone can add their own tools to the libraries they use most.

'''Caveat''': the universe is ''not'' used by the tools if an ACE file is given. In this case, the ACE file must describe the whole universe. On the other hand it is very simple to do so since just adding a single line or two to your ACE file will produce the desired effect:

cluster
standard: "${path_liberty_core}loadpath.se"

=== Tools ===

All the tools used by the [[se]] command are set here. These tools must be in the directory pointed to by the <tt>bin</tt> key of the <tt>[General]</tt> section. The key is used as first argument of [[se]].

The [[install|installation tool]] installs the following default commands:

[Tools]
ace_check: ace_check
c2c: compile_to_c
c: compile
class_check: class_check
clean: clean
doc: eiffeldoc
find: finder
make: se_make.sh
mock: mocker
pretty: pretty
short: short
test: eiffeltest
test_ng: eiffeltest_ng
test_server: eiffeltest_server
wrap: wrappers_generator
x_int: extract_internals

Note that anyone can add their own tools, as long as the executable is in the directory pointed to by the <tt>bin</tt> key of the <tt>[General]</tt> section and an entry is added to the <tt>[Tools]</tt> section.

=== C modes ===

These modes are used by the C back-end: used C compiler, options... E. g.
[boost]
c_compiler_type: gcc
c_compiler_path: gcc
c_compiler_options: -pipe -O2 -fno-gcse
c_linker_path: gcc
c_linker_options: -Xlinker -no-as-needed
cpp_compiler_type: g++
cpp_compiler_path: g++
cpp_compiler_options: -pipe -O2 -fno-gcse
cpp_linker_path: gcc
cpp_linker_options: -Xlinker -no-as-needed

By default some C modes are automatically associated to the Eiffel compilation levels (<TT>-boost</TT>, <TT>-require_check</TT>, etc.). The C mode can also be explicitely set in the command line of [[compile_to_c|compile_to_c]] or [[compile|compile]] thanks to the <TT>-c_mode</TT> option.

The following C modes are default for a standard installation: <TT>boost</TT>, <TT>no_check</TT>, <TT>require_check</TT>, <TT>ensure_check</TT>, <TT>invariant_check</TT>, <TT>loop_check</TT>, <TT>all_check</TT>, <TT>debug_check</TT> and <TT>release</TT>. Only the last one must be explicitely set; it is usually used to finalize a program (<TT>se c -boost -c_mode release ...</TT>)

Usually the default C modes depend on the chosen C compiler and needs adaption if GCC is not used.

Configuration file

2017-02-17T19:33:10Z

Ramack:

Release Notes (Versions history)

2017-01-14T00:15:01Z

Ramack: /* Curtiss (2016.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 (2017.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:
** redesign of eiffeldoc generated HTML to reduce its size dramatically
** addition of a zsh completer for se
** finally got rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused legacy platforms (Amiga, Elate, BeOS, OS/2, Macintosh)
** 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
** C99 conforming C code generation (hopefully)
* Developer changes:
** RUN_FEATUREs now have clear names (hopefully)
** to better support the user access rights model of the more recent 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]

== SmartEiffel (all releases which are predecessors of Liberty) ==

=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===

Again, a lot of novelties for this release:

* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans

Release Notes (Versions history)

2017-01-14T00:14:49Z

Ramack: /* Curtiss (2016.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 (2016.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:
** redesign of eiffeldoc generated HTML to reduce its size dramatically
** addition of a zsh completer for se
** finally got rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused legacy platforms (Amiga, Elate, BeOS, OS/2, Macintosh)
** 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
** C99 conforming C code generation (hopefully)
* Developer changes:
** RUN_FEATUREs now have clear names (hopefully)
** to better support the user access rights model of the more recent 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]

== SmartEiffel (all releases which are predecessors of Liberty) ==

=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===

Again, a lot of novelties for this release:

* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans

Release Checklist

2017-01-05T19:40:20Z

Ramack: add checkpoint

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (remove ~dev tag)
* create release candidate
git tag <release_name>-rc1
git push --tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create doc tarballs
check for next release
work/build_doc.sh -plain -zip
make doc.liberty-eiffel.org point to the released docs
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (fix release version and date, without SNAPSHOT)
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email
** to our mailing list
** on http://lists.gnu.org/archive/html/info-gnu/
** as news entry on savannah
** https://en.wikipedia.org/wiki/LibertyEiffel - stable release docs
** https://directory.fsf.org/wiki/Liberty-eiffel
** adapt changelog (in work/packaging/debian.skel/debian/) in master branch (readd ~dev tagged version)
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Manual index

2016-11-28T20:44:37Z

Ramack: /* I */

Manual index

2016-11-28T20:43:52Z

Ramack: /* N */

Manual index

2016-11-28T20:42:44Z

Ramack: /* R */

Type Aliases

2016-11-28T20:41:52Z

Ramack: creation

Some types have an alias for convenience and backward compatibility. Even though it is wise to use explicitly sized numeric types the following "shortcuts" exist:
* REAL maps to [[library_class:REAL_64|REAL_64]]
* INTEGER maps to [[library_class:INTEGER_32|INTEGER_32]]
* NATURAL maps to [[library_class:NATURAL_32|NATURAL_32]]

all this is internally handled in the compilers class [[tool_class:TYPE_ALIASING|TYPE_ALIASING]].

Manual index

2016-11-28T20:37:18Z

Ramack: /* T */

Release Checklist

2016-07-23T18:36:36Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (remove ~dev tag)
* create release candidate
git tag <release_name>-rc1
git push --tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create doc tarballs
check for next release
work/build_doc.sh -plain -zip
make doc.liberty-eiffel.org point to the released docs
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (fix release version and date, without SNAPSHOT)
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email
** to our mailing list
** on http://lists.gnu.org/archive/html/info-gnu/
** as news entry on savannah
** https://en.wikipedia.org/wiki/LibertyEiffel - stable release docs
** adapt changelog (in work/packaging/debian.skel/debian/) in master branch (readd ~dev tagged version)
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Release Notes (Versions history)

2016-06-16T19:36:29Z

Ramack: /* Adler (2013.11, named after Charles Adler, Jr.) */

[[Category: Releases]]
== Liberty Eiffel (latest release first) ==
For other upcoming releases see the [[upcoming releases|list of names]].
=== Curtiss (2016.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:
** addition of a zsh completer for se
** finally got rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused platforms (Amiga, Elate, BeOS, OS/2 ...)
** creation keyword now generates an error
** C99 conforming C code generation (hopefully)
* Developer changes:
** RUN_FEATUREs now have clear names (hopefully)
** to better support the user access rights model of the more recent 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]

== SmartEiffel (all releases which are predecessors of Liberty) ==

=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===

Again, a lot of novelties for this release:

* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans

Get involved

2016-06-16T18:01:07Z

Ramack: added repository details

[[Category: Community]]
=Interested in the Eiffel language and the Liberty compiler?=

First of all you are invited to use Liberty for developing your own applications. If you encounter any problem, just raise your voice and [[Get in touch|get in touch]] with us. We are here to fix your issues and support you in using the Liberty Eiffel compiler and its libraries. Our primary goal is to provide a working Eiffel compiler and a bunch of libraries for real life applications. Now you face the opportunity to come up with a nice little program (or a new office suite), written with Liberty.

Liberty is an open project, where anyone can clone the public repository from git://git.savannah.gnu.org/liberty-eiffel.git and dig into the code, improve it and get the changes into the master branch. You are welcome to provide patches, issue pull requests and to become a project member on Savannah.

We are open to any bug fix or new feature in the libraries or tools. And if you don't want to get your hands dirty we are happy for you to create feature requests or bug reports in the [https://savannah.gnu.org/bugs/?func=additem&group=liberty-eiffel issue tracker on GNU Savannah].

Please also feel free to improve the pages in this Wiki. - Although we disabled the anonymous account creation due to spamming it is simple to get an account by asking via [[Get in touch|email]].

=Technical Details of our repository setup=
The main development repository is on Savannah: http://git.savannah.gnu.org/r/liberty-eiffel.git
Pushes to this repo are replicated (every two minutes) to [https://github.com/LibertyEiffel/Liberty Github/LibertyEiffel/Liberty] by ET. Many of us have an account and a private clone of the GitHub repo to be able to publish something, that is not yet pushable to the master repository, but others might want to take a look, comment and/or try. The main trick now is, that the local clones we work with on our development machines have the savannah repo also as remote and we do not directly commit to the Liberty repo master on github, but only to our personal github clones or to savannah.

One easy way to handle patches from not-yet-savannah-project members is probably a pull-request on github. We then just have to remember that we have to manually pull those into our repositories first before pushing them to savannah (using the "manual mergin tipps" on github).

Release Notes (Versions history)

2016-06-12T20:15:44Z

Ramack: /* Curtiss (2016.09, named after Glenn Curtiss) */

[[Category: Releases]]
== LibertyEiffel (latest release first) ==
For upcoming releases see the [[upcoming releases|list of names]].
=== Curtiss (2016.09, named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===
* not yet released (see next section for current release notes)
* User-visible changes:
** addition of a zsh completer for se
** finally get rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** removed support for some unused platforms (Amiga, elate, ...)
** creation keyword generates now an error

** C99 conforming C code generation (hopefully)
* Developer changes:
** RUN_FEATUREs now have clear names (hopefully)
* 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 LibertyEiffel 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 LibertyEiffel
* 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
* 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]

== SmartEiffel (all releases which are predecessors of Liberty) ==

=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===

Again, a lot of novelties for this release:

* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans

Release Notes (Versions history)

2016-06-09T18:50:00Z

Ramack: /* Curtiss (2016.09, named after Glenn Curtiss) */

[[Category: Releases]]
== LibertyEiffel (latest release first) ==
For upcoming releases see the [[upcoming releases|list of names]].
=== Curtiss (2016.09, named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===
* not yet released (see next section for current release notes)
* User-visible changes:
** addition of a zsh completer for se
** finally get rid of obsolete classes GEN_RAND, MIN_STAND and STD_RAND
** C99 conforming C code generation
* Developer changes:
** RUN_FEATUREs now have clear names
* 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 LibertyEiffel 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 LibertyEiffel
* 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
* 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]

== SmartEiffel (all releases which are predecessors of Liberty) ==

=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===

Again, a lot of novelties for this release:

* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans

Getting Started

2016-05-31T18:11:17Z

Ramack:

== 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 ==
So far we don't have an installer for windows, but a [[GSoC_-_Windows_Support|current GSoC project]] is working on that. In case of interest get in touch with us, maybe you can provide some input or help with testing.

== 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
* GCC-XML extension
* Boehm-Demers-Weiser garbage collector dev-packages

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

On Fedora you'll need gc-devel, rather than libgc-dev, gccxml 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 SmartEiffel should not be already installed on your system. Particularily, any /etc/serc file will prevent you from installing Liberty 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 LibertyEiffel 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]].

ToDo

2016-05-27T21:13:16Z

Ramack:

* describe polymorphism
* [[Cloning_objects]]
* describe difference between variable and object (should be already there, so make it easier to find, maybe add aliasing as effect)
* restructure to simplify the entry into LibertyEiffel for newcomers (remove the separation between "The Grand Book" and Community pages)
* clean up syntax diagrams

ToDo

2016-05-27T21:12:47Z

Ramack:

Talk:Upcoming release names

2016-05-27T16:49:51Z

Ramack:

Release Notes (Versions history)

2016-05-26T20:19:44Z

Ramack: /* Bell (2016.05, named after Alexander Graham Bell) */

[[Category: Releases]]
== LibertyEiffel (latest release first) ==
For upcoming releases see the [[upcoming releases|list of names]].
=== Curtiss (2016.09, named after [https://en.wikipedia.org/wiki/Glenn_Curtiss Glenn Curtiss]) ===
* not yet released (see next section for current release notes)
* User-visible changes:
** C99 conforming C code generation
* Developer changes:
** RUN_FEATUREs now have clear names
* 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 LibertyEiffel is 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
** 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 LibertyEiffel
* 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
* 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]

== SmartEiffel (all releases which are predecessors of Liberty) ==

=== Release 2.3 [Antoine-Auguste Parmentier] - Wednesday July 11th 2007 ===

Again, a lot of novelties for this release:

* New [[Typing policy|typing rules]] have been revisited and are now crystal clear. See [[Typing policy|this page]] for details.
* Implemented a new [[class loading]] algorithm, which takes into account the "distance" between classes, thus reifying the notion of clusters and sub-clusters. Everything is trans

Release Checklist

2016-05-23T18:40:16Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi?
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (remove ~dev tag)
* create release candidate
git tag <release_name>-rc1
git push --tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (fix release version and date, without SNAPSHOT)
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email
** to our mailing list
** on http://lists.gnu.org/archive/html/info-gnu/
** as news entry on savannah
** https://en.wikipedia.org/wiki/LibertyEiffel - stable release docs
** adapt changelog (in work/packaging/debian.skel/debian/) in master branch (readd ~dev tagged version)
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Eiffeltest

2016-05-22T11:24:56Z

Ramack: /* Synopsis */

[[Category: Tool]]
<code>eiffeltest</code> is a tool that runs a suite of tests.

Users can use it to run a test-suite of their own, which is a useful tool for their project robustness.

It is also used by LibertyEiffel itself to validate, with the provided test-suite, the compiler and the libraries.

== Synopsis ==

* <code>se test directory </code>

== File handling ==

The tools recursively iterates over the directory given as a command-line parameter, looking for test files or over the given test file names.

Test files are Eiffel source files with special names:

* <code>test_*.e</code>: valid source file that should be compilable and runnable without causing an error
* <code>bad_*.e</code>: invalid source file that should trigger a given compiler error message

For each test file, there can be optional files that have the same name but a different extension. These optional files can be used to provide:

* '''output''' that the compiler is expected to provide when '''compiling''' <tt>bad_*.e</tt> files. This mandatory file for invalid tests has the extension <tt>.msg</tt>.
* '''input''' to be fed to the program. This optional file (allowed only for valid tests) has the extension <tt>.in</tt>.
* '''output''' that the program is expected to provide when '''run'''. This optional file (allowed only for valid tests) has the extension <tt>.out</tt>

* <code>glu_*.c</code>: ***
* <code>cecil_*.se</code>: ***
* <code>extra_options_*.se</code>: ***

In each test directory a file named loadpath.se may exist, which is passed to the compiler as loadpath.

== Test implementation ==
A test case in general is a program - defined by an Eiffel class - returning 0 in case of success and 1 if the test failed. To ease writing such classes we recommend to insert [[library_class::EIFFELTEST_TOOLS]] and call label_assert("some descriptive message", assertion_condition) for any assertion condition that shall be tested. This class internally counts the assertions and provides an error message in case of failure - even with a sedb_breakpoint if compiled with -sedb. For more advanced, or dynamic labels the feature message_assert can be used, which takes an agent to generate the label. After telling the user about the failed testcase [[library_class::EIFFELTEST_TOOLS]] also ensures to terminate the program with exit code 1. One simple example for a test case is the following:

class TEST_EXAMPLE

insert
EIFFELTEST_TOOLS

create {}
make

feature {ANY}
make
-- the root creation procedure
do
label_assert("first test", 2 + 3 = 5)
label_assert("second test", False)
end
end -- class TEST_EXAMPLE

== Modes that are checked ==
Eiffeltest checks the following modes (presuming they are not disabled by the excluded.lst file)

{|border="1"
|-
|
* -boost
* -boost -bdw_gc
* -boost -debug -bdw_gc
* -no_check
* -no_check -bdw_gc
|
* -flat_check -all_check -debug
* -flat_check -require_check
* -flat_check -ensure_check
* -flat_check -invariant_check
* -flat_check -loop_check
* -flat_check -all_check
|
* -flat_check -no_check -bdw_gc
* -flat_check -require_check -bdw_gc
* -flat_check -ensure_check -bdw_gc
* -flat_check -invariant_check -bdw_gc
* -flat_check -loop_check -bdw_gc
* -flat_check -all_check -bdw_gc
|
* -no_gc -boost
* -no_gc -boost -debug
* -no_gc -no_check
* -no_gc -flat_check -require_check
* -no_gc -ensure_check
|-
|
* -no_gc -flat_check -debug
* -no_gc -flat_check -invariant_check
* -no_gc -flat_check -loop_check
* -no_gc -flat_check -all_check
|
* -all_check -debug
* -require_check
* -ensure_check
* -invariant_check
* -loop_check
* -all_check
* -debug
|
* -no_gc -all_check -debug
* -no_gc -require_check
* -no_gc -ensure_check
* -no_gc -invariant_check
* -no_gc -loop_check
* -no_gc -all_check
|
* -all_check -debug -bdw_gc
* -require_check -bdw_gc
* -ensure_check -bdw_gc
* -invariant_check -bdw_gc
* -loop_check -bdw_gc
* -all_check -bdw_gc
* -debug -bdw_gc
|-
|
* -profile -boost
* -profile -all_check -debug
* -profile -no_check
* -profile -require_check
* -profile -ensure_check
* -profile -invariant_check
* -profile -loop_check
* -profile -all_check
|
* -profile -no_gc -boost
* -profile -no_gc -all_check -debug
* -profile -no_gc -no_check
* -profile -no_gc -require_check
* -profile -no_gc -ensure_check
* -profile -no_gc -invariant_check
* -profile -no_gc -loop_check
* -profile -no_gc -all_check
|
* -profile -boost -bwd_gc
* -profile -all_check -debug -bdw_gc
* -profile -no_check -bdw_gc
* -profile -require_check -bdw_gc
* -profile -ensure_check -bdw_gc
* -profile -invariant_check -bdw_gc
* -profile -loop_check -bdw_gc
* -profile -all_check -bdw_gc
|
* -profile -flat_check -all_check -debug
* -profile -flat_check -require_check
* -profile -flat_check -ensure_check
* -profile -flat_check -invariant_check
* -profile -flat_check -loop_check
* -profile -flat_check -all_check
|-
|
* -no_split -boost
* -no_split -no_gc -boost
* -no_split -boost -bdw_gc
|}

== Open issues ==

* How can we use <tt>.in</tt> and <tt>.out</tt> files on platforms that do not allow redirecting the standard input and output of programs?

''Easy: just finish the "exec" cluster ;-)'' --[[User:Cadrian|Cyril]] 08:16, 10 nov 2005 (CET)

''Sounds good. Can you give a brief listing of what is to be done ?'' --[[User:Pini|pini]] 23:36, 25 nov 2005 (CET)

''The win32 port (at least) is to be written. Ah, and testing ;-)'' --[[User:Cadrian|Cyril]] 15:39, 28 Nov 2005 (CET)

* Which compilation modes are used for testing? There are many options and running all possibilities is probably too much.
Flags I can remember from: -no_gc, -flat_check, -no_split, (-debug_check | -all_check | -loop_check | -invariant_check | -ensure_check | -require_check | -no_check | -boost)
This means compiling and running about 64 times (minus incompatibilities between -flat_check and boost/no_check).

* How to test some specific capabilities: options -profile, -no_main, -c_mode, -sedb, -cecil, or testing with c2j?

* What about tests specific to some compiler mode? For example GC tests should not be run without GC, optimizer tests are invalid in modes other than -boost...

''Perhaps we could use indexing/notes clauses with tags indicating which modes/options are relevant for the test?'' --[[User:Dmoisset|Dmoisset]] 22:44, 26 Nov 2005 (CET)

''Nice idea. I would improve it by proposing the opposite: list the modes/options to exclude. This means that all modes will be checked by default. If the test is incompatible with some mode, then it has to be specified. If some new mode is added, this mode will be tested with all tests. If some tests are not compatible with this mode, they have to be excluded. Otherway, you would have to edit about every test to add this mode. -- Philippe Ribet

''Why not remove the 'test_' and 'bad_' substrings from the test names? That reduces clutter and leaves more space for readable, self-documenting filenames.''

''The test harness can look for response files that match the test prefix. You already have two suffixes: *.out (for output) and *.msg (for a compiler error message). Another useful one is *.match (for a regular expression match on the output, because the output might contain things like date/time/version-number that are not relevant to the test).''

''That is how I'm doing testing for the Amber project, and it seems to work well. --Roger Browne 2005-11-26''

That's a good point to raise, if only to mention that the current test suite (pre-eiffeltest) does a "fuzzy" matching of error messages (using SmartEiffel/tools/commands/same_msg.e).--[[User:FM|FM]] 21:42, 19 Dec 2005 (CET)

Getting Started

2016-05-21T19:18:08Z

Ramack:

== 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 ==
So far we don't have an installer for windows, but a [[GSoC_-_Windows_Support|current GSoC project]] is working on that. In case of interest get in touch with us, maybe you can provide some input or help with testing.

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

== 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
* GCC-XML extension
* Boehm-Demers-Weiser garbage collector dev-packages

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

On Fedora you'll need gc-devel, rather than libgc-dev, gccxml 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 SmartEiffel should not be already installed on your system. Particularily, any /etc/serc file will prevent you from installing Liberty 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 LibertyEiffel 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]].

2016-05-21T19:09:03Z

Ramack:

'''LibertyEiffel Wiki'''

<div id="History">
'''1''' History and goals of the LibertyEiffel project

<blockquote>
'''1.1''' [[Introduction]]
</blockquote>

<blockquote>
'''1.2''' [[Versions history|All LibertyEiffel versions]]
</blockquote>
</div>

<div id="Tutorial">
'''2''' Build with LibertyEiffel

<blockquote>
'''2.1''' [[Getting_Started|Setup LibertyEiffel on your computer]]
</blockquote>

<blockquote>
'''2.2''' [[Tutorial tour|Guided tour of the tutorial]]
</blockquote>

<blockquote>
'''2.3''' [[Build your library]]
</blockquote>

<blockquote>
'''2.4''' [[sedb|Debug your programs]]
</blockquote>

<blockquote>
'''2.5''' [[profile|Profile your programs]]
</blockquote>
</div>

<div id="Lecture">
'''3''' Lecture on object-oriented programming and design by contract in Eiffel

<blockquote>
'''3.1''' [[Inheritance]]
</blockquote>

<blockquote>
'''3.2''' [[Dynamic dispatch]]
</blockquote>

<blockquote>
'''3.3''' [[Comparison of objects|Comparison of objects]]
</blockquote>

<blockquote>
'''3.4''' [[Cloning objects]]
</blockquote>
</div>

<div id="Library">
'''4''' The LibertEiffel general purpose library

<blockquote>
'''4.1''' [[Library interface|How to use the library]]
</blockquote>

<blockquote>
'''4.2''' [[Library design|Design of the library]]
</blockquote>

<blockquote>
'''4.3''' [[Library Wrappers|How to use existing libraries in LibertyEiffel (wrappers)]]
</blockquote>

<blockquote>
'''4.4''' [[Wrapping_C_libraries|How to create a wrapper for existing libraries]]
</blockquote>

</div>

<div id="Tools">
'''5''' [[Tools|LibertyEiffel's tools documentation]]
</div>

<div id="Eiffel">
'''6''' The Eiffel language of LibertyEiffel

<blockquote>
'''6.1''' [[System defintion]] of Eiffel
</blockquote>

<blockquote>
'''6.2''' [[Syntax diagrams]] of Eiffel
</blockquote>

<blockquote>
'''6.3''' [[Expanded or reference|Expanded object or reference object]]
</blockquote>

<blockquote>
'''6.4''' [[Typing policy|Validity of assignments and feature redefinitions]]
</blockquote>

<blockquote>
'''6.5''' [[Current|What you need to know about <TT>Current</TT>]]
</blockquote>

<blockquote>
'''6.6''' [[Void|A definition of <TT>Void</TT>]]
</blockquote>

<blockquote>
'''6.7''' [[Once]]
</blockquote>

<blockquote>
'''6.8''' [[Tuple]]s
</blockquote>

<blockquote>
'''6.9''' [[Agent]]s
</blockquote>

<blockquote>
'''6.10''' [[Precursor]]
</blockquote>

<blockquote>
'''6.11''' [[Manifest storage notation]]
</blockquote>

<blockquote>
'''6.12''' [[Dynamic type testing]]
</blockquote>

<blockquote>
'''6.13''' [[Type of integer constants]]
</blockquote>

<blockquote>
'''6.14''' [[SCOOP]] - Concurrency in LibertyEiffel
</blockquote>

<blockquote>
'''6.15''' [[ECMA]] - The ECMA standard andLiberty
</blockquote>
</div>

'''7''' [[FAQ|The LibertyEiffel FAQ]]

'''8''' [[Glossary]]

'''9''' [[Papers]]

'''10''' [[License]]

<div id="Appendices">
'''11''' Appendices

<blockquote>
'''11.1''' [[Author guidelines]] for this wiki
</blockquote>

<blockquote>
'''11.2''' Why there are [[no threads]]
</blockquote>

<blockquote>
'''11.3''' [[Gc info|The output of the <tt>-gc_info</tt> option]].
</blockquote>
</div>

'''12''' [[Bibliography]]

'''13''' [[Manual index|Index]]

Getting Started

2016-05-21T19:00:14Z

Ramack: added apt repository example

== 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 ==
So far we don't have an installer for windows, but a [[GSoC_-_Windows_Support|current GSoC project]] is working on that. In case of interest get in touch with us, maybe you can provide some input or help with testing.

== Bootstrapping 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
* GCC-XML extension
* Boehm-Demers-Weiser garbage collector dev-packages

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

On Fedora you'll need gc-devel, rather than libgc-dev, gccxml 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 SmartEiffel should not be already installed on your system. Particularily, any /etc/serc file will prevent you from installing Liberty 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 LibertyEiffel 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 Checklist

2016-05-21T09:32:36Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi?
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (remove ~dev tag)
* create release candidate
git tag <release_name>-rc1
git push --tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (fix release version and date, without SNAPSHOT)
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email
** to our mailing list
** on http://lists.gnu.org/archive/html/info-gnu/
** as news entry on savannah
** adapt changelog (in work/packaging/debian.skel/debian/) in master branch (readd ~dev tagged version)
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Release Checklist

2016-05-19T19:33:21Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi?
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (remove ~dev tag)
* create release candidate
git tag <release_name>-rc1
git push --follow-tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* adapt changelog (in work/packaging/debian.skel/debian/) in bell branch (fix release version and date, without SNAPSHOT)
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email
** to our mailing list
** on http://lists.gnu.org/archive/html/info-gnu/
** as news entry on savannah
** adapt changelog (in work/packaging/debian.skel/debian/) in master branch (readd ~dev tagged version)
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Release Checklist

2016-05-19T17:43:47Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi?
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* create release candidate
git tag <release_name>-rc1
git push --follow-tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email
** to our mailing list
** on http://lists.gnu.org/archive/html/info-gnu/
** as news entry on savannah
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Release Checklist

2016-05-15T20:56:26Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi?
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* create release candidate
git tag <release_name>-rc1
git push --follow-tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* create the final release tag
git tag <release_name>
* create release debian packages
see above, use -release instead of -rc1
* create tarball and put on FTP server
see above for rc
* write announce email to our mailing list and as news entry on savannah
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Release Checklist

2016-05-15T20:55:24Z

Ramack:

This is WIP. Please update if you think of any missing detail. The target is to include all necessary command line commands (where applicable)

* cleanup Testsuite
* update LIBERTY_VERSION
* create new bootstrap germ code
resources/smarteiffel-germ/make_germ.sh
* create a local branch for the next release
git branch bell
* create a bell branch in the github repo (via web interface?)
* push it to savannah
git checkout bell
git push upstream bell
* remove all tools and libraries which are not sufficiently mature to be included in the release
** for Bell these are:
cluster smarteiffel/generation/run
smarteiffel/commands/run.e
edc-new, edc
lib/mmi?
effect tool
src/staging
src/lib/net/ezmq
wrappers: cairo, database/postgresql, ewlc, llvm, zmq, xml
* switch ET to use the new branch
** echo "bell" > ~/branch on ETs account
** change website/et/html_templates/head.html to make ET output tell people which branch is being tested...
* create release candidate
git tag <release_name>-rc1
git push --follow-tags upstream
* on ETs account...
work/packaging/build_debian.sh -rc1
work/packaging/build_debian.sh -rc1 -deploy
ssh et32@et32 "cd $LibertyBase && git fetch origin && git checkout $gitBranch && git merge --ff-only FETCH_HEAD && $LibertyBase/work/packaging/build_debian.sh -rc1"
scp -p et32@et32:Liberty/work/packaging/debs/* ~/Liberty/work/packaging/debs_i386/
reprepro --basedir ~/Liberty/website/apt includedeb rc liberty-eiffel-tools_2016~dev~rc1_i386.deb
* create tarball and put on FTP server
download the tag tarball from http://git.savannah.gnu.org/cgit/liberty-eiffel.git
work/strip_tgz.sh bell-rc1.tar.gz
scp bell-rc1.tar.gz ramack@dl.sv.gnu.org:/srv/download/liberty-eiffel/
* collect RC feedback on our mailing list
* create the final release tag
git tag <release_name>
* create release debian packages
work/packaging/build_debian.sh -release
* create tarball and put on FTP server
* write announce email to our mailing list and as news on savannah
* switch ET back to use the master branch
** echo "master" > ~/branch on ETs account
* prepare changelog for the third release
* plan the next release (tickets on savannah)

Release Checklist

2016-05-15T20:53:34Z

Ramack:

Release Checklist

2016-05-15T18:24:51Z

Ramack:

Release Checklist

2016-05-05T18:11:57Z

Ramack:

Tools

2016-05-02T19:33:55Z

Ramack: /* Compiling */

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

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

== The tools ==

=== Tool box ===

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

=== Compiling ===

* [[clean]]: remove the useless C files
* [[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 LibertyEiffel testing tool
* [[mock]]: the LibertyEiffel mock tool

=== Installing ===

* [[install]]: installs the LibertyEiffel tools

== The system core ==

If you are interested by 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 LibertyEiffel-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)]]