EiffelStudio: an EiffelSoftware project - User contributions [en]

Main Page

2017-02-03T22:15:20Z

Schoelle: /* Contributing! */

[[Category:General]]__NOTOC__
<h1 class="firstHeading">EiffelStudio Integrated Development Environment</h1>

[[Image:EiffelStudioScreenshot.png|thumb|250px|right|EiffelStudio IDE ([http://eiffel.com/products/studio/screenshots.html more screenshots]) ]]

Welcome to the central resource for EiffelStudio developers and contributors.
==News==
*''January 2017'': EiffelStudio [[EiffelStudio 17.01 Releases|17.01]] is available for download at https://www.eiffel.org/downloads
*''May 2016'': EiffelStudio [[EiffelStudio 16.05 Releases|16.05]] is available for download at https://www.eiffel.org/downloads
*''Dec 2015'': EiffelStudio [[EiffelStudio 15.12 Releases|15.12]] is available for download at https://www.eiffel.org/downloads

==Background==

EiffelStudio is an open-source IDE for the [http://en.wikipedia.org/wiki/Eiffel_programming_language Eiffel programming language]. [http://www.eiffel.com Eiffel Software] is the principal contributor and hosts the subversion repository. EiffelStudio is maintained and developed by Eiffel Software as well many contributors, including ETH Zurich.

EiffelStudio is a full-featured IDE offering the following features, many of them unique:

* Complete compiler for the Eiffel programming language, with Design By Contract (DBC) support and both high compile-time speed and high-performance executables, based on the Melting Ice Technology.
* Full portability (including graphics) across Windows, MacOS X, Linux, *BSD, Solaris and other operating systems
* Smart code editor
* Sophisticated multi-view browsing and viewing facilities
* Interactive debugger
* Graphical modeling tool for UML and BON with full roundtrip
* Refactoring support
* GUI development tool (EiffelBuild) and fully portable GUI library (EiffelVision)
* Many other libraries of reusable component.

The Eiffel compiler creates C code that is then handed to a standard C compiler. As a result, Eiffel programs have a run-time performance comparable to those directly written in C or C++, but with the benefits of an advanced object-oriented model and strong typing. EiffelStudio uses a highly efficient compacting garbage collector to free the developer from the burden of memory management.

<center>If you want to know more about the unique features of Eiffel and EiffelStudio, check out our [[Reasons for using Eiffel]] page.</center>

{|style="font-size:80%;" bgcolor=white|
{| cellspacing=8 width="100%"
|- valign="top"
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|

== Getting Started ==

* [[Downloads]]
* [[EiffelStudio Releases|Changelog of current release (release branch)]]
* [http://docs.eiffel.com/book/eiffelstudio/software-installation-eiffelstudio Installing EiffelStudio]
* [[Compiling Hello World]]
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|

== Working with EiffelStudio ==

* [[Frequently Asked Questions]]
* [[Eiffel Glossary]]
* [[Eiffel Compilation Explained]]
* [[EiffelStudio Wish List]]

|- valign="top"
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|
== Contributing! ==

* [[:Category:Projects|How to contribute: the Projects page]]
* [[:Category:Testing|EiffelStudio testing process: you can participate!]]
* [[EiffelStudio 17.01 Releases|Changelog of latest version, currently 17.01]]
* [[Repository|Getting the source: Subversion repository]]
* [[Compiling EiffelStudio]]
* [[:Category:Tools|Developer's tools]]
* [[Language_Roadmap|Language roadmap]]
* [[Environment_Roadmap|Environment roadmap]]
* [[Design_and_coding_rules|Design and coding rules]]
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|

== Community ==

* [https://www.eiffel.org Eiffel.org]
* [[Spread_the_word|Spread the word]]
* [[Eiffel Sites and Links]]
* [[Mailing Lists]]
* [[:Category:News|News]]
* Join us on gitter https://gitter.im/EiffelSoftware/EiffelStudio or through https://groups.eiffel.com/

|}

Talk:Catcall Test Proposal

2007-11-06T11:26:37Z

Schoelle:

Can you give an example of when using the variant keyword makes sense?

As for the frozen keyword, doesn't this break the open/closed principle yet again (I know the example shows an attribute, but the wording suggests a routine could also be marked with a frozen type - does this limit redeclaration)?

What is supposed to happen in the multiple constraint case (if the compiler didn't have a limitation)?
--[[User:Colin-adams|Colin-adams]] 00:09, 6 November 2007 (PST)

: The 'variant' keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments. --[[User:Schoelle|Schoelle]] 03:26, 6 November 2007 (PST)

Talk:Catcall Test Proposal

2007-11-06T11:26:21Z

Schoelle:

EiffelStudio Wish List

2007-10-12T15:37:57Z

Schoelle: /* IDE */

[[Category:Projects]]
Welcome to the Eiffel/EiffelStudio Wish List. This is the place where you, the community, get a chance to tell us what you think is important to include in the future versions of the Eiffel compiler and EiffelStudio IDE.

Please use this list responsibly and try to correctly categorize your wishes. A brief description may help us evaluate your requirements but please be brief.

Our stock pile of genie snared, dusty gold lamps is running low for our next release ([[EiffelStudio Releases]]) but we'll be sure to scour the lands for more.

== Compiler ==

=== General ===
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! Source & Generated Files in an RDBMS and (optionally) Compile directly from database
| Use an RDBMS to store all sources,libraries and generated files instead of a filesystem. Optionally directly compile from the database. Repository can be shared amongst multiple users
|| Pro's:
* Easy queriable
* Much more appropriate to use a database to store relations (dependencies) between objects.
* Easier for using a shared repository amongst multiple users
||
* Sophisticated collaboration tools already exist for sharing project source e.g. SVN, CVS
||

|-
! Shared EIFGEN
| Allow sharing of EIFGENs (in read-only mode)|| || ||]

|-
! On-demand tab loading
| Allow creation of an EV_NOTEBOOK tab with an agent to be called to fill the tab when it is first loaded|| || ||

|-
! Enum
| A way to author Enum-like class for typed options or flags. Currently using INTEGER and a bag of analogous constants doesn't make Eiffel "elegant". || ||
* The best practice way to get a value that only needs to be defined once is by using the "once" keyword in combination with a feature.
||

|-
! Decimal
|Addition of a decimal type / REAL_128 for 28 digit precision - || MA_DECIMAL is not efficient || MA_DECIMAL already covers this||

|-
!User types
|I want to be able to define types .e.g. a decimal type as mentioned above. I know all built in types can be defined from scratch, except I a way to initialise from literals. So we need a way to define them as well. Suggest a new defered class with create methods from_literal( s:STRING), and queries is_interger_ok:BOOLIAN, is_real_ok:BOOLIAN, is_arbitary_string_ok:BOOLIAN, is_type_string_ok:BOOLIAN (we would define a new type of string just for this). The compiler when generating optimised code will have to compile the new types and dynamicaly bind to them to create an object that can be embeded into the code. I beleave this would let us write code like: x:DECIMAL; x=1.23 (without a conversion from REAL (float base2)) || || ||

|-
! CHARACTER_16
| CHARACTER_16 type || Smaller footprint than CHARACTER_32, UTF-16 is the default internal text representation for Windows/.Net/OS X/Java so conversion from CHARACTER_32 is costly, particular when dealing with large amounts of text || Please No! CHARACTER_32 covers this already. And UTF-8 is more space-efficient than UTF-16, which is an abomination. What will happen if you have a character from above the BMP? You will then have two CHARACTER_16s in the string for one real character - neither of which is a valid character - then `count' and `item' are all wrong. If you must have UTF-16 STRINGs, then let item return a CHARACTER_32. But note that having a UTF_16 STRING in itself won't eliminate all conversion costs - there is still the endian problem - this could be tackled by each individual UTF-16 STRING knowing whether it is UTF-16BE or UTF-16LE, but you may still need to convert. Comparing two such strings with different endianness would then have to be done using the codes - in what way is that going to be more efficient than using UTF-32? See [[Wish_CHARACTER_16]] for more details on why it is not ok.||

|-
! 7-bit ASCII
| 7-bit (US) ASCII_CHARACTER and ASCII_STRING which extends upon an ARRAY [ASCII_CHARACTER] with values of 0-127, removing the need for UTF8 conversion/checking when passing basic char values to C (gtk interfacing for example when connecting to signals) || || ||

|-
! MUTEX
| Make MUTEX recursive on non-windows platforms or at least provide a mutex and separate recursive mutex for all platforms. || || ||

|-
! Multiple Precompiled.
| Ability for multiple precompiles in a system. || || ||

|-
! XXX
| Ability to compile/debug for both 32/64 bit systems via project settings || || ||

|-
! XXX
| Ability for for a fully optimal finalization for systems marked as 'client only', so that unused variables will not get generated in the finalized C Code. || || ||

|-
! XXX
| Ability for Eiffel Studio to cross compile || || ||

|-
! XXX
| Ability to be able to control all user settable options in studio without having to resort to manually editing files, this is mainly for C compilation options || || ||

|-
! XXX
| Have a smarter C code generation system that can launch a C compilation of any module as soon as the C code is generated, this way we can also be smarter when monitoring C compilation progress || || ||

|-
! XXX
| Ability for ANY to generate a unique id for each object for referencing and hashability || ||
Objects that are hashable should implement HASHABLE
||

|-
! XXX
| With hashable ability of ANY, change object graph traversal for serialization so that multiple threads can serialize at the same time without having to wait linearly (lock_marking/unlock_marking). This may also require a reworking of the mismatch corrector facility as this does not appear to be thread-safe when magically called by the run-time|| || ||

|-
! XXX
| Ability for Studio to work and compile with Cygwin || || ||

|-
! XXX
| Ability to get a list of file dependencies in the form of a file listing to stdout. This list would contain a) all .e files used in the system, b) all .lib/.so files explicitly listed in the ECF/Ace file and c) all .h files referenced in external features (ideally that have not been subjected to dead code removal). Preferably, this feature should be able to be used without performing a full compilation (level 4?). || || ||

|}

=== .NET ===
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Consume .NET generics. Not being able to use them is becoming harder.<br/>We cannot write Atlas (AJAX) based web applications because of it. The Visual Studio SDK, used by EiffelEnvision, is increasing it's use of generics and preventing use from supporting some features. The people who want to use the .NET framework classes instead of the Eiffel ones cannot use generics and have to resort to using the non-generic versions of list, which bulks implementation and leads ambiguity. || || ||

|-
! XXX
| Emit .NET generics types for Eiffel generic classes. || || ||

|-
! XXX
| Allow direct access to member of TYPED_POINTER [xxx] item out/ref routine arguments. || || ||

|-
! XXX
| Allow direct setting of TYPED_POINTER [xxx] item for out/ref routine arguments. || || ||

|-
! XXX
| Optimized ''call.do_nothing'' as a IL pop instruction to removed returned value. || || ||

|-
! XXX
| Custom attributes on routine arguments and Result. || || ||

|-
! XXX
| An ability to call a parent .NET constructor from an Eiffel creation routine. || || ||

|}

== IDE ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Halt repainting for the GUI library while the GUI is assembled or changed.
|| || ||

|-
! XXX
| Give the user control over which classes will be compiled over the GUI (say: click on grey class and it becomes yellow and will be compiled always from now on, even though it may not be used at all. This is good for development of classes which are not added over GUI in ES.) || || ||

|-
! XXX
| While searching for word or after a double click on a word, it would be nice if all words would be highlighted in pastel color style. || || ||

|-
! XXX
| Allow arguments and locals of a routine to be pickable so that they can be renamed via the refactoring tool. || || || In the case of arguments it might be interesting to allow
renaming in ancestor and descendant versions of the feature.

|-
! XXX
| It's a pain to pick`n`drop huge features source code into the context window for setting break point. What about the following: Pick on the right side of the class text picks the feature as well? (Pick on the left side of the class text picks already the feature call). || || ||

|-
! XXX
| Make editor and grid more theme compliant in terms of color and font || || ||

|-
! XXX
| Remove all use of EV_TREE and EV_MULTI_COLUMN_LIST from studio so that all list widgets are drawn by vision2, this will make porting easier, we can also use the grid items to be able to change names of clusters, classes and features inline via the tree items. || || To which other platform would it make porting easier? For the Mac OS port that's completely unnecessary I think. Also it would make the tree view look uglier (not as other tree views etc on the same platform) and inline editing can be made accessible in other ways (at least in OS X that's quite easy) ||

|-
! Extended Static Checking
| Extended static checking integrated into the IDE. || Provides more immediate feedback on potential contract violations. || ||See, for example, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf ES-Verify]

|-
! XXX
| Rearrange widgets of ''search tool'' so that they use free space on the right. Currently it uses too much vertical space. || || I don't see free space on the right. Has this already been done? ||

|-
! XXX
| Add an option to show the target name before the current edited class in the application title bar. When multiple projects are open, it's not possible to identify an EStudio session based on the title that appears on the tray bar|| || |||

|-
!Step-by-step debugging
| It would be useful in step-by-step debugging to be able to follow the execution cursor when checking the invariants as it is done for the preconditions and postconditions of a routine. This way, it would be easy to step into the right features and skip some (or all) of those present in the invariant. || || |||

|-
!Integrated Designer
| It would be nice to have an integrated visual designer so that building business applications where visual design is very import can be created more easily. || || ||

|-
! Drag-n-Drop
| Allow the alternative of using drag and drop everywhere instead of pick and drop. || || ||

|-
! Code annotation tags support
| Log the tags contained in comments. For example, when using Eclipse, it is useful to leave TODO comments behind to ensure that a part that is not implemented will be eventually. When the time comes to clean up the TODO tags, a tool can list them all along with the descriptions and the locations of the comments. || || || Similar approach can be applied to indexing/note tags.

|-
! Token locations in flat-view
| When debugging, I always look at flat view of a feature, then I found something that I want to change, so I have to go back to basic view. Buf often, I need to search the basic view to relocate the code. It would be nice if I can somehow pick a location in flat view and drop it into the right location in basic view.
|| || ||

|-
! External commands in context menu
| Suppose there is an external command "tortoisediff $file_name" to show diff of a file from its working base, then when a context menu for a class is displayed, this command will be in it, and before launch this command, the $file_name placeholder will be replaced by the actual file name. Also, some special placeholders starting with # will be recognized. They represent open arguments. So before launching the command, a dialog will prompt out asking for those values.
|Easy to use, no need to go to Console tool anymore. || ||

|-
! Outline
| When a mouse pointer is over a class name, a feature name, etc., it would be nice to see in a pop-up tooltip some basic information about it like description, header comment, signature, etc. || || ||

|-
! Current value of a variable
| When a mouse pointer is over a variable in debug mode if would be nice to see in a pop-up tooltip its value. || || ||

|-
! Immediate syntax checks
| It would be nice if editor can detect syntax errors and warnings and highlight them inline as well as outline (using a vertical bar, an icon of a particular color, etc.). || || || Syntax warnings include obsolete language constructs as well as unused code (such as unused local variables). For them it should be possible to suggest a replacement, so that manual editing is not required.

|-
! Refactoring: unused inheritance
| A new tool can be introduced to check if a given inheritance path is actually used in a project and if not, would suggest to remove it. || || || It would be great to be able to run such tools in background, so that the checks are invisible to the user that only gets a warning and a suggestion to remove the unused parent clause. This way some other similar tools can be added.

|-
! Refactoring: unused arguments
| A new tool can be introduced to check if all arguments of a feature are used (including all versions of the feature) and would suggest to remove those that are never used. || || ||

|-
! Refactoring: more interactive renaming
| Renaming tool can be changed to prompt for renaming in comments and strings (one by one) rather than to apply renaming for all of them silently. || || ||

|-
! Improve search tool
| Progress of search operation could be shown when performing search on a project and would ensure that the IDE remains responsible at that time. It should be also possible for a user to break the search operation. || || ||

|-
! Automatic source format
| There could be an option to tell the editor to reformat the code according to user preference settings. Those can address the multi-line expression format and the exceptions to the comb format (like for a class' name), for example. The reformat feature can be made to affect only the display so that different project members can view the source as it pleases them in an uniform way. || || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<code>
foo: STRING assign set_key_value ("foo", ?) is
do
Result := values.item ("foo")
end

values: HASH_TABLE [STRING, STRING]

set_key_value (k: STRING; v: STRING) is
do
values.force (v,k)
end
</code>
|
|
|

|-
! Convenient Number Syntax
|| Adalike syntax for numbers, e.g. 2#101010 = 10#42 = 2#10_10_10 and 100_000_000 = 100000000. || effectively reduces silly bugs when reading and writing numbers || Eiffel allows underscores within numbers to allow digit grouping e.g. 8_961_226||see annotated ada reference manual ||

|-
! Exceptions mentioned in method interface
|| syntax for telling developers about exceptions thrown by a method. e.g.:
<code>
foo( a : B) : C is
require
a /= Void
exceptions
Net_Unreachable, Net_Timeout
do
Result := values.item ("foo")
end
</code>
|| Clear and elegant syntax, no more looking into the implementation to find out which exceptions might occur and which of them might be handled at which level.
|| 1) new keyword. 2) new compiler option necessary (using this interface extension is fully useful only if enforced by the compiler which would break older code). 3) Does not scale well with sub classing and redefining features. Redefined versions may have fewer exceptions, in which some stated exceptions won't occur anymore, or more exceptions, where the feature would no longer conform to the signature and a hack would need to be made or redefining the base class in which case you have a fragile base class problem. The Eiffel way of handling exceptions with the paradigm "a feature either satisfies its contract or an exception is thrown" is really an elegant way of handling the unknown, although it takes some getting used to when coming from Java. ECMA exceptions as objects and the type multibranch instructions will help with non-trivial exception handling.
||
Could this be included only on generated views. Not in typed in code, as this can cause a maintinance problem having to propogate changes.
||
|}

== Other ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Make every effective EiffelBase class implement default_create so that it can be used to instantiate any class with default values. || || ||

|-
! XXX
| Provide a WEAK_REFERENCE [G] class to abstract away the implementation details currently provided by IDENTIFIED for implementing weak references. || || ||

|-
! XXX
| Locale support to determine what the default charset is (or whether it is UTF-8 or not) || || ||

|-
! XXX
| Build an object storing database with built-in record locking so that multiple systems can have access to the same 'objects' || || ||

|-
! XXX
| Make base.ecf rely on smaller ecf's (kernel.ecf, structures.ecf, support.ecf) so that these smaller dependancies can be compiled in only if needs be. It would be good if ANY could be optimized so that it doesn't have any references to io (or print) or mismatch information (only needed when storable is employed) as these bring in a lot of overhead when compiling a simple system. The smaller ecf could also link in with the object files of the runtime to avoid linking against a monolithic runtime (cecil, storable, etc) when you only want to print ("Hello World") || ||
* Unused features are already eliminated in the dead code removal step when finalizing a system.
||

|-
! XXX
| Put more of the run-time code in to inline C code reducing the size of the executable if you are not using certain features, ideally the linked against runtime should only contain the core functionality needed to create objects, perform simple operations and garbage collect, any other features can be brought in on a class/library/configuration level. || || ||

|-
! Additional Classes
| It would be nice to have classes in the basic eiffel libraries for handling serial port communication, zip compression, encryption, smtp, pop3, ftp, http, TCP/IP, usb, pdf generation, print engine for report writing. I am sure their are others but the basic idea is that it would be nice to have a complete multi-OS tool for developing business applications with quick access to classes needed. Presently you have to search the internet to find some of these classes. It would be nicer to have a more complete library available from within the IDE. || || ||

|}

Talk:Single-level call rule and generics

2007-07-15T12:02:50Z

Schoelle:

Look very close to my suggestion, only that I had suggested to reuse the keyword 'invariant' instead of introducing a new keyword 'monomorphic', that not average developer will understand --[[User:Schoelle|Schoelle]] 14:02, 15 July 2007 (CEST)

Talk:Interval types

2007-07-11T20:22:29Z

Schoelle:

'''--[[User:Schoelle|Schoelle]] 12:33, 8 July 2007 (CEST)''': Could somebody illustrate how this solves the problem of convariant argument redefinition using 'like Current' or similar?

:'''--[[User:Manus|manus]] 18:14, 8 July 2007 (CEST)''': This case is just a typical case of implicit covariance. The rules are the same and therefore any feature involving `like Current' in its arguments will most likely be rejected in some cases unless the target is monomorphic. Dont' forget that it is mostly the case with `is_equal' and `copy' which are getting new signatures in the new ECMA standard. For COMPARABLE then it just mean that you won't be able to compare apple with oranges which is exactly what we are trying to avoid.

'''--[[User:Schoelle|Schoelle]] 15:30, 10 July 2007 (CEST)''' Thanks for the answer, this was enlighting. Second question: can anybody give examples from the practice that are different from A..A and A..NONE ? Something like A..B that really is needed and makes sense?

:'''--[[User:Seilerm|Seilerm]] 20:33, 10 July 2007 (CEST)''': I think this comes down to the very question where covariance on ordinary types is needed. If you want I can give a lot of examples for generics, probably because it is the main source where I personally use covariance. Besides that: I have seen code where one uses anchored types (i.e. the like keyword) to anchor argument types to the type of queries (mostly attributes). And then the query result type is redefined covariantly. This might be interesting if otherwise you would need a lot of generic parameters, but you only redefine a few times different query (attribute) types in your class hierarchy. That being said, I personally don't like this style of coding.

'''--[[User:Schoelle|Schoelle]] 12:13, 11 July 2007 (CEST)''' Ok, lets me see if I can correctly summarize, relating to my article [http://www.fams.de/text/type-safe-eiffel.html]. I am not doing this to advertise for my solution, but just because it is easier for me to understand something new by relating it to something that I have understood.

For ''Covariant arguments and anchored types'', we are (more or less) removing covariance from the language (the conformance rules have been made so restrictive that the BOAT/SKIPPER/CAT/CAT_SKIPPER example becomes illegal), as demanded in my article. '''(1)'''

For ''Genericity'', we are using rules similar to Wildcard types in Java, which disallows calls to features with arguments of a generic type (X[A..A] is X<A> in Java, X[A..NONE] is X<? extends A> in Java). '''(2)'''

I think that the approach of invariant arguments described in my paper is more elegant (I am probably just locked into own ideas), as the decision of using a generic parameter covariantly is made by the supplier and not the client, i.e. it becomes part of the library design. But if Java people can live with Wildcard types, so can we ... ;-) '''(3)'''

:'''--[[User:Juliant|Juliant]] 19:01, 11 July 2007 (CEST)'''
:for '''(1)''': Actually it's not the conformance rules that have been restricted, but the feature call rules. Per default you still have full conformance between normal types, but you mostly cannot call covariant features. In the end it is the same, restricting covariance as much as you probably won't use it anymore.
:for '''(2)''': Yes, they are very similar.
:for '''(3)''': The problem with the [[definition-site variance#Conclusion|invariant arguments]] you described is that they break the library for sure. Since one of the criterias for a catcall solution is backwards compatibility, this is not an option. If you would be starting from scratch, it may be a good option as the use of a generic is dictated by the library designer and it could be easier to use by the programmer.

::'''--[[User:Schoelle|Schoelle]] 22:22, 11 July 2007 (CEST)''' This needs to be seen. Both approaches break existing code. I do not know which one breaks more. I think that invariant arguments are easier to fix, as they are fixed on the supplier side, and not on the client side.

Talk:Interval types

2007-07-11T10:13:57Z

Schoelle:

'''--[[User:Schoelle|Schoelle]] 12:33, 8 July 2007 (CEST)''': Could somebody illustrate how this solves the problem of convariant argument redefinition using 'like Current' or similar?

:'''--[[User:Manus|manus]] 18:14, 8 July 2007 (CEST)''': This case is just a typical case of implicit covariance. The rules are the same and therefore any feature involving `like Current' in its arguments will most likely be rejected in some cases unless the target is monomorphic. Dont' forget that it is mostly the case with `is_equal' and `copy' which are getting new signatures in the new ECMA standard. For COMPARABLE then it just mean that you won't be able to compare apple with oranges which is exactly what we are trying to avoid.

'''--[[User:Schoelle|Schoelle]] 15:30, 10 July 2007 (CEST)''' Thanks for the answer, this was enlighting. Second question: can anybody give examples from the practice that are different from A..A and A..NONE ? Something like A..B that really is needed and makes sense?

:'''--[[User:Seilerm|Seilerm]] 20:33, 10 July 2007 (CEST)''': I think this comes down to the very question where covariance on ordinary types is needed. If you want I can give a lot of examples for generics, probably because it is the main source where I personally use covariance. Besides that: I have seen code where one uses anchored types (i.e. the like keyword) to anchor argument types to the type of queries (mostly attributes). And then the query result type is redefined covariantly. This might be interesting if otherwise you would need a lot of generic parameters, but you only redefine a few times different query (attribute) types in your class hierarchy. That being said, I personally don't like this style of coding.

'''--[[User:Schoelle|Schoelle]] 12:13, 11 July 2007 (CEST)''' Ok, lets me see if I can correctly summarize, relating to my article [http://www.fams.de/text/type-safe-eiffel.html]. I am not doing this to advertise for my solution, but just because it is easier for me to understand something new by relating it to something that I have understood.

For ''Covariant arguments and anchored types'', we are (more or less) removing covariance from the language (the conformance rules have been made so restrictive that the BOAT/SKIPPER/CAT/CAT_SKIPPER example becomes illegal), as demanded in my article.

For ''Genericity'', we are using rules similar to Wildcard types in Java, which disallows calls to features with arguments of a generic type (X[A..A] is X<A> in Java, X[A..NONE] is X<? extends A> in Java).

I think that the approach of invariant arguments described in my paper is more elegant (I am probably just locked into own ideas), as the decision of using a generic parameter covariantly is made by the supplier and not the client, i.e. it becomes part of the library design. But if Java people can live with Wildcard types, so can we ... ;-)

Talk:Interval types

2007-07-10T13:30:43Z

Schoelle:

Talk:Interval types

2007-07-08T10:33:28Z

Schoelle:

Could somebody illustrate how this solves the problem of convariant argument redefinition using 'like Current' or similar? --[[User:Schoelle|Schoelle]] 12:33, 8 July 2007 (CEST)

Talk:How to add a tool to Eiffel Studio

2007-03-23T07:07:36Z

Schoelle:

Looking forward to some content --[[User:Schoelle|Schoelle]] 08:07, 23 March 2007 (CET)

Talk:Debugging Eiffel Applications with gdb

2007-03-22T10:32:30Z

Schoelle:

Thanks, nice to have - but think you text got a little bit mixed up at the end. --[[User:Schoelle|Schoelle]] 11:32, 22 March 2007 (CET)

Covariance through renaming

2007-03-18T10:13:49Z

Schoelle: No construction

[[Category:ECMA]]

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

We have renamed 'eat' to 'animal_eat', to create space for a different feature 'eat' that is adequate for cows. We implement 'animal_eat' in terms of 'eat' if the supplied food is the right one. Otherwise, we have the conditions of a CAT call and raise an exception.

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we '''do not address the problems of CAT calls through genericity and change of export status'''. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Interestingly, the approach can be used to model any change of signature, including covariant, contravariant arguments, covariant and contravariant return types and even the change of existing or the introduction of new arguments. It is thus more powerful than the covariant mechansims available in Eiffel.

Talk:Compile EiffelStudio with Automatic Build Scripts

2007-03-15T08:48:23Z

Schoelle:

'''--[[User:Manus|manus]] 05:43, 11 March 2007 (CET)''' Three things:
# On Windows, you should let follow the instructions at [[Installing Microsoft C compiler]]
# Is the bash version relevant?
# I always recommend installing cygwin using DOS/Windows style file otherwise you end up with text file that contains a mixture of DOS and Unix newline. So why do you need UNIX end of file?

: I have carified the documentation concerning the BASH issues. We have indeed experienced problems with the current version of BASH. AFAIK, it is a known issues, but I just could not google the source. I hope that is ok like that. Also I have added a reference to [[Installing Microsoft C compiler]]. --[[User:Schoelle|Schoelle]] 09:48, 15 March 2007 (CET)

Compile EiffelStudio with Automatic Build Scripts

2007-03-15T08:33:34Z

Schoelle: /* Prerequisites */

[[Category:Compiler]]
[[Category:EiffelStudio]]

'''WARNING!'''

'''THIS DOCUMENT IS UNDER HEAVY DEVELOPMENT AND CORRESPONDS ONLY TO THE ES-MAKE BRANCH'''

=Linux-x86=

==Prerequisites==

In this example we use the example directory /home/user/eiffel. That means the binary EiffelStudio
would be installed at /home/user/eiffel/Eiffel60 and the trunk at /home/user/eiffel/trunk. This
documentation will have these paths as examples, so please replace them if you use different paths.

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the
precompiled EiffelStudio installation) on your machine. The current source tree requires at least
version 6.0 of EiffelStudio. You can download the precompiled version from
http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install
EiffelStudio.

To checkout the latest source code from the repository, you need subversion installed.

Also be sure to have the the gtk2.0 development library (for Ubuntu it would be the package
libgtk2.0-dev) and the xtst development library (ubuntu: libxtst-dev) installed

== Downloading Source Code==

Go to the directory where you want to have the EiffelStudio source code (/home/user/eiffel). Now
check out the sources from the repository.

<pre>
cd /home/user/eiffel
svn co https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make trunk
</pre>

== Setting Environmental Variables==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should
already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, GOBO. As well the binary paths
for gobo and EiffelStudio need to be added to the PATH variable.

There are two different ways for doing this: either set it temporary for this session (don't restart the
terminal) or set it permanently in your .bashrc

* Temporary
'''(don't restart the terminal during the compilation, all variables will be lost!)'''
<pre>
export EIFFEL_SRC=/home/user/eiffel/trunk/Src
export ISE_EIFFEL=/home/user/eiffel/Eiffel60
export ISE_PLATFORM=linux-x86
export ISE_LIBRARY=${EIFFEL_SRC}
export GOBO=${EIFFEL_SRC}/library/gobo/svn
export PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
</pre>

* Permanent
edit your /home/user/.bashrc and add these lines:
<pre>
EIFFEL_SRC="/home/user/eiffel/trunk/Src"
ISE_EIFFEL="/home/user/eiffel/Eiffel60"
ISE_PLATFORM="linux-x86"
ISE_LIBRARY="${EIFFEL_SRC}"
GOBO="/home/user/eiffel/trunk/Src/library/gobo/svn
PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
export ISE_EIFFEL ISE_PLATFORM EIFFEL_SRC ISE_LIBRARY PATH GOBO
</pre>
'''IMPORTANT: You need to restart the terminal for the changes to take effect'''

== Compiling and Installing Gobo tools ==

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it.
For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.
<pre>
cd $GOBO/work/bootstrap
sh bootstrap.sh gcc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to trunk/Src and run the check_setup script

<pre>
cd $EIFFEL_SRC
make check_setup
</pre>

If all tests were successful, it says „Setup check complete. Your configuration seems ok!“ Now you can start compiling.Otherwise check the error messages and fix the problems.

<pre>
cd $EIFFEL_SRC
make build_delivery
</pre>

(this will take a while)

GOOD LUCK!

=Windows=

== Prerequisites ==

In this example we use the example directory C:\Programme\EiffelSoftware\. That means the binary EiffelStudio would be installed at C:\Programme\EiffelSoftware\Eiffel60 and the trunk at C:\Programme\EiffelSoftware\trunk. Cygwin is located in C:\cygwin. This documentation will have these paths as examples, so please replace them if you use different paths.

At first you need a C compiler on your system. We recommend to install Microsoft Visual Studio .NET as it has all included and is easy to install. Instead you can install the Microsoft SDK from http://download.microsoft.com/download/a/7/7/a7767f09-0136-4a96-a1f8-276bf0ee31fa/Setup.exe . Please also see the documentation that is available under [[Installing Microsoft C compiler]].

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the precompiled EiffelStudio installation) on your machine. The current source tree requires at least version 6.0 of EiffelStudio. You can download the precompiled version from http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install EiffelStudio.

To checkout the latest source code from the repository, you need a subversion client installed (for example TortoiseSVN).

As the compilation needs a working bash on the system you need to install cygwin. It is important that you choose Unix/binary as Default Text File Type during the installation and select a bash version 3.1-6 (in the package selection screen --> Shells /bash, click on version number to change). The latest version of Bash (while writing this documentation) had some troubles with Windows newlines. Future versions should be fine, too, but if you have trouble running the scripts, this might be the first thing to check.

== Downloading Source Code ==

Go to the directory where you want to have the EiffelStudio source code (C:\Programme\EiffelSoftware\). Now check out the sources from the repository.

<pre>
right-click in the folder, choose SVN Checkout
URL of repository: https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make
Checkout directory: C:\Programme\EiffelSoftware\trunk
</pre>

possibly you need to kill TSVNcache.exe ... memory leak

== Setting Environmental Variables ==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, ISE_C_COMPILER, GOBO. As well the binary-paths for gobo, cygwin and EiffelStudio need to be added to the PATH variable.

Goto Systemsteuerung, open the 'System' Dialogue, in 'erweitert' you can click on 'Umgebungsvariabeln' In the upper Box enter each of the new environmental variables by clicking new:

<pre>
name value

EIFFEL_SRC C:\Programme\EiffelSoftware\trunk\Src
ISE_EIFFEL C:\Programme\EiffelSoftware\Eiffel60
ISE_PLATFORM windows
ISE_LIBRARY %EIFFEL_SRC%
ISE_C_COMPILER msc
GOBO C:\Programme\EiffelSoftware\trunk\Src\library\gobo\svn
Path %Path%;%ISE_EIFFEL%\studio\spec\%ISE_PLATFORM%\bin;%GOBO%\bin;C:\cygwin\bin;
C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\bin
</pre>

== Compiling and Installing Gobo tools ==

You should really use the Command Prompt included in Microsoft Visual Studio .NET. The regular Windows Command Prompt should work as well but you had to set all the binary paths for Visual Studio.

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it. For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.

<pre>
cd %GOBO%\work\bootstrap
bootstrap.bat msc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to C:\Programme\EiffelSoftware\trunk\Src and run the check_setup script

<pre>
cd %EIFFEL_SRC%
Makefile.bat check_setup
</pre>

If all tests were successful, it says "Setup check complete. Your configuration seems ok!" Now you can start compiling. Otherwise check the error messages and fix the problems.

<pre>
cd %EIFFEL_SRC%
Makefile.bat build_delivery
</pre>

(this will take a while)

GOOD LUCK!

Compile EiffelStudio with Automatic Build Scripts

2007-03-15T08:32:29Z

Schoelle: /* Prerequisites */

[[Category:Compiler]]
[[Category:EiffelStudio]]

'''WARNING!'''

'''THIS DOCUMENT IS UNDER HEAVY DEVELOPMENT AND CORRESPONDS ONLY TO THE ES-MAKE BRANCH'''

=Linux-x86=

==Prerequisites==

In this example we use the example directory /home/user/eiffel. That means the binary EiffelStudio
would be installed at /home/user/eiffel/Eiffel60 and the trunk at /home/user/eiffel/trunk. This
documentation will have these paths as examples, so please replace them if you use different paths.

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the
precompiled EiffelStudio installation) on your machine. The current source tree requires at least
version 6.0 of EiffelStudio. You can download the precompiled version from
http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install
EiffelStudio.

To checkout the latest source code from the repository, you need subversion installed.

Also be sure to have the the gtk2.0 development library (for Ubuntu it would be the package
libgtk2.0-dev) and the xtst development library (ubuntu: libxtst-dev) installed

== Downloading Source Code==

Go to the directory where you want to have the EiffelStudio source code (/home/user/eiffel). Now
check out the sources from the repository.

<pre>
cd /home/user/eiffel
svn co https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make trunk
</pre>

== Setting Environmental Variables==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should
already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, GOBO. As well the binary paths
for gobo and EiffelStudio need to be added to the PATH variable.

There are two different ways for doing this: either set it temporary for this session (don't restart the
terminal) or set it permanently in your .bashrc

* Temporary
'''(don't restart the terminal during the compilation, all variables will be lost!)'''
<pre>
export EIFFEL_SRC=/home/user/eiffel/trunk/Src
export ISE_EIFFEL=/home/user/eiffel/Eiffel60
export ISE_PLATFORM=linux-x86
export ISE_LIBRARY=${EIFFEL_SRC}
export GOBO=${EIFFEL_SRC}/library/gobo/svn
export PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
</pre>

* Permanent
edit your /home/user/.bashrc and add these lines:
<pre>
EIFFEL_SRC="/home/user/eiffel/trunk/Src"
ISE_EIFFEL="/home/user/eiffel/Eiffel60"
ISE_PLATFORM="linux-x86"
ISE_LIBRARY="${EIFFEL_SRC}"
GOBO="/home/user/eiffel/trunk/Src/library/gobo/svn
PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
export ISE_EIFFEL ISE_PLATFORM EIFFEL_SRC ISE_LIBRARY PATH GOBO
</pre>
'''IMPORTANT: You need to restart the terminal for the changes to take effect'''

== Compiling and Installing Gobo tools ==

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it.
For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.
<pre>
cd $GOBO/work/bootstrap
sh bootstrap.sh gcc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to trunk/Src and run the check_setup script

<pre>
cd $EIFFEL_SRC
make check_setup
</pre>

If all tests were successful, it says „Setup check complete. Your configuration seems ok!“ Now you can start compiling.Otherwise check the error messages and fix the problems.

<pre>
cd $EIFFEL_SRC
make build_delivery
</pre>

(this will take a while)

GOOD LUCK!

=Windows=

== Prerequisites ==

In this example we use the example directory C:\Programme\EiffelSoftware\. That means the binary EiffelStudio would be installed at C:\Programme\EiffelSoftware\Eiffel60 and the trunk at C:\Programme\EiffelSoftware\trunk. Cygwin is located in C:\cygwin. This documentation will have these paths as examples, so please replace them if you use different paths.

At first you need a C compiler on your system. We recommend to install Microsoft Visual Studio .NET as it has all included and is easy to install. Instead you can install the Microsoft SDK from http://download.microsoft.com/download/a/7/7/a7767f09-0136-4a96-a1f8-276bf0ee31fa/Setup.exe . Please also see the documentation that is available under [[Installing Microsoft C compiler]].

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the precompiled EiffelStudio installation) on your machine. The current source tree requires at least version 6.0 of EiffelStudio. You can download the precompiled version from http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install EiffelStudio.

To checkout the latest source code from the repository, you need a subversion client installed (for example TortoiseSVN).

As the compilation needs a working bash on the system you need to install cygwin. It is important that you choose Unix/binary as Default Text File Type during the installation and select a bash version 3.1-6 (in the package selection screen --> Shells /bash, click on version number to change). The latest version while writing had some troubles with Windows newlines. Future versions should be fine, too, but if you have trouble running the scripts, this might be the first thing to check.

== Downloading Source Code ==

Go to the directory where you want to have the EiffelStudio source code (C:\Programme\EiffelSoftware\). Now check out the sources from the repository.

<pre>
right-click in the folder, choose SVN Checkout
URL of repository: https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make
Checkout directory: C:\Programme\EiffelSoftware\trunk
</pre>

possibly you need to kill TSVNcache.exe ... memory leak

== Setting Environmental Variables ==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, ISE_C_COMPILER, GOBO. As well the binary-paths for gobo, cygwin and EiffelStudio need to be added to the PATH variable.

Goto Systemsteuerung, open the 'System' Dialogue, in 'erweitert' you can click on 'Umgebungsvariabeln' In the upper Box enter each of the new environmental variables by clicking new:

<pre>
name value

EIFFEL_SRC C:\Programme\EiffelSoftware\trunk\Src
ISE_EIFFEL C:\Programme\EiffelSoftware\Eiffel60
ISE_PLATFORM windows
ISE_LIBRARY %EIFFEL_SRC%
ISE_C_COMPILER msc
GOBO C:\Programme\EiffelSoftware\trunk\Src\library\gobo\svn
Path %Path%;%ISE_EIFFEL%\studio\spec\%ISE_PLATFORM%\bin;%GOBO%\bin;C:\cygwin\bin;
C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\bin
</pre>

== Compiling and Installing Gobo tools ==

You should really use the Command Prompt included in Microsoft Visual Studio .NET. The regular Windows Command Prompt should work as well but you had to set all the binary paths for Visual Studio.

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it. For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.

<pre>
cd %GOBO%\work\bootstrap
bootstrap.bat msc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to C:\Programme\EiffelSoftware\trunk\Src and run the check_setup script

<pre>
cd %EIFFEL_SRC%
Makefile.bat check_setup
</pre>

If all tests were successful, it says "Setup check complete. Your configuration seems ok!" Now you can start compiling. Otherwise check the error messages and fix the problems.

<pre>
cd %EIFFEL_SRC%
Makefile.bat build_delivery
</pre>

(this will take a while)

GOOD LUCK!

Compile EiffelStudio with Automatic Build Scripts

2007-03-15T08:29:18Z

Schoelle: /* Prerequisites */

[[Category:Compiler]]
[[Category:EiffelStudio]]

'''WARNING!'''

'''THIS DOCUMENT IS UNDER HEAVY DEVELOPMENT AND CORRESPONDS ONLY TO THE ES-MAKE BRANCH'''

=Linux-x86=

==Prerequisites==

In this example we use the example directory /home/user/eiffel. That means the binary EiffelStudio
would be installed at /home/user/eiffel/Eiffel60 and the trunk at /home/user/eiffel/trunk. This
documentation will have these paths as examples, so please replace them if you use different paths.

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the
precompiled EiffelStudio installation) on your machine. The current source tree requires at least
version 6.0 of EiffelStudio. You can download the precompiled version from
http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install
EiffelStudio.

To checkout the latest source code from the repository, you need subversion installed.

Also be sure to have the the gtk2.0 development library (for Ubuntu it would be the package
libgtk2.0-dev) and the xtst development library (ubuntu: libxtst-dev) installed

== Downloading Source Code==

Go to the directory where you want to have the EiffelStudio source code (/home/user/eiffel). Now
check out the sources from the repository.

<pre>
cd /home/user/eiffel
svn co https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make trunk
</pre>

== Setting Environmental Variables==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should
already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, GOBO. As well the binary paths
for gobo and EiffelStudio need to be added to the PATH variable.

There are two different ways for doing this: either set it temporary for this session (don't restart the
terminal) or set it permanently in your .bashrc

* Temporary
'''(don't restart the terminal during the compilation, all variables will be lost!)'''
<pre>
export EIFFEL_SRC=/home/user/eiffel/trunk/Src
export ISE_EIFFEL=/home/user/eiffel/Eiffel60
export ISE_PLATFORM=linux-x86
export ISE_LIBRARY=${EIFFEL_SRC}
export GOBO=${EIFFEL_SRC}/library/gobo/svn
export PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
</pre>

* Permanent
edit your /home/user/.bashrc and add these lines:
<pre>
EIFFEL_SRC="/home/user/eiffel/trunk/Src"
ISE_EIFFEL="/home/user/eiffel/Eiffel60"
ISE_PLATFORM="linux-x86"
ISE_LIBRARY="${EIFFEL_SRC}"
GOBO="/home/user/eiffel/trunk/Src/library/gobo/svn
PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
export ISE_EIFFEL ISE_PLATFORM EIFFEL_SRC ISE_LIBRARY PATH GOBO
</pre>
'''IMPORTANT: You need to restart the terminal for the changes to take effect'''

== Compiling and Installing Gobo tools ==

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it.
For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.
<pre>
cd $GOBO/work/bootstrap
sh bootstrap.sh gcc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to trunk/Src and run the check_setup script

<pre>
cd $EIFFEL_SRC
make check_setup
</pre>

If all tests were successful, it says „Setup check complete. Your configuration seems ok!“ Now you can start compiling.Otherwise check the error messages and fix the problems.

<pre>
cd $EIFFEL_SRC
make build_delivery
</pre>

(this will take a while)

GOOD LUCK!

=Windows=

== Prerequisites ==

In this example we use the example directory C:\Programme\EiffelSoftware\. That means the binary EiffelStudio would be installed at C:\Programme\EiffelSoftware\Eiffel60 and the trunk at C:\Programme\EiffelSoftware\trunk. Cygwin is located in C:\cygwin. This documentation will have these paths as examples, so please replace them if you use different paths.

At first you need a C compiler on your system. We recommend to install Microsoft Visual Studio .NET as it has all included and is easy to install. Instead you can install the Microsoft SDK from http://download.microsoft.com/download/a/7/7/a7767f09-0136-4a96-a1f8-276bf0ee31fa/Setup.exe . Please also see the documentation that is available under [[Installing Microsoft C compiler]].

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the precompiled EiffelStudio installation) on your machine. The current source tree requires at least version 6.0 of EiffelStudio. You can download the precompiled version from http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install EiffelStudio.

To checkout the latest source code from the repository, you need a subversion client installed (for example TortoiseSVN).

As the compilation needs a working bash on the system you need to install cygwin. It is important that you choose Unix/binary as Default Text File Type during the installation and select a bash version 3.1-6 (in the package selection screen --> Shells /bash, click on version number to change). There should not be such a problem with other versions, but if you have trouble running the scripts, this might be the first thing to check.

== Downloading Source Code ==

Go to the directory where you want to have the EiffelStudio source code (C:\Programme\EiffelSoftware\). Now check out the sources from the repository.

<pre>
right-click in the folder, choose SVN Checkout
URL of repository: https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make
Checkout directory: C:\Programme\EiffelSoftware\trunk
</pre>

possibly you need to kill TSVNcache.exe ... memory leak

== Setting Environmental Variables ==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, ISE_C_COMPILER, GOBO. As well the binary-paths for gobo, cygwin and EiffelStudio need to be added to the PATH variable.

Goto Systemsteuerung, open the 'System' Dialogue, in 'erweitert' you can click on 'Umgebungsvariabeln' In the upper Box enter each of the new environmental variables by clicking new:

<pre>
name value

EIFFEL_SRC C:\Programme\EiffelSoftware\trunk\Src
ISE_EIFFEL C:\Programme\EiffelSoftware\Eiffel60
ISE_PLATFORM windows
ISE_LIBRARY %EIFFEL_SRC%
ISE_C_COMPILER msc
GOBO C:\Programme\EiffelSoftware\trunk\Src\library\gobo\svn
Path %Path%;%ISE_EIFFEL%\studio\spec\%ISE_PLATFORM%\bin;%GOBO%\bin;C:\cygwin\bin;
C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\bin
</pre>

== Compiling and Installing Gobo tools ==

You should really use the Command Prompt included in Microsoft Visual Studio .NET. The regular Windows Command Prompt should work as well but you had to set all the binary paths for Visual Studio.

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it. For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.

<pre>
cd %GOBO%\work\bootstrap
bootstrap.bat msc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to C:\Programme\EiffelSoftware\trunk\Src and run the check_setup script

<pre>
cd %EIFFEL_SRC%
Makefile.bat check_setup
</pre>

If all tests were successful, it says "Setup check complete. Your configuration seems ok!" Now you can start compiling. Otherwise check the error messages and fix the problems.

<pre>
cd %EIFFEL_SRC%
Makefile.bat build_delivery
</pre>

(this will take a while)

GOOD LUCK!

Compile EiffelStudio with Automatic Build Scripts

2007-03-15T08:24:54Z

Schoelle: /* Prerequisites */

[[Category:Compiler]]
[[Category:EiffelStudio]]

'''WARNING!'''

'''THIS DOCUMENT IS UNDER HEAVY DEVELOPMENT AND CORRESPONDS ONLY TO THE ES-MAKE BRANCH'''

=Linux-x86=

==Prerequisites==

In this example we use the example directory /home/user/eiffel. That means the binary EiffelStudio
would be installed at /home/user/eiffel/Eiffel60 and the trunk at /home/user/eiffel/trunk. This
documentation will have these paths as examples, so please replace them if you use different paths.

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the
precompiled EiffelStudio installation) on your machine. The current source tree requires at least
version 6.0 of EiffelStudio. You can download the precompiled version from
http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install
EiffelStudio.

To checkout the latest source code from the repository, you need subversion installed.

Also be sure to have the the gtk2.0 development library (for Ubuntu it would be the package
libgtk2.0-dev) and the xtst development library (ubuntu: libxtst-dev) installed

== Downloading Source Code==

Go to the directory where you want to have the EiffelStudio source code (/home/user/eiffel). Now
check out the sources from the repository.

<pre>
cd /home/user/eiffel
svn co https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make trunk
</pre>

== Setting Environmental Variables==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should
already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, GOBO. As well the binary paths
for gobo and EiffelStudio need to be added to the PATH variable.

There are two different ways for doing this: either set it temporary for this session (don't restart the
terminal) or set it permanently in your .bashrc

* Temporary
'''(don't restart the terminal during the compilation, all variables will be lost!)'''
<pre>
export EIFFEL_SRC=/home/user/eiffel/trunk/Src
export ISE_EIFFEL=/home/user/eiffel/Eiffel60
export ISE_PLATFORM=linux-x86
export ISE_LIBRARY=${EIFFEL_SRC}
export GOBO=${EIFFEL_SRC}/library/gobo/svn
export PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
</pre>

* Permanent
edit your /home/user/.bashrc and add these lines:
<pre>
EIFFEL_SRC="/home/user/eiffel/trunk/Src"
ISE_EIFFEL="/home/user/eiffel/Eiffel60"
ISE_PLATFORM="linux-x86"
ISE_LIBRARY="${EIFFEL_SRC}"
GOBO="/home/user/eiffel/trunk/Src/library/gobo/svn
PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
export ISE_EIFFEL ISE_PLATFORM EIFFEL_SRC ISE_LIBRARY PATH GOBO
</pre>
'''IMPORTANT: You need to restart the terminal for the changes to take effect'''

== Compiling and Installing Gobo tools ==

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it.
For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.
<pre>
cd $GOBO/work/bootstrap
sh bootstrap.sh gcc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to trunk/Src and run the check_setup script

<pre>
cd $EIFFEL_SRC
make check_setup
</pre>

If all tests were successful, it says „Setup check complete. Your configuration seems ok!“ Now you can start compiling.Otherwise check the error messages and fix the problems.

<pre>
cd $EIFFEL_SRC
make build_delivery
</pre>

(this will take a while)

GOOD LUCK!

=Windows=

== Prerequisites ==

In this example we use the example directory C:\Programme\EiffelSoftware\. That means the binary EiffelStudio would be installed at C:\Programme\EiffelSoftware\Eiffel60 and the trunk at C:\Programme\EiffelSoftware\trunk. Cygwin is located in C:\cygwin. This documentation will have these paths as examples, so please replace them if you use different paths.

At first you need a C compiler on your system. We recommend to install Microsoft Visual Studio .NET as it has all included and is easy to install. Instead you can install the Microsoft SDK from http://download.microsoft.com/download/a/7/7/a7767f09-0136-4a96-a1f8-276bf0ee31fa/Setup.exe . Please also see the documentation that is available under [[Installing Microsoft C compiler]].

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the precompiled EiffelStudio installation) on your machine. The current source tree requires at least version 6.0 of EiffelStudio. You can download the precompiled version from http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install EiffelStudio.

To checkout the latest source code from the repository, you need a subversion client installed (for example TortoiseSVN).

As the compilation needs a working bash on the system you need to install cygwin. It is important that you choose Unix/binary as Default Text File Type during the installation and select a bash version 3.1-6 (in the package selection screen --> Shells /bash, click on version number to change)

== Downloading Source Code ==

Go to the directory where you want to have the EiffelStudio source code (C:\Programme\EiffelSoftware\). Now check out the sources from the repository.

<pre>
right-click in the folder, choose SVN Checkout
URL of repository: https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make
Checkout directory: C:\Programme\EiffelSoftware\trunk
</pre>

possibly you need to kill TSVNcache.exe ... memory leak

== Setting Environmental Variables ==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, ISE_C_COMPILER, GOBO. As well the binary-paths for gobo, cygwin and EiffelStudio need to be added to the PATH variable.

Goto Systemsteuerung, open the 'System' Dialogue, in 'erweitert' you can click on 'Umgebungsvariabeln' In the upper Box enter each of the new environmental variables by clicking new:

<pre>
name value

EIFFEL_SRC C:\Programme\EiffelSoftware\trunk\Src
ISE_EIFFEL C:\Programme\EiffelSoftware\Eiffel60
ISE_PLATFORM windows
ISE_LIBRARY %EIFFEL_SRC%
ISE_C_COMPILER msc
GOBO C:\Programme\EiffelSoftware\trunk\Src\library\gobo\svn
Path %Path%;%ISE_EIFFEL%\studio\spec\%ISE_PLATFORM%\bin;%GOBO%\bin;C:\cygwin\bin;
C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\bin
</pre>

== Compiling and Installing Gobo tools ==

You should really use the Command Prompt included in Microsoft Visual Studio .NET. The regular Windows Command Prompt should work as well but you had to set all the binary paths for Visual Studio.

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it. For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.

<pre>
cd %GOBO%\work\bootstrap
bootstrap.bat msc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to C:\Programme\EiffelSoftware\trunk\Src and run the check_setup script

<pre>
cd %EIFFEL_SRC%
Makefile.bat check_setup
</pre>

If all tests were successful, it says "Setup check complete. Your configuration seems ok!" Now you can start compiling. Otherwise check the error messages and fix the problems.

<pre>
cd %EIFFEL_SRC%
Makefile.bat build_delivery
</pre>

(this will take a while)

GOOD LUCK!

Compile EiffelStudio with Automatic Build Scripts

2007-03-14T11:49:32Z

Schoelle: /* Setting Environmental Variables */ Typos

[[Category:Compiler]]
[[Category:EiffelStudio]]

'''WARNING!'''

'''THIS DOCUMENT IS UNDER HEAVY DEVELOPMENT AND CORRESPONDS ONLY TO THE ES-MAKE BRANCH'''

=Linux-x86=

==Prerequisites==

In this example we use the example directory /home/user/eiffel. That means the binary EiffelStudio
would be installed at /home/user/eiffel/Eiffel60 and the trunk at /home/user/eiffel/trunk. This
documentation will have these paths as examples, so please replace them if you use different paths.

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the
precompiled EiffelStudio installation) on your machine. The current source tree requires at least
version 6.0 of EiffelStudio. You can download the precompiled version from
http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install
EiffelStudio.

To checkout the latest source code from the repository, you need subversion installed.

Also be sure to have the the gtk2.0 development library (for Ubuntu it would be the package
libgtk2.0-dev) and the xtst development library (ubuntu: libxtst-dev) installed

== Downloading Source Code==

Go to the directory where you want to have the EiffelStudio source code (/home/user/eiffel). Now
check out the sources from the repository.

<pre>
cd /home/user/eiffel
svn co https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make trunk
</pre>

== Setting Environmental Variables==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should
already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, GOBO. As well the binary paths
for gobo and EiffelStudio need to be added to the PATH variable.

There are two different ways for doing this: either set it temporary for this session (don't restart the
terminal) or set it permanently in your .bashrc

* Temporary
'''(don't restart the terminal during the compilation, all variables will be lost!)'''
<pre>
export EIFFEL_SRC=/home/user/eiffel/trunk/Src
export ISE_EIFFEL=/home/user/eiffel/Eiffel60
export ISE_PLATFORM=linux-x86
export ISE_LIBRARY=${EIFFEL_SRC}
export GOBO=${EIFFEL_SRC}/library/gobo/svn
export PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
</pre>

* Permanent
edit your /home/user/.bashrc and add these lines:
<pre>
EIFFEL_SRC="/home/user/eiffel/trunk/Src"
ISE_EIFFEL="/home/user/eiffel/Eiffel60"
ISE_PLATFORM="linux-x86"
ISE_LIBRARY="${EIFFEL_SRC}"
GOBO="/home/user/eiffel/trunk/Src/library/gobo/svn
PATH=${PATH}:${ISE_EIFFEL}/studio/spec/${ISE_PLATFORM}/bin:${EIFFEL_SRC}/library/gobo/svn/bin
export ISE_EIFFEL ISE_PLATFORM EIFFEL_SRC ISE_LIBRARY PATH GOBO
</pre>
'''IMPORTANT: You need to restart the terminal for the changes to take effect'''

== Compiling and Installing Gobo tools ==

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it.
For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.
<pre>
cd $GOBO/work/bootstrap
sh bootstrap.sh gcc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to trunk/Src and run the check_setup script

<pre>
cd $EIFFEL_SRC
make check_setup
</pre>

If all tests were successful, it says „Setup check complete. Your configuration seems ok!“ Now you can start compiling.Otherwise check the error messages and fix the problems.

<pre>
cd $EIFFEL_SRC
make build_delivery
</pre>

(this will take a while)

GOOD LUCK!

=Windows=

== Prerequisites ==

In this example we use the example directory C:\Programme\EiffelSoftware\. That means the binary EiffelStudio would be installed at C:\Programme\EiffelSoftware\Eiffel60 and the trunk at C:\Programme\EiffelSoftware\trunk. Cygwin is located in C:\cygwin. This documentation will have these paths as examples, so please replace them if you use different paths.

At first you need a C compiler on your system. We recommend to install Microsoft Visual Studio .NET as it has all included and is easy to install. Instead you can install the Microsoft SDK from http://download.microsoft.com/download/a/7/7/a7767f09-0136-4a96-a1f8-276bf0ee31fa/Setup.exe

To compile EiffelStudio, you need an already working EiffelStudio compiler (which comes with the precompiled EiffelStudio installation) on your machine. The current source tree requires at least version 6.0 of EiffelStudio. You can download the precompiled version from http://eiffelsoftware.origo.ethz.ch/downloads/builds/. Read the existing documentation to install EiffelStudio.

To checkout the latest source code from the repository, you need a subversion client installed (for example TortoiseSVN).

As the compilation needs a working bash on the system you need to install cygwin. It is important that you choose Unix/binary as Default Text File Type during the installation and select a bash version 3.1-6 (in the package selection screen --> Shells /bash, click on version number to change)

== Downloading Source Code ==

Go to the directory where you want to have the EiffelStudio source code (C:\Programme\EiffelSoftware\). Now check out the sources from the repository.

<pre>
right-click in the folder, choose SVN Checkout
URL of repository: https://eiffelsoftware.origo.ethz.ch/svn/es/branches/es-make
Checkout directory: C:\Programme\EiffelSoftware\trunk
</pre>

possibly you need to kill TSVNcache.exe ... memory leak

== Setting Environmental Variables ==

These environmental variables need to be set: ISE_EIFFEL, ISE_PLATFORM (these two should already be set from EiffelStudio installation), ISE_LIBRARY, EIFFEL_SRC, ISE_C_COMPILER, GOBO. As well the binary-paths for gobo, cygwin and EiffelStudio need to be added to the PATH variable.

Goto Systemsteuerung, open the 'System' Dialogue, in 'erweitert' you can click on 'Umgebungsvariabeln' In the upper Box enter each of the new environmental variables by clicking new:

<pre>
name value

EIFFEL_SRC C:\Programme\EiffelSoftware\trunk\Src
ISE_EIFFEL C:\Programme\EiffelSoftware\Eiffel60
ISE_PLATFORM windows
ISE_LIBRARY %EIFFEL_SRC%
ISE_C_COMPILER msc
GOBO C:\Programme\EiffelSoftware\trunk\Src\library\gobo\svn
Path %Path%;%ISE_EIFFEL%\studio\spec\%ISE_PLATFORM%\bin;%GOBO%\bin;C:\cygwin\bin;
C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\bin
</pre>

== Compiling and Installing Gobo tools ==

You should really use the Command Prompt included in Microsoft Visual Studio .NET. The regular Windows Command Prompt should work as well but you had to set all the binary paths for Visual Studio.

The Gobo tools source code is already included in the SVN checkout of the Eiffel source. But we still need to bootstrap it. For further information about the different valid compilers please read the Readme.txt in the bootstrap directory or execute the bootstrap script without any arguments.

<pre>
cd %GOBO%\work\bootstrap
bootstrap.bat msc ise
</pre>

(this will take a while)

== Compiling EiffelStudio ==

Now go to C:\Programme\EiffelSoftware\trunk\Src and run the check_setup script

<pre>
cd %EIFFEL_SRC%
Makefile.bat check_setup
</pre>

If all tests were successful, it says "Setup check complete. Your configuration seems ok!" Now you can start compiling. Otherwise check the error messages and fix the problems.

<pre>
cd %EIFFEL_SRC%
Makefile.bat build_delivery
</pre>

(this will take a while)

GOOD LUCK!

Eiffel Glossary

2007-03-13T10:40:08Z

Schoelle: Removed content, that was moved to eiffelroom

[[Category: General]]
Eiffel uses a precisely defined terminology. That terminology sometimes sounds strange to programmers used to other languages, but it's only because (1) there has been a systematic effort to classify object-oriented concepts in a logical way; (2) some of the terms predate terminology that is used in other languages. You will see, however, that behind every choice of term there is a carefully devised rationale.

The new, community-based Eiffel glossary has been moved and is now available at http://www.eiffelroom.org/glossary

Also, there is a glossary of Eiffel terminology for .NET developers available at http://docs.eiffel.com/eiffelstudio/technologies/dotnet/eiffel_dotnet_language/10_conventions/10_terminology.html

Main Page

2007-03-05T15:52:15Z

Schoelle: /* Getting Started */ Added the EiffelRoom

__NOTOC__
<h1 class="firstHeading">EiffelStudio Integrated Development Environment</h1>

[[Image:EiffelStudioScreenshot.png|thumb|250px|right|EiffelStudio IDE ([http://eiffel.com/products/studio/screenshots.html more screenshots]) ]]

Welcome to the homepage and Wiki of the EiffelStudio IDE open-source project. EiffelStudio is a full-featured, commercial grade IDE for the [http://en.wikipedia.org/wiki/Eiffel_programming_language Eiffel programming language]. It is maintained and developed mostly by [http://www.eiffel.com Eiffel Software Inc.] and hosted at the [http://se.inf.ethz.ch/ Chair of Software Engineering] at the [http://www.ethz.ch/ ETH Zurich].

On April 5th, 2006, Eiffel Software relicensed the EiffelStudio product under the [[Gnu Public License]]. Eiffel Software still offers a commercial variant. Both versions share the same source code.

EiffelStudio is a modern IDE that offers the following features:

* Complete and efficient compiler for the Eiffel programming language
* Support for Windows, MacOS X, Linux, *BSD, Solaris and other operating systems
* Editor for Eiffel code
* Different browsing and viewing facilities
* Interactive debugger
* Graphical modelling tool for UML and BON with full roundtrip
* Refactoring support
* GUI development tool and fully portable GUI library

The Eiffel compiler creates C code that is then handed to a standard C compiler. As a result, the programs have a performance comparable to programs directly written in C or C++. At the same time, Eiffel is an object-oriented and strongly typed language. EiffelStudio uses a highly efficient moving garbage collector to free the developer from the burden of memory management.

<center>If you want to know more about the unique features of Eiffel and EiffelStudio, check out our [[Reasons for using Eiffel]] page.</center>

{|style="font-size:80%;" bgcolor=white|
{| cellspacing=8 width="100%"
|- valign="top"
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|

== Getting Started ==

* [[Downloads]]
* [[EiffelStudio 5.7 Releases|Changelog of 5.7 (release branch)]]
* [http://docs.eiffel.com/eiffelstudio/installation/studio57 Installing EiffelStudio]
* [[Compiling Hello World]]
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|

== Working with EiffelStudio ==

* [[Frequently Asked Questions]]
* [[Eiffel Glossary]]
* [[Eiffel Compilation Explained]]
* [[EiffelStudio Wish List]]

|- valign="top"
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|
== EiffelStudio's Development ==

* [[EiffelStudio 6.0 Releases|Changelog of 6.x (development trunk)]]
* [[Repository|Getting the source: Subversion repository]]
* [[Compiling EiffelStudio]]
* [[:Category:Tools|Developer's tools]]
* [[Contributing|How to contribute]]
* [[:Category:Eweasel|Regression testing]]
* [[:Category:Projects|Projects]]
|width="50%" bgcolor="#f6f9fb" style="border:1px solid #8f8f8f;padding:0 .5em .5em .5em;"|

== Community ==

* [http://www.eiffelroom.com EiffelRoom]
* [[Eiffel Sites and Links]]
* [[Mailing Lists]]
* [[:Category:News|News]]

|}

Talk:Covariance through renaming

2007-02-22T18:54:02Z

Schoelle:

The key insight here is that it is inappropriate and unworkable to try to use the type system to model the eating habits of herbivores. Any real-world animals will have eating preferences too complex to model through the type system anyway, even if it did not cause catcalls.

The precondition "likes" solves the problem. And once you have the problem solved this way, there is no need for the renaming and the introduction of new, unrelated 'eat' features in descendants. Just redefine "likes" for each kind of animal. [[User:Eiffel|Eiffel]] 12:38, 22 February 2007 (CET)

: Which does not solve the problem of covariant arguments, for example when you want to add a postcondition to 'eat' the needs to talk about the fact that grass was eaten. --[[User:Schoelle|Schoelle]] 15:08, 22 February 2007 (CET)

'''--[[User:Manus|manus]] 17:43, 22 February 2007 (CET)''' One of the issue of the proposal is that it is more or less what the other languages are currently using to fake covariance. So Eiffel would not be in a better position, this is why I think we should find a solution not involving the addition of new routines.

: I really cannot understand what 'fake covariance' is. We are facing a modelling problem and that needs to be adequately solved. My suggestion tries to show that there is a certain class of problems that are normally called good examples for the need of covariance (CAT_SKIPPER, ANIMAL/COW) that can be solved purely by renaming, without any loss of precision or generality. The problem of 'implicit covariance' through generic parameters seems to be the only reason to support covariance (although this is indeed a hard problem). --[[User:Schoelle|Schoelle]] 19:54, 22 February 2007 (CET)

Talk:Covariance through renaming

2007-02-22T14:08:21Z

Schoelle:

Covariance through renaming

2007-02-21T14:47:32Z

Schoelle: /* Discussion */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

We have renamed 'eat' to 'animal_eat', to create space for a different feature 'eat' that is adequate for cows. We implement 'animal_eat' in terms of 'eat' if the supplied food is the right one. Otherwise, we have the conditions of a CAT call and raise an exception.

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we '''do not address the problems of CAT calls through genericity and change of export status'''. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Interestingly, the approach can be used to model any change of signature, including covariant, contravariant arguments, covariant and contravariant return types and even the change of existing or the introduction of new arguments. It is thus more powerful than the covariant mechansims available in Eiffel.

Talk:Forget / Keep Mechanism

2007-02-21T14:45:24Z

Schoelle:

Ouch, this seems to produce many problems. Specially the introduction of all these parameters for types. Also, I am not sure that this approach is sound and modular. It also looks difficult to teach. --[[User:Schoelle|Schoelle]] 15:45, 21 February 2007 (CET)

Covariance through renaming

2007-02-21T14:43:30Z

Schoelle: /* Discussion */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

We have renamed 'eat' to 'animal_eat', to create space for a different feature 'eat' that is adequate for cows. We implement 'animal_eat' in terms of 'eat' if the supplied food is the right one. Otherwise, we have the conditions of a CAT call and raise an exception.

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we do not address the problems of CAT calls through genericity and change of export status. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Interestingly, the approach can be used to model any change of signature, including covariant, contravariant arguments, covariant and contravariant return types and even the change of existing or the introduction of new arguments. It is thus more powerful than the covariant mechansims available in Eiffel.

Covariance through renaming

2007-02-21T14:40:57Z

Schoelle: /* Solution 1: explicit exception */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

We have renamed 'eat' to 'animal_eat', to create space for a different feature 'eat' that is adequate for cows. We implement 'animal_eat' in terms of 'eat' if the supplied food is the right one. Otherwise, we have the conditions of a CAT call and raise an exception.

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we do not address the problems of CAT calls through genericity and change of export status. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Covariance through renaming

2007-02-21T14:32:41Z

Schoelle: /* Example */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we do not address the problems of CAT calls through genericity and change of export status. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Covariance through renaming

2007-02-21T14:31:49Z

Schoelle: /* Example */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening of the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we do not address the problems of CAT calls through genericity and change of export status. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Covariance through renaming

2007-02-21T14:30:51Z

Schoelle: /* Discussion */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening of the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also to to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Also, we do not address the problems of CAT calls through genericity and change of export status. These problems need a different treatment (for example though the restriction of the interface though readonly types).

Covariance through renaming

2007-02-21T14:25:14Z

Schoelle: /* Example */

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call? The error comes from strengthening of the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also to to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Covariance through renaming

2007-02-21T14:22:34Z

Schoelle:

{{Warning|'''Warning''': Article under development}}

Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

== Example ==

A class ANIMAL defines a command called 'eat' with an argument 'food':

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Eating
eat (f: FOOD) is
require
not_void: f /= Void
do
last_food := f
ensure
last_food = f
end
end
</e>

And we introduce the food class:

<e>
interface class
FOOD

feature -- Access
is_vegetarian: BOOLEAN
end
</e>

Now we want to model the fact that cows only eat grass, a vegetarian food.

<e>
class
COW

inherit
ANIMAL
redefine
eat
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

<e>
interface class
GRASS

inherit
FOOD

invariant
grass_is_vegetarian: is_vegetarian
end
</e>

We have a potential CAT call, as we can regard a COW as an ANIMAL. An ANIMAL can be fed with any food:

<e>
local
a_cow: COW
a_animal: ANIMAL
do
create a_cow
an_animal := a_cow
an_animal.eat (create {FOOD}) -- CAT call!
end
</e>

What is the origin of the CAT call ? The error comes from a strengthening of the precondition of eat through the type system. The precondition of ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition of COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.

It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also to to a COW' (modification) relation.

== Solution 1: explicit exception ==

We start by clearly stating through the code when a CAT call happens. This solution does not require any further thinking and could be regarded as a ''flattened'' form of covariance (though this should be rejected, as this would take away the benefits of making exceptions explicit).

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat
end

feature -- Eating
eat (g: GRASS) is
require
not_void: g /= Void
do
last_food := g
ensure
last_food = f
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f
if g /= Void then
eat (g)
else
raise (1,"CAT call")
end
end

invariant
only_eats_vegetarian: last_food.is_vegetarian
end
</e>

The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.

== Solution 2: stronger precondition ==

The deeper insight is that ANIMAL is not a correct model of an animal. The contract is too weak: we know from reality that not every animal will eat every food. Animals are picky. We model this by a test predicate that checks if the animal will actually like our food.

<e>
class
ANIMAL

feature -- Access
last_food: FOOD

feature -- Status report

likes (f: FOOD): BOOLEAN is
require
not_void: f /= Void
do
Result := True
end

feature -- Eating
eat (f: FOOD) is
require
likes (f)
do
last_food := f
ensure
last_food = f
end
end
</e>

<e>
class
COW

inherit
ANIMAL
rename
eat as animal_eat
redefine
animal_eat,
likes
end

feature -- Status report
likes (f: FOOD): BOOLEAN is
local
g: GRASS
do
g ?= f
Result := (g /= Void)
end

feature -- Eating
eat (g: GRASS) is
do
last_food := g
end

animal_eat (f: FOOD) is
local
g: GRASS
do
g ?= f -- We can assume that this will succeed from the local definition of `likes'.
eat (g)
end

invariant
only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
end
</e>

== Discussion ==

From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.

Talk:Forget / Keep Mechanism

2007-02-21T12:48:57Z

Schoelle:

Ouch --[[User:Schoelle|Schoelle]] 13:48, 21 February 2007 (CET)

Reasons for using Eiffel

2007-01-31T17:18:38Z

Schoelle: /* Reasons for EiffelStudio */

[[Category:General]]
The step away from the main stream of languages is a difficult one. Leaving common ground is worrying. There is always the need to justify unorthodox decisions. This page tries to capture reasons to convince you, your friends, you boss, your client or your grandmother to use Eiffel and EiffelStudio.

You can also read the following articles from Eiffel Software for more reasons:
* [http://docs.eiffel.com/eiffelstudio/general/guided_tour/other/why_eiffel.html Why your next project should use Eiffel]
* [http://docs.eiffel.com/eiffelstudio/general/guided_tour/other/one_minute.html 1-Minute Summary]

== Reasons for Eiffel ==

; Eiffel is object-oriented : While you might think that every modern language is calls itself object-oriented, there are very few languages that have the object-oriented paradigm so deeply integrated into the language as in Eiffel. Eiffel was built around object-orientation. Objects just feel right in Eiffel. Contracts make you understand inheritance. Even if you will change to another language later, object-orientation will never be the same to you once you have developed in Eiffel.

; Eiffel is fast : Eiffel compiles to C, which is then directly translated to the machine code of your target platform. With that you can exploit the full speed of your target architecture. Eiffel can be used in embedded environments or on mainframes. Eiffel competes with C and C++ in terms of speed, not with Java or C#.

; Eiffel has a garbage collector : Memory management is very error prone. Detecting memory leaks is a tedious job that can endanger the reliability of the application. Eiffel was designed from the start to be a language that uses garbage collection. That way, developers do not have to free memory explicitly. EiffelStudio offers a fast moving garbage collector.

; Eiffel is mature : Development on Eiffel started in 1985, long before Java (1991) or C# (2001). During more than two decades, Eiffel has been constantly improved and revised.

; Eiffel is standard : Eiffel is standardized by ECMA standard 367, ISO/IEC DIS 25436

; Eiffel is strongly typed : Eiffel offers a static type system. By this, it can detect conceptual errors much easier than with language with a weak or no type system like C++ or Smalltalk.

; Eiffel has powerful constructs : Eiffel offers constructs like generics (somewhat like Templates) or agents (also known as delegates), constructs that were only recently added to Java 1.5 or C# 2.0. Also, Eiffel has some unique concepts like Design by Contract or full-featured multiple inheritance.

; Eiffel is highly portable : EiffelStudio has been ported to nearly all major operating systems, from Windows, MacOS X, Linux, FreeBSD to VMS. Portable libraries like EiffelVision2 make it possible to write applications for one platform and compile it for any other platform.

; Eiffel is built on 'Design by Contract' : Design by Contract (DbC) is what made Eiffel famous. Using DbC, you can clearly define what your implementation expects from and what it provides to the caller. This behavior is checked at run-time, making it much easier to find bugs. The contracts are also used from documentation and play an important role for inheritance.

== Reasons for EiffelStudio ==

; EiffelStudio is open-source : EiffelStudio has been released under the well-known Gnu Public License, making sure that the source code will be available in the future and giving you the power to read and modify the system if you need.

; EiffelStudio is supported by a company : Eiffel Software remains the driving force behind EiffelStudio. A horde of full-time employees are working to improve EiffelStudio, react on you questions and provide commercial support if needed.

; EiffelStudio has a power IDE : EiffelStudio features everything that you can expect from a modern IDE, starting with syntax highlighting, organization of your classes, interface extraction of features and classes, hypertext-like browsing, refactoring, and many more.

; EiffelStudio offers incremental compilation : Changed just a single line in your huge system ? No need to wait for minutes or even hours for a recompilation. Even for a million lines of code, recompilation is a matter of seconds.

; EiffelStudio adds run-time checking : Run-time checks of contracts and assertions are an inherit part of Design by Contract. With EiffelStudio, you get a tool for enabling efficient checks for just parts, or for the full system. Problems get reported where they happen, when they happen.

; EiffelStudio has a powerful interactive debugger : The IDE integrates a full-featured debugger that makes it easy to trace what is really happening during execution.

; EiffelStudio allows you to draw UML and BON diagrams : Sometimes a picture can say more than a 1000 words. EiffelStudio integrates an interactive tool to draw UML and BON diagrams. The tool features full round-trip engineering: Any change in the diagram is directly reflected in the code, and any change in the code is directly reflected in the diagram. So, your diagrams never become outdated.

Reasons for using Eiffel

2007-01-31T17:18:01Z

Schoelle: /* Reasons for EiffelStudio */ Some reasons for EiffelStudio added.

[[Category:General]]
The step away from the main stream of languages is a difficult one. Leaving common ground is worrying. There is always the need to justify unorthodox decisions. This page tries to capture reasons to convince you, your friends, you boss, your client or your grandmother to use Eiffel and EiffelStudio.

You can also read the following articles from Eiffel Software for more reasons:
* [http://docs.eiffel.com/eiffelstudio/general/guided_tour/other/why_eiffel.html Why your next project should use Eiffel]
* [http://docs.eiffel.com/eiffelstudio/general/guided_tour/other/one_minute.html 1-Minute Summary]

== Reasons for Eiffel ==

; Eiffel is object-oriented : While you might think that every modern language is calls itself object-oriented, there are very few languages that have the object-oriented paradigm so deeply integrated into the language as in Eiffel. Eiffel was built around object-orientation. Objects just feel right in Eiffel. Contracts make you understand inheritance. Even if you will change to another language later, object-orientation will never be the same to you once you have developed in Eiffel.

; Eiffel is fast : Eiffel compiles to C, which is then directly translated to the machine code of your target platform. With that you can exploit the full speed of your target architecture. Eiffel can be used in embedded environments or on mainframes. Eiffel competes with C and C++ in terms of speed, not with Java or C#.

; Eiffel has a garbage collector : Memory management is very error prone. Detecting memory leaks is a tedious job that can endanger the reliability of the application. Eiffel was designed from the start to be a language that uses garbage collection. That way, developers do not have to free memory explicitly. EiffelStudio offers a fast moving garbage collector.

; Eiffel is mature : Development on Eiffel started in 1985, long before Java (1991) or C# (2001). During more than two decades, Eiffel has been constantly improved and revised.

; Eiffel is standard : Eiffel is standardized by ECMA standard 367, ISO/IEC DIS 25436

; Eiffel is strongly typed : Eiffel offers a static type system. By this, it can detect conceptual errors much easier than with language with a weak or no type system like C++ or Smalltalk.

; Eiffel has powerful constructs : Eiffel offers constructs like generics (somewhat like Templates) or agents (also known as delegates), constructs that were only recently added to Java 1.5 or C# 2.0. Also, Eiffel has some unique concepts like Design by Contract or full-featured multiple inheritance.

; Eiffel is highly portable : EiffelStudio has been ported to nearly all major operating systems, from Windows, MacOS X, Linux, FreeBSD to VMS. Portable libraries like EiffelVision2 make it possible to write applications for one platform and compile it for any other platform.

; Eiffel is built on 'Design by Contract' : Design by Contract (DbC) is what made Eiffel famous. Using DbC, you can clearly define what your implementation expects from and what it provides to the caller. This behavior is checked at run-time, making it much easier to find bugs. The contracts are also used from documentation and play an important role for inheritance.

== Reasons for EiffelStudio ==

; EiffelStudio is open-source : EiffelStudio has been released under the well-known Gnu Public License, making sure that the source code will be available in the future and giving you the power to read and modify the system if you need.

; EiffelStudio is supported by a company : Eiffel Software remains the driving force behind EiffelStudio. A horde of full-time employees are working to improve EiffelStudio, react on you questions and provide commercial support if needed.

; EiffelStudio has a power IDE : EiffelStudio features everything that you can expect from a moder IDE, starting with syntax highlighting, organization of your classes, interface extraction of features and classes, hypertext-like browsing, refactoring, and many more.

; EiffelStudio offers incremental compilation : Changed just a single line in your huge system ? No need to wait for minutes or even hours for a recompilation. Even for a million lines of code, recompilation is a matter of seconds.

; EiffelStudio adds run-time checking : Run-time checks of contracts and assertions are an inherit part of Design by Contract. With EiffelStudio, you get a tool for enabling efficient checks for just parts, or for the full system. Problems get reported where they happen, when they happen.

; EiffelStudio has a powerful interactive debugger : The IDE integrates a full-featured debugger that makes it easy to trace what is really happening during execution.

; EiffelStudio allows you to draw UML and BON diagrams : Sometimes a picture can say more than a 1000 words. EiffelStudio integrates an interactive tool to draw UML and BON diagrams. The tool features full round-trip engineering: Any change in the diagram is directly reflected in the code, and any change in the code is directly reflected in the diagram. So, your diagrams never become outdated.

User:Trosim

2007-01-18T21:49:03Z

Schoelle:

There should not be a red link here!

Identifier: Martino Trosi
Computer science branch: web, database
Preferred linux-box: Gentoo

''I got doly fan is mach!''

I am involved in the following projects:

* [[Internationalization]]
* [[Build tool]]

User:Trosim

2007-01-18T21:48:57Z

Schoelle:

Build tool

2007-01-18T21:43:23Z

Schoelle:

[[Category:Projects]]

== Overview ==

The whole build process of EiffelStudio is rather tedious at the moment. This project aims to simplify this by various means:

* Tight integration of '''GOBO geant''' into the build process
* '''Setup checker''' - a script that checks that the current development environment is correctly setup for the development on EiffelStudio
* Fully automated '''build scripts''' that enable the compilation of the runtime, libraries and EiffelStudio with a single command
* Automatic generation of an '''Eiffel delivery''' from a successful compilation, including all necessary tools

This will lead to a better overall build infrastructure, automated (nightly) builds, and things alike. We work on our own branch of the sourcecode, but will sync it from time to time with the EiffelStudio SVN trunk.

Other goals of the effort include:

* Transition of EiffelStudio from GOBO 3.4 to a more current GOBO release.
* Extension of geant tasks as seen necessary.
* Minimization of foreign software tools required for the compilation.
** Specially to get rid of the dependency on Cygwin on Windows.
* Production a one-click-and-go script for easy installation and compilation.

We aim to have a compact build process by using only Eiffel related tools (mainly geant scripts).

== Current Status ==

There are already a number of GEANT scripts available in the 'scripts' directory. These scripts cover compilation of EiffelStudio, the runtime and the libraries. An existing GOBO installation will be used if available. The setup checker script checks for major problems in the setup.

== Todo ==

* makefile/batchfile for getting the installation started (for users unexperienced with gobo/geant)
* expand setup-checker
** find more dependencies on windows
* automatical use of existing gobo-installations
* full migration of the tree to current GOBO
* building a delivery

== Team ==

* [[User:schoelle]]
* [[User:sanakan]]
* [[User:trosim]]
* [[User:jfiat]]

User:Schoelle

2007-01-18T21:39:47Z

Schoelle:

Homepage: http://se.inf.ethz.ch/people/schoeller

I am involved in the following projects:

* [[Internationalization]]
* [[Build tool]]

Build tool

2007-01-18T21:30:26Z

Schoelle: /* Overview */

[[Category:Projects]]

== Overview ==

The whole build process of EiffelStudio is rather tedious at the moment. This project aims to simplify this by various means:

* Tight integration of '''GOBO geant''' into the build process
* '''Setup checker''' - a script that checks that the current development environment is correctly setup for the development on EiffelStudio
* Fully automated '''build scripts''' that enable the compilation of the runtime, libraries and EiffelStudio with a single command
* Automatic generation of an '''Eiffel delivery''' from a successful compilation, including all necessary tools

This will lead to a better overall build infrastructure, automated (nightly) builds, and things alike. We work on our own branch of the sourcecode, but will sync it from time to time with the EiffelStudio SVN trunk.

Other side-products of the effort are:

* Transition of EiffelStudio from GOBO 3.4 to a more current GOBO release
* Extension of geant tasks

== Goals ==
We aim to have a compact build process by using only Eiffel related tools (mainly geant scripts) and thus minimizing the needed (alien) tools to get an EiffelStudio compilation going.

== Steps ==
* produce a one-click-and-go script for easy installation
* get rid of windows dependency for bash
* remove script-only tools like finish_freezing, Makefile.sh, etc.

== Done ==

* first draft of geant scripts to build c-libraries
* first draft of setup-checker tool

== Milestones ==

== Todo ==
* makefile/batchfile for getting the installation started (for users unexperienced with gobo/geant)
* expand setup-checker
** find more dependencies on windows
* automatical use of existing gobo-installations

== Team ==

Contributors

2006-12-03T12:41:50Z

Schoelle: Removed unnecessary disclaimer

[[Category:Contributions]]
Welcome to the contributors page. You will find here names of people that we would like to thank for their contribution.

To have your name here, start contributing. The best place to start is to look at the [[Open_Projects| list of open projects]] we have, or the list of all [[:Category:Projects|projects]].

==Top Contributors==

==Contributors==
* '''Sébastien Bernard''' is providing his [http://sunsolve.sun.com/handbook_pub/Systems/U60/U60.html Ultra 60] workstation for porting EiffelStudio on Linux-sparc.
* '''Francesco Ferreri''' is taking care of the port for FreeBSD 64-bit on AMD64.
* '''David Hollenberg''' is the creator of '''[[Eweasel|eweasel]]''', the regression test tool used for the Eiffel Software compiler.
* '''Raphael Manfredi''' was the inventor of the Eiffel runtime as we know it today. He also contributed '''jmake''' which is still used by the runtime to produce portable Makefiles.

Talk:Main Page

2006-11-30T08:36:54Z

Schoelle: Removed old talk

'''--[[User:Juliant|Juliant]] 23:22, 28 November 2006 (CET)'''

Just that it doesn't get forgotten and since someone of the admins has to change navigation I post this here again (From [[Talk:New Main Page]]):

Also a new page logo (at least withouth the white border) and a new navigation would look better. I would split the navigation to a 'normal navigation' part and a 'developers' part (see below).

Navigation proposal:

* Navigation
** Home (not sure if this is needed because the logo alredy points to the main page)
** Categories
** Downloads
** Version history
** FAQ
** Mailing lists
** Eiffel links

* Developement
** Recent changes
** Changelog of 6.x
** SVN repository
** Compiling
** How to contribute

Talk:Agent problems

2006-11-21T08:26:10Z

Schoelle:

== Is CAT Call ==

First comment: I assume you are missing a 'l_f := f'.

Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'. --[[User:Schoelle|Schoelle]] 09:26, 21 November 2006 (CET)

Reasons for using Eiffel

2006-11-20T13:27:16Z

Schoelle: /* Reasons for Eiffel */

Reasons for using Eiffel

2006-11-20T13:26:03Z

Schoelle: /* Reasons for Eiffel */

Reasons for using Eiffel

2006-11-20T13:23:56Z

Schoelle: /* Reasons for Eiffel */

Reasons for using Eiffel

2006-11-20T13:21:49Z

Schoelle:

Reasons for using Eiffel

2006-11-20T13:19:23Z

Schoelle: /* Reasons for Eiffel */ More reasons

[[Category:General]]
The step away from the main stream of languages is a difficult one. Leaving common group makes one feel insecure. There is always the need to justify unorthodox decisions. This page tries to capture reasons to convince you, your friends, you boss, your client or your grandmother to use Eiffel and EiffelStudio.

== Reasons for Eiffel ==

; Eiffel is object-oriented : While you might think that every modern language is calls itself object-oriented, there are very few languages that have the object-oriented paradigm so deeply integrated into the language as in Eiffel. Eiffel was built around object-orientation. Objects just feel right in Eiffel. Contracts make you understand inheritance. Even if you will change to another language later, object-orientation will never be the same to you once you have developed in Eiffel.

; Eiffel is fast : Eiffel compiles to C, which is then directly translated to the machine code of your target platform. With that you can exploit the full speed of your target architecture. Eiffel can be used in embedded environments, in

; Eiffel has a garbage collector : Memory management is very error prone. Detecting memory leaks is a tedious job that can endanger the reliability of the application. Eiffel was designed from the start to be a language that uses garbage collection. That way, developers do not have to free memory explicitly. EiffelStudio offers a fast moving garbage collector.

; Eiffel is mature : Development on Eiffel started in 1985, long before Java (1991) or C# (2001). During more than two decades, Eiffel has been constantly improved and revised.

; Eiffel is standard : Eiffel is standarized by ECMA standard 367, ISO/IEC DIS 25436

; Eiffel is strongly typed : Eiffel offers strongly typed. By this, it can detect conceptual errors much easier than C++ or Smalltalk.

; Eiffel has powerful constructs : Eiffel offers constructs like generics (somewhat like Templates) or agents (also known as delegates), constructs where have only recently been added to Java 1.5 or C# 2.0. Also, Eiffel has some unique concepts like Design by Contract or full-featured multiple inheritance.

; Eiffel is highly portable : EiffelStudio has been ported to nearly all major operating systems, from Windows, MacOS X, Linux, FreeBSD to VMS. Protable libraries like EiffelVision2 make it possible to write applications for one platform and compile it for any other platform.

; Eiffel is built on 'Design by Contract' : Design by Contract (DbC) is what made Eiffel famous. Using DbC, you can clearly define what your implementation expects from and what it provides to the caller. This behavior is checked at run-time, making it much easier to find bugs. The contracts are also used from documentation and play an important role for inheritance.

== Reasons for EiffelStudio ==

; EiffelStudio is open-source : ...

; EiffelStudio is supported by a company : ...

; EiffelStudio has a power IDE : ...

; EiffelStudio offers incremental compilation : ...

; EiffelStudio adds run-time checking : ...

; EiffelStudio has a powerful interactive debugger : ...

; EiffelStudio allows you to draw UML and BON diagrams : ...

Mailing Lists

2006-11-19T10:20:29Z

Schoelle: Made the archive more explicit

Here are the various mailing lists you can subscribe to at http://origo.ethz.ch/cgi-bin/mailman/listinfo:
* es-announce@origo.ethz.ch: Announcement (moderated, low traffic)
* es-users@origo.ethz.ch: It is intended for all users of EiffelStudio and its libraries.
* es-devel@origo.ethz.ch: It is intended for all developers of EiffelStudio and its libraries.
* es-changes@origo.ethz.ch: It is intended for those who wants the evolution of the software on a daily basis.

In addition of all those mailing lists, you may find project's specific mailing lists. Consult http://origo.ethz.ch/cgi-bin/mailman/listinfo for the complete list.

== Archive ==

You can read old postings of the mailinglists in the archives:

* es-users@origo.ethz.ch: [news://origo.ethz.ch/eiffel.eiffelstudio.users Newsgroup] [http://www.nabble.com/Eiffel-Software-Users-f16963.html Nabble.com]
* es-devel@origo.ethz.ch: [news://origo.ethz.ch/eiffel.eiffelstudio.devel Newsgroup] [http://www.nabble.com/Eiffel-Software-Development-f16977.html Nabble.com]

Main Page

2006-11-17T22:57:41Z

Schoelle: typos

__NOTOC__

<div align="center"><font size="+2">EiffelStudio Integrated Development Environment</font></div><br/>

[[Image:EiffelStudioScreenshot.png|thumb|250px|right|GUI of the EiffelStudio IDE ([http://eiffel.com/products/studio/screenshots.html more screenshots]) ]]

Welcome to the homepage and Wiki of the EiffelStudio IDE open-source project. EiffelStudio is a full-featured, commercial grade IDE for the [http://en.wikipedia.org/wiki/Eiffel_programming_language Eiffel programming language]. It is maintained and developed mostly by [http://www.eiffel.com Eiffel Software Inc.] and hosted at the [http://se.inf.ethz.ch/ Chair of Software Engineering] at the [http://www.ethz.ch/ ETH Zurich].

On April 5th, 2006, Eiffel Software relicensed the EiffelStudio product under the [[Gnu Public License]]. Eiffel Software still offers a commercial variant. Both versions share the same source code.

EiffelStudio is a modern IDE that offers the following features:

* Complete and efficient compiler for the Eiffel programming language
* Support for Windows, MacOS X, Linux, *BSD, Solaris and other operating systems
* Editor for Eiffel code
* Different browsing and viewing facilities
* Interactive debugger
* Graphical modelling tool for UML and BON with full roundtrip
* Refactoring support
* GUI development tool and fully portable GUI library

The Eiffel compiler creates C code that is then handed to a standard C compiler. As a result, the programs have a performance comparable to programs directly written in C or C++. At the same time, Eiffel is an object-oriented and strongly typed language. EiffelStudio uses a highly efficient moving garbage collector to free the developer from the burden of memory management.

<center>If you want to know more about the unique features of Eiffel and EiffelStudio, check out our [[Reasons for using Eiffel]] page.</center>

{|style="font-size:80%;" bgcolor=white|
{| cellspacing=3 width="100%"
|- valign="top"
|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|

== Getting Started ==

* [[Downloads]]
* [[EiffelStudio 5.7 Releases|Changelog of 5.7 (release branch)]]
* [[Installing EiffelStudio]]
* [[Compiling Hello World]]
|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|
== Working with EiffelStudio ==

* [[Frequently Asked Questions]]
* [[Eiffel Glossary]]
* [[Eiffel Compilation Explained]]
* [[EiffelStudio Wish List]]
|}
{|style="font-size:80%;" bgcolor=white|
{| cellspacing=3 width="100%"
|- valign="top"
|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|
== EiffelStudio's Development ==

* [[EiffelStudio 6.0 Releases|Changelog of 6.x (development trunk)]]
* [[Repository|Getting the source: Subversion repository]]
* [[Compiling EiffelStudio]]
* [[Contributing|How to contribute]]
* [[:Category:Projects|Projects]]

|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|

== Community ==

* [[Eiffel Sites and Links]]
* [[Mailing Lists]]
|}

Main Page

2006-11-17T22:52:54Z

Schoelle: Replaced by new main page

__NOTOC__

<div align="center"><font size="+2">EiffelStudio Integrated Development Environment</font></div><br/>

[[Image:EiffelStudioScreenshot.png|thumb|250px|right|GUI of the EiffelStudio IDE ([http://eiffel.com/products/studio/screenshots.html more screenshots]) ]]

Welcome to the homepage and Wiki of the EiffelStudio IDE open-source project. EiffelStudio is a full-features, commercial grade IDE for the [http://en.wikipedia.org/wiki/Eiffel_programming_language Eiffel programming language]. It is maintained and developed mostly by [http://www.eiffel.com Eiffel Software Inc.] and hosted at the [http://se.inf.ethz.ch/ Chair of Software Engineering] at the [http://www.ethz.ch/ ETH Zurich].

On April 5th, 2006, Eiffel Software relicensed the EiffelStudio product under the [[Gnu Public License]]. Eiffel Software still offers a commercial variant. Both versions share the same source code.

EiffelStudio is a modern IDE that offers the following features:

* Complete and efficient compiler for the Eiffel programming language
* Support for Windows, MacOS X, Linux, *BSD, Solaris and other operating systems
* Editor for Eiffel code
* Different browsing and viewing facilities
* Interactive debugger
* Graphical modelling tool for UML and BON with full roundtrip
* Refactoring support
* GUI development tool and fully portable GUI library

The Eiffel compiler creates C code that is then handed to a standard C compiler. As a result, the programs have a performance comparable to programs directly written in C or C++. At the same time, Eiffel is an object-oriented and strongly typed language. EiffelStudio uses a highly efficient moving garbage collector to free the developer from the burden of memory management.

<center>If you want to know more about the unique features of Eiffel and EiffelStudio, check out our [[Reasons for using Eiffel]] page.</center>

{|style="font-size:80%;" bgcolor=white|
{| cellspacing=3 width="100%"
|- valign="top"
|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|

== Getting Started ==

* [[Downloads]]
* [[EiffelStudio 5.7 Releases|Changelog of 5.7 (release branch)]]
* [[Installing EiffelStudio]]
* [[Compiling Hello World]]
|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|
== Working with EiffelStudio ==

* [[Frequently Asked Questions]]
* [[Eiffel Glossary]]
* [[Eiffel Compilation Explained]]
* [[EiffelStudio Wish List]]
|}
{|style="font-size:80%;" bgcolor=white|
{| cellspacing=3 width="100%"
|- valign="top"
|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|
== EiffelStudio's Development ==

* [[EiffelStudio 6.0 Releases|Changelog of 6.x (development trunk)]]
* [[Repository|Getting the source: Subversion repository]]
* [[Compiling EiffelStudio]]
* [[Contributing|How to contribute]]
* [[:Category:Projects|Projects]]

|width="50%" bgcolor="#ededed" style="border:1px solid #8f8f8f;padding:.4em;padding-top:0.5em;"|

== Community ==

* [[Eiffel Sites and Links]]
* [[Mailing Lists]]
|}